Re: [Trans] Precertificates and revocation

[Eran Messeri <[e-mail]>]

That reasoning makes sense to me. If 6962-bis precertificate is not a
certificate but 6962-bis states that the existence of a precertificate
indicates intent to issue a certificate, then checking whether the final
certificate has been issued/revoked via OCSP makes sense.

On Thu, Sep 26, 2019 at 5:40 PM Rob Stradling <[e-mail]> wrote:

> 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 <[e-mail]>
> *Sent:* 25 September 2019 17:58
> *To:* Rob Stradling <[e-mail]>
> *Cc:* Ryan Sleevi <[e-mail]>; [e-mail] <[e-mail]>
> *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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/trans
>
>