Move chain building/verification out of X509Certificate

Move chain building/verification out of X509Certificate

This is the second part of a multi-part refactor. This moves X509Certificate::Verify() into a new namespace and static method, x509_chain::VerifySSLServer().

This has a light dependency upon http://codereview.chromium.org/2944008/show , to reduce conflicts related to moving the code.

[Ryan Sleevi, 2010-08-16 08:50:50]

Overall, the remaining changes that fit into this proposed namespace/refactor:

1) General
- CertVerifyResult optionally including the constructed certificate chain

2) Used by CertDatabase's AddUserCert for x-x509-user-cert handling (Depends
   on 1)
- VerifyBasic([List of extra untrusted certs]) - Perform basic validation
  checks, without requiring any particular policy.
- VerifyCA([List of extra untrusted certs]) - Verify a certificate chain can be
  created and validated, performing basic validation checks and ensuring the
  basicConstraints CA flag is valid, whether it is explicitly present or if it
  is implicit

3) Used to clean up client authentication (Depends on 1)
- VerifySSLClient([List of CAs], [List of extra untrusted certs]) - Verify a
  certificate chain can be created for a given certificate for SSL client auth,
  and that it is issued by one of the CAs in the list.
  * Affects: X509Certificate::SupportsSSLClientAuth()
             X509Certificate::CreateSSLClientPolicy()
             X509Certificate::CreateClientCertificateChain()
- CertDatabase::GetSSLClientCertificates([List of CAs], [List of extra
  untrusted certs]) - Get all available certificates that can be used for
  client authentication. For OS X/NSS, this will involve calls to
  VerifySSLClient(), while for Windows, it's not necessary.
  * Affects: X509Certificate::GetSSLClientCertificates()
             SSLClientSocket[NSS/Mac/Win] routines for client certs

4) Further client auth cleanup (Depends on 3)
- RFC 3280 compliant name validation for OS X and NSS (using NSS's compliant
  name routines)
  * Affects: VerifySSLClient()

5) CertVerifier changes to support the newly introduced routines
   asynchronously

My intent in moving this out is to make X509Certificate deal with single
certificates, and primarily focus on display/presentation (eg: CertPrincipal),
and keep chain building (which has many similar paths with small variants) a
separate task for the few places that care about it.

This was originally part of http://codereview.chromium.org/2934014/show, which
integrated everything so as to present what the end refactor would look like.
I'm in the process of breaking up into several components, with this just being
some simple shuffling with no semantic changes. 

What I'm unsure with this API is whether it is appropriate to go with the
(proposed) 4 static methods for verification, or if policies and purposes
should instead be expressed through some sort of object hierarchy. The purpose
of such a design would solely be for CertVerifier's sake, so that it would only
need to call a single method. Since each of the Verify*() methods may end up
blocking needing to do IO (AIA fetches, CRL/OCSP checks), it seems expected
that CertVerifier will be needed to handle x-x509-user-cert chain building.

My concern with and avoidance of trying to fit it all under one function
call, or under a constructed object hierarchy, is that it can very easily
introduce a lot of complication for what is, for our intents and purposes,
some very simple calls. That said, if you would rather see a "ChainVerifier"
or "ChainBuilder", which exposes a single virtual Verify() method, and for
which the above policies (Basic, SSL, CA) derive from, let me know.

[bulach, 2010-10-21 10:21:32]

sorry, forgot to press 'm' here.. :(

some general nits:

http://codereview.chromium.org/3112013/diff/18001/19008
File net/base/x509_chain.h (right):

http://codereview.chromium.org/3112013/diff/18001/19008#newcode25
net/base/x509_chain.h:25: // given |hostname|. against the given hostname. 
Returns OK if successful
s/against the given hostname.//

http://codereview.chromium.org/3112013/diff/18001/19010
File net/base/x509_chain_nss.cc (right):

http://codereview.chromium.org/3112013/diff/18001/19010#newcode53
net/base/x509_chain_nss.cc:53: for (CERTValOutParam *p = cvout_; p->type !=
cert_po_end; p++) {
nits:
s/CERTValOutParam */CERTValOutParam* /
s/p++/++p/

http://codereview.chromium.org/3112013/diff/18001/19010#newcode157
net/base/x509_chain_nss.cc:157: node = CERT_LIST_NEXT(node), i++) {
nit: ++i

http://codereview.chromium.org/3112013/diff/18001/19010#newcode285
net/base/x509_chain_nss.cc:285: cvin.reserve(5);
nit: not sure why 5 as there are three push_back below.. if relevant, it may be
clearer to have a 
const int kExplainWhyHere = 5; of some kind.

http://codereview.chromium.org/3112013/diff/18001/19010#newcode469
net/base/x509_chain_nss.cc:469: cvout_index++;
nit: ++cvout_index;

http://codereview.chromium.org/3112013/diff/18001/19011
File net/base/x509_chain_win.cc (right):

http://codereview.chromium.org/3112013/diff/18001/19011#newcode226
net/base/x509_chain_win.cc:226: DWORD num_wchars = rdn_attr->Value.cbData / 2;
nit: const DWORD kNumWChars

http://codereview.chromium.org/3112013/diff/18001/19011#newcode237
net/base/x509_chain_win.cc:237: DWORD num_ints = rdn_attr->Value.cbData / 4;
nit: const DWORD kNumInts

http://codereview.chromium.org/3112013/diff/18001/19011#newcode263
net/base/x509_chain_win.cc:263: int num_elements = first_chain->cElement;
nit: const kNumElements

http://codereview.chromium.org/3112013/diff/18001/19011#newcode306
net/base/x509_chain_win.cc:306: CERT_CHAIN_PARA chain_para;
can remove the memset with:

CERT_CHAIN_PARA chain_para = {0};

http://codereview.chromium.org/3112013/diff/18001/19011#newcode366
net/base/x509_chain_win.cc:366: for (int i = 0; i < num_policies; i++) {
nit: ++i

http://codereview.chromium.org/3112013/diff/18001/19011#newcode442
net/base/x509_chain_win.cc:442: memset(&chain_para, 0, sizeof(chain_para));
ditto, = {0};

http://codereview.chromium.org/3112013/diff/18001/19011#newcode469
net/base/x509_chain_win.cc:469: certificate->CreateOSCertListHandle();
there's a bunch of places that CreateOSCertListHandle and then free..
perhaps we could have a helper ScopedOSCertListHandle there?
or provide a functor for FreeOSCertListHandle and a typedef for
scoped_ptr_malloc with it?