On 08/09/14 19:50, Melinda Shore wrote:
It seems as if we've been talking about precertificate format for
quite some time, without coming to resolution. Let's try to find
agreement on how to handle it and close issue 26.
The ticket, with description, is here:
http://trac.tools.ietf.org/wg/trans/trac/ticket/26
The fundamental problem is that because precertificates are currently
encoded as X.509 structures we have the potential for two certificates
to exist with the same issuer and same serial number. Because the
precertificate is not usable as a TLS certificate in practice, this
may not be an issue. However, it's a clear violation of section 4.1.2.2
in 5280 (and to be honest I'm a little fuzzy on its implications for
CRL processing).
So, are you all comfortable with letting the X.509 representation
stand, or do you have an alternative proposal?
I don't mind us adding an alternative Precertificate format to 6962-bis
(if we can agree on a suitable format!), but I'd also like to retain the
RFC6962 Precertificate format as an option.
Several CAs have already deployed code to generate RFC6962
Precertificates. Why force these CAs to change to a different format
just because some other CAs find it hard to implement the RFC6962 format?
Some CAs will actually find it _easier_ to implement the RFC6962
Precertificate format than to implement some new format that we haven't
defined yet. (My experience: When I wrote Comodo's code for RFC6962
Precertificates, reusing the TBSCertificate format was definitely a
blessing rather than a curse).
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
