Chromium Code Reviews
Help | Chromium Project | Sign in

Issue 10160007: Parse an application/x-x509-user-cert response with (Closed)

Can't Edit
Can't Publish+Mail
Start Review
5 years ago by wtc
5 years ago
Ryan Sleevi, mattm
chromium-reviews,,,, jam


[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)., BUG=37142 TEST=none

Patch Set 1 #

Patch Set 2 : Add back a blank line deleted by accident #

Total comments: 7
Unified diffs Side-by-side diffs Delta from patch set Stats (+35 lines, -2 lines) Patch
M chrome/browser/ssl/ View 1 chunk +4 lines, -0 lines 0 comments Download
M content/browser/renderer_host/ View 1 chunk +15 lines, -2 lines 3 comments Download
M net/base/ View 1 2 chunks +14 lines, -0 lines 4 comments Download
M net/base/ View 1 chunk +2 lines, -0 lines 0 comments Download
Trybot results:
Commit queue not available (can’t edit this change).


Total messages: 4 (0 generated)
mattm: just FYI. rsleevi: this CL is just a proof of concept. It works with ...
5 years ago (2012-04-26 23:11:53 UTC) #1
Ryan Sleevi
I wasn't sure if you meant to commit this or just show it, but NACK ...
5 years ago (2012-04-27 00:55:48 UTC) #2
rsleevi: thank you for your comments. I've updated the CL's description and marked it closed ...
5 years ago (2012-04-27 21:16:49 UTC) #3
Ryan Sleevi
5 years ago (2012-04-27 21:24:21 UTC) #4
File content/browser/renderer_host/ (right):
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

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.
File net/base/ (right):
net/base/ PK11_ImportCert(slot, intermediate_cert,
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,
> > 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.
Sign in to reply to this message.

Powered by Google App Engine
RSS Feeds Recent Issues | This issue
This is Rietveld cc6ac46