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

content/browser/renderer_host/x509_user_cert_resource_handler.cc

Index: content/browser/renderer_host/x509_user_cert_resource_handler.cc
===================================================================
--- content/browser/renderer_host/x509_user_cert_resource_handler.cc	(revision 133822)
+++ content/browser/renderer_host/x509_user_cert_resource_handler.cc	(working copy)
@@ -101,9 +101,22 @@
   AssembleResource();
   scoped_refptr<net::X509Certificate> cert;
   if (resource_buffer_) {
-      cert = net::X509Certificate::CreateFromBytes(resource_buffer_->data(),
-                                                   content_length_);
+      net::CertificateList cert_list =
+          net::X509Certificate::CreateCertificateListFromBytes(
+              resource_buffer_->data(), content_length_,
+              net::X509Certificate::FORMAT_AUTO);
+      if (cert_list.size()) {
+        net::X509Certificate::OSCertHandle cert_handle =
+            cert_list[0]->os_cert_handle();
+        net::X509Certificate::OSCertHandles intermediate_certs;
+        for (size_t i = 1; i < cert_list.size(); ++i)
+          intermediate_certs.push_back(cert_list[i]->os_cert_handle());
+        cert = net::X509Certificate::CreateFromHandle(cert_handle,
+                                                      intermediate_certs);

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

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)

[wtc, 2012/04/27 21:16:50]

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.

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

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.

+      }
   }
+  // TODO(wtc): change ContentBrowserClient::AddNewCertificate() to take
+  // a net::CertificateList instead of a net::X509Certificate?
   content::GetContentClient()->browser()->AddNewCertificate(
       request_, cert, render_process_host_id_, render_view_id_);
   return true;