Hi Eran. OCSP (RFC6960, RFC5019) responses and CRLs (RFC5280) provide status information for certificates (RFC5280). In CTv1 (RFC6962), precertificates are certificates; whereas in CTv2 (6962-bis), precertificates are (by design!) not certificates.
The "effective MUST NOT" is because anything that is not a certificate (be it a CTv2 precertificate, a cat GIF, or whatever) is not in scope for OCSP, as currently specified. The fact that a CTv2 precertificate has a serial number that is intended to subsequently belong to a certificate makes it possible to imagine extending the OCSP protocol to report statuses of CTv2 precertificates. But until the OCSP protocol is extended in this way, the fact is that...the OCSP protocol has not yet been extended in this way. I think 6962-bis should extend the OCSP protocol in this way. If it can be avoided, I don't think it should be left to CT client policies to extend IETF protocols. ________________________________ From: Eran Messeri <[email protected]> Sent: 25 September 2019 17:58 To: Rob Stradling <[email protected]> Cc: Ryan Sleevi <[email protected]>; [email protected] <[email protected]> Subject: Re: [Trans] Precertificates and revocation Rob, what leads you to say that "6962-bis has an effective MUST NOT" regarding the CA not having to provide status information for a 6962-bis precertificate? I agree it'd be helpful to add a clarification in 6962-bis regarding CAs possibly being asked about revocation status of a not-yet-issued certificate. I just want to understand where 6962-bis prevents CAs from publishing revocation info for 6962-bis precerts. On Mon, Sep 23, 2019 at 12:21 PM Rob Stradling <[email protected]<mailto:[email protected]>> wrote: If 6962-bis says nothing about this topic, then ISTM that the default effective requirement will be that a CA MUST NOT provide OCSP status for a (CT v2) precertificate where the corresponding certificate has not (yet) been issued. This is because, whichever way you look at it, a CT v2 precertificate is not a "certificate" according to RFC5280/RFC6960/RFC5019. I agree that a statement such as "CAs MUST provide OCSP status for CT v2 precertificates" would not belong in 6962-bis, but would instead belong in a TLS client policy document. However, I would prefer to avoid the situation where 6962-bis has an effective MUST NOT but where (some, but not necessarily all) TLS client policies have a MUST. In order to avoid such a conflict, I think it would be helpful for 6962-bis to outline the policy space by making the following points: 1. Since issuance of a precertificate `P` is a binding commitment to issue a corresponding certificate `C`, monitors may reasonably assume that `C` has been issued. 2. It follows that monitors may wish to request status information (e.g., via CRL and/or OCSP) for the serial number of `P`, even though (unbeknownst to the monitor) `C` has not actually been issued. 3. Although `P` is not a "certificate" according to RFC5280/RFC6960/RFC5019, some TLS clients may have policies that require CAs to provide certificate status (e.g., signed OCSP responses and/or CRLs) for the serial number of `P`, regardless of whether or not `C` has been issued. Making these points would transform 6962-bis's effective requirement from a MUST NOT into a MAY. A TLS client policy could then profile that to a MUST without introducing any conflict. ISTM that this approach of outlining the policy space but not setting policy would be consistent with, for example, https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-33#section-6.1. On 20/09/2019 17:16, Ryan Sleevi wrote: > As I mentioned elsewhere, I'm not sure this is an entirely useful or > productive concern to be raising at this time. I have also shared that I > think this is a question of policy than protocol, even though the policy > decision has implications on other protocols. Thus I think it's much > more appropriately discussed among individual implementations. > > As a protocol for allowing both the pre-disclosure of a certificate and > post-disclosure of a certificate. We saw, rather extensively in the > Threat Model document, different perspectives on policies regarding how > pre-disclosure should be treated and handled. For example, using the > protocol in 6962 or -bis, it's possible to use CT as a means of > detecting and correcting certificates prior to issuance (the discussion > about Logs applying rules to certificates). Similarly, it's possible for > CT as a protocol to be used entirely internal to an organization, as > part of audit logging for external audits via a common protocol, even > with the inclusion of data that might otherwise be inappropriate for > publicly-exposed logs. > > So I do think that, from the point of view of the RFCs, it's a matter of > policy as to how the existence of a pre-certificate is treated, which > aligns with the particular intended deployment of the CT protocol. If a > policy (e.g. by a browser, for the Web PKI) treats the issuance of a > pre-certificate as an unrebuttable proof of an equivalent certificate, > which is certainly one of the core things CT enables policy to state, > then it naturally follows that it must be treated as such within > protocols that are keyed on the issuance of certificates. > > It's an operational concern, defined by local policy, as to what impact, > if any, it has on other protocols. Just as RFC 5280 does not define, for > example, what forms of names to include within a distinguished name, I'm > not convinced that this would even belong in 6962-bis, because it covers > the operational aspects and implications of a PKI that may use, in part > or whole, these RFCs. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ Trans mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/trans
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
