Re: [Trans] Precertificate format

[Rob Stradling <[e-mail]>]

On 09/09/14 21:15, Brian Smith wrote:
> On Tue, Sep 9, 2014 at 3:17 AM, Rob Stradling <[e-mail]> 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