On Tue, Sep 9, 2014 at 4:40 PM, Kyle Hamilton <[email protected]> wrote: > I think the best way to change a Certificate into a Precertificate would be > to alter the first field of the tbsCertificate to be non-optional and > explicitly tagged as something other than tag [0]. Then, reconstruct the > actual tbsCertificate by changing the first field to tag [0], perform any > other necessary edits (like, for name redaction), re-encode the > validly-tagged tbsCertificate to DER, and digest the encoded data.
Let's back up a bit: we want to ensure that the certificate chains browsers use are a matter of public record. To do this we need to record the chain in a log, and give the server back a way to prove "yes, we've seen this chain" from the log. What I don't understand here is the role of the CA and the Precertificate in this process. Sincerely, Watson Ladd > > But, I also proposed (a few years ago) a way to include an issued > certificate list in a CRL extension to mitigate the Diginotar-style "we > didn't know it had been issued" problem, and to be able to feed CRL-based > OCSP responders with a minimum of code changes. That didn't go anywhere, and > I expect this suggestion to go nowhere as well. > > -Kyle H > > On September 9, 2014 12:56:11 PM PST, Brian Smith <[email protected]> > wrote: >> >> On Mon, Sep 8, 2014 at 4:24 PM, Rick Andrews <[email protected]> >> wrote: >>>> >>>> The CA may use a Precertificate Signing Certificate to sign the >>>> Precertificate, and then sign the final certificate with the production CA >>>> certificate. Then, there would be no duplicate serial number issues. >>> >>> >>> Brian, even if the CA uses a Precert signing cert, the precert's issuer >>> name has to be that of the ultimate issuer, and the serial number has to be >>> that of the ultimate certificate, so I don't think that solves the problem. >> >> >> Thanks for pointing that out. Basically, the cause of that problem is >> that a Precertificate is a syntactically-valid X.509 certificate, and >> so it could be >> considered a duplicate of the final certificate. If the >> Precertificate weren't a syntactically-valid X.509 certificate, then >> there would be no way it could be considered a duplicate. So, why not >> make this simple change to the syntax: >> >> enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType; >> >> struct { >> LogEntryType entry_type; >> select (entry_type) { >> case x509_entry: ASN.1Cert; >> case precert_entry: ASN.1Precert; >> } entry; >> ASN.1Cert certificate_chain<0..2^24-1>; >> } LogEntry; >> >> opaque ASN.1Cert<1..2^24-1>; >> opaque ASN.1Precert<1..2^24-1>; >> >> where the internal syntax of ASN.1Precert is (in ASN.1): >> >> ASN1Precert ::= SEQUENCE { >> precertSigningCert [0] EXPLICIT OptionalCertificate, >> tbsCertificate TBSCertificate, >> signatureAlgorithm AlgorithmIdentifier, >> signatureValue BIT STRING } >> >> >> OptionalCertificate ::= certificate Certificate OPTIONAL; >> >> In other words, ASN1Precert is exactly an X.509 Certificate except >> that it starts with an explicitly-tagged, possibly-empty >> precertSigningCert field. Thus, no X.509 certificate parser would >> parse a precert as though it were a real certificate, and so the >> precert could never be considered a duplicate of the final cert. >> Additionally, there would be no need for the "poison extension" >> because the added precertSigningCert field serves the same purpose. >> >> This strawman only attempts to solve the "duplicate certificate" >> problem, not the "must reserve the serial number in advance" problem. >> However, I suspect that this change would make it more difficult for >> some CAs to create precertificates. >> >> Cheers, >> Brian >> >> ________________________________ >> >> Trans mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/trans > > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
