On Tue, 23 May 2017 14:43:09 +0100 Eran Messeri <[email protected]> wrote:
> >> [6] In theory, a new certificate, with the inclusion proof embedded, > >> could be issued - but it may run afoul of the restriction on issuing > >> different certificates with the same serial number. > >> > > > > Isn't that the whole reason 6962-bis moved to the (terrible) CMS > > structure? :) That CAs were concerned that precerts & certs constituted two > > logically distinct X.509 certificates? If that was to be introduced, it > > would make sense to simply return to the critical extension, since we'd > > have lost the main argument for using CMS :) > > > Yes :( I mention that as an unlikely option. > I'd like to return to the critical extension too, the main concern brought > against it (AFAIK) is some TLS libraries that would accept precerts as > valid X.509 certificates. Is that such a bad thing? RFC6962 and RFC6962-bis are both quite clear that a pre-certificate is a binding commitment by the CA to issue the final certificate, and that misissuance of a pre-certificate is equivalent to misissuance of the final certificate. So what's the difference between a client accepting a pre-certificate and a client accepting the final certificate which the CA is bound to issue anyways? The only difference I see is that one has embedded CT information and the other doesn't. The pre-certificate is not inherently untrustworthy. CT would be simpler and more flexible if it didn't have pre-certificates, and instead CAs were permitted to re-issue certificates with duplicate serial numbers as long as the only change was the addition/modification of the Transparency Information extension. I suggest keeping this in mind for RFC6962-bis-bis. Regards, Andrew _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
