Parse an application/x-x509-user-cert response with

[This CL is for reference only.]

Parse an application/x-x509-user-cert response with
net::X509Certificate::CreateCertificateListFromBytes(), which supports
three formats (in particular PKCS #7).

Import the intermediate CA certificates in the response (only implemented
for NSS).

R=rsleevi@chromium.org,mattm@chromium.org
BUG=37142
TEST=none

[wtc, 2012-04-26 23:11:53]

mattm: just FYI.

rsleevi: this CL is just a proof of concept.  It works with
COMODO (which uses the PKCS #7 format).

Please feel free to use any code in this CL.

[Ryan Sleevi, 2012-04-27 00:55:48]

I wasn't sure if you meant to commit this or just show it, but NACK on it =)

Below are notes from the previous investigation into this

https://chromiumcodereview.appspot.com/10160007/diff/6001/content/browser/ren...
File content/browser/renderer_host/x509_user_cert_resource_handler.cc (right):

https://chromiumcodereview.appspot.com/10160007/diff/6001/content/browser/ren...
content/browser/renderer_host/x509_user_cert_resource_handler.cc:115:
intermediate_certs);
note: This is not an accurate interpretation of the results, from what I've
seen. I definitely agree with the comment on 118/119 that a CertificateList
should be threaded through everything

I saw many with either the form of:

Root -> Intermediate -> Client (which Firefox handles)

or
Client -> A1 -> Root(1) -> A2 -> B -> Root(2) [where Root(1) and Root(2) are two
different roots, and A1/A2 are two cross-signed versions of the same cert)

https://chromiumcodereview.appspot.com/10160007/diff/6001/net/base/cert_datab...
File net/base/cert_database_nss.cc (right):

https://chromiumcodereview.appspot.com/10160007/diff/6001/net/base/cert_datab...
net/base/cert_database_nss.cc:43: // here or in the caller?
Presuming a CertificateList, I would assume it's the caller's responsibility.
This would still need to be a single cert.

https://chromiumcodereview.appspot.com/10160007/diff/6001/net/base/cert_datab...
net/base/cert_database_nss.cc:89: PK11_ImportCert(slot, intermediate_cert,
CK_INVALID_HANDLE, nickname,
This is quite dangerous for Linux, in that non-libpkix applications (such as
Firefox) can become confused by cross-signed roots and fail to successfully
build chains.

This is why Firefox ensures a chain can be built for each certificate, before
importing.

[wtc, 2012-04-27 21:16:49]

rsleevi: thank you for your comments.  I've updated the CL's
description and marked it closed to clarify the purpose of
this CL -- to make my proof of concept code available to you.

https://chromiumcodereview.appspot.com/10160007/diff/6001/content/browser/ren...
File content/browser/renderer_host/x509_user_cert_resource_handler.cc (right):

https://chromiumcodereview.appspot.com/10160007/diff/6001/content/browser/ren...
content/browser/renderer_host/x509_user_cert_resource_handler.cc:115:
intermediate_certs);

On 2012/04/27 00:55:48, Ryan Sleevi wrote:
> note: This is not an accurate interpretation of the results, from what I've
> seen.

You mean we cannot assume the first certificate in the
certificate list is the leaf user certificate?  I wasn't
sure if we could depend on this assumption either; it just
happened to be true for COMODO's PKCS #7 response.

https://chromiumcodereview.appspot.com/10160007/diff/6001/net/base/cert_datab...
File net/base/cert_database_nss.cc (right):

https://chromiumcodereview.appspot.com/10160007/diff/6001/net/base/cert_datab...
net/base/cert_database_nss.cc:89: PK11_ImportCert(slot, intermediate_cert,
CK_INVALID_HANDLE, nickname,
On 2012/04/27 00:55:48, Ryan Sleevi wrote:
>
> This is why Firefox ensures a chain can be built for each certificate, before
> importing.

We can copy Firefox's behavior.  This means if client certs
are issued by a private CA that is not in the browser's
trusted root CA list, that private CA has to issue the client
certs directly and can't issue them from an intermediate CA
(because the browser won't import the intermediate CA cert).

[Ryan Sleevi, 2012-04-27 21:24:21]

https://chromiumcodereview.appspot.com/10160007/diff/6001/content/browser/ren...
File content/browser/renderer_host/x509_user_cert_resource_handler.cc (right):

https://chromiumcodereview.appspot.com/10160007/diff/6001/content/browser/ren...
content/browser/renderer_host/x509_user_cert_resource_handler.cc:115:
intermediate_certs);
On 2012/04/27 21:16:50, wtc wrote:
> 
> On 2012/04/27 00:55:48, Ryan Sleevi wrote:
> > note: This is not an accurate interpretation of the results, from what I've
> > seen.
> 
> You mean we cannot assume the first certificate in the
> certificate list is the leaf user certificate?  I wasn't
> sure if we could depend on this assumption either; it just
> happened to be true for COMODO's PKCS #7 response.

Correct. The behaviour of Firefox is to do a first pass scan to see if it
notices issuing order and, if so, reverse if appropriate.

It then checks the first cert for private key possession before continuing.

It then imports the cert (regardless of any secondary trust / issued by known CA
bits)

Then, for each remaining cert in the range [1..i..n], it tries to verify that
cert [i], supplying [i+1..n] as optional intermediates, chains to a
known/trusted root.

https://chromiumcodereview.appspot.com/10160007/diff/6001/net/base/cert_datab...
File net/base/cert_database_nss.cc (right):

https://chromiumcodereview.appspot.com/10160007/diff/6001/net/base/cert_datab...
net/base/cert_database_nss.cc:89: PK11_ImportCert(slot, intermediate_cert,
CK_INVALID_HANDLE, nickname,
On 2012/04/27 21:16:50, wtc wrote:
> On 2012/04/27 00:55:48, Ryan Sleevi wrote:
> >
> > This is why Firefox ensures a chain can be built for each certificate,
before
> > importing.
> 
> We can copy Firefox's behavior.  This means if client certs
> are issued by a private CA that is not in the browser's
> trusted root CA list, that private CA has to issue the client
> certs directly and can't issue them from an intermediate CA
> (because the browser won't import the intermediate CA cert).

What Firefox does is described in my previous comment. It effectively
accomplishes the same thing, in that no intermediates will be imported that do
not chain to a (previously trusted/imported/built-in) root.

That's were my comment about UI behaviour comes in, since there are typically
one or two (such as non-cross-signed root certs) in these bundles.