Re: [Trans] Precertificates and revocation

[Rob Stradling <[e-mail]>]

Chairs,

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

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

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

Feedback welcome.

On 03/10/2019 11:02, Eran Messeri wrote:
> 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]
> <mailto:[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] <mailto:[e-mail]>>
>     *Sent:* 25 September 2019 17:58
>     *To:* Rob Stradling <[e-mail] <mailto:[e-mail]>>
>     *Cc:* Ryan Sleevi <[e-mail]
>     <mailto:[e-mail]>>; [e-mail]
>     <mailto:[e-mail]> <[e-mail] <mailto:[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]
>     <mailto:[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] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/trans
>

--
Rob Stradling
Senior Research & Development Scientist
Email: [e-mail]
Bradford, UK
Office: [phone]
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.
_______________________________________________
Trans mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/trans