On 09/09/14 21:15, Brian Smith wrote:
On Tue, Sep 9, 2014 at 3:17 AM, Rob Stradling <[email protected]> wrote:
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.
If the old form is acceptable, then there would be no point in
defining a new form. The chief issue is that technically the old form
of precertificate is technically a certificate, and since it has the
same issuer name it must (according to RFC 5280) have a different
serial number. It would be good for the group to decide whether or not
that issue is so bad that we cannot accept it.
Chairs,
Do we have the option of keeping the existing Precertificate format,
such that once 6962-bis becomes a standards track RFC it would violate
the serial number uniqueness rule in the RFC5280?
Or, does the IETF process absolutely require that we don't violate any
rules in existing standards track RFCs?
If it is that bad, it makes sense to define a replacement format. If it isn't
so bad that we can't accept it, then it doesn't make sense to define a
replacement format, IMO.
Brian,
Unless it turns out that there is no single format that all CAs are able
to use, I agree.
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?
If the only issue is whether it is a little bit tricky to implement
the X.509-certificate form of precertificate, then there's no point in
defining a new format. CAs always have the non-precertificate
mechanism to fall back on.
IMO, the ultimate goal should be to get the non-precertificate
mechanisms working well enough that we can remove (or at least
deprecate) the precertificate mechanism completely.
I'm not convinced that this should be the ultimate goal. A benefit of
the Precertificate mechanism is that the certificate holder doesn't need
to worry about configure their TLS Server for CT, because the CA has
already taken care of the CT stuff for them.
Also, out of scope for 6962-bis but in scope for discussion on this list...
Precertificates could be useful if/when we extend CT to Code Signing
certificates, S/MIME certificates, etc, but the RFC6962 TLS Extension
won't be useful in these contexts.
--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
