Bring the handling of <keygen> and support for the application/x-x509-user-ce...

Bring the handling of <keygen> and support for the application/x-x509-user-cert mime-type to parity with Mozilla's implementation.

For <keygen>:
  On Windows, you may use <keygen> in one browsing session, completely close the browser, and later import a certificate supplied by application/x-x509-user-cert. Previously, you could only download certificates in direct response to a <keygen> element, during the same browsing session. This matches the Linux and Mac implementations, which allow you to import them at any time.

X509Certificate/CertDatabase/X509UserCertResourceHandler
  Support for parsing PEM chains, PKCS#7 data (PEM armored or DER), and Netscape certificate sequences (PEM armored or DER) has been added. Additional certificates that are supplied will be imported by CertDatabase, provided that they are valid CA certificates and properly chain to a trusted root certificate on the user's machine. 

BUG=37142
BUG=148
TEST=X509CertificateParseTest.*
TEST=KeygenHandlerTest.SmokeTest
TEST=PEMTokenizer.*

[rsleevi-old, 2010-06-06 22:30:45]

Wan-Teh,

Here's the drop of support for PEM, PKCS#7, and Netscape cert sequences for
Linux/Mac/Win. As mentioned via e-mail, the Mac support has been developed
blind, as I don't have a suitable Mac dev environment. As I don't have SVN
access, I can't push to the trybots either, so it's something I'd encourage
before you get too far in the review.

I've tried to follow the style guide as closely as I can, with my biggest
concerns being:
  - Have I wrapped the lines appropriately
  - Should ImportIntermediates of CertDatabase be exposed as a member to the
interface of CertDatabase, given that it's the same signature and same name
across all three platforms, or is it appropriate to keep it local, as I have
currently done.

While I've mentioned it in the code comments, given that it affects the UX
substantially, I feel it bears mentioning again: Only intermediates that chain
to a currently trusted root certificate will be imported. 

There still remain a few TODOs, even after this drop, that I'm investigating:

1) CertDatabase.AddUserCert() may now take more time, as it involves locating
keys (potentially enumerating all smart cards/keychains/etc)  and both
constructing and validating chains (though revocation checking/root cert
updating is disabled, presently). Currently, this is running on the UI thread
(see chrome\browser\ssl_add_cert_handler.h), which means it almost certainly
needs to be moved to the IO thread
2) In chrome\browser\ssl_add_cert_handler, support for prompting the user prior
to importing needs to implemented for Windows and GTK. This probably needs to be
spun into it's own issue.
3) Related to #2, further work must be done to display the intermediate
certificates which will also be imported in that same UI. Simply displaying the
chain for the primary certificate is not sufficient, as it's perfectly valid
(and I can find references to it being used as such) to return multiple chain
paths in the application/x-x509-user-cert, so presumably the user should be
prompted.

[rsleevi-old, 2010-06-19 19:44:10]

This has been split into
http://codereview.chromium.org/2809024/show
http://codereview.chromium.org/2874002/show
http://codereview.chromium.org/2843015/show

for the minor issues. I'm closing this out and will be splitting the parsing and
the importing into two separate reviews. This is because there is a bug in how
this interacts with the X509Certificate::Cache that can result in
server-supplied certificate chains either being ignored (because the user has an
alternative-but-longer chain) or replacing the user-supplied-chain for client
authentication (because the user chain is replaced by the longer, but not as
high quality, system chain).

While |intermediates| is merely advisory now, and thus this bug would only
affect parsing, when coupled with http://codereview.chromium.org/2828002/show,
it could severely interfere with client auth.