Extract Certificate Transparency SCTs from stapled OCSP responses

net/cert/ct_objects_extractor.h

 // Copyright 2013 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef NET_CERT_CT_OBJECTS_EXTRACTOR_H_
 #define NET_CERT_CT_OBJECTS_EXTRACTOR_H_
 
 #include <string>
 
 #include "net/base/net_export.h"
@@ skipping 27 matching lines @@
 
 // Obtains an X509Chain log entry for |leaf|, an X.509v3 certificate that
 // is not expected to contain an X.509v3 extension with the OID
 // 1.3.6.1.4.1.11129.2.4.2 (meaning a certificate without an embedded SCT).
 // On success, fills |result| with the data for an X509Chain log entry and
 // returns true.
 // The filled |*result| should be verified using ct::CTLogVerifier::Verify
 NET_EXPORT_PRIVATE bool GetX509LogEntry(X509Certificate::OSCertHandle leaf,
                                         LogEntry* result);
 
+// Extracts a SignedCertificateTimestampList that has been embedded within
+// an OCSP response as an extension with the OID 1.3.6.1.4.1.11129.2.4.5.
+// If the extension is present, and matches the serial number of the leaf
+// certificate, returns true, updating |*sct_list| to contain
+// the encoded list, minus the DER encoding necessary for the extension.
+// |*sct_list| can then be further decoded with ct::DecodeSCTList.
+//
+// Note that we do response matching by serial number only so if the response

[wtc, 2013/12/03 01:18:06]

Nit: add a comma (,) after "by serial number only".

[ekasper, 2013/12/03 13:50:51]

Done.

+// contains statuses for different certificates with the same serial number,
+// this method does not work. However, repeating serial numbers within the same

[wtc, 2013/12/03 01:18:06]

I don't think we need to worry about this, because certificate serial numbers
are supposed to be unique under the same issuer.

Unless an OCSP response is allowed to contain statuses for certificates issued
by different CAs.

Update: I checked the CertID ASN.1 type. I think we should also match
issuerNameHash or issuerKeyHash. I agree the risk of not doing this is low.

[ekasper, 2013/12/03 13:50:51]

In theory we should. In practice a collision here would happen if different CAs
were delegating to the same OCSP responder, and these two CAs had certs with
colliding serial numbers, and the responder was including the status for the
second, presumably unrelated, certificate, in the response (which is a SHOULD
NOT because the request for a stapled response would never ask for other certs).

But I've added a TODO and will look into this.

+// OCSP response are unlikely to begin with, and since CT further only
+// uses stapled OCSP responses which are known to pertain to the server (leaf)
+// certificate, this is a non-concern for us.
+NET_EXPORT_PRIVATE bool ExtractSCTListFromOCSPResponse(
+    X509Certificate::OSCertHandle leaf,
+    const std::string& ocsp_response,
+    std::string* sct_list);
+
 }  // namespace ct
 
 }  // namespace net
 
 #endif  // NET_CERT_CT_OBJECTS_EXTRACTOR_H_