Re: [Trans] Precertificates and revocation

Paul Wouters <paul@nohats.ca> Fri, 11 October 2019 01:19 UTC

Return-Path: <paul@nohats.ca>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B3F12003E for <trans@ietfa.amsl.com>; Thu, 10 Oct 2019 18:19:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMPRSw7bZ3vr for <trans@ietfa.amsl.com>; Thu, 10 Oct 2019 18:18:56 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 62673120024 for <trans@ietf.org>; Thu, 10 Oct 2019 18:18:56 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46q98G2TSwzDZF; Fri, 11 Oct 2019 03:18:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570756734; bh=g1OPt4u05SEkPqVMXUTFhhBRUpz1UwJXxgvUFPyxPcE=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=dWWMfuIKnxP4OgRppvjBJXLfVEV0+MbgSTQmGF01inX8ssfl7Dh7aMX87EGFZEOFu LEKS78/YuJ2XuyWKnpXoNZvaB1J0pfzcpZaJXRdIOzmy+RmVmkQTdDfcF6u167qGZe /Z0BiYZbi/7fODP8Vqrb5AK9t2cAzUWbslMJOLjo=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id rd_TV8JJq_cq; Fri, 11 Oct 2019 03:18:51 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Fri, 11 Oct 2019 03:18:50 +0200 (CEST)
Received: from [193.111.228.74] (unknown [193.111.228.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 9D9636089B52; Thu, 10 Oct 2019 21:18:49 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-224AAB69-DD19-46F4-A512-B1E1C181ABA0"
Mime-Version: 1.0 (1.0)
From: Paul Wouters <paul@nohats.ca>
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <DM6PR17MB31620B66797CAD12B9499039AA940@DM6PR17MB3162.namprd17.prod.outlook.com>
Date: Thu, 10 Oct 2019 21:18:32 -0400
Cc: "trans@ietf.org" <trans@ietf.org>, Ryan Sleevi <ryan-ietf@sleevi.com>, Eran Messeri <eranm@google.com>
Content-Transfer-Encoding: 7bit
Message-Id: <2851BD23-A5A6-4407-B5FC-8F9DFCE76DDD@nohats.ca>
References: <20190916100800.5b62d43c0f28e30269f41b7a@andrewayer.name> <21a9ea1e-124b-3bf2-72f5-4dc755d4061b@sectigo.com> <CAErg=HHcG8p_6NAzKyDYg+gPpF6p7F688pSD+qD+shcFdr9vRA@mail.gmail.com> <39d0ea14-36ca-b311-91df-074c1346f8c3@sectigo.com> <CALzYgEciP=y401SWQhsCc71tbFVVFZ0W5S929QStXqJ1EQfFog@mail.gmail.com> <DM6PR17MB3162ED32E10F53952FD61FA2AA860@DM6PR17MB3162.namprd17.prod.outlook.com> <CALzYgEd5Q-UGMiHS4+nRjUvAt-YneMW0W1m=377kb8qzA4oxgg@mail.gmail.com> <401e243a-98bb-7030-51e4-69faadb8977e@sectigo.com> <DM6PR17MB31620B66797CAD12B9499039AA940@DM6PR17MB3162.namprd17.prod.outlook.com>
To: Rob Stradling <rob@sectigo.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/ImHBZtPEuxr9yEHoyORyAh3YwSQ>
Subject: Re: [Trans] Precertificates and revocation
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Oct 2019 01:19:01 -0000

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