Why not use a TBSCertificate from RFC 5280 with no modifications from the final certificate (no poison extension) and sign it with a PKCS7 signature instead of a RFC 5280 signature? By doing this you are not creating a valid certificate so you are not technically breaking RFC 5280 (re-using serial numbers) and it couldn't be used as a certificate even if some software incorrectly ignored the poison extension.
Jeremy -----Original Message----- From: Trans [mailto:[email protected]] On Behalf Of Stephen Kent Sent: Thursday, September 11, 2014 12:15 PM To: [email protected] Subject: Re: [Trans] Precertificate format Ben, > ... > I managed to miss that proposal. I've found it now. > > There seems to be a flaw: if I'm an evil CA wishing to issue an evil > certificate, I simply log a precert, minus serial, get an SCT*, log a > certificate containing that SCT*, which I then revoke when requested > to do so, > > In order to attack a user with the evil certificate, I simply issue a > second copy with a different serial, containing the original SCT*, and > the certificate works. Yes, the discrepancy should be discovered in > audit, but that is a significantly weaker protection than we get if > the serial is included in the pre-certificate. I agree that the attack you describe would work, but it needs to be evaluated in the overall context of how CT works in the case of several different types of attack scenarios. The threat model and attack model text I just submitted provides a first cut at describing such scenarios. Once we get agreement on that model, let's revisit the question of whether the vulnerability you noted above is significant relative to other residual vulnerabilities. > Also this adds quite a lot of complexity in order to allow what > appears to be, so far, an entirely theoretical use case. I do know that when VeriSign used the Safekeyper HSM to issue all of its certs (which it did for several years), it would have been impossible to generate a pre-cert and matching final cert. So, the concern I raise would have been a show stopper for them in that time frame. I guess it depends on how one defines a "theoretical use case" :-) Separately, the pre-cert model, requires a CA to issue two certs with the same serial number, which is a bad security practice. I think it makes sense to re-consider forcing CAs to behave this way. Steve _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
