[Trans] Precertificates and revocation

Rob Stradling <rob@sectigo.com> Fri, 20 September 2019 13:52 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 DAD7A12011E for <trans@ietfa.amsl.com>; Fri, 20 Sep 2019 06:52:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 8uX3Omgj2mtv for <trans@ietfa.amsl.com>; Fri, 20 Sep 2019 06:52:30 -0700 (PDT)
Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-eopbgr690060.outbound.protection.outlook.com [40.107.69.60]) (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 0CAC6120025 for <trans@ietf.org>; Fri, 20 Sep 2019 06:52:29 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TTqHHr1MFbj6xeN3gcDNJ/+GabELqQeHoYHPIXEf3YjC+RT75wnhhw3NjFfs4nhfA2YNLHOgVokOGlrsZrUqDi1iotrTYiJouOtcKftlPKaS5U4fOCxyvhHhWorkh1lc0brOCngOnV/NI0P268FChys9mu4qamp+bYxpZxBYTZbg6pYwGydhUPjcVUfo0kcYgHbcqBdObJCcGoTd1eLGPZ/l2w8I24GA9rGcpXiyYvpFDRALseS8C3fCJWKe+icZwfGUztNfXJ/coaPjOl54r5eIc9LhTPUAEVQEqlhIgnimEsJu6jhenErO+MbY87xzF91S6E8qtM458470syX4jw==
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=RX3daJjy3ezO8cumJZmNMi7wXBssglgE515ROBUqqu4=; b=U7XWeBLSQKNBPUSC2Iv90rjHvMqAuE5ujGcbafFWfW0PCQC+hmn8EpVUSgSd6+B1WahkEbebO0HNFWuR0L8wb8ngm08UpTosT6YdyUIQwMouAPJGC9ztUrgimKxunQfHrUC5TNeCKu28eUyWVSsEMf/YVq2zzRQ0ky2kpLKLTLMaHf9nYzjzt3OOPuegwNQZUpmpbOrDjnmnXwmKvZKp1sv2DMp72i9ZC5aOLkl0iFEMWqcHvkQXyiCsyizW8aUApInuWHIK8bRw53Bexl+jzJhCwmAuXXBLYHpDFWTSrfOue54OU2ygaU2DZHlO7E5y6gl/2+DlSPPVbxH8QJ76HQ==
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=RX3daJjy3ezO8cumJZmNMi7wXBssglgE515ROBUqqu4=; b=MRUIOyX9y/ILPIXkLY46EhW6Q48ltdBi2mZfigPW9ui4laJ7n715kp3hMKl3/Plau2VQJ1M5y8XZQeNFnOJjAi0RG7BIcCM6NDy7HMAwPORqB6THbOOkaS7hUhKvHebruaTR/DCJwh3VOCe5v+0zHxQ3qtOVf6+GxtXe6LAQTJI=
Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB3740.namprd17.prod.outlook.com (10.255.109.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.23; Fri, 20 Sep 2019 13:52:27 +0000
Received: from DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::dc78:38ff:9fc6:58cf]) by DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::dc78:38ff:9fc6:58cf%3]) with mapi id 15.20.2263.028; Fri, 20 Sep 2019 13:52:27 +0000
From: Rob Stradling <rob@sectigo.com>
To: "trans@ietf.org" <trans@ietf.org>
Thread-Topic: Precertificates and revocation
Thread-Index: AQHVb7qjeJ8k5jrm8UOJQ5rvAEBgSA==
Date: Fri, 20 Sep 2019 13:52:27 +0000
Message-ID: <21a9ea1e-124b-3bf2-72f5-4dc755d4061b@sectigo.com>
References: <20190916100800.5b62d43c0f28e30269f41b7a@andrewayer.name>
In-Reply-To: <20190916100800.5b62d43c0f28e30269f41b7a@andrewayer.name>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LNXP265CA0084.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:76::24) 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-forwarded-message-id: <20190916100800.5b62d43c0f28e30269f41b7a@andrewayer.name>
x-originating-ip: [2a0e:ac00:25d:300:f68e:38ff:fe7a:a226]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 64db17f3-9622-42be-d816-08d73dd1c602
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM6PR17MB3740;
x-ms-traffictypediagnostic: DM6PR17MB3740:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <DM6PR17MB374090C1FD70D7E0D592951DAA880@DM6PR17MB3740.namprd17.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0166B75B74
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39850400004)(396003)(376002)(136003)(199004)(189003)(3480700005)(6486002)(6916009)(5640700003)(6436002)(6306002)(25786009)(6512007)(71200400001)(31696002)(71190400001)(8936002)(86362001)(7116003)(305945005)(6116002)(2351001)(36756003)(31686004)(2501003)(2906002)(5660300002)(7736002)(52116002)(102836004)(14454004)(478600001)(76176011)(966005)(316002)(14444005)(386003)(6506007)(256004)(46003)(66446008)(99286004)(64756008)(446003)(66556008)(66476007)(1730700003)(66946007)(186003)(8676002)(486006)(81156014)(476003)(11346002)(2616005)(81166006); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB3740; 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-message-info: KN1ZWQakTFr9jeQEbTdLnzHsruCHXkNpo6wKzxwYjBdNcQHpEiXUgrEsDeIjaLCZSXj3+3RIXkoujkF0G5Q5FKkVH0xVxDAwgm0g8dSTIDZFIz4BDQUQS9tUb+RI7cIfHvHQxGTp9SRZIH52O8+4mSp5LWmV08xzAk3eUFVmlpxbJJmze/loOKxd1XFSzjuH5eE/k6OCN9wnpKy53U3fK/5bWpD9rm5SilPeGRQGObpNY79Pf3uua8lIbvA4QwkWKnZ2ODHGwFj4Wm9CcxLsG3mnWStCXz65LZl+XCSuxBvr1NaFDJNm+No34xSlUuhsqz9T0ONoNUl5LxJw0lwCaoORe6T8WGl+J/KYAm82K5KV24MPVfRCDKOXMckIEo4JQB83SmU6n40aTVdQQqGWZp/EQsM1lxeZ3pKBYazuKyA=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <4AFBE18444F1BF4284BFC145AAA474EE@namprd17.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: sectigo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 64db17f3-9622-42be-d816-08d73dd1c602
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Sep 2019 13:52:27.7647 (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: MoAD6AYUw6teZScAxp6BxggXfB/8y9rRfodalWpa0s65jurvA5lj+j09ln+vxkFEFWW6eixhHA3Mn2WnRSd42w==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3740
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/jnsemnq443kaD5tYztSfWKK75kY>
Subject: [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, 20 Sep 2019 13:52:33 -0000

[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>
To: Rob Stradling <rob@sectigo.com>
CC: 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> 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