Subject: Re: [Trans] Precertificates and revocation

From: Eran Messeri <[email-masked]>
Date: Thu, 3 Oct 2019 11:02:35 +0100

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

---

From: Rob Stradling <[email-masked]>
Date: Thu, 3 Oct 2019 14:11:43 +0000

Here's a PR:
https://github.com/google/certificate-transparency-rfcs/pull/315

Feedback welcome.

On 03/10/2019 11:02, Eran Messeri wrote:
> On Thu, Sep 26, 2019 at 5:40 PM Rob Stradling <[email-masked] 
> <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>>
>     *To:* Rob Stradling <[email-masked] <mailto:[email-masked]>>
>     *Cc:* Ryan Sleevi <[email-masked]
>     <mailto:[email-masked]>>; [email-masked]
>     <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
>     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-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         [email-masked] <mailto:[email-masked]>

Email: [email-masked]
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 10 Oct 2019 22:01:33 +0000

Chairs,

May I interpret silence as consent, and go ahead and merge this PR?

________________________________
From: Trans <[email-masked]> on behalf of Rob Stradling <[email-masked]>
Sent: 03 October 2019 15:11
To: [email-masked] <[email-masked]>
Cc: Ryan Sleevi <[email-masked]>; Eran Messeri <[email-masked]>
Subject: Re: [Trans] Precertificates and revocation

Here's a PR:

Feedback welcome.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 10 Oct 2019 21:18:32 -0400

It has been a week, so please go ahead. Worst case people can object during the IETF LC.

Paul

Sent from my iPhone

> On Oct 10, 2019, at 18:01, Rob Stradling <[email-masked]> wrote:
> 
> Chairs,
> 
> >         https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-33#section-6.1..
> > 
> >          > policy (e.g.. by a browser, for the Web PKI) treats the
> >         issuance of a