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. -Tim 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 <dev-security-policy@lists.mozilla.org <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.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
