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 protected]> wrote: > > Chairs, > > May I interpret silence as consent, and go ahead and merge this PR? > > From: Trans <[email protected]> on behalf of Rob Stradling > <[email protected]> > Sent: 03 October 2019 15:11 > To: [email protected] <[email protected]> > Cc: Ryan Sleevi <[email protected]>; Eran Messeri <[email protected]> > 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 <[email protected] > > <mailto:[email protected]>> 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 protected] <mailto:[email protected]>> > > *Sent:* 25 September 2019 17:58 > > *To:* Rob Stradling <[email protected] <mailto:[email protected]>> > > *Cc:* Ryan Sleevi <[email protected] > > <mailto:[email protected]>>; [email protected] > > <mailto:[email protected]> <[email protected] <mailto:[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 > > > > -- > Rob Stradling > Senior Research & Development Scientist > Email: [email protected] > 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. > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
