I think “IETF does not define policy” is about as true as “individuals 
represent themselves at IETF.”  But that’s a longer rathole.


I also don’t think it’s helpful to try to redefine long-standing and 
well-understood terminology like what it means to issue a certificate.  In 
fact, I just checked, and using a definition like “reserving a serial number” 
causes many of the issuance requirements in RFC 5280 to be non-sensical.


It would be helpful for one of the relevant documents, or another document, or 
even an errata, to clarify that OCSP services can be offered for 
pre-certificates.  It’s merely a question of clarifying the technical 
requirements about how an OCSP service should operate, as those requirements 
currently can be read to not allow OCSP responses for non-certificates.


Not sure what reason there would be to oppose such a simple clarification that 
aligns the relevant requirements with the desired policy, especially since it 
is backwards compatible.




From: Ryan Sleevi <r...@sleevi.com> 
Sent: Thursday, September 19, 2019 2:17 PM
To: Tim Hollebeek <tim.holleb...@digicert.com>
Cc: Rob Stradling <r...@sectigo.com>; Alex Cohn <a...@alexcohn.com>; 
mozilla-dev-security-pol...@lists.mozilla.org; Wayne Thayer 
<wtha...@mozilla.com>; Jeremy Rowley <jeremy.row...@digicert.com>
Subject: Re: DigiCert OCSP services returns 1 byte




On Thu, Sep 19, 2019 at 1:52 PM Tim Hollebeek via dev-security-policy 
<mailto:dev-security-policy@lists.mozilla.org> > wrote:

I think that's fine as Mozilla and/or the CABF can and should override RFCs 
when it makes sense to do so, but I think it would also be helpful in the long 
term to fix the discrepancy, especially as CT is likely to be used in more 
certificate ecosystems in the future.


Isn't the core tenet that the IETF does not define policy? This seems very well 
rooted in policy, as you note.


The question does not seem to be about whether or not 
precertificates-are-certificates (and, in a -bis world, they're clearly a 
SignedData-thing-that-isn't), but what constitutes the act of issuance: is it 
signing a thing (whether a TBSCertificate or something other, like a 
precertificate under 6962 or 6962-bis)? Is it reserving the serial number and 
assigning it in the system?


In any event, if/when CT is used in other systems, they'll be using different 
CT logs, so they'll really be entirely different ecosystems. It seems that the 
policy management authority (i.e. the equivalent to browsers, in the Web PKI) 
for those ecosystems can provide clarity, and it further emphasizes why a 
single CA certificate should not participate in multiple PMAs, to reduce the 
risk of and avoid conflicts and/or misunderstandings.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

dev-security-policy mailing list

Reply via email to