Re: [Trans] Precertificates and revocation

Rob Stradling <rob@sectigo.com> Mon, 30 September 2019 16:11 UTC

Return-Path: <rob@sectigo.com>
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 8E57012004F for <trans@ietfa.amsl.com>; Mon, 30 Sep 2019 09:11:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FUZZY_CPILL=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=comodoca.onmicrosoft.com
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 9cx3d_iiRCoR for <trans@ietfa.amsl.com>; Mon, 30 Sep 2019 09:11:53 -0700 (PDT)
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730073.outbound.protection.outlook.com [40.107.73.73]) (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 5E8871201DC for <trans@ietf.org>; Mon, 30 Sep 2019 09:11:53 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=m9D3imqIXmbCwf8kb/CqcF0SSZ4KFZfFa294j2dz9Gn6U6zm9UVw076sVlIHtwRnGB0+TXf/QFRklQN0fFGPoGWpipM6OWXY4776hrjMFuWoNr6HSSOn73UEimGK8n9F5d5L7lgzpNFGhkoyACE761+kp1g/CmInQg59wQ8OhHTPJbeG3ShoC1c97wk5E7GpBI2oxL6vAB9fKg2x+co3Df4iggME++PNKj2Z6n1pVhobRQQWq1Bvrk8EKIlUbv7lpRqgcLQJ83QakOQsTveIUO3cvl42lRzXP+KwLSCh3KsZQrwR0vOUlChq3tyPLyglmKTQ1kYQ5bw7PDH7HI8l1Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=11j4QpxufS+Ls/Azk41FyENqVT1TbhUIufd+9dpmoxQ=; b=G5t3lwErHhzNWTeKfXz9nywToR0cLnOd8VS07NtPCFgbuL0brJdDC3tOVLNdHufiTVIrbeHNsGaLnWv2w4egXpaOqlE9NJPR7RJnnmiXkgIDZxy4TRmx+woSEJVcqVI6t3v9mOz8ZzIaEm7JfdJyjq7fQ+fYbta0baZH4U35yoy+P0FpwJutriN5AAAh48FAm2bFtCBSAZRw5QlJW/WAqjBMLOPjaPPkEshqOjhcX4i1+9CWPdcY9q9VObRZVDM0k81Idd7+YhcyTgjcuL/t6W9Ma2zrOG/oWOWouj898M+EVNEMRNRJiqY3wYs4kA/kAqWqvFVL5eWq5nkRQNo0Sw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sectigo.com; dmarc=pass action=none header.from=sectigo.com; dkim=pass header.d=sectigo.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector2-comodoca-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=11j4QpxufS+Ls/Azk41FyENqVT1TbhUIufd+9dpmoxQ=; b=HAiJjpmGpdpSM1+TOiL8A7N2iZZQtAO4LOGdlkZIl56r8Ewmrw+LhmlxhauAGhSlt1dc9/z30gGlBMXu0B1t4LnLhpdQC4SpFiDjoD9vEcO3UyEpQmrqvUT0Kyxq7c7APh3MA+FcKb5T8xcAwMkPStX1Utu7AmT4YHgruQFBerA=
Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB3834.namprd17.prod.outlook.com (20.180.20.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Mon, 30 Sep 2019 16:11:51 +0000
Received: from DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::9c8b:aa25:83b0:6c85]) by DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::9c8b:aa25:83b0:6c85%6]) with mapi id 15.20.2305.017; Mon, 30 Sep 2019 16:11:51 +0000
From: Rob Stradling <rob@sectigo.com>
To: Erwann Abalea <eabalea@gmail.com>
CC: "trans@ietf.org" <trans@ietf.org>
Thread-Topic: [Trans] Precertificates and revocation
Thread-Index: AQHVb7qjeJ8k5jrm8UOJQ5rvAEBgSKc02/mAgA+YFoA=
Date: Mon, 30 Sep 2019 16:11:50 +0000
Message-ID: <f37e8935-4559-a857-c1d3-29d255879913@sectigo.com>
References: <20190916100800.5b62d43c0f28e30269f41b7a@andrewayer.name> <21a9ea1e-124b-3bf2-72f5-4dc755d4061b@sectigo.com> <CA+i=0E74Obi+Q=H_km9MFKzMBUTsjxRKt2-XxpJuf60Bz+99mw@mail.gmail.com>
In-Reply-To: <CA+i=0E74Obi+Q=H_km9MFKzMBUTsjxRKt2-XxpJuf60Bz+99mw@mail.gmail.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LO2P265CA0265.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a1::13) To DM6PR17MB3162.namprd17.prod.outlook.com (2603:10b6:5:192::31)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com;
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [2a0e:ac00:25d:300:f68e:38ff:fe7a:a226]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6d74d72f-fbc3-490a-f5e2-08d745c0e703
x-ms-traffictypediagnostic: DM6PR17MB3834:
x-ms-exchange-purlcount: 3
x-microsoft-antispam-prvs: <DM6PR17MB38341B65D51AEAF9D4694BFBAA820@DM6PR17MB3834.namprd17.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01762B0D64
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(39850400004)(366004)(346002)(136003)(199004)(189003)(305945005)(6246003)(53546011)(6506007)(66556008)(64756008)(66446008)(66476007)(76176011)(8676002)(386003)(66946007)(36756003)(4326008)(31696002)(52116002)(7736002)(14444005)(99286004)(5660300002)(31686004)(1411001)(25786009)(256004)(6486002)(86362001)(316002)(71190400001)(71200400001)(446003)(6436002)(66574012)(2616005)(81156014)(6116002)(478600001)(476003)(46003)(229853002)(8936002)(486006)(11346002)(966005)(186003)(102836004)(2906002)(6512007)(81166006)(14454004)(6916009)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB3834; H:DM6PR17MB3162.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: TRwhz6yuycdUavLRBesbmOsFqPSMn1e8BoGqUlBxllGpvhDKsSMM3hlqYzzutmG4Gyjjkr2X1uhNMkLV3nU63zJlllsUj/8srBINi/BI/KkCATsuueeHLh/tBslkXsQ60HNPlAfEh5gnpYAwDcjs1Vsj6Zc/8XmBa3MpBEOzgsT9maIsLQAemYvcdPhz+xQwpLty7EVLZVTBkciR4DvG05xVRu5bfD96iwUp9GqSg7KJZvS28vZbI2uDpLGhzC9NCbu/QS2PUR1e/OMjxIm98Zcp83+JpxSoBcDiUJf3rI7TKaWvUlDkEVeDX9ySO//YGT0ml/Le/hwPj48XHcto87dn5XIrqK86+FWUO4En9PZuo/tDY4rT8JzqJaZvSAQ1AmbqI1vU6Iz7IhMzHJ4OX3JE4HeO0Gpcx6pu9SvUT01XUT3MuqDpHqdzzUtRGImQpXbdcVBLbYUEye7fi6IIyw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <498FDF55E69A1D45A46F4168F5BD34EA@namprd17.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: sectigo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6d74d72f-fbc3-490a-f5e2-08d745c0e703
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Sep 2019 16:11:51.2215 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 0e9c4894-6caa-465d-9660-4b6968b49fb7
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: snIxNUwcIHGVymjlGd8kYRokgvwymiYSLO5L1WAVAq9Z/KtVST0HwirnCYYhK3HFf4QjVJZ8TNAu7l6/y85iIA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3834
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/OI1MOHSCyFwJq00r-TpV56C1B1Q>
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: Mon, 30 Sep 2019 16:11:58 -0000

On 20/09/2019 19:03, Erwann Abalea wrote:
> In the case of a precert subordinate CA, the CRLDP and AIA:ocsp will 
> contain the URLs of the real CA (the one that issued the precert sub 
> CA). How is it supposed to work? In a CTv1 world.

Hi Erwann.

In a CTv1 world, ISTM that the current situation is the same for CAs 
that do and for CAs that don't use a precert subordinate CA.

1. As far as Mozilla is concerned, it is now a "Required Practice" (but 
not yet "Policy") that a CA MUST provide OCSP status for a 
precertificate, acting as if the corresponding certificate has been 
issued (even if it hasn't actually (yet) been issued).

2. As far as other consumers of the CABForum Baseline Requirements are 
concerned, OCSP is a certificate status protocol, and (according to the 
BRs) a precertificate is not a certificate.  Therefore, CAs 
(effectively) MUST NOT provide OCSP status for a precertificate, unless 
the corresponding certificate has actually been issued.

To resolve this conflict, there is a draft ballot being discussed on the 
CABForum public list:
https://cabforum.org/pipermail/servercert-wg/2019-September/001097.html

Until this conflict is resolved, all WebPKI CAs are out of compliance 
with either 1 or 2.  :-(

> Le ven. 20 sept. 2019 à 15:52, Rob Stradling <rob@sectigo.com 
> <mailto:rob@sectigo.com>> a écrit :
> 
>     [This topic came up on mozilla.dev.security.policy recently.  Although
>     the focus there is on the currently deployed CT v1 ecosystem, ISTM that
>     TRANS should consider if/how CT v2 (6962-bis) should address the
>     same issue]
> 
>     How should revocation servers behave when a precertificate exists but
>     the corresponding certificate has not yet been (or will never be)
>     issued?
> 
>     Should it be possible to revoke a precertificate when the corresponding
>     certificate has not been issued?
> 
>     In RFC6962, precertificates are X.509 certificates, and so it's not
>     unreasonable to expect OCSP responders to be able to provide their
>     status.  However, 6962-bis precertificates are not X.509 certificates,
>     which I think changes what might or might not be a reasonable
>     expectation.
> 
>     Andrew points out (see forwarded message below) that outside observers
>     have to assume that a certificate has been issued when they see a
>     corresponding precertificate (since the presumed-to-exist certificate
>     may never be submitted to a log), and that outside observers will
>     expect
>     CAs to operate revocation services for the presumed-to-exist
>     certificates.
> 
>     Back to CT v1: Mozilla now requires [1] that...
>     "- A CA must provide OCSP services and responses in accordance with
>     Mozilla policy for all certificates presumed to exist based on the
>     presence of a Precertificate, even if the certificate does not actually
>     exist
>     - A CA must be able to revoke a certificate presumed to exist, if
>     revocation of the certificate is required under Mozilla policy, even if
>     the certificate does not actually exist."
> 
>     ISTM that we should address this topic in 6962-bis somehow, but what do
>     folks think we could say without straying into "policy"?
> 
> 
>     [1]
>     https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Precertificates
> 
> 
>     -------- Forwarded Message --------
>     Subject: Re: DigiCert OCSP services returns 1 byte
>     Date: Mon, 16 Sep 2019 10:08:00 -0700
>     From: Andrew Ayer <agwa@andrewayer.name <mailto:agwa@andrewayer.name>>
>     To: Rob Stradling <rob@sectigo.com <mailto:rob@sectigo.com>>
>     CC: dev-security-policy@lists.mozilla.org
>     <mailto:dev-security-policy@lists.mozilla.org>
> 
>     On Fri, 13 Sep 2019 08:22:21 +0000
>     Rob Stradling via dev-security-policy
>     <dev-security-policy@lists.mozilla.org
>     <mailto:dev-security-policy@lists.mozilla.org>> wrote:
> 
>      > Thinking aloud...
>      > Does anything need to be clarified in 6962-bis though?
> 
>     Yes, it's long past time that we clarified what this means:
> 
>     "This signature indicates the CA's intent to issue the certificate. 
>     This
>     intent is considered binding (i.e., misissuance of the precertificate is
>     considered equivalent to misissuance of the corresponding certificate)."
> 
>     The goal is that a precertificate signature creates an unrebuttable
>     presumption that the CA has issued the corresponding certificate. If a
>     CA issues a precertificate, outside observers will treat the CA as if
>     it had issued the corresponding certificate - whether or not the CA
>     really did - so the CA should behave accordingly.
> 
>     It's worth explicitly mentioning the implications of this:
> 
>     * The CA needs to operate revocation services for the corresponding
>     certificate as if the certificate had been issued.
> 
>     * If the corresponding certificate would be misissued, the CA will be
>     treated as if it had really issued that certificate.
> 
>     Are there any other implications that 6962-bis should call out
>     explicitly?
> 
>     Regards,
>     Andrew
> 
>     _______________________________________________
>     Trans mailing list
>     Trans@ietf.org <mailto:Trans@ietf.org>
>     https://www.ietf.org/mailman/listinfo/trans
> 
> -- 
> Erwann.

-- 
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.