Rob,
...
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?
Commonly in the IETF, there is no preference given to folks who have
implemented against
an experimental RFC when that RFC is being revised to become a standards
track doc.
Another way to look at this is to ask why a standards track should have
to adopt a
design element from an Experimental RFC that received little review?
So, saying that clients, logs, auditors, etc. MUST support both seems
inappropriate.
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).
I can't argue with your personal experience as a developer. I can argue
that, on the
basis of 5280 (4.1.2.2), and on my experience as a developer of an HSM,
the pre-cert
model is very problematic.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
