From nobody Wed Oct 2 11:44:43 2019 Return-Path: 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 24D791200FA for ; Wed, 2 Oct 2019 11:44:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 BFm36MkfhdH0 for ; Wed, 2 Oct 2019 11:44:35 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0627.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe45::627]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88C4212022E for ; Wed, 2 Oct 2019 11:44:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=FYdEqs05LX8aqc12hVe0+LLLQmkRu3Iw5Tf5OO3cNDlxQ1vRQgCRsI59wApQIA5TZWS2jyI8tK6HPewvQpFu05e2AOZoHRRT/TS3kdpcHrg1oNdlE2lVrOcWsCpbg0KXfwWVdv7qnfgnNgHvbgtfONwRfcNzIaIVscX0rmiVtf6YdjBAJ+a0Cs9NnBVb0mCGRRiia+35hB2xWhQtJ84eNvx48+n7VNIA5Nnckew80bJprLAv24LELaEEw2q19GBOMJwU1wfkmpPJEOFid/FtN93rXwQ3E4bph3A1iNYzG8+/NbOZQqxKTfV6ojQFNKkj1Z+VkEb30BFjF0/RCnStlg== 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=ubWJDCWPfHhZisaI2i/rzmgHMQZcL5X+WTnRjD9ijAo=; b=gFopUgHqY9nUPb7V8Ci0eLJ9byYDyOz2bq/mqzaXMV6f8kFoUzcwk9c4Mf9mDXqen3AK1AKOugabLCnCV9EyHL7nEt/4VMldFchDw4UY0q0Pbyp7ZSUU0KQE1QPnB3kMAH63cMJ+/UpvIMd0Hhbl+ScSzQ22Sur79gpv6Wfm4XDAMGTitKEYmD37bfNxG+q900zG8Jj6V6KM+5ZHTpTY+GdZ5rCVkFkrcoigDV29Qbjm/cSS6E/ncFuEVioE9T6LspYtwDSbBgavjxWXASeO5JXmMJOJGLXyM2QSz6rFr1IcOqbPsY5AITGRDrCICReuJhlz42I0xCv1h2W2a9uaBg== 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=ubWJDCWPfHhZisaI2i/rzmgHMQZcL5X+WTnRjD9ijAo=; b=AO77rbsLoI7vSKO7IyICmbDyhZBgW/4CtZ8DYDzj0vTvcpLEbdyhZF1yxfqOW25xKafDvnchtLHTmsMH+4Gr+JF/47cVUEZgOxnAlsgwTtnDKc7ADYC8fC2WbilZs7jlWjaU8T6RRMgm8oLmzJ97z7a/zAQIj7sWIM3wrHEYmRY= Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB2955.namprd17.prod.outlook.com (20.178.228.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Wed, 2 Oct 2019 18:44:33 +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; Wed, 2 Oct 2019 18:44:33 +0000 From: Rob Stradling To: Paul Wouters CC: Andrew Ayer , Trans , Alissa Cooper , Eran Messeri Thread-Topic: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-trans-rfc6962-bis-33 Thread-Index: AQHVblRQ0CWg5MVGO0ywZM7RXIf1a6czBmsAgAApD4CABg+gAIAAkfwAgADwIYCAAF/EgIABJ5cAgABSrgCACyngTw== Date: Wed, 2 Oct 2019 18:44:33 +0000 Message-ID: References: <4632c221-c207-72c4-83c3-ecc8dcbf2ba7@sectigo.com> <20190924075519.6a9daab1def6475bd26e5370@andrewayer.name> <2fa45a40-c12c-4d85-a0ab-17c83fdd2443@sectigo.com>, In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; x-originating-ip: [185.69.144.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9860c4e3-c9f4-4f5d-d22b-08d74768917b x-ms-traffictypediagnostic: DM6PR17MB2955: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(39850400004)(366004)(376002)(199004)(189003)(8936002)(25786009)(91956017)(105004)(76116006)(236005)(54896002)(8676002)(9686003)(102836004)(81156014)(6506007)(478600001)(6306002)(53546011)(446003)(2906002)(606006)(14444005)(64756008)(19627405001)(66946007)(66476007)(66446008)(966005)(66556008)(71190400001)(71200400001)(55016002)(5660300002)(7736002)(76176011)(99286004)(33656002)(54906003)(81166006)(7696005)(6436002)(316002)(486006)(14454004)(6916009)(186003)(86362001)(52536014)(256004)(26005)(6246003)(6116002)(229853002)(3846002)(4326008)(66066001)(74316002)(476003)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2955; 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: No5gR3ICTCJ1trvCvc1fU+DthmaTint8U1nqxBaefsPWeX1TSUpNaTlRjUQDGXC7pT1wfjHxUt2VeChc9Gix7JNgh1ehtEOBTO3gfm8CXHJlqjuvqk7flcgC/nwiauU15ML9DhyLaRCglmyQeIu+WyUT+Vorvtxc/O2EczROpbGIktggyJWFQ55uMORlWGU7jIX9UD3/XbG/7RFLoEddwHHGPdfRdUt6YMTHhFluZe8zRUMmSp/ZdYHR46JccrtO5iHsVQqRGU39FQxWveZueb8fUwPfG1zDLRMkPl4EKVWmc+cKWm+/L0XyIzmcd0TZ9qvyPrgNGzIx993U+pBlXP/rx7hHb8QxL0q9fO2ByxiYxi3fxxmMNPYhiuLnHLX3an6F7sdaMmYsS73f1qgvYEnyjgDp4AqhIGzVLbjwx+pD+KEhaC77vHcnG5XUUZ9fu3n+gGZ/yV8FlvoQBlYo7g== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR17MB31624457FAC84E6D7DC91AE2AA9C0DM6PR17MB3162namp_" MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 9860c4e3-c9f4-4f5d-d22b-08d74768917b X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2019 18:44:33.7667 (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: bZT5q9MYG52X/7QfWQrgcByzlErskVF2EFHIQhLxKTYqrDgxjgEONAjzv2gqt+nMNp9iNdntr549+KbOJdvROQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2955 Archived-At: Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-trans-rfc6962-bis-33 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 18:44:41 -0000 --_000_DM6PR17MB31624457FAC84E6D7DC91AE2AA9C0DM6PR17MB3162namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, Does https://github.com/google/certificate-transparency-rfcs/pull/314 addre= ss your concern? May I go ahead and merge this PR? (It's still not clear to me what the 6962-bis authors can or can't do at th= is point in the editing cycle). ________________________________ From: Eran Messeri Sent: 25 September 2019 17:11 To: Rob Stradling Cc: Paul Wouters ; Andrew Ayer ; Tran= s ; Alissa Cooper Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-= trans-rfc6962-bis-33 On Wed, Sep 25, 2019 at 12:16 PM Rob Stradling > wrote: On 24/09/2019 18:38, Paul Wouters wrote: > On Tue, 24 Sep 2019, Andrew Ayer wrote: > >>> While I agree with you, I am just a WG chair. So we need to hear a few >>> more opinions of people and then if there is a consensus, we can go >>> ahead and make this change. >> >> I'm also not sure what "this change" would be, but I agree with the >> other comments here that CT shouldn't provide a mechanism for logs to >> change URL. > > I meant the clarification text of Base URL change (verus a potential > other consensus of text that would allow updating the base url) > > I'm not sure what the policy is for declaring a registry append only. > Maybe leave a comment in for IANA whether or not that needs text? In -33, section 10.6.1 says: "Each application for the allocation of a Log ID MUST be accompanied by: - the Log's Base URL (see Section 4.1). - a Contact (including contact information), from whom further information can be obtained. - an Owner (including contact information), who is authorized to change this Log ID allocation." I think we should fold "Owner" and "Contact" into just one field named "Log Operator", and clarify that the only part of a Log ID Registry entry that can be updated is the log operator's contact information. Also, given that log operators are permitted to allocate Log IDs from other OID arcs (see section 4.4), ISTM that we also need to update section 4.1 to say that a log's Base URL is immutable. Furthermore, ISTM that it would help to be explicit about the immutability of each and every log parameter. Here's a PR that attempts to resolve all of the above: https://github.com/google/certificate-transparency-rfcs/pull/314 I agree with Rob and Ryan's stance - as demonstrated with 6962 deployment, = client agility would address the issue of logs wanting to change their URLs= (and I do not recall an occasion where having the ability to change just t= he log URL would have been helpful). > Or alternatively, in the text for the Expert Review, mention the > registry is strictly append-only ? There is no Expert Review text relating to the Log ID Registry. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans --_000_DM6PR17MB31624457FAC84E6D7DC91AE2AA9C0DM6PR17MB3162namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul,


May I go ahead and merge this PR?

(It's still not clear to me what the 6962-bis authors can or can't do at th= is point in the editing cycle).

From: Eran Messeri <eran= m@google.com>
Sent: 25 September 2019 17:11
To: Rob Stradling <rob@sectigo.com>
Cc: Paul Wouters <paul@nohats.ca>; Andrew Ayer <agwa@andrew= ayer.name>; Trans <trans@ietf.org>; Alissa Cooper <alissa@coope= rw.in>
Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draf= t-ietf-trans-rfc6962-bis-33
 


On Wed, Sep 25, 2019 at 12:16 PM Ro= b Stradling <rob@sectigo.com> = wrote:
On 24/09/2019 18:38, Paul Wouters wrote:
> On Tue, 24 Sep 2019, Andrew Ayer wrote:
>
>>> While I agree with you, I am just a WG chair. So we need to he= ar a few
>>> more opinions of people and then if there is a consensus, we c= an go
>>> ahead and make this change.
>>
>> I'm also not sure what "this change" would be, but I agr= ee with the
>> other comments here that CT shouldn't provide a mechanism for logs= to
>> change URL.
>
> I meant the clarification text of Base URL change (verus a potential > other consensus of text that would allow updating the base url)
>
> I'm not sure what the policy is for declaring a registry append only.<= br> > Maybe leave a comment in for IANA whether or not that needs text?

In -33, section 10.6.1 says:
   "Each application for the allocation of a Log ID MUST be = accompanied
    by:
      - the Log's Base URL (see Section 4.1).
      - a Contact (including contact information), from whom= further
        information can be obtained.
      - an Owner (including contact information), who is aut= horized to
        change this Log ID allocation."

I think we should fold "Owner" and "Contact" into just = one field named
"Log Operator", and clarify that the only part of a Log ID Regist= ry
entry that can be updated is the log operator's contact information.

Also, given that log operators are permitted to allocate Log IDs from
other OID arcs (see section 4.4), ISTM that we also need to update
section 4.1 to say that a log's Base URL is immutable.

Furthermore, ISTM that it would help to be explicit about the
immutability of each and every log parameter.

Here's a PR that attempts to resolve all of the above:
https://github.com/google/certificat= e-transparency-rfcs/pull/314
I agree with Rob and Ryan's stance - as demonstrated with 6962 deploym= ent, client agility would address the issue of logs wanting to change their= URLs (and I do not recall an occasion where having the ability to change j= ust the log URL would have been helpful).
 


> Or alternatively, in the text for the Expert Review, mention the
> registry is strictly append-only ?

There is no Expert Review text relating to the Log ID Registry.

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--_000_DM6PR17MB31624457FAC84E6D7DC91AE2AA9C0DM6PR17MB3162namp_-- From nobody Wed Oct 2 11:49:13 2019 Return-Path: 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 9B66E12087F for ; Wed, 2 Oct 2019 11:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 cUgtuvxEMZn5 for ; Wed, 2 Oct 2019 11:49:09 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710077.outbound.protection.outlook.com [40.107.71.77]) (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 6B84C120867 for ; Wed, 2 Oct 2019 11:49:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W3TqvpJ2OTakwGMSW5IKbJ2ekBGadUJw+0FHVpQVv1ehyosYCqjFqBeVXmEfb9sF2G2B4Yap9jbJ6jCNpeBNNxdteRHwinIlMCYwlXjoPf7IpDo3kZrpKJHk4jNTey8XrHEfNoAF2GKBebg5uAHil2c3Mv3z/mD/060LJGSwosLDMAO8Rd77GKJOaD6ncjD+VXEBg+41n6v2TSrNDeNPWS5pLXJkuvBjxawtBpeT+++73PXm1TsDYX7rlNvc7WZEvcdxUL7wKy2EFzzbSjjgLse5t88eKxsg6bEGNx99FT1LLaWPtlQz9MxSkmF0pLEwmX77rPhvToEmYDqKOrv5iw== 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=8PXp3+8nm8NF0EJCdKWlPf1K/j+SVMBAQkh+qghy32o=; b=K5I3mLCwKKGcDazYuuFCqLAiFm/0ijTVG7/iiDq62svB3K5b25NGIyWuuWqKsPQfWDQESeqG25kt7cznyU8sXDRT4Lqsc1jDFRjT5Jn0zgtIIFk2G6cUCgxCJlFCMUrjXeQHWGRl2ZvU/K0NxczIU4V+ev9lbjGkGQl9fJxoeub5bM8p0qEr9oqJIaHNSB0vPT7OLIBh+HTHU522zmHUzG8j1da1ff53waRcmaQLXKCKrA7bh/sxMkB/l0BBtoPDq07kfSudTLR5lTyt9toCPeZfnxXowrAuQZgNM1QRC6CDWzT62c/6W6sxprvz60YVyLMQ40xVt4JgwRUTOApS3g== 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=8PXp3+8nm8NF0EJCdKWlPf1K/j+SVMBAQkh+qghy32o=; b=fvKZWRe2aQaJ6A4zGA0rFg+ZDmaO5nO8nXIVPXh/KYWv8OBb18gdUQJDsetuBLjSJlZQFoc3dO3qdfUiT7kgfG1Ae9K8J8ZjH15idXX0MOF81zupZ+AXGYx6TjH57GovjI5Lq5FyZVEKX+CYOVc2SDJ6IEmBOdXpQ3+6YgV+jdc= Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB2955.namprd17.prod.outlook.com (20.178.228.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Wed, 2 Oct 2019 18:49:08 +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; Wed, 2 Oct 2019 18:49:08 +0000 From: Rob Stradling To: "trans@ietf.org" CC: "Manger, James" , Andrew Ayer Thread-Topic: [Trans] draft-ietf-trans-rfc6962-bis-33: base URL vs Thread-Index: AdVvREj2DdEV5M/hT+uTLxGHks8RfwDfW8cAABCTjgABk2Y2CQ== Date: Wed, 2 Oct 2019 18:49:07 +0000 Message-ID: References: <627fc1e2-b31a-f735-d85b-f16966a744ca@sectigo.com>, <20190924141520.376fbedc7f469fe9971568f7@andrewayer.name> In-Reply-To: <20190924141520.376fbedc7f469fe9971568f7@andrewayer.name> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; x-originating-ip: [185.69.144.9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: dc4522e4-d527-434e-ca28-08d7476934fc x-ms-traffictypediagnostic: DM6PR17MB2955: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0178184651 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(39850400004)(366004)(376002)(199004)(189003)(8936002)(25786009)(91956017)(105004)(76116006)(236005)(54896002)(8676002)(9686003)(1730700003)(102836004)(81156014)(6506007)(478600001)(6306002)(53546011)(446003)(2906002)(606006)(14444005)(64756008)(2351001)(19627405001)(66946007)(66476007)(66446008)(966005)(66556008)(71190400001)(71200400001)(55016002)(5660300002)(5640700003)(7736002)(76176011)(99286004)(33656002)(54906003)(81166006)(7696005)(6436002)(316002)(486006)(14454004)(6916009)(186003)(86362001)(52536014)(256004)(26005)(6246003)(2501003)(6116002)(229853002)(3846002)(4326008)(66066001)(74316002)(476003)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2955; 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: DizKQTI+RufN6XouTccirn9ck9jsGtWpqiRPZVoFO4CAshD5FNewaKhUEH0xjxeWrqXT4rtj66lEfCoKF0dNcO8sogyR8LIkCYNbQCXlcIgbdbTszRtgKxBa3LinGZ4ipp3eBP+1pV3kNKeUvruW58His+Ic6nqWjvfWT/is4p0jKibFNRzBoUfpKjuVtOzj/k/U1kLn/qX/+xYreDOtyI4PLMJD+pWy3mgc34Crk3ot3lE9urNFdO6lBmLK3Ptd9xplz8yCp0XVZxO/2QHw3PJH0BCaPGk3CXvb1n5zjjMByzsvuU6QPQuVreAFeoQNqfNKKBfnTIxmWzfmY8y9UQcDa4E4llFUTU9TNlSSy9+CXymCZndrW0BJ3QvrCwWmg/Tl+KQ0d/0zq+HU5SUgldtNC5CD+5oiE4YMp2oWx658Z5bWl1ctvwd6GNoOHb6gjt7hpvY0ZRHETaIDKDw5LA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR17MB3162421FA5F9B3E45C9701D6AA9C0DM6PR17MB3162namp_" MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: dc4522e4-d527-434e-ca28-08d7476934fc X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2019 18:49:07.8107 (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: lG66LW+Z2IzH1jsikJ1x1LuVpRmrZfvWSQ8mOYnatBYOblQlNtfww3E5Wv251MiqyeYt+MD5OVSDLUiLE4Kdxw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2955 Archived-At: Subject: Re: [Trans] draft-ietf-trans-rfc6962-bis-33: base URL vs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 18:49:12 -0000 --_000_DM6PR17MB3162421FA5F9B3E45C9701D6AA9C0DM6PR17MB3162namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, Melinda, May I go ahead and merge https://github.com/google/certificate-transparency= -rfcs/pull/313? James (via a private message) and Andrew have both given it the thumbs up, = but it's still not clear to me what the 6962-bis authors can or can't do at= this point in the editing cycle. Thanks. ________________________________ From: Andrew Ayer Sent: 24 September 2019 19:15 To: Rob Stradling Cc: Manger, James ; trans@ietf.org Subject: Re: [Trans] draft-ietf-trans-rfc6962-bis-33: base URL vs On Tue, 24 Sep 2019 10:20:46 +0000 Rob Stradling wrote: > [Chairs: Given the stage we're at with this document, please could I > ask you to confirm whether or not we may adopt James's editorial > suggestions?] > > On 20/09/2019 03:17, Manger, James wrote: > > Editorial suggestions for draft-ietf-trans-rfc6962-bis. > > James: Thanks! I think your editorial suggestions add clarity. > > Here's a PR: > https://github.com/google/certificate-transparency-rfcs/pull/313 This is a good change. With RFC6962, some implementations include "https://" when addressing logs and others don't. This change makes clear that "https://" should be included. Regards, Andrew --_000_DM6PR17MB3162421FA5F9B3E45C9701D6AA9C0DM6PR17MB3162namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul, Melinda,


James (via a private message) and Andrew have both given it the thumbs up, = but it's still not clear to me what the 6962-bis authors can or c= an't do at this point in the editing cycle.

Thanks.

From: Andrew Ayer <agwa@= andrewayer.name>
Sent: 24 September 2019 19:15
To: Rob Stradling <rob@sectigo.com>
Cc: Manger, James <James.H.Manger@team.telstra.com>; trans@iet= f.org <trans@ietf.org>
Subject: Re: [Trans] draft-ietf-trans-rfc6962-bis-33: base URL vs &l= t;log server>
 
On Tue, 24 Sep 2019 10:20:46 +0000
Rob Stradling <rob@sectigo.com> wrote:

> [Chairs: Given the stage we're at with this document, please could I > ask you to confirm whether or not we may adopt James's editorial
> suggestions?]
>
> On 20/09/2019 03:17, Manger, James wrote:
> > Editorial suggestions for draft-ietf-trans-rfc6962-bis.
>
> James: Thanks!  I think your editorial suggestions add clarity. >
> Here's a PR:
> https://github.com/google/certificate-transparency-rfcs/pull/313=

This is a good change.  With RFC6962, some implementations include
"https://" when addressing logs and others don't.  This chan= ge
makes clear that "https://" should be included.

Regards,
Andrew
--_000_DM6PR17MB3162421FA5F9B3E45C9701D6AA9C0DM6PR17MB3162namp_-- From nobody Wed Oct 2 13:34:01 2019 Return-Path: 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 B692912002F for ; Wed, 2 Oct 2019 13:33:59 -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 LR-e_DwukvFj for ; Wed, 2 Oct 2019 13:33:57 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 231DD120018 for ; Wed, 2 Oct 2019 13:33:57 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46k7C70jVszJsK; Wed, 2 Oct 2019 22:33:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570048435; bh=dS098yfwH1pQr4LH3ejgS/MpwCWh4NG/XHUjqGKRCMo=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=TFbbT7rxBBORSpz1ZW/5LjnyJucFbcijhgafWKiGKc9PfuBFlC9X+XpBpzuvKXauQ ScSwdFz692wfCFLvh+HIacqWsV4ag4GFeu+zb3xlxx2cAL6DXVH1+GGVajQjj76neg uNXaHxmElkBulncUHIBVqpJoqDMMM+dFlsO4TUtM= 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 4YDFu6nJRzSS; Wed, 2 Oct 2019 22:33:53 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 2 Oct 2019 22:33:52 +0200 (CEST) Received: from [10.199.47.64] (199-7-157-65.eng.wind.ca [199.7.157.65]) (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 B61EBB378B; Wed, 2 Oct 2019 16:33:50 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B61EBB378B Content-Type: multipart/alternative; boundary=Apple-Mail-B8479737-B3C9-4C5E-A05F-35C5D18563BA Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Wed, 2 Oct 2019 16:33:48 -0400 Cc: "trans@ietf.org" , "Manger, James" , Andrew Ayer Content-Transfer-Encoding: 7bit Message-Id: <865F1869-312D-417F-8423-C408ACB07098@nohats.ca> References: <627fc1e2-b31a-f735-d85b-f16966a744ca@sectigo.com> <20190924141520.376fbedc7f469fe9971568f7@andrewayer.name> To: Rob Stradling Archived-At: Subject: Re: [Trans] draft-ietf-trans-rfc6962-bis-33: base URL vs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Oct 2019 20:34:00 -0000 --Apple-Mail-B8479737-B3C9-4C5E-A05F-35C5D18563BA Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Go ahead Rob, Thanks Sent from my iPhone > On Oct 2, 2019, at 14:49, Rob Stradling wrote: >=20 > Paul, Melinda, >=20 > May I go ahead and merge https://github.com/google/certificate-transparenc= y-rfcs/pull/313? >=20 > James (via a private message) and Andrew have both given it the thumbs up,= but it's still not clear to me what the 6962-bis authors can or can't do at= this point in the editing cycle. >=20 > Thanks. >=20 > From: Andrew Ayer > Sent: 24 September 2019 19:15 > To: Rob Stradling > Cc: Manger, James ; trans@ietf.org > Subject: Re: [Trans] draft-ietf-trans-rfc6962-bis-33: base URL vs > =20 > On Tue, 24 Sep 2019 10:20:46 +0000 > Rob Stradling wrote: >=20 > > [Chairs: Given the stage we're at with this document, please could I > > ask you to confirm whether or not we may adopt James's editorial > > suggestions?] > >=20 > > On 20/09/2019 03:17, Manger, James wrote: > > > Editorial suggestions for draft-ietf-trans-rfc6962-bis. > >=20 > > James: Thanks! I think your editorial suggestions add clarity. > >=20 > > Here's a PR: > > https://github.com/google/certificate-transparency-rfcs/pull/313 >=20 > This is a good change. With RFC6962, some implementations include > "https://" when addressing logs and others don't. This change > makes clear that "https://" should be included. >=20 > Regards, > Andrew > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --Apple-Mail-B8479737-B3C9-4C5E-A05F-35C5D18563BA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Go ahead Rob,

Thanks

Sent from my iPhone

On Oct 2, 2019, at 14:49, Rob Stradling <rob@sectigo.com> wrote:

Paul, Melinda,


James (via a private message) and Andrew have both given it the thumbs up, but it's still not clear to me what the 6962-bis authors can or can't do at this point in the editing cycle.

Thanks.

From: Andrew Ayer <agwa@andrewayer.name>
Sent: 24 September 2019 19:15
To: Rob Stradling <rob@sectigo.com>
Cc: Manger, James <James.H.Manger@team.telstra.com>; trans@ietf.org <trans@ietf.org>
Subject: Re: [Trans] draft-ietf-trans-rfc6962-bis-33: base URL vs <log server>
 
On Tue, 24 Sep 2019 10:20:46 +0000
Rob Stradling <rob@sectigo.com> wrote:

> [Chairs: Given the stage we're at with this document, please could I
> ask you to confirm whether or not we may adopt James's editorial
> suggestions?]
>
> On 20/09/2019 03:17, Manger, James wrote:
> > Editorial suggestions for draft-ietf-trans-rfc6962-bis.
>
> James: Thanks!  I think your editorial suggestions add clarity.
>
> Here's a PR:
> https://github.com/google/certificate-transparency-rfcs/pull/313

This is a good change.  With RFC6962, some implementations include
"https://" when addressing logs and others don't.  This change
makes clear that "https://" should be included.

Regards,
Andrew
_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--Apple-Mail-B8479737-B3C9-4C5E-A05F-35C5D18563BA-- From nobody Thu Oct 3 02:37:26 2019 Return-Path: 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 C5B401200A3 for ; Thu, 3 Oct 2019 02:37:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 V5r65q5mvjkZ for ; Thu, 3 Oct 2019 02:37:21 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-eopbgr790087.outbound.protection.outlook.com [40.107.79.87]) (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 539601200C5 for ; Thu, 3 Oct 2019 02:37:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cYgCnTCnvXXNiap8KWiumRKIdgCzbTbC67edl4WkiGaIvABq5wUI/L+3VPZHNBwY7pRovoYGhqGmDuuOurbjRMJp20QN6VHgt2feLYV2Wv8xUP+MSLaTZQsBQhUNcfqYj/2CTUGMnWEgeniXEVnD0AOe5SYbKRtAzMp5++5ZuFdPOASaZbOu5jQlpTqFwWm5dIBRS4Mo2NMNQgqDDCSnearCMJoFA4EAVgmRvKF7HOmaBQV+cXtUVfH6crNXz8uhML04neVsItDHU/Ktr/V9slhbZNomewUJ7Id1y4S7+1ZQoWc6UIt+m95ccXAagakQ6WWU3H2s4E4K/5uemiZrCg== 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=YCwXgijPEKRcX0rEsxL+kWZ/XWpnCu2EFEB2YsTthFo=; b=Xgbk8qjDKnO5DthDPiC6XRW0RdRsyRT1KIZmYP6S11/UGRlvPmgYsP41BrNK6FxF45gnfA1BVvBNiKMUnnNAKtmwo65o1s/90eVD9K/S3nk8cGSGlxPJ+NYMMlBtWfBqUWD8g2JAskkg/NupTkU6mdAlry2HzN+aMeh8G/9qqUlNIHgNtBy/Z7oRnBYQf4kBK0tjmpSCcq8G3kqFgz8abr2CHYqV6juQ99K6g0py4dbRx86MwP/EG70I2SqbhCaA7LfkTYQP5SY5neU+YEJf+OLv+balx0jFeCMaij/tx+1X5WRZ41Dm2vhr0gXOJzWsLiapY0i87rP8pQCihyQ6BA== 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=YCwXgijPEKRcX0rEsxL+kWZ/XWpnCu2EFEB2YsTthFo=; b=IrRq00gaAm3jCFxPBZatsJUUMyjqJH1jbcJOkf3mSFCSjTX3rUQ6nGqoeTL6sDNU+x6/6MxHtyj2bAgyXcBa4W+bgLqIsHgVx7QIz8Q5XFTNjpDnEN0CfKD/EcF2lhJfiN2xVIE2fGyAqh2vUVaG9UHSA8Ge4LPcnpdgV22Ye8U= Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB3290.namprd17.prod.outlook.com (20.176.126.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Thu, 3 Oct 2019 09:37:19 +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; Thu, 3 Oct 2019 09:37:18 +0000 From: Rob Stradling To: Paul Wouters CC: "trans@ietf.org" , "Manger, James" , Andrew Ayer Thread-Topic: [Trans] draft-ietf-trans-rfc6962-bis-33: base URL vs Thread-Index: AdVvREj2DdEV5M/hT+uTLxGHks8RfwDfW8cAABCTjgABk2Y2CQADxJsAABtcSoA= Date: Thu, 3 Oct 2019 09:37:18 +0000 Message-ID: <422232c3-213b-1dab-ad1c-ae64ad33e53f@sectigo.com> References: <627fc1e2-b31a-f735-d85b-f16966a744ca@sectigo.com> <20190924141520.376fbedc7f469fe9971568f7@andrewayer.name> <865F1869-312D-417F-8423-C408ACB07098@nohats.ca> In-Reply-To: <865F1869-312D-417F-8423-C408ACB07098@nohats.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LNXP265CA0034.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5c::22) 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: be06b51f-3079-4e26-8307-08d747e5487d x-ms-traffictypediagnostic: DM6PR17MB3290: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(376002)(136003)(366004)(396003)(346002)(199004)(189003)(6916009)(9886003)(66446008)(66556008)(64756008)(66476007)(66946007)(5660300002)(6436002)(25786009)(36756003)(316002)(229853002)(6306002)(71190400001)(71200400001)(54906003)(6512007)(256004)(14444005)(4326008)(6486002)(8676002)(46003)(8936002)(81156014)(81166006)(446003)(31686004)(11346002)(305945005)(86362001)(486006)(386003)(7736002)(99286004)(53546011)(476003)(102836004)(2616005)(2906002)(6506007)(52116002)(76176011)(186003)(14454004)(6116002)(6246003)(478600001)(966005)(31696002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB3290; 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: 4rd9I/bd9PyrSANqjkLE8jXp23P946pvtlv655TJ7Zn8EIQaml/KCR1YxFPkGgVg43lT/1NBp6TmPE2QzqAQwj/+Iw/sqVvM/mjk3qaoZNRkKor8V+j6j1Qj/fKsSoRfZ24C0Yg/D72I11YC3zP762njMzplPVoTJWmwIHqPwwFCltsioQLq5nh0Xf/Zqalh2Kb09i3Dvwe21R9fV844EU5QtsfgqaJbcXzT/AoG2pcEIberRJ0kZuw4Pj/3XvAe8TMWL9WZ2xG5LZ6UxYYbCLoLZ7UsD8tRjIo2FnRTFw70PqM8fYs3OjwjiGqOelSTAs5eu0MfmgNtmbpC2IHTVFgrQ3CTfe8rwhTyBuvJPhVvKJQsHm7B/mynPrVjYchJLQfknB8X0QCFCHi/PciiqjiPAloiBWtBU8xju08Nrt8UGQr2efaNsRnHcqnArUNm/CZml6r3zV8JsD5VKXjRRw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <88660F02B0EAB847ADC8E9555E7A84A5@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: be06b51f-3079-4e26-8307-08d747e5487d X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2019 09:37:18.7461 (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: wpO9SRG3hoED7AxXNr1imai+7nRYNH79bKu93xuEuY8uepajR30/nYZtqEeNtN9L3K7oLm3nsaRDGoh7/NqapQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3290 Archived-At: Subject: Re: [Trans] draft-ietf-trans-rfc6962-bis-33: base URL vs X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 09:37:25 -0000 VGhhbmtzLiAgTWVyZ2VkLg0KDQpPbiAwMi8xMC8yMDE5IDIxOjMzLCBQYXVsIFdvdXRlcnMgd3Jv dGU6DQo+IEdvIGFoZWFkIFJvYiwNCj4gDQo+IFRoYW5rcw0KPiANCj4gU2VudCBmcm9tIG15IGlQ aG9uZQ0KPiANCj4gT24gT2N0IDIsIDIwMTksIGF0IDE0OjQ5LCBSb2IgU3RyYWRsaW5nIDxyb2JA c2VjdGlnby5jb20gDQo+IDxtYWlsdG86cm9iQHNlY3RpZ28uY29tPj4gd3JvdGU6DQo+IA0KPj4g UGF1bCwgTWVsaW5kYSwNCj4+DQo+PiBNYXkgSSBnbyBhaGVhZCBhbmQgbWVyZ2UgDQo+PiBodHRw czovL2dpdGh1Yi5jb20vZ29vZ2xlL2NlcnRpZmljYXRlLXRyYW5zcGFyZW5jeS1yZmNzL3B1bGwv MzEzPw0KPj4NCj4+IEphbWVzICh2aWEgYSBwcml2YXRlIG1lc3NhZ2UpIGFuZCBBbmRyZXcgaGF2 ZSBib3RoIGdpdmVuIGl0IHRoZSB0aHVtYnMgDQo+PiB1cCwgYnV0IGl0J3Mgc3RpbGwgbm90IGNs ZWFyIHRvIG1lIHdoYXQgdGhlIDY5NjItYmlzIGF1dGhvcnMgY2FuIG9yIA0KPj4gY2FuJ3QgZG8g YXQgdGhpcyBwb2ludCBpbiB0aGUgZWRpdGluZyBjeWNsZS4NCj4+DQo+PiBUaGFua3MuDQo+Pg0K Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+PiAqRnJvbToqIEFuZHJldyBBeWVyIDxhZ3dhQGFuZHJld2F5 ZXIubmFtZSA8bWFpbHRvOmFnd2FAYW5kcmV3YXllci5uYW1lPj4NCj4+ICpTZW50OiogMjQgU2Vw dGVtYmVyIDIwMTkgMTk6MTUNCj4+ICpUbzoqIFJvYiBTdHJhZGxpbmcgPHJvYkBzZWN0aWdvLmNv bSA8bWFpbHRvOnJvYkBzZWN0aWdvLmNvbT4+DQo+PiAqQ2M6KiBNYW5nZXIsIEphbWVzIDxKYW1l cy5ILk1hbmdlckB0ZWFtLnRlbHN0cmEuY29tIA0KPj4gPG1haWx0bzpKYW1lcy5ILk1hbmdlckB0 ZWFtLnRlbHN0cmEuY29tPj47IHRyYW5zQGlldGYub3JnIA0KPj4gPG1haWx0bzp0cmFuc0BpZXRm Lm9yZz4gPHRyYW5zQGlldGYub3JnIDxtYWlsdG86dHJhbnNAaWV0Zi5vcmc+Pg0KPj4gKlN1Ympl Y3Q6KiBSZTogW1RyYW5zXSBkcmFmdC1pZXRmLXRyYW5zLXJmYzY5NjItYmlzLTMzOiBiYXNlIFVS TCB2cyANCj4+IDxsb2cgc2VydmVyPg0KPj4gT24gVHVlLCAyNCBTZXAgMjAxOSAxMDoyMDo0NiAr MDAwMA0KPj4gUm9iIFN0cmFkbGluZyA8cm9iQHNlY3RpZ28uY29tIDxtYWlsdG86cm9iQHNlY3Rp Z28uY29tPj4gd3JvdGU6DQo+Pg0KPj4gPiBbQ2hhaXJzOiBHaXZlbiB0aGUgc3RhZ2Ugd2UncmUg YXQgd2l0aCB0aGlzIGRvY3VtZW50LCBwbGVhc2UgY291bGQgSQ0KPj4gPiBhc2sgeW91IHRvIGNv bmZpcm0gd2hldGhlciBvciBub3Qgd2UgbWF5IGFkb3B0IEphbWVzJ3MgZWRpdG9yaWFsDQo+PiA+ IHN1Z2dlc3Rpb25zP10NCj4+ID4gDQo+PiA+IE9uIDIwLzA5LzIwMTkgMDM6MTcsIE1hbmdlciwg SmFtZXMgd3JvdGU6DQo+PiA+ID4gRWRpdG9yaWFsIHN1Z2dlc3Rpb25zIGZvciBkcmFmdC1pZXRm LXRyYW5zLXJmYzY5NjItYmlzLg0KPj4gPiANCj4+ID4gSmFtZXM6IFRoYW5rcyHCoCBJIHRoaW5r IHlvdXIgZWRpdG9yaWFsIHN1Z2dlc3Rpb25zIGFkZCBjbGFyaXR5Lg0KPj4gPiANCj4+ID4gSGVy ZSdzIGEgUFI6DQo+PiA+IGh0dHBzOi8vZ2l0aHViLmNvbS9nb29nbGUvY2VydGlmaWNhdGUtdHJh bnNwYXJlbmN5LXJmY3MvcHVsbC8zMTMNCj4+DQo+PiBUaGlzIGlzIGEgZ29vZCBjaGFuZ2UuwqAg V2l0aCBSRkM2OTYyLCBzb21lIGltcGxlbWVudGF0aW9ucyBpbmNsdWRlDQo+PiAiaHR0cHM6Ly8i IHdoZW4gYWRkcmVzc2luZyBsb2dzIGFuZCBvdGhlcnMgZG9uJ3QuwqAgVGhpcyBjaGFuZ2UNCj4+ IG1ha2VzIGNsZWFyIHRoYXQgImh0dHBzOi8vIiBzaG91bGQgYmUgaW5jbHVkZWQuDQo+Pg0KPj4g UmVnYXJkcywNCj4+IEFuZHJldw0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCj4+IFRyYW5zIG1haWxpbmcgbGlzdA0KPj4gVHJhbnNAaWV0Zi5vcmcg PG1haWx0bzpUcmFuc0BpZXRmLm9yZz4NCj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vdHJhbnMNCg0KLS0gDQpSb2IgU3RyYWRsaW5nDQpTZW5pb3IgUmVzZWFyY2ggJiBE ZXZlbG9wbWVudCBTY2llbnRpc3QNCkVtYWlsOiByb2JAc2VjdGlnby5jb20NCkJyYWRmb3JkLCBV Sw0KT2ZmaWNlOiArNDQxMjc0MDI0NzA3DQpTZWN0aWdvIExpbWl0ZWQNCg0KVGhpcyBtZXNzYWdl IGFuZCBhbnkgZmlsZXMgYXNzb2NpYXRlZCB3aXRoIGl0IG1heSBjb250YWluIGxlZ2FsbHkgDQpw cml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLiBJZiB5 b3UgYXJlIG5vdCB0aGUgDQppbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90IHBlcm1pdHRl ZCB0byB1c2UsIGNvcHksIG9yIGZvcndhcmQgaXQsIA0KaW4gd2hvbGUgb3IgaW4gcGFydCB3aXRo b3V0IHRoZSBleHByZXNzIGNvbnNlbnQgb2YgdGhlIHNlbmRlci4gUGxlYXNlIA0Kbm90aWZ5IHRo ZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwsIGRpc3JlZ2FyZCB0aGUgZm9yZWdvaW5nIG1lc3NhZ2Vz LCBhbmQgDQpkZWxldGUgaXQgaW1tZWRpYXRlbHkuDQo= From nobody Thu Oct 3 03:03:09 2019 Return-Path: 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 0F20A120119 for ; Thu, 3 Oct 2019 03:03:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 7Msn7R25dsDj for ; Thu, 3 Oct 2019 03:03:05 -0700 (PDT) Received: from mail-yw1-xc2a.google.com (mail-yw1-xc2a.google.com [IPv6:2607:f8b0:4864:20::c2a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A030120113 for ; Thu, 3 Oct 2019 03:03:05 -0700 (PDT) Received: by mail-yw1-xc2a.google.com with SMTP id i207so775360ywc.9 for ; Thu, 03 Oct 2019 03:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+BQEcVAKL8zIh05aSzVzACi3gDAcwqShGXH5zcJIp+w=; b=XenRMXR4Ul/OsJRkPuIj6xu0lCs4rRriDWgyDmp0YUkzJ4NU+LxjTGRKPBB1v74a2K KEG89p4Jj0ZyKB2IZFLQBD2rLXyc8pndHlGg0Y+iIVrzxjpyYNNSWQUGGiTFheYo5jMT 7QoM2w28puHotAp9E4lkftyQ3SY4Vgdfl3ADtYYXf9PNqkrNimCBWp13Qe/IJtq5ztiN TxoW2yWxko8w3wzJbzCabPBRQW7cpbLRv/1E4FOqUY70/wkqF6osCzuhLzl4x4XyRTyx 5SW3g4e/N2HhMHTgXLIa0z9kFzSWneMLV+W/G/lW2SF39p4krIFN5L/jFlA1KSG57lKB XLHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+BQEcVAKL8zIh05aSzVzACi3gDAcwqShGXH5zcJIp+w=; b=kRfFlHqDWGikT40vIUttPxq+0s6R9TmoG8cHpl7QOGb1cut8e68KXlBMXMVKCB6XIX EXbF94dIIhcz7vayExeSVFQCQpXPAsFg36RXGo9Ijan9vrni4VceS8GHN1hlRtTALvfW D1T2ZA436yP9IwPrsA1pF2YGdHuifhVkEbRN94EZ5kf7G8TSd+atYskfvGv07EFhFR0N 4Flkg4vG/coCC1bdTTco4P1rK5kSlqopLYozIvetrC2NU2IiHFDCHdFuaj26onU7VoC2 9J3yi642hgsLHoxF//wYZbYW7yt4n7fH19pEK9tSAGjfGZNe8NJHG6KvsQmEsI0dzKQ9 4+lg== X-Gm-Message-State: APjAAAUu7ehPB4N7r2o5AFCGLl5LJ2cs17hq+GDvMdmOyIVe3wrE6gTB V5m+3HOU7eWOZg0r1uJbMYEXUJfDRj6xqH2NY6uFWw== X-Google-Smtp-Source: APXvYqzzyC7BQ2eLDFX+aQDTI0tJewBWmJzNr0eum9RYsP6jUd7IrbT0ZryPXij1DU2RwZiWh+U/gUxzTtCICTOKzN0= X-Received: by 2002:a81:3182:: with SMTP id x124mr5361165ywx.411.1570096982803; Thu, 03 Oct 2019 03:03:02 -0700 (PDT) MIME-Version: 1.0 References: <20190916100800.5b62d43c0f28e30269f41b7a@andrewayer.name> <21a9ea1e-124b-3bf2-72f5-4dc755d4061b@sectigo.com> <39d0ea14-36ca-b311-91df-074c1346f8c3@sectigo.com> In-Reply-To: From: Eran Messeri Date: Thu, 3 Oct 2019 11:02:35 +0100 Message-ID: To: Rob Stradling Cc: Ryan Sleevi , "trans@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ecae420593feb0ab" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 10:03:08 -0000 --000000000000ecae420593feb0ab Content-Type: text/plain; charset="UTF-8" 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 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 > *Sent:* 25 September 2019 17:58 > *To:* Rob Stradling > *Cc:* Ryan Sleevi ; 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 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 > https://www.ietf.org/mailman/listinfo/trans > > --000000000000ecae420593feb0ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
That reasoning makes sense to me. If 6962-bis precertifica= te is not a certificate but 6962-bis states that the existence of a precert= ificate 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 <ro= b@sectigo.com> wrote:
Hi Eran.=C2=A0 OCSP (RFC6960, RFC5019) responses and CRLs (RFC5280) provide= status information for certificates (RFC5280).=C2=A0 In CTv1 (RFC6962), pr= ecertificates are certificates; whereas in CTv2 (6962-bis), precertificates= are (by design!) not certificates.

The "effective MUST NOT" is because anything that is not a certif= icate (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 extendin= g the OCSP protocol to report statuses of CTv2 precertificates.=C2=A0 But u= ntil the OCSP protocol is extended in this way, the fact is that...the OCSP protocol has not yet been extended i= n this way.

I think 6962-bis should extend the OCSP protocol in this way.=C2=A0 If it c= an be avoided, I don't think it should be left to CT client policies to= extend IETF protocols.

Fro= m: Eran Messeri <eranm@google.com>
Sent: 25 September 2019 17:58
To: Rob Stradling <rob@sectigo.com>
Cc: Ryan Sleevi <ryan-ietf@sleevi.com>; trans@ietf.org <trans@ietf.org>
Subject: Re: [Trans] Precertificates and revocation
=C2=A0
Rob, what leads you to say that "6962-bis has an effe= ctive MUST NOT" regarding the CA not having to provide status informat= ion for a 6962-bis precertificate?

I agree it'd be helpful to add a clarification in 6962-bis regardi= ng CAs possibly being asked about revocation status of a not-yet-issued cer= tificate. I just want to understand where 6962-bis prevents CAs from publis= hing revocation info for 6962-bis precerts.

On Mon, Sep 23, 2019 at 12:21 PM Rob Stradling <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.=C2=A0 This is because, whichever way you look at it, a C= T
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 belon= g
in a TLS client policy document.=C2=A0 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.=C2=A0 In order to avo= id
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.=C2=A0 A TLS client policy could then profile th= at
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/d= raft-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 poli= cy
> decision has implications on other protocols. Thus I think it's mu= ch
> more appropriately discussed among individual implementations.
>
> As a protocol for allowing both the pre-disclosure of a certificate an= d
> post-disclosure of a certificate. We saw, rather extensively in the > Threat Model document, different perspectives on policies regarding ho= w
> pre-disclosure should be treated and handled. For example, using the <= br> > protocol in 6962 or -bis, it's possible to use CT as a means of > detecting and correcting certificates prior to issuance (the discussio= n
> about Logs applying rules to certificates). Similarly, it's possib= le for
> CT as a protocol to be used entirely internal to an organization, as <= br> > part of audit logging for external audits via a common protocol, even =
> with the inclusion of data that might otherwise be inappropriate for <= br> > publicly-exposed logs.
>
> So I do think that, from the point of view of the RFCs, it's a mat= ter 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 <= br> > 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 i= mpact,
> if any, it has on other protocols. Just as RFC 5280 does not define, f= or
> 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 cove= rs
> the operational aspects and implications of a PKI that may use, in par= t
> or whole, these RFCs.

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--000000000000ecae420593feb0ab-- From nobody Thu Oct 3 07:11:56 2019 Return-Path: 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 E35AA12092A for ; Thu, 3 Oct 2019 07:11:53 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 p0yHf3kt4svt for ; Thu, 3 Oct 2019 07:11:49 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-eopbgr740059.outbound.protection.outlook.com [40.107.74.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A37C812093D for ; Thu, 3 Oct 2019 07:11:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jXz5A4Lxx3lvBLkDFa9SQxKoqJy4lfNOmDs8RE7l0Wz7WCwf86GZ7qIanXM5pMeWXa38D9y+gOC+yDHqERvL45xV0bZWirbblLsc9N81bVBTUGAVaQoBk0a9k8oKJ0qM6AD6phWpmhzqcq012l3rXiNBzNHq+b4JLtekZ9lBSQS5OpyWSKVQus29rxys1pIiL64NPtzJO9dVuh0DVZz2Nr6kgJk4W1hSs3ulclyGW2yy3/HVa7/EGRyhJNQtMrlhF1O2nfBw7kCkKD9SlHTAfUiapdTOw2amGDpjs4sO6Sa7XKZHMzF1bBmU/njlk8hnyrHbvoTmCuEL5xFY60ZzMQ== 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=GtNPQP9TTuguGfz8MxXpbdVCHw6JAgPV6kl8HgZdpnI=; b=RIb+BA3cHTiuPL6/8Dgp8X+3U94zNGSr6Y2YbkoX7SVEcpzOZAVIFXSxUwo4lQiO9lRMaFiv8KdO1FC3rVC4HTITOtMkj7g69nJGqyW/bsvAAvzxPdwB0H17WJxPPXznn7NcTzsYI09WwuxAlgw86VGkf8e6mSgK1d03oGd9TtztQKVTgcirb0hv3bT8rKKfKa9FnlczbzBMRPpLoVOUa0HEYaU7Vg8jNm62X3jnK0/uLiDtWTkrU/S93ThmPoe77ZJI+JiLh/S19lKy9lnPEvO2WBlnsqgDtxxpPkXj9eVdu71rWDJ6jsgNskXzVzhW37SHMLozpHNtoATNdPwR1A== 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=GtNPQP9TTuguGfz8MxXpbdVCHw6JAgPV6kl8HgZdpnI=; b=N/N6HwAOP1mIa40VA1flHd+ZvXGaEfuf6PgkjEw28Dk2B/7lzmUoG2LWtnVw46+dln37+br58U7rcd9MbG4aba7OmpRZ3q7t4o8rLHlR13in47vcEyuIvB4vh5wzJVb69nqmksI02/fnaEbXWcFMGx0yomJxHU8003LRAj1b4Vc= Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB3612.namprd17.prod.outlook.com (52.132.248.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.20; Thu, 3 Oct 2019 14:11:43 +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; Thu, 3 Oct 2019 14:11:43 +0000 From: Rob Stradling To: "trans@ietf.org" CC: Eran Messeri , Ryan Sleevi Thread-Topic: [Trans] Precertificates and revocation Thread-Index: AQHVb7qjeJ8k5jrm8UOJQ5rvAEBgSKc0vfSAgARklACAA4LeAIABh9wegAqWpICAAEWXgA== Date: Thu, 3 Oct 2019 14:11:43 +0000 Message-ID: <401e243a-98bb-7030-51e4-69faadb8977e@sectigo.com> References: <20190916100800.5b62d43c0f28e30269f41b7a@andrewayer.name> <21a9ea1e-124b-3bf2-72f5-4dc755d4061b@sectigo.com> <39d0ea14-36ca-b311-91df-074c1346f8c3@sectigo.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0035.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:61::23) 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: 17468479-d47d-418d-68a7-08d7480b9e2b x-ms-traffictypediagnostic: DM6PR17MB3612: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01792087B6 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(136003)(366004)(376002)(39850400004)(189003)(199004)(40224003)(476003)(66476007)(54906003)(66556008)(478600001)(64756008)(66446008)(2616005)(66946007)(446003)(11346002)(229853002)(6306002)(6512007)(186003)(486006)(102836004)(53546011)(66574012)(6506007)(386003)(2351001)(99286004)(46003)(31686004)(14454004)(6916009)(36756003)(6116002)(76176011)(52116002)(71190400001)(71200400001)(6436002)(966005)(25786009)(2501003)(316002)(6246003)(8936002)(14444005)(2906002)(305945005)(5640700003)(7736002)(5660300002)(4326008)(31696002)(8676002)(81156014)(86362001)(81166006)(6486002)(256004)(1730700003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB3612; H:DM6PR17MB3162.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: EH2lxVYr/1WO+VYF/RWDatSkKVDjJ+l2ZFVkHTMayw6Tm6RvkOcakIZyeiBRBuHTfWQf8VWe4Lvbft/2g/M0Ps+WBpChXBRhg1wyAwlhk94ibJNMl3OY8A7OjG4E1FAs3sMSeHzySvsYhgfGAgqsFG2pDvZyPNrM/4djrWIdXOYxo5pX/9MWa38JfIq8qppdAwc/fWRAOrWOk6tiCFkF1FdJFWnE1p4bcP3bM7cf/iujQM1XeZXYvEOAInLsI+TkL9XflnBntiMrCQdPnGc3lis1CH3APcK3/Np56rtbxvI4Ae953BvVSBqjAyFU5i5djRQ6Jhu/yGXwJaRWKO0q7/ufR0WItpTvTFKoV1LJsVcIfbzEWlzHxDpLPr376vDip4reo4TbPQv2BUqd72o2U/nZl+8I9dqyFVklIChHUbUGSBeBaeY/V1dFrqoSmfPfh+UWheG0fDbuxDmr9Wi3rQ== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <84335ABAFAC5CE47840512900245A808@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 17468479-d47d-418d-68a7-08d7480b9e2b X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Oct 2019 14:11:43.3648 (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: S81us3Axs9yCr83i9A90jyCtVf+Apt5Qv1ytwPseOfVwlF6AARHa5QQr90QGCw7gpsgD8s5I/3Mg4va/5HvuOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3612 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Oct 2019 14:11:55 -0000 SGVyZSdzIGEgUFI6DQpodHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlL2NlcnRpZmljYXRlLXRyYW5z cGFyZW5jeS1yZmNzL3B1bGwvMzE1DQoNCkZlZWRiYWNrIHdlbGNvbWUuDQoNCk9uIDAzLzEwLzIw MTkgMTE6MDIsIEVyYW4gTWVzc2VyaSB3cm90ZToNCj4gVGhhdCByZWFzb25pbmcgbWFrZXMgc2Vu c2UgdG8gbWUuIElmIDY5NjItYmlzIHByZWNlcnRpZmljYXRlIGlzIG5vdCBhIA0KPiBjZXJ0aWZp Y2F0ZSBidXQgNjk2Mi1iaXMgc3RhdGVzIHRoYXQgdGhlIGV4aXN0ZW5jZSBvZiBhIHByZWNlcnRp ZmljYXRlIA0KPiBpbmRpY2F0ZXMgaW50ZW50IHRvIGlzc3VlIGEgY2VydGlmaWNhdGUsIHRoZW4g Y2hlY2tpbmcgd2hldGhlciB0aGUgZmluYWwgDQo+IGNlcnRpZmljYXRlIGhhcyBiZWVuIGlzc3Vl ZC9yZXZva2VkIHZpYSBPQ1NQIG1ha2VzIHNlbnNlLg0KPiANCj4gT24gVGh1LCBTZXAgMjYsIDIw MTkgYXQgNTo0MCBQTSBSb2IgU3RyYWRsaW5nIDxyb2JAc2VjdGlnby5jb20gDQo+IDxtYWlsdG86 cm9iQHNlY3RpZ28uY29tPj4gd3JvdGU6DQo+IA0KPiAgICAgSGkgRXJhbi7CoCBPQ1NQIChSRkM2 OTYwLCBSRkM1MDE5KSByZXNwb25zZXMgYW5kIENSTHMgKFJGQzUyODApDQo+ICAgICBwcm92aWRl IHN0YXR1cyBpbmZvcm1hdGlvbiBmb3IgY2VydGlmaWNhdGVzIChSRkM1MjgwKS7CoCBJbiBDVHYx DQo+ICAgICAoUkZDNjk2MiksIHByZWNlcnRpZmljYXRlcyBhcmUgY2VydGlmaWNhdGVzOyB3aGVy ZWFzIGluIENUdjINCj4gICAgICg2OTYyLWJpcyksIHByZWNlcnRpZmljYXRlcyBhcmUgKGJ5IGRl c2lnbiEpIG5vdCBjZXJ0aWZpY2F0ZXMuDQo+IA0KPiAgICAgVGhlICJlZmZlY3RpdmUgTVVTVCBO T1QiIGlzIGJlY2F1c2UgYW55dGhpbmcgdGhhdCBpcyBub3QgYQ0KPiAgICAgY2VydGlmaWNhdGUg KGJlIGl0IGEgQ1R2MiBwcmVjZXJ0aWZpY2F0ZSwgYSBjYXQgR0lGLCBvciB3aGF0ZXZlcikgaXMN Cj4gICAgIG5vdCBpbiBzY29wZSBmb3IgT0NTUCwgYXMgY3VycmVudGx5IHNwZWNpZmllZC4NCj4g DQo+ICAgICBUaGUgZmFjdCB0aGF0IGEgQ1R2MiBwcmVjZXJ0aWZpY2F0ZSBoYXMgYSBzZXJpYWwg bnVtYmVyIHRoYXQgaXMNCj4gICAgIGludGVuZGVkIHRvIHN1YnNlcXVlbnRseSBiZWxvbmcgdG8g YSBjZXJ0aWZpY2F0ZSBtYWtlcyBpdCBwb3NzaWJsZQ0KPiAgICAgdG8gaW1hZ2luZSBleHRlbmRp bmcgdGhlIE9DU1AgcHJvdG9jb2wgdG8gcmVwb3J0IHN0YXR1c2VzIG9mIENUdjINCj4gICAgIHBy ZWNlcnRpZmljYXRlcy7CoCBCdXQgdW50aWwgdGhlIE9DU1AgcHJvdG9jb2wgaXMgZXh0ZW5kZWQg aW4gdGhpcw0KPiAgICAgd2F5LCB0aGUgZmFjdCBpcyB0aGF0Li4udGhlIE9DU1AgcHJvdG9jb2wg aGFzIG5vdCB5ZXQgYmVlbiBleHRlbmRlZA0KPiAgICAgaW4gdGhpcyB3YXkuDQo+IA0KPiAgICAg SSB0aGluayA2OTYyLWJpcyBzaG91bGQgZXh0ZW5kIHRoZSBPQ1NQIHByb3RvY29sIGluIHRoaXMg d2F5LsKgIElmIGl0DQo+ICAgICBjYW4gYmUgYXZvaWRlZCwgSSBkb24ndCB0aGluayBpdCBzaG91 bGQgYmUgbGVmdCB0byBDVCBjbGllbnQNCj4gICAgIHBvbGljaWVzIHRvIGV4dGVuZCBJRVRGIHBy b3RvY29scy4NCj4gDQo+ICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gICAgICpGcm9tOiogRXJhbiBN ZXNzZXJpIDxlcmFubUBnb29nbGUuY29tIDxtYWlsdG86ZXJhbm1AZ29vZ2xlLmNvbT4+DQo+ICAg ICAqU2VudDoqIDI1IFNlcHRlbWJlciAyMDE5IDE3OjU4DQo+ICAgICAqVG86KiBSb2IgU3RyYWRs aW5nIDxyb2JAc2VjdGlnby5jb20gPG1haWx0bzpyb2JAc2VjdGlnby5jb20+Pg0KPiAgICAgKkNj OiogUnlhbiBTbGVldmkgPHJ5YW4taWV0ZkBzbGVldmkuY29tDQo+ICAgICA8bWFpbHRvOnJ5YW4t aWV0ZkBzbGVldmkuY29tPj47IHRyYW5zQGlldGYub3JnDQo+ICAgICA8bWFpbHRvOnRyYW5zQGll dGYub3JnPiA8dHJhbnNAaWV0Zi5vcmcgPG1haWx0bzp0cmFuc0BpZXRmLm9yZz4+DQo+ICAgICAq U3ViamVjdDoqIFJlOiBbVHJhbnNdIFByZWNlcnRpZmljYXRlcyBhbmQgcmV2b2NhdGlvbg0KPiAg ICAgUm9iLCB3aGF0IGxlYWRzIHlvdSB0byBzYXkgdGhhdCAiNjk2Mi1iaXMgaGFzIGFuIGVmZmVj dGl2ZSBNVVNUIE5PVCINCj4gICAgIHJlZ2FyZGluZyB0aGUgQ0Egbm90IGhhdmluZyB0byBwcm92 aWRlIHN0YXR1cyBpbmZvcm1hdGlvbiBmb3IgYQ0KPiAgICAgNjk2Mi1iaXMgcHJlY2VydGlmaWNh dGU/DQo+IA0KPiAgICAgSSBhZ3JlZSBpdCdkIGJlIGhlbHBmdWwgdG8gYWRkIGEgY2xhcmlmaWNh dGlvbiBpbiA2OTYyLWJpcyByZWdhcmRpbmcNCj4gICAgIENBcyBwb3NzaWJseSBiZWluZyBhc2tl ZCBhYm91dCByZXZvY2F0aW9uIHN0YXR1cyBvZiBhIG5vdC15ZXQtaXNzdWVkDQo+ICAgICBjZXJ0 aWZpY2F0ZS4gSSBqdXN0IHdhbnQgdG8gdW5kZXJzdGFuZCB3aGVyZSA2OTYyLWJpcyBwcmV2ZW50 cyBDQXMNCj4gICAgIGZyb20gcHVibGlzaGluZyByZXZvY2F0aW9uIGluZm8gZm9yIDY5NjItYmlz IHByZWNlcnRzLg0KPiANCj4gICAgIE9uIE1vbiwgU2VwIDIzLCAyMDE5IGF0IDEyOjIxIFBNIFJv YiBTdHJhZGxpbmcgPHJvYkBzZWN0aWdvLmNvbQ0KPiAgICAgPG1haWx0bzpyb2JAc2VjdGlnby5j b20+PiB3cm90ZToNCj4gDQo+ICAgICAgICAgSWYgNjk2Mi1iaXMgc2F5cyBub3RoaW5nIGFib3V0 IHRoaXMgdG9waWMsIHRoZW4gSVNUTSB0aGF0IHRoZQ0KPiAgICAgICAgIGRlZmF1bHQNCj4gICAg ICAgICBlZmZlY3RpdmUgcmVxdWlyZW1lbnQgd2lsbCBiZSB0aGF0IGEgQ0EgTVVTVCBOT1QgcHJv dmlkZSBPQ1NQDQo+ICAgICAgICAgc3RhdHVzIGZvcg0KPiAgICAgICAgIGEgKENUIHYyKSBwcmVj ZXJ0aWZpY2F0ZSB3aGVyZSB0aGUgY29ycmVzcG9uZGluZyBjZXJ0aWZpY2F0ZSBoYXMNCj4gICAg ICAgICBub3QNCj4gICAgICAgICAoeWV0KSBiZWVuIGlzc3VlZC7CoCBUaGlzIGlzIGJlY2F1c2Us IHdoaWNoZXZlciB3YXkgeW91IGxvb2sgYXQNCj4gICAgICAgICBpdCwgYSBDVA0KPiAgICAgICAg IHYyIHByZWNlcnRpZmljYXRlIGlzIG5vdCBhICJjZXJ0aWZpY2F0ZSIgYWNjb3JkaW5nIHRvDQo+ ICAgICAgICAgUkZDNTI4MC9SRkM2OTYwL1JGQzUwMTkuDQo+IA0KPiAgICAgICAgIEkgYWdyZWUg dGhhdCBhIHN0YXRlbWVudCBzdWNoIGFzICJDQXMgTVVTVCBwcm92aWRlIE9DU1Agc3RhdHVzDQo+ ICAgICAgICAgZm9yIENUIHYyDQo+ICAgICAgICAgcHJlY2VydGlmaWNhdGVzIiB3b3VsZCBub3Qg YmVsb25nIGluIDY5NjItYmlzLCBidXQgd291bGQgaW5zdGVhZA0KPiAgICAgICAgIGJlbG9uZw0K PiAgICAgICAgIGluIGEgVExTIGNsaWVudCBwb2xpY3kgZG9jdW1lbnQuwqAgSG93ZXZlciwgSSB3 b3VsZCBwcmVmZXIgdG8NCj4gICAgICAgICBhdm9pZCB0aGUNCj4gICAgICAgICBzaXR1YXRpb24g d2hlcmUgNjk2Mi1iaXMgaGFzIGFuIGVmZmVjdGl2ZSBNVVNUIE5PVCBidXQgd2hlcmUNCj4gICAg ICAgICAoc29tZSwgYnV0DQo+ICAgICAgICAgbm90IG5lY2Vzc2FyaWx5IGFsbCkgVExTIGNsaWVu dCBwb2xpY2llcyBoYXZlIGEgTVVTVC7CoCBJbiBvcmRlcg0KPiAgICAgICAgIHRvIGF2b2lkDQo+ ICAgICAgICAgc3VjaCBhIGNvbmZsaWN0LCBJIHRoaW5rIGl0IHdvdWxkIGJlIGhlbHBmdWwgZm9y IDY5NjItYmlzIHRvDQo+ICAgICAgICAgb3V0bGluZSB0aGUNCj4gICAgICAgICBwb2xpY3kgc3Bh Y2UgYnkgbWFraW5nIHRoZSBmb2xsb3dpbmcgcG9pbnRzOg0KPiANCj4gICAgICAgICAxLiBTaW5j ZSBpc3N1YW5jZSBvZiBhIHByZWNlcnRpZmljYXRlIGBQYCBpcyBhIGJpbmRpbmcNCj4gICAgICAg ICBjb21taXRtZW50IHRvDQo+ICAgICAgICAgaXNzdWUgYSBjb3JyZXNwb25kaW5nIGNlcnRpZmlj YXRlIGBDYCwgbW9uaXRvcnMgbWF5IHJlYXNvbmFibHkNCj4gICAgICAgICBhc3N1bWUNCj4gICAg ICAgICB0aGF0IGBDYCBoYXMgYmVlbiBpc3N1ZWQuDQo+ICAgICAgICAgMi4gSXQgZm9sbG93cyB0 aGF0IG1vbml0b3JzIG1heSB3aXNoIHRvIHJlcXVlc3Qgc3RhdHVzIGluZm9ybWF0aW9uDQo+ICAg ICAgICAgKGUuZy4sIHZpYSBDUkwgYW5kL29yIE9DU1ApIGZvciB0aGUgc2VyaWFsIG51bWJlciBv ZiBgUGAsIGV2ZW4NCj4gICAgICAgICB0aG91Z2gNCj4gICAgICAgICAodW5iZWtub3duc3QgdG8g dGhlIG1vbml0b3IpIGBDYCBoYXMgbm90IGFjdHVhbGx5IGJlZW4gaXNzdWVkLg0KPiAgICAgICAg IDMuIEFsdGhvdWdoIGBQYCBpcyBub3QgYSAiY2VydGlmaWNhdGUiIGFjY29yZGluZyB0bw0KPiAg ICAgICAgIFJGQzUyODAvUkZDNjk2MC9SRkM1MDE5LCBzb21lIFRMUyBjbGllbnRzIG1heSBoYXZl IHBvbGljaWVzIHRoYXQNCj4gICAgICAgICByZXF1aXJlDQo+ICAgICAgICAgQ0FzIHRvIHByb3Zp ZGUgY2VydGlmaWNhdGUgc3RhdHVzIChlLmcuLCBzaWduZWQgT0NTUCByZXNwb25zZXMNCj4gICAg ICAgICBhbmQvb3INCj4gICAgICAgICBDUkxzKSBmb3IgdGhlIHNlcmlhbCBudW1iZXIgb2YgYFBg LCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90DQo+ICAgICAgICAgYENgIGhhcw0KPiAgICAg ICAgIGJlZW4gaXNzdWVkLg0KPiANCj4gICAgICAgICBNYWtpbmcgdGhlc2UgcG9pbnRzIHdvdWxk IHRyYW5zZm9ybSA2OTYyLWJpcydzIGVmZmVjdGl2ZQ0KPiAgICAgICAgIHJlcXVpcmVtZW50DQo+ ICAgICAgICAgZnJvbSBhIE1VU1QgTk9UIGludG8gYSBNQVkuwqAgQSBUTFMgY2xpZW50IHBvbGlj eSBjb3VsZCB0aGVuDQo+ICAgICAgICAgcHJvZmlsZSB0aGF0DQo+ICAgICAgICAgdG8gYSBNVVNU IHdpdGhvdXQgaW50cm9kdWNpbmcgYW55IGNvbmZsaWN0Lg0KPiANCj4gICAgICAgICBJU1RNIHRo YXQgdGhpcyBhcHByb2FjaCBvZiBvdXRsaW5pbmcgdGhlIHBvbGljeSBzcGFjZSBidXQgbm90DQo+ ICAgICAgICAgc2V0dGluZw0KPiAgICAgICAgIHBvbGljeSB3b3VsZCBiZSBjb25zaXN0ZW50IHdp dGgsIGZvciBleGFtcGxlLA0KPiAgICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXRyYW5zLXJmYzY5NjItYmlzLTMzI3NlY3Rpb24tNi4xLg0KPiANCj4gICAgICAg ICBPbiAyMC8wOS8yMDE5IDE3OjE2LCBSeWFuIFNsZWV2aSB3cm90ZToNCj4gICAgICAgICAgPiBB cyBJIG1lbnRpb25lZCBlbHNld2hlcmUsIEknbSBub3Qgc3VyZSB0aGlzIGlzIGFuIGVudGlyZWx5 DQo+ICAgICAgICAgdXNlZnVsIG9yDQo+ICAgICAgICAgID4gcHJvZHVjdGl2ZSBjb25jZXJuIHRv IGJlIHJhaXNpbmcgYXQgdGhpcyB0aW1lLiBJIGhhdmUgYWxzbw0KPiAgICAgICAgIHNoYXJlZCB0 aGF0IEkNCj4gICAgICAgICAgPiB0aGluayB0aGlzIGlzIGEgcXVlc3Rpb24gb2YgcG9saWN5IHRo YW4gcHJvdG9jb2wsIGV2ZW4gdGhvdWdoDQo+ICAgICAgICAgdGhlIHBvbGljeQ0KPiAgICAgICAg ICA+IGRlY2lzaW9uIGhhcyBpbXBsaWNhdGlvbnMgb24gb3RoZXIgcHJvdG9jb2xzLiBUaHVzIEkg dGhpbmsNCj4gICAgICAgICBpdCdzIG11Y2gNCj4gICAgICAgICAgPiBtb3JlIGFwcHJvcHJpYXRl bHkgZGlzY3Vzc2VkIGFtb25nIGluZGl2aWR1YWwgaW1wbGVtZW50YXRpb25zLg0KPiAgICAgICAg ICA+DQo+ICAgICAgICAgID4gQXMgYSBwcm90b2NvbCBmb3IgYWxsb3dpbmcgYm90aCB0aGUgcHJl LWRpc2Nsb3N1cmUgb2YgYQ0KPiAgICAgICAgIGNlcnRpZmljYXRlIGFuZA0KPiAgICAgICAgICA+ IHBvc3QtZGlzY2xvc3VyZSBvZiBhIGNlcnRpZmljYXRlLiBXZSBzYXcsIHJhdGhlciBleHRlbnNp dmVseQ0KPiAgICAgICAgIGluIHRoZQ0KPiAgICAgICAgICA+IFRocmVhdCBNb2RlbCBkb2N1bWVu dCwgZGlmZmVyZW50IHBlcnNwZWN0aXZlcyBvbiBwb2xpY2llcw0KPiAgICAgICAgIHJlZ2FyZGlu ZyBob3cNCj4gICAgICAgICAgPiBwcmUtZGlzY2xvc3VyZSBzaG91bGQgYmUgdHJlYXRlZCBhbmQg aGFuZGxlZC4gRm9yIGV4YW1wbGUsDQo+ICAgICAgICAgdXNpbmcgdGhlDQo+ICAgICAgICAgID4g cHJvdG9jb2wgaW4gNjk2MiBvciAtYmlzLCBpdCdzIHBvc3NpYmxlIHRvIHVzZSBDVCBhcyBhIG1l YW5zIG9mDQo+ICAgICAgICAgID4gZGV0ZWN0aW5nIGFuZCBjb3JyZWN0aW5nIGNlcnRpZmljYXRl cyBwcmlvciB0byBpc3N1YW5jZSAodGhlDQo+ICAgICAgICAgZGlzY3Vzc2lvbg0KPiAgICAgICAg ICA+IGFib3V0IExvZ3MgYXBwbHlpbmcgcnVsZXMgdG8gY2VydGlmaWNhdGVzKS4gU2ltaWxhcmx5 LCBpdCdzDQo+ICAgICAgICAgcG9zc2libGUgZm9yDQo+ICAgICAgICAgID4gQ1QgYXMgYSBwcm90 b2NvbCB0byBiZSB1c2VkIGVudGlyZWx5IGludGVybmFsIHRvIGFuDQo+ICAgICAgICAgb3JnYW5p emF0aW9uLCBhcw0KPiAgICAgICAgICA+IHBhcnQgb2YgYXVkaXQgbG9nZ2luZyBmb3IgZXh0ZXJu YWwgYXVkaXRzIHZpYSBhIGNvbW1vbg0KPiAgICAgICAgIHByb3RvY29sLCBldmVuDQo+ICAgICAg ICAgID4gd2l0aCB0aGUgaW5jbHVzaW9uIG9mIGRhdGEgdGhhdCBtaWdodCBvdGhlcndpc2UgYmUN Cj4gICAgICAgICBpbmFwcHJvcHJpYXRlIGZvcg0KPiAgICAgICAgICA+IHB1YmxpY2x5LWV4cG9z ZWQgbG9ncy4NCj4gICAgICAgICAgPg0KPiAgICAgICAgICA+IFNvIEkgZG8gdGhpbmsgdGhhdCwg ZnJvbSB0aGUgcG9pbnQgb2YgdmlldyBvZiB0aGUgUkZDcywgaXQncw0KPiAgICAgICAgIGEgbWF0 dGVyIG9mDQo+ICAgICAgICAgID4gcG9saWN5IGFzIHRvIGhvdyB0aGUgZXhpc3RlbmNlIG9mIGEg cHJlLWNlcnRpZmljYXRlIGlzDQo+ICAgICAgICAgdHJlYXRlZCwgd2hpY2gNCj4gICAgICAgICAg PiBhbGlnbnMgd2l0aCB0aGUgcGFydGljdWxhciBpbnRlbmRlZCBkZXBsb3ltZW50IG9mIHRoZSBD VA0KPiAgICAgICAgIHByb3RvY29sLiBJZiBhDQo+ICAgICAgICAgID4gcG9saWN5IChlLmcuIGJ5 IGEgYnJvd3NlciwgZm9yIHRoZSBXZWIgUEtJKSB0cmVhdHMgdGhlDQo+ICAgICAgICAgaXNzdWFu Y2Ugb2YgYQ0KPiAgICAgICAgICA+IHByZS1jZXJ0aWZpY2F0ZSBhcyBhbiB1bnJlYnV0dGFibGUg cHJvb2Ygb2YgYW4gZXF1aXZhbGVudA0KPiAgICAgICAgIGNlcnRpZmljYXRlLA0KPiAgICAgICAg ICA+IHdoaWNoIGlzIGNlcnRhaW5seSBvbmUgb2YgdGhlIGNvcmUgdGhpbmdzIENUIGVuYWJsZXMg cG9saWN5DQo+ICAgICAgICAgdG8gc3RhdGUsDQo+ICAgICAgICAgID4gdGhlbiBpdCBuYXR1cmFs bHkgZm9sbG93cyB0aGF0IGl0IG11c3QgYmUgdHJlYXRlZCBhcyBzdWNoIHdpdGhpbg0KPiAgICAg ICAgICA+IHByb3RvY29scyB0aGF0IGFyZSBrZXllZCBvbiB0aGUgaXNzdWFuY2Ugb2YgY2VydGlm aWNhdGVzLg0KPiAgICAgICAgICA+DQo+ICAgICAgICAgID4gSXQncyBhbiBvcGVyYXRpb25hbCBj b25jZXJuLCBkZWZpbmVkIGJ5IGxvY2FsIHBvbGljeSwgYXMgdG8NCj4gICAgICAgICB3aGF0IGlt cGFjdCwNCj4gICAgICAgICAgPiBpZiBhbnksIGl0IGhhcyBvbiBvdGhlciBwcm90b2NvbHMuIEp1 c3QgYXMgUkZDIDUyODAgZG9lcyBub3QNCj4gICAgICAgICBkZWZpbmUsIGZvcg0KPiAgICAgICAg ICA+IGV4YW1wbGUsIHdoYXQgZm9ybXMgb2YgbmFtZXMgdG8gaW5jbHVkZSB3aXRoaW4gYQ0KPiAg ICAgICAgIGRpc3Rpbmd1aXNoZWQgbmFtZSwgSSdtDQo+ICAgICAgICAgID4gbm90IGNvbnZpbmNl ZCB0aGF0IHRoaXMgd291bGQgZXZlbiBiZWxvbmcgaW4gNjk2Mi1iaXMsDQo+ICAgICAgICAgYmVj YXVzZSBpdCBjb3ZlcnMNCj4gICAgICAgICAgPiB0aGUgb3BlcmF0aW9uYWwgYXNwZWN0cyBhbmQg aW1wbGljYXRpb25zIG9mIGEgUEtJIHRoYXQgbWF5DQo+ICAgICAgICAgdXNlLCBpbiBwYXJ0DQo+ ICAgICAgICAgID4gb3Igd2hvbGUsIHRoZXNlIFJGQ3MuDQo+IA0KPiAgICAgICAgIC0tIA0KPiAg ICAgICAgIFJvYiBTdHJhZGxpbmcNCj4gICAgICAgICBTZW5pb3IgUmVzZWFyY2ggJiBEZXZlbG9w bWVudCBTY2llbnRpc3QNCj4gICAgICAgICBTZWN0aWdvIExpbWl0ZWQNCj4gDQo+ICAgICAgICAg X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICAg ICBUcmFucyBtYWlsaW5nIGxpc3QNCj4gICAgICAgICBUcmFuc0BpZXRmLm9yZyA8bWFpbHRvOlRy YW5zQGlldGYub3JnPg0KPiAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vdHJhbnMNCj4gDQoNCi0tIA0KUm9iIFN0cmFkbGluZw0KU2VuaW9yIFJlc2VhcmNoICYg RGV2ZWxvcG1lbnQgU2NpZW50aXN0DQpFbWFpbDogcm9iQHNlY3RpZ28uY29tDQpCcmFkZm9yZCwg VUsNCk9mZmljZTogKzQ0MTI3NDAyNDcwNw0KU2VjdGlnbyBMaW1pdGVkDQoNClRoaXMgbWVzc2Fn ZSBhbmQgYW55IGZpbGVzIGFzc29jaWF0ZWQgd2l0aCBpdCBtYXkgY29udGFpbiBsZWdhbGx5IA0K cHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBwcm9wcmlldGFyeSBpbmZvcm1hdGlvbi4gSWYg eW91IGFyZSBub3QgdGhlIA0KaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdCBwZXJtaXR0 ZWQgdG8gdXNlLCBjb3B5LCBvciBmb3J3YXJkIGl0LCANCmluIHdob2xlIG9yIGluIHBhcnQgd2l0 aG91dCB0aGUgZXhwcmVzcyBjb25zZW50IG9mIHRoZSBzZW5kZXIuIFBsZWFzZSANCm5vdGlmeSB0 aGUgc2VuZGVyIGJ5IHJlcGx5IGVtYWlsLCBkaXNyZWdhcmQgdGhlIGZvcmVnb2luZyBtZXNzYWdl cywgYW5kIA0KZGVsZXRlIGl0IGltbWVkaWF0ZWx5Lg0K From nobody Thu Oct 10 15:00:51 2019 Return-Path: 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 C0F901200C3 for ; Thu, 10 Oct 2019 15:00:48 -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, HTML_MESSAGE=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 ImLSdoe9twQM for ; Thu, 10 Oct 2019 15:00:45 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780041.outbound.protection.outlook.com [40.107.78.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68AF1200C1 for ; Thu, 10 Oct 2019 15:00:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=iiRgZw9Ar2iO1CL92HySaQIm4g6dccf0FDhlKy7Of6qPkEObfaQYp3NadYgp5Yz7eixJktltYa+7ZMx+dqlf5Hx47vKmqkh/Uz9dP42TK8+JfHK+13Hb41AcgoVURTQraAGP6wwDvBSWDD6/f3cXPt2dan5SXdGId5905bQcB+npXlDW98slTtxYkR3QhvTKgJGk30FhCTKFmYWd4mBiQwa8rkQ7PPguU+DOdIKyF5d4Sq32oYSazTTCrrUvIpEqZaaiy3HdfBAXR1XwR5hDTjD7SVOIJrdpy3vs0uEkuOtzXY79Uske/DN9kJSrYnV7DcituwQFYvylIJsEITqhrQ== 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=pcf7vgukTNlVK3qoHF6c7lrDIt4FhL5MWeDrRY4/4iE=; b=iw906+fT74urb/j9UtNtRYXi5zrIk6JEGyJ5nUoRD4yGDbRrHFRzveg3uT/WoOWDyCJYaCP04heYmr8puzAlapNB1Ahyy+h/erKg/3LP1ORiJgsR1/lhysek7Cm2Ezfw2eMFHC3OziTQpdlgyOP3S1GiGilk/nZoedA8QCzmEw8/oDlPPxhIhrd6xt1ZgAvpaeyhTfVVa/i3FAx6z3sABrEjFPOLcklJ50p0fGeVddZpWW2ZuAZOMfm6+pavX59uvZYhKwJzSjjirgQlJY0j7fvIbupc48NJ3EsaOMknhZdcxeZsLEXDUq41lJh0x7YhLM3TjoZrh3z5JazQakQanA== 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=pcf7vgukTNlVK3qoHF6c7lrDIt4FhL5MWeDrRY4/4iE=; b=O+n1sQF/Mi5jXxsBIYCR04oB2m9jLHrDU0zG72P4/mwdtU7exi+d71yuCa9LVE6D2c7Rpd+xeI+z0gBcXmrEF7M6igFK4XtH/wW2FU92rh2aedwOcaZTZLsZ1HMNRFOgoy4Plr2kH8XiE0cdcBJrYQPhjFRnxyVe2Ff5uhXX61U= Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB3947.namprd17.prod.outlook.com (20.180.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.17; Thu, 10 Oct 2019 22:00:42 +0000 Received: from DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695]) by DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695%3]) with mapi id 15.20.2347.016; Thu, 10 Oct 2019 22:00:42 +0000 From: Rob Stradling To: Paul Wouters CC: Alissa Cooper , Eran Messeri , Trans , Andrew Ayer Thread-Topic: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-trans-rfc6962-bis-33 Thread-Index: AQHVblRQ0CWg5MVGO0ywZM7RXIf1a6czBmsAgAApD4CABg+gAIAAkfwAgADwIYCAAF/EgIABJ5cAgABSrgCACyngT4AMynB8 Date: Thu, 10 Oct 2019 22:00:42 +0000 Message-ID: References: <4632c221-c207-72c4-83c3-ecc8dcbf2ba7@sectigo.com> <20190924075519.6a9daab1def6475bd26e5370@andrewayer.name> <2fa45a40-c12c-4d85-a0ab-17c83fdd2443@sectigo.com>, , In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; x-originating-ip: [143.159.112.29] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b757a0e9-2f5a-4280-56ba-08d74dcd4b8c x-ms-traffictypediagnostic: DM6PR17MB3947: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(136003)(366004)(39860400002)(199004)(189003)(102836004)(105004)(19627405001)(5660300002)(55016002)(486006)(52536014)(6916009)(446003)(6116002)(2906002)(3846002)(186003)(74316002)(26005)(54896002)(476003)(54906003)(316002)(7736002)(9686003)(11346002)(236005)(6306002)(229853002)(6436002)(86362001)(66066001)(33656002)(4326008)(53546011)(6506007)(76176011)(99286004)(966005)(6246003)(25786009)(478600001)(7696005)(606006)(8936002)(91956017)(76116006)(66476007)(66446008)(64756008)(14444005)(71200400001)(66556008)(66946007)(81166006)(8676002)(256004)(81156014)(71190400001)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB3947; 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: oYq/0yNgYNb8gfQ89ACOsscfLkWOnOPTWyESK9Rm0Mx93zcdI5Mk3H8C/xRSQbnAUZ+GCqxXTOpHtJyWydEUNi2oTVp+fyvlRv32uLmoGRk1l7THICan2GubNEX+xL4vm+PqOGXvZQjbAcQRBYe4r5qH9Sc8AsVVlBnwrxux8rZ62mUDYZgBSnBWpuTLscWNpebHTGaLwkHUcGQo5J72G33RXSpC3U9UA92npobNYjDI8rsrbJCiytAc7WdfrHyFXoxr4noYLKEZpsT0arpL8UrQXVwXqyVCE4lGwBtmBUMmRVcjg4xX2Q94dvfWBG5+etHB/ospjfmx4DxM+QneSHYbq2zBLrdOy0KCAAWQIPtus2eubDNLMJc7lqQUHEjhHz0SAtj72H8wmJ6xDeGaaLuhhbiDk80CeDvXi12gpztju82VG/AF816GaXO4jewRB5IGpIARaRZs0c7uEqLeZg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR17MB316272984FAC2D14B237EA65AA940DM6PR17MB3162namp_" MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: b757a0e9-2f5a-4280-56ba-08d74dcd4b8c X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2019 22:00:42.6048 (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: srdwSwYIaY4wJ99rMI3TKt2xvWI6G4kHzoDrKXldSnptJ0Ngxp8qCRtKyhaQZaK6FBUnfaWY2X+pKAfshIyE8Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3947 Archived-At: Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-trans-rfc6962-bis-33 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 22:00:49 -0000 --_000_DM6PR17MB316272984FAC2D14B237EA65AA940DM6PR17MB3162namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul, Still awaiting your feedback on this one. ________________________________ From: Trans on behalf of Rob Stradling Sent: 02 October 2019 19:44 To: Paul Wouters Cc: Alissa Cooper ; Eran Messeri ; Tra= ns ; Andrew Ayer Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-= trans-rfc6962-bis-33 Paul, Does https://github.com/google/certificate-transparency-rfcs/pull/314 addre= ss your concern? May I go ahead and merge this PR? (It's still not clear to me what the 6962-bis authors can or can't do at th= is point in the editing cycle). ________________________________ From: Eran Messeri Sent: 25 September 2019 17:11 To: Rob Stradling Cc: Paul Wouters ; Andrew Ayer ; Tran= s ; Alissa Cooper Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-= trans-rfc6962-bis-33 On Wed, Sep 25, 2019 at 12:16 PM Rob Stradling > wrote: On 24/09/2019 18:38, Paul Wouters wrote: > On Tue, 24 Sep 2019, Andrew Ayer wrote: > >>> While I agree with you, I am just a WG chair. So we need to hear a few >>> more opinions of people and then if there is a consensus, we can go >>> ahead and make this change. >> >> I'm also not sure what "this change" would be, but I agree with the >> other comments here that CT shouldn't provide a mechanism for logs to >> change URL. > > I meant the clarification text of Base URL change (verus a potential > other consensus of text that would allow updating the base url) > > I'm not sure what the policy is for declaring a registry append only. > Maybe leave a comment in for IANA whether or not that needs text? In -33, section 10.6.1 says: "Each application for the allocation of a Log ID MUST be accompanied by: - the Log's Base URL (see Section 4.1). - a Contact (including contact information), from whom further information can be obtained. - an Owner (including contact information), who is authorized to change this Log ID allocation." I think we should fold "Owner" and "Contact" into just one field named "Log Operator", and clarify that the only part of a Log ID Registry entry that can be updated is the log operator's contact information. Also, given that log operators are permitted to allocate Log IDs from other OID arcs (see section 4.4), ISTM that we also need to update section 4.1 to say that a log's Base URL is immutable. Furthermore, ISTM that it would help to be explicit about the immutability of each and every log parameter. Here's a PR that attempts to resolve all of the above: https://github.com/google/certificate-transparency-rfcs/pull/314 I agree with Rob and Ryan's stance - as demonstrated with 6962 deployment, = client agility would address the issue of logs wanting to change their URLs= (and I do not recall an occasion where having the ability to change just t= he log URL would have been helpful). > Or alternatively, in the text for the Expert Review, mention the > registry is strictly append-only ? There is no Expert Review text relating to the Log ID Registry. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ Trans mailing list Trans@ietf.org https://www.ietf.org/mailman/listinfo/trans --_000_DM6PR17MB316272984FAC2D14B237EA65AA940DM6PR17MB3162namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Paul,

Still awaiting your feedback on this one.

From: Trans <trans-bounc= es@ietf.org> on behalf of Rob Stradling <rob@sectigo.com>
Sent: 02 October 2019 19:44
To: Paul Wouters <paul@nohats.ca>
Cc: Alissa Cooper <alissa@cooperw.in>; Eran Messeri <eranm@= google.com>; Trans <trans@ietf.org>; Andrew Ayer <agwa@andreway= er.name>
Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draf= t-ietf-trans-rfc6962-bis-33
 
Paul,


May I go ahead and merge this PR?

(It's still not clear to me what the 6962-bis authors can or can't do at th= is point in the editing cycle).

From: Eran Messeri <er= anm@google.com>
Sent: 25 September 2019 17:11
To: Rob Stradling <rob@sectigo.com>
Cc: Paul Wouters <paul@nohats.ca>; Andrew Ayer <agwa@andrew= ayer.name>; Trans <trans@ietf.org>; Alissa Cooper <alissa@coope= rw.in>
Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draf= t-ietf-trans-rfc6962-bis-33
 


On Wed, Sep 25, 2019 at 12:16 PM = Rob Stradling <rob@sectigo.com>= ; wrote:
On 24/09/2019 18:38, Paul Wouters wrote:
> On Tue, 24 Sep 2019, Andrew Ayer wrote:
>
>>> While I agree with you, I am just a WG chair. So we need to he= ar a few
>>> more opinions of people and then if there is a consensus, we c= an go
>>> ahead and make this change.
>>
>> I'm also not sure what "this change" would be, but I agr= ee with the
>> other comments here that CT shouldn't provide a mechanism for logs= to
>> change URL.
>
> I meant the clarification text of Base URL change (verus a potential > other consensus of text that would allow updating the base url)
>
> I'm not sure what the policy is for declaring a registry append only.<= br> > Maybe leave a comment in for IANA whether or not that needs text?

In -33, section 10.6.1 says:
   "Each application for the allocation of a Log ID MUST be = accompanied
    by:
      - the Log's Base URL (see Section 4.1).
      - a Contact (including contact information), from whom= further
        information can be obtained.
      - an Owner (including contact information), who is aut= horized to
        change this Log ID allocation."

I think we should fold "Owner" and "Contact" into just = one field named
"Log Operator", and clarify that the only part of a Log ID Regist= ry
entry that can be updated is the log operator's contact information.

Also, given that log operators are permitted to allocate Log IDs from
other OID arcs (see section 4.4), ISTM that we also need to update
section 4.1 to say that a log's Base URL is immutable.

Furthermore, ISTM that it would help to be explicit about the
immutability of each and every log parameter.

Here's a PR that attempts to resolve all of the above:
https://github.com/google/certificat= e-transparency-rfcs/pull/314
I agree with Rob and Ryan's stance - as demonstrated with 6962 deploym= ent, client agility would address the issue of logs wanting to change their= URLs (and I do not recall an occasion where having the ability to change j= ust the log URL would have been helpful).
 


> Or alternatively, in the text for the Expert Review, mention the
> registry is strictly append-only ?

There is no Expert Review text relating to the Log ID Registry.

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--_000_DM6PR17MB316272984FAC2D14B237EA65AA940DM6PR17MB3162namp_-- From nobody Thu Oct 10 15:01:42 2019 Return-Path: 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 633411200C1 for ; Thu, 10 Oct 2019 15:01:39 -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, HTML_MESSAGE=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 rhivnEarUv7t for ; Thu, 10 Oct 2019 15:01:35 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780082.outbound.protection.outlook.com [40.107.78.82]) (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 9ABBC120041 for ; Thu, 10 Oct 2019 15:01:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=St5gb5GBFxpWstpbWDakDp7RBNCaLfnLevE06RMykkwIXo2dE/Qp7aEhH1H3Co+8Y70UGWF2OCg8Mhb2iXNGPZnNyr1/CgIDltw4C9qK8NevxyoZVJDNP+daZJAB439h57wz4GARmyRdNyo4ddQrKIsCYKimIrthjejLaBN1RH/Q0vwIWS+8MM4wUoloptE7zhJIo76vQt5gGiWhFealHpuPeGa7WImqBos20urI7kuOw+f3ZAKVUEpLFm+PCCYQalZ+l2PL4IE+4lfE9SyLchp6+BTKgXbMrXigUCTy0FBP5sgbNm+hq3I9Xs9nyi1Qdg+g0HInZuKjzUaeYaTlxw== 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=j87Zf4rtxTNJRNk80Oakymx+zCDgyRyklX8KCCZ6NM8=; b=mJJWgmmu+2MZTn6HUCw1OOoZ7YyWpJAKOby6wSrxD+cUrQt2zo5cDWmFlQZxXF7jqhcQVYVFrpCY/kxXZaC5XjQZhLoLfDDXs+xgB5B7BuE68ftafsLLNLiAxZU7FHrC+i+nEqM8yx0aPKwE5wdUVhc23zcuOoDD4r0BLoS2eZ/lANKec6fpcRsy+q8QUbs7IYaxq01ao5KNgVXBdHTAuwGP2lsHxToC5RJDJ0bvyd3PA/Yy/sZlFYXrsevK1+3v0Fz1ndqqOBrzDYreGQ45eVBAOYzhPyKPLOJLPorczRZi4PLdg6XJ994e4HXp13jFxjD5h+irjFBFGaen8tIcIg== 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=j87Zf4rtxTNJRNk80Oakymx+zCDgyRyklX8KCCZ6NM8=; b=DWeVSUrNw71c1eaWmXUYHTSc3yY+U2Z+jpY8SHVE75LbW0kgB3EyLNmMM7ZFHl5mTZrUFqEhgjN/cx6RVyYjdu4ZVqo/0qL3HlN8peCGScZCLNf/bRUg6A2sWnIVFvNQSmqgq0u1cy7GTPdWpRE9p/s8tqRFIPU1xDpcYhN/p2Y= Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB3947.namprd17.prod.outlook.com (20.180.22.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.17; Thu, 10 Oct 2019 22:01:33 +0000 Received: from DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695]) by DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695%3]) with mapi id 15.20.2347.016; Thu, 10 Oct 2019 22:01:33 +0000 From: Rob Stradling To: "trans@ietf.org" CC: Ryan Sleevi , Eran Messeri Thread-Topic: [Trans] Precertificates and revocation Thread-Index: AQHVb7qjeJ8k5jrm8UOJQ5rvAEBgSKc0vfSAgARklACAA4LeAIABh9wegAqWpICAAEWXgIALg3EF Date: Thu, 10 Oct 2019 22:01:33 +0000 Message-ID: References: <20190916100800.5b62d43c0f28e30269f41b7a@andrewayer.name> <21a9ea1e-124b-3bf2-72f5-4dc755d4061b@sectigo.com> <39d0ea14-36ca-b311-91df-074c1346f8c3@sectigo.com> , <401e243a-98bb-7030-51e4-69faadb8977e@sectigo.com> In-Reply-To: <401e243a-98bb-7030-51e4-69faadb8977e@sectigo.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=rob@sectigo.com; x-originating-ip: [143.159.112.29] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b008074b-52c3-459d-c5b4-08d74dcd69d3 x-ms-traffictypediagnostic: DM6PR17MB3947: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(396003)(136003)(366004)(39850400004)(199004)(189003)(40224003)(102836004)(105004)(19627405001)(5660300002)(55016002)(486006)(52536014)(6916009)(66574012)(446003)(2351001)(6116002)(2501003)(2906002)(3846002)(186003)(74316002)(26005)(54896002)(476003)(54906003)(316002)(7736002)(9686003)(11346002)(236005)(5640700003)(6306002)(229853002)(6436002)(86362001)(66066001)(33656002)(4326008)(53546011)(6506007)(76176011)(99286004)(966005)(6246003)(25786009)(478600001)(7696005)(606006)(8936002)(91956017)(76116006)(66476007)(66446008)(64756008)(14444005)(71200400001)(66556008)(66946007)(81166006)(8676002)(256004)(81156014)(71190400001)(1730700003)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB3947; 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: 9koZQ+uCDXh1v3xs8GWn1NKpfYfDK5gJRvqqO31G2DlZlH5L9eHic3kI9+bZ1nI4s0mGuSTM25A/ByiyxyZma1XUgdWX6cZM6LZenIv2Z7QO71ksXYdW7VkEGQWWXbn2/NnGRkwAhgtfrqe4lWrvl6K0EG5Y10To5VnyJh92WAhfD5eg3S9na4T+ReQE7PwmNqGDANcuvSMh5KT01fXGQyE376LBndBI9KckaJGpQ2T/jgjSUm0Mq+f7yF3S0OfdMkBox2iW4FgGQVJSgVfOqMilY3nrXRVDW9OhEqyEdBlII83cGtTQUsF102b+6fqIYIMLu9s2DmpWyKchIMT1vZUIhDhbYKrEi5fCivsWfD8KeiJokYeoFCzR8svGDTzgtIbwo5zB5G9VuP5XqZ8H9mv7fpfW2Mtfwe9xhpRR/uRo35V8FznnVdT4WrGFspg+mZtcU90KGnWsSfhWLcZJGw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM6PR17MB31620B66797CAD12B9499039AA940DM6PR17MB3162namp_" MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: b008074b-52c3-459d-c5b4-08d74dcd69d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2019 22:01:33.3796 (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: ZND6rW9Wk5g+n76djs+xLA1rAt9rNuKnfqnK52vzN1UnujI2qKyj6nRmxsvVwkFoAr7gx/91LQn2rn/m93ws5w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3947 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 22:01:40 -0000 --_000_DM6PR17MB31620B66797CAD12B9499039AA940DM6PR17MB3162namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Chairs, May I interpret silence as consent, and go ahead and merge this PR? ________________________________ From: Trans on behalf of Rob Stradling Sent: 03 October 2019 15:11 To: trans@ietf.org Cc: Ryan Sleevi ; Eran Messeri 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 > 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 > > *Sent:* 25 September 2019 17:58 > *To:* Rob Stradling > > *Cc:* Ryan Sleevi >; 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 > 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 informatio= n > (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#secti= on-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 o= f > > 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 with= in > > 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 > 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 --_000_DM6PR17MB31620B66797CAD12B9499039AA940DM6PR17MB3162namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Chairs,

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

From: Trans <trans-bounc= es@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 fin= al
> 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>&= gt; wrote:
>
>     Hi Eran.  OCSP (RFC6960, RFC5019) respons= es and CRLs (RFC5280)
>     provide status information for certificates (R= FC5280).  In CTv1
>     (RFC6962), precertificates are certificates; w= hereas in CTv2
>     (6962-bis), precertificates are (by design!) n= ot certificates.
>
>     The "effective MUST NOT" is because = anything that is not a
>     certificate (be it a CTv2 precertificate, a ca= t GIF, or whatever) is
>     not in scope for OCSP, as currently specified.=
>
>     The fact that a CTv2 precertificate has a seri= al number that is
>     intended to subsequently belong to a certifica= te makes it possible
>     to imagine extending the OCSP protocol to repo= rt statuses of CTv2
>     precertificates.  But until the OCSP prot= ocol 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 protoc= ol in this way.  If it
>     can be avoided, I don't think it should be lef= t 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
>     <ma= ilto:ryan-ietf@sleevi.com>>; trans@ietf.org
>     <mailto:t= rans@ietf.org> <trans@ietf.org <mailto:trans@ietf.org>>
>     *Subject:* Re: [Trans] Precertificates and rev= ocation
>     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 stat= us of a not-yet-issued
>     certificate. I just want to understand where 6= 962-bis prevents CAs
>     from publishing revocation info for 6962-bis p= recerts.
>
>     On Mon, Sep 23, 2019 at 12:21 PM Rob Stradling= <rob@sectigo.com
>     <mailto:= rob@sectigo.com>> wrote:
>
>         If 6962-bis says nothi= ng about this topic, then ISTM that the
>         default
>         effective requirement = will be that a CA MUST NOT provide OCSP
>         status for
>         a (CT v2) precertifica= te where the corresponding certificate has
>         not
>         (yet) been issued.&nbs= p; This is because, whichever way you look at
>         it, a CT
>         v2 precertificate is n= ot a "certificate" according to
>         RFC5280/RFC6960/RFC501= 9.
>
>         I agree that a stateme= nt 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-b= is has an effective MUST NOT but where
>         (some, but
>         not necessarily all) T= LS client policies have a MUST.  In order
>         to avoid
>         such a conflict, I thi= nk 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 issu= ed.
>         2. It follows that mon= itors may wish to request status information
>         (e.g., via CRL and/or = OCSP) for the serial number of `P`, even
>         though
>         (unbeknownst to the mo= nitor) `C` has not actually been issued.
>         3. Although `P` is not= a "certificate" according to
>         RFC5280/RFC6960/RFC501= 9, some TLS clients may have policies that
>         require
>         CAs to provide certifi= cate status (e.g., signed OCSP responses
>         and/or
>         CRLs) for the serial n= umber of `P`, regardless of whether or not
>         `C` has
>         been issued.
>
>         Making these points wo= uld 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 intr= oducing any conflict.
>
>         ISTM that this approac= h of outlining the policy space but not
>         setting
>         policy would be consis= tent with, for example,
>         https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-33#section-6.1= .
>
>         On 20/09/2019 17:16, R= yan Sleevi wrote:
>          > As I mentio= ned 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 ha= s implications on other protocols. Thus I think
>         it's much
>          > more approp= riately discussed among individual implementations.
>          >
>          > As a protoc= ol for allowing both the pre-disclosure of a
>         certificate and
>          > post-disclo= sure of a certificate. We saw, rather extensively
>         in the
>          > Threat Mode= l document, different perspectives on policies
>         regarding how
>          > pre-disclos= ure 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 a= nd correcting certificates prior to issuance (the
>         discussion
>          > about Logs = applying rules to certificates). Similarly, it's
>         possible for
>          > CT as a pro= tocol to be used entirely internal to an
>         organization, as
>          > part of aud= it logging for external audits via a common
>         protocol, even
>          > with the in= clusion of data that might otherwise be
>         inappropriate for
>          > publicly-ex= posed logs.
>          >
>          > So I do thi= nk that, from the point of view of the RFCs, it's
>         a matter of
>          > policy as t= o 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-certifi= cate as an unrebuttable proof of an equivalent
>         certificate,
>          > which is ce= rtainly one of the core things CT enables policy
>         to state,
>          > then it nat= urally follows that it must be treated as such within
>          > protocols t= hat are keyed on the issuance of certificates.
>          >
>          > It's an ope= rational 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, wh= at forms of names to include within a
>         distinguished name, I'= m
>          > not convinc= ed that this would even belong in 6962-bis,
>         because it covers
>          > the operati= onal aspects and implications of a PKI that may
>         use, in part
>          > or whole, t= hese 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/tra= ns
>

--
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.or= g/mailman/listinfo/trans
--_000_DM6PR17MB31620B66797CAD12B9499039AA940DM6PR17MB3162namp_-- From nobody Thu Oct 10 15:11:01 2019 Return-Path: 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 AFAF71200C3 for ; Thu, 10 Oct 2019 15:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.995 X-Spam-Level: X-Spam-Status: No, score=-1.995 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, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=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 5GFPuASsmKAj for ; Thu, 10 Oct 2019 15:10:55 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.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 4900712003E for ; Thu, 10 Oct 2019 15:10:55 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 46q4zJ2lBBz35k; Fri, 11 Oct 2019 00:10:52 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1570745452; bh=PHpFlDeqQzTteCqvnC5gYprGtQOf7viWfqmN+hjumRg=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=WXhKyohE2Vw4eyumHkCGzOpxwf/fK+R2d3ZfnDPbu2/0wmC/snDATOP4AUc/BDetz Wy/zUXZIIA9u+NVwUVLsnfHBcJTf6szkeZmwKPKFjWHHfHDoKQMDmum6uo2UboNsbO AsK215cfKPdUo9eUKjroCtI5vvvjwAl1/HJhoLZM= 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 ErRxx4b9N0P2; Fri, 11 Oct 2019 00:10:50 +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 00:10:50 +0200 (CEST) Received: from [10.168.10.175] (199-7-157-60.eng.wind.ca [199.7.157.60]) (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 1C6D06089B51; Thu, 10 Oct 2019 18:10:49 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-26C64DC0-75BE-45F8-8F54-60A3D473CB62 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Thu, 10 Oct 2019 18:10:47 -0400 Cc: Alissa Cooper , Eran Messeri , Trans , Andrew Ayer Content-Transfer-Encoding: 7bit Message-Id: References: <4632c221-c207-72c4-83c3-ecc8dcbf2ba7@sectigo.com> <20190924075519.6a9daab1def6475bd26e5370@andrewayer.name> <2fa45a40-c12c-4d85-a0ab-17c83fdd2443@sectigo.com> To: Rob Stradling Archived-At: Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-trans-rfc6962-bis-33 X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Oct 2019 22:10:59 -0000 --Apple-Mail-26C64DC0-75BE-45F8-8F54-60A3D473CB62 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Go ahead, I didn=E2=80=99t hear any objection. Paul Sent from my iPhone > On Oct 10, 2019, at 18:00, Rob Stradling wrote: >=20 > Paul, >=20 > Still awaiting your feedback on this one. >=20 > From: Trans on behalf of Rob Stradling > Sent: 02 October 2019 19:44 > To: Paul Wouters > Cc: Alissa Cooper ; Eran Messeri ; Tr= ans ; Andrew Ayer > Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draft-ietf= -trans-rfc6962-bis-33 > =20 > Paul, >=20 > Does https://github.com/google/certificate-transparency-rfcs/pull/314 addr= ess your concern? >=20 > May I go ahead and merge this PR? >=20 > (It's still not clear to me what the 6962-bis authors can or can't do at t= his point in the editing cycle). >=20 > From: Eran Messeri > Sent: 25 September 2019 17:11 > To: Rob Stradling > Cc: Paul Wouters ; Andrew Ayer ; Tra= ns ; Alissa Cooper > Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draft-ietf= -trans-rfc6962-bis-33 > =20 >=20 >=20 > On Wed, Sep 25, 2019 at 12:16 PM Rob Stradling wrote: > On 24/09/2019 18:38, Paul Wouters wrote: > > On Tue, 24 Sep 2019, Andrew Ayer wrote: > >=20 > >>> While I agree with you, I am just a WG chair. So we need to hear a few= > >>> more opinions of people and then if there is a consensus, we can go > >>> ahead and make this change. > >> > >> I'm also not sure what "this change" would be, but I agree with the > >> other comments here that CT shouldn't provide a mechanism for logs to > >> change URL. > >=20 > > I meant the clarification text of Base URL change (verus a potential > > other consensus of text that would allow updating the base url) > >=20 > > I'm not sure what the policy is for declaring a registry append only. > > Maybe leave a comment in for IANA whether or not that needs text? >=20 > In -33, section 10.6.1 says: > "Each application for the allocation of a Log ID MUST be accompanied > by: > - the Log's Base URL (see Section 4.1). > - a Contact (including contact information), from whom further > information can be obtained. > - an Owner (including contact information), who is authorized to > change this Log ID allocation." >=20 > I think we should fold "Owner" and "Contact" into just one field named=20 > "Log Operator", and clarify that the only part of a Log ID Registry=20 > entry that can be updated is the log operator's contact information. >=20 > Also, given that log operators are permitted to allocate Log IDs from=20 > other OID arcs (see section 4.4), ISTM that we also need to update=20 > section 4.1 to say that a log's Base URL is immutable. >=20 > Furthermore, ISTM that it would help to be explicit about the=20 > immutability of each and every log parameter. >=20 > Here's a PR that attempts to resolve all of the above: > https://github.com/google/certificate-transparency-rfcs/pull/314 > I agree with Rob and Ryan's stance - as demonstrated with 6962 deployment,= client agility would address the issue of logs wanting to change their URLs= (and I do not recall an occasion where having the ability to change just th= e log URL would have been helpful). > =20 >=20 >=20 > > Or alternatively, in the text for the Expert Review, mention the > > registry is strictly append-only ? >=20 > There is no Expert Review text relating to the Log ID Registry. >=20 > --=20 > Rob Stradling > Senior Research & Development Scientist > Sectigo Limited >=20 > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans --Apple-Mail-26C64DC0-75BE-45F8-8F54-60A3D473CB62 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Go ahead, I didn=E2=80=99t hear any objecti= on.

Paul

Sent from my iPhone

On Oct 10, 2019, at 18:0= 0, Rob Stradling <rob@sectigo.com&= gt; wrote:

Paul,

Still awaiting your feedback on this one.

From: Trans <trans-bounces@ietf.org> on behalf of Rob= Stradling <rob@sectigo.com> Sent: 02 October 2019 19:44
To: Paul Wouters <paul@nohats.ca= >
Cc: Alissa Cooper <alissa@coo= perw.in>; Eran Messeri <eranm@= google.com>; Trans <trans@ietf.o= rg>; Andrew Ayer <agwa@and= rewayer.name>
Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draft= -ietf-trans-rfc6962-bis-33
 
Paul,


May I go ahead and merge this PR?

(It's still not clear to me what the 6962-bis authors can or can't do at thi= s point in the editing cycle).

From: Eran Messeri <eranm@google.com>
Sent: 25 September 2019 17:11
To: Rob Stradling <rob@sectigo.= com>
Cc: Paul Wouters <paul@nohats.ca= >; Andrew Ayer <agwa@andre= wayer.name>; Trans <trans@ietf.o= rg>; Alissa Cooper <alissa@co= operw.in>
Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draft= -ietf-trans-rfc6962-bis-33
 


On Wed, Sep 25, 2019 at 12:16 PM R= ob Stradling <rob@sectigo.com> w= rote:
On 24/09/2019 18:38, Paul Wouters wrote:
> On Tue, 24 Sep 2019, Andrew Ayer wrote:
>
>>> While I agree with you, I am just a WG chair. So we need to hea= r a few
>>> more opinions of people and then if there is a consensus, we ca= n go
>>> ahead and make this change.
>>
>> I'm also not sure what "this change" would be, but I agree with the=
>> other comments here that CT shouldn't provide a mechanism for logs t= o
>> change URL.
>
> I meant the clarification text of Base URL change (verus a potential > other consensus of text that would allow updating the base url)
>
> I'm not sure what the policy is for declaring a registry append only. > Maybe leave a comment in for IANA whether or not that needs text?

In -33, section 10.6.1 says:
   "Each application for the allocation of a Log ID MUST be accomp= anied
    by:
      - the Log's Base URL (see Section 4.1).
      - a Contact (including contact information), from whom f= urther
        information can be obtained.
      - an Owner (including contact information), who is auth= orized to
        change this Log ID allocation."

I think we should fold "Owner" and "Contact" into just one field named
"Log Operator", and clarify that the only part of a Log ID Registry
entry that can be updated is the log operator's contact information.

Also, given that log operators are permitted to allocate Log IDs from
other OID arcs (see section 4.4), ISTM that we also need to update
section 4.1 to say that a log's Base URL is immutable.

Furthermore, ISTM that it would help to be explicit about the
immutability of each and every log parameter.

Here's a PR that attempts to resolve all of the above:
https://github.com/google/certificate-= transparency-rfcs/pull/314
I agree with Rob and Ryan's stance - as demonstrated with 6962 deployme= nt, client agility would address the issue of logs wanting to change their U= RLs (and I do not recall an occasion where having the ability to change just= the log URL would have been helpful).
 


> Or alternatively, in the text for the Expert Review, mention the
> registry is strictly append-only ?

There is no Expert Review text relating to the Log ID Registry.

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
= --Apple-Mail-26C64DC0-75BE-45F8-8F54-60A3D473CB62-- From nobody Thu Oct 10 18:19:01 2019 Return-Path: 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 ; 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 ; 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 ; 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 X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Thu, 10 Oct 2019 21:18:32 -0400 Cc: "trans@ietf.org" , Ryan Sleevi , Eran Messeri 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> <39d0ea14-36ca-b311-91df-074c1346f8c3@sectigo.com> <401e243a-98bb-7030-51e4-69faadb8977e@sectigo.com> To: Rob Stradling Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Oct 2019 01:19:01 -0000 --Apple-Mail-224AAB69-DD19-46F4-A512-B1E1C181ABA0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable It has been a week, so please go ahead. Worst case people can object during t= he IETF LC. Paul Sent from my iPhone > On Oct 10, 2019, at 18:01, Rob Stradling wrote: >=20 > Chairs, >=20 > May I interpret silence as consent, and go ahead and merge this PR? >=20 > From: Trans on behalf of Rob Stradling > Sent: 03 October 2019 15:11 > To: trans@ietf.org > Cc: Ryan Sleevi ; Eran Messeri > Subject: Re: [Trans] Precertificates and revocation > =20 > Here's a PR: > https://github.com/google/certificate-transparency-rfcs/pull/315 >=20 > Feedback welcome. >=20 > On 03/10/2019 11:02, Eran Messeri wrote: > > That reasoning makes sense to me. If 6962-bis precertificate is not a=20= > > certificate but 6962-bis states that the existence of a precertificate=20= > > indicates intent to issue a certificate, then checking whether the final= =20 > > certificate has been issued/revoked via OCSP makes sense. > >=20 > > On Thu, Sep 26, 2019 at 5:40 PM Rob Stradling > > wrote: > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > 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. > >=20 > > --------------------------------------------------------------------= ---- > > *From:* Eran Messeri > > > *Sent:* 25 September 2019 17:58 > > *To:* Rob Stradling > > > *Cc:* Ryan Sleevi > >; 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? > >=20 > > 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. > >=20 > > On Mon, Sep 23, 2019 at 12:21 PM Rob Stradling > > wrote: > >=20 > > 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. > >=20 > > 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: > >=20 > > 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 informati= on > > (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. > >=20 > > 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. > >=20 > > 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#sect= ion-6.1.. > >=20 > > 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 o= f > > > 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 wit= hin > > > 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. > >=20 > > --=20 > > Rob Stradling > > Senior Research & Development Scientist > > Sectigo Limited > >=20 > > _______________________________________________ > > Trans mailing list > > Trans@ietf.org > > https://www.ietf.org/mailman/listinfo/trans > >=20 >=20 > --=20 > Rob Stradling > Senior Research & Development Scientist > Email: rob@sectigo.com > Bradford, UK > Office: +441274024707 > Sectigo Limited >=20 > This message and any files associated with it may contain legally=20 > privileged, confidential, or proprietary information. If you are not the=20= > intended recipient, you are not permitted to use, copy, or forward it,=20 > in whole or in part without the express consent of the sender. Please=20 > notify the sender by reply email, disregard the foregoing messages, and=20= > 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 --Apple-Mail-224AAB69-DD19-46F4-A512-B1E1C181ABA0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit 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
--Apple-Mail-224AAB69-DD19-46F4-A512-B1E1C181ABA0-- From nobody Mon Oct 14 07:08:07 2019 Return-Path: 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 7CC04120058; Mon, 14 Oct 2019 07:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 QXC4U18-W5iY; Mon, 14 Oct 2019 07:07:55 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770087.outbound.protection.outlook.com [40.107.77.87]) (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 A4D1512002F; Mon, 14 Oct 2019 07:07:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cuz/I36A+4OUR7lFa6F0jONgxGfWlDs/UAMxmHvVIxfKWWKv+hME+XYjXbA/OlyPCqEgjm3F3pu9SKFvu8zV0UuQEFUqd7A3KG13IYwcSmqauHmIufnkhYp6X4aEANqiinNmBeL1I72uASE+Q5ofRSFwhrp8lgUzlrwd37lwroxc7IQm6iM7Ql3WP5HP4IFMSKnxKG/Ym1VJg9c/sIcCmi9LIbt3pAxPZgqLQnu75MHwN0xwdBjI74fngCE6a84J0WUu9RLCBtmCf4hA2Gd8L0SwnN1OluQ4BhOwXeUgfosqCgtN7/W/X8ZLUAhi/I+7WKs81coONfBJioCg8GARZQ== 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=39TJMRulFfXtLHd+slCYawbGpV3itmA5eTRhXyNMMt4=; b=oT/ntdT+IJ6y/DLWpU0jDI6jIAgwuHJeEn0Ul2GDqolHT9L0K8QaqwHRaUXL2IIYn8dHWSckskwnpd1TAi++HZA39Ow6jhq4plXtj+3ZpPZ3gkd+Y5fP/6ADAy3ipFa2ILLMA3InCYCWDitTM8ptHcImthL5GFrVdmNEkrIEzORuJmWw50d2uFvo+o1lCOBkJ5JsBKkZm60G6Mqm+LWRga42DOySkHfplXQBqYbMPl3NsAJuYYDzXas0x433uN0xzLsitEmUyda6KLfgZiLEfxsNmz8p5BiEzr4WHgnnPOPt+CjcwArxb5unQL4qhrIRG4ZAUwRMbzf0vcEc2zewfA== 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=39TJMRulFfXtLHd+slCYawbGpV3itmA5eTRhXyNMMt4=; b=TiqzX/Y+d40QR+XPgvaxUWuY9nNR7ca+QFqf6XJULXfVjsPtNBgFDOatD6dgFAllUwb/TF97Xv5v25Sa/IZNuqRORRNphi7inlQTiVisMMhnYjkUNRm2yuWhs3DgjJF6ZJn/5besZDqMhpTloGkAs+pwkyp8RWZ026CtU22fAZQ= Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB2780.namprd17.prod.outlook.com (20.178.225.205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.16; Mon, 14 Oct 2019 14:07:53 +0000 Received: from DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695]) by DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695%3]) with mapi id 15.20.2347.021; Mon, 14 Oct 2019 14:07:53 +0000 From: Rob Stradling To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , The IESG CC: "draft-ietf-trans-rfc6962-bis@ietf.org" , Paul Wouters , "trans-chairs@ietf.org" , "trans@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10cmFu?= =?utf-8?Q?s-rfc6962-bis-31:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHU2mzZvrQWumqliU+mEnmmbgWJ/adbfJiA Date: Mon, 14 Oct 2019 14:07:53 +0000 Message-ID: References: <155257141035.2645.11460081509986673853.idtracker@ietfa.amsl.com> In-Reply-To: <155257141035.2645.11460081509986673853.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0143.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9f::35) 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: 7e49a51e-411c-41f2-bdca-08d750afe7c7 x-ms-traffictypediagnostic: DM6PR17MB2780: x-ms-exchange-purlcount: 8 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(396003)(346002)(366004)(39850400004)(189003)(199004)(54094003)(99286004)(6512007)(186003)(54906003)(6306002)(7736002)(31686004)(8936002)(52116002)(25786009)(6486002)(229853002)(224303003)(53546011)(2906002)(76176011)(6506007)(386003)(31696002)(6436002)(102836004)(86362001)(66574012)(11346002)(256004)(14444005)(36756003)(4326008)(71200400001)(71190400001)(478600001)(81156014)(81166006)(305945005)(446003)(46003)(110136005)(2616005)(66556008)(64756008)(66446008)(966005)(316002)(66946007)(66476007)(14454004)(5660300002)(6116002)(486006)(476003)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2780; H:DM6PR17MB3162.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: mUZ64joB3JBqi6nAlUHTpV6A1SrhRRoY4Y16hrNzLwBO/Hl9ZehFNq5xPlfsRWiIci8oDcfkA0mlauR3Ul+MzhdPQL2kM7yM8Se2+XhqgxfE3E+TgqcaqVTfH/W34zpIZIsSMSbkYhbc9mLliqdqov0Hg4krLRI591+cyqRAoa4slqwk+Tf8havTutaTU4Fn7XSeu9vEg6ggm4RUOWLBkWNktLtjXZ7IGNwg6jdAand1Qcr2XdeKpmUo6obD89YbcCiXerQTvfu+qlO7CzYtapNLzklWOSOV9/e7Uw/XPbpu9tOGXcYP86q39pkbVt4OsIJ+cfYv9jauFB8FXXAOH4Cp6tOMIUqYn+C1hxoyh4dG4uG6Pd2Xo3ScrgWt/lA2ALenPF1EXI3+dQG1+5oCKnLKLulim/zDwU5JwjvpvkbDaJGFiBm7V5KdC7BvYae0M0gNNmOGzEji8itO19aMkw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <435A175BB312DE409421626CE83D86C0@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7e49a51e-411c-41f2-bdca-08d750afe7c7 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Oct 2019 14:07:53.6079 (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: jmNaTgZIKhQp3F3nkZb9lHn8CnzvZDPA4rBuT5/ZjaOmPGzyCwSYPDaqjCxz/tJdB7RjVZBgSi30xVMYbgHw+g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2780 Archived-At: Subject: Re: [Trans] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-trans-rfc6962-bis-31=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 14:07:59 -0000 SGkgTWlyamEuICBTb3JyeSBmb3IgdGhlIGxvb29uZyBkZWxheS4NCg0KQ29tbWVudHMgaW5saW5l LCBhbmQgSSd2ZSBqdXN0IHBvc3RlZCB0aGlzIFBSOg0KaHR0cHM6Ly9naXRodWIuY29tL2dvb2ds ZS9jZXJ0aWZpY2F0ZS10cmFuc3BhcmVuY3ktcmZjcy9wdWxsLzMxNg0KDQpPbiAxNC8wMy8yMDE5 IDEzOjUwLCBNaXJqYSBLw7xobGV3aW5kIHZpYSBEYXRhdHJhY2tlciB3cm90ZToNCj4gTWlyamEg S8O8aGxld2luZCBoYXMgZW50ZXJlZCB0aGUgZm9sbG93aW5nIGJhbGxvdCBwb3NpdGlvbiBmb3IN Cj4gZHJhZnQtaWV0Zi10cmFucy1yZmM2OTYyLWJpcy0zMTogRGlzY3Vzcw0KPiANCj4gUGxlYXNl IHJlZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3Jp dGVyaWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5k IENPTU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBv dGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFucy1yZmM2OTYyLWJpcy8NCj4gDQo+ IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiBESVNDVVNTOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0K PiBUaGVyZSB3YXMgYSBwcmVzZW50YXRpb24gYXQgbWFwcmcgSUVURiAxMDMgYWJvdXQgdGhlIHF1 ZXN0aW9uIGlmIENUIGhlbHBzDQo+IGF0dGFja2VycyB0byBmaW5kIG5ldyBkb21haW5zLiBJIHRo aW5rIHRoaXMgcmlzayBzaG91bGQgYXQgbGVhc3QgYmUgbWVudGlvbmVkDQo+IGluIHRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLg0KDQpBZGRyZXNzZWQgYnkgDQpodHRwczovL2dp dGh1Yi5jb20vcm9ic3RyYWRsaW5nL2NlcnRpZmljYXRlLXRyYW5zcGFyZW5jeS1yZmNzL2NvbW1p dC8zYjJlYzBhNTFmOGFiYjRjOGMwYjk4NTYxNGZlZmE0MjkxNDMyZGQ5DQoNCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPiBDT01NRU5UOg0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IA0KPiAgIDEpIEkgZm91bmQgc2Vj dGlvbiAyIGEgYml0IGhhcmQgdG8gZm9sbG93LiBXb3VsZCBpdCBtYXliZSBiZSBwb3NzaWJsZSB0 bw0KPiAgIHByb3ZpZGUgbW9yZSB0ZXh0dWFsIGV4cGxhbmF0aW9uIG9mIHRoZSBhbGdvcml0aG1z IGluc3RlYWQgb2YganVzdCBkZXNjcmliaW5nDQo+ICAgdGhlIHN0ZXBzIG9mIHRoZSBhbGdvcml0 aG1zPyBBbHNvIEkgd2FzIHdvbmRlcmluZyBob3cgbXVjaCBtdWNoIHRoZXNlDQo+ICAgYWxnb3Jp dGhtcyBhcmUgYWN0dWFsbHkg4oCecGFydOKAnCBvZiB0aGUgcHJvdG9jb2wgc3BlY+KApj8gQXJl IGNvdWxkIHRoZXNlIGJlDQo+ICAgcmF0aGVyIHNlZW4gYXMgZXhhbXBsZSBhbGdvcml0aG1zPyBN YXliZSB0aGF0IGNvdWxkIGJlIGZ1cnRoZXIgY2xhcmlmaWVkDQoNCldlJ2xsIGNvbnNpZGVyIHRo ZXNlIGNvbW1lbnRzIG9uIHNlY3Rpb24gMiBhdCBhIGxhdGVyIGRhdGUsIGFsb25nIHdpdGggDQpC ZW5qYW1pbiBLYWR1aydzIGNvbW1lbnRzIG9uIHNlY3Rpb24gMi4NCg0KPiAgIDIpIFBsZWFzZSBl eHBhbmQgU1RIIG9uIGZpcnN0IG9jY3VycmVuY2UgKGluIHNlYyA0LjEpDQoNCkFkZHJlc3NlZCBi eSANCmh0dHBzOi8vZ2l0aHViLmNvbS9yb2JzdHJhZGxpbmcvY2VydGlmaWNhdGUtdHJhbnNwYXJl bmN5LXJmY3MvY29tbWl0L2QyZDZiMGFjMzAzYWYyNjU5ZTVkZjUzODM5MTAwMmYxYmY0NTRlZGIN Cg0KPiAgIDMpIFNlYyA0LjQ6IOKAnkEgbG9nJ3Mgb3BlcmF0b3IgTVVTVCBlaXRoZXIgYWxsb2Nh dGUgdGhlIE9JRA0KPiAgICAgIHRoZW1zZWx2ZXMgb3IgcmVxdWVzdCBhbiBPSUQgZnJvbSB0aGUg TG9nIElEIFJlZ2lzdHJ5IChzZWUNCj4gICAgICBTZWN0aW9uIDEwLjYuMSku4oCcDQo+IElzbid0 IHRoZXJlIGFuIG9ibGlnYXRpb24gdG8gcmVnaXN0ZXI/DQoNClRoZSBMb2cgSUQgUmVnaXN0cnkg aXMgbWVyZWx5IGEgc291cmNlIG9mIE9JRHMgdGhhdCBoYXZlIHNob3J0IERFUiANCmVuY29kaW5n cy4gIEEgbG9nIG9wZXJhdG9yIG1heSBlaXRoZXIgKDEpIHJlcXVlc3QgYW4gT0lEIGZyb20gdGhl IExvZyBJRCANClJlZ2lzdHJ5LCBvciAoMikgYWxsb2NhdGUgYW4gT0lEIHRoZW1zZWx2ZXMgKGZy b20gYW4gT0lEIGFyYyB0aGF0IHRoZXkgDQpjb250cm9sLCBuYXR1cmFsbHkpLg0KDQpUaGUgUmVn aXN0cnkgaXMgbm90IGludGVuZGVkIHRvIGJlIGEgZ2xvYmFsIGRpcmVjdG9yeSBvZiBhbGwgbG9n cy4NCg0KPiAgIDQpIHNlYyA0Ljg6IOKAnklmIGFuDQo+ICAgICBpbXBsZW1lbnRhdGlvbiBzZWVz IGFuIGV4dGVuc2lvbiB0aGF0IGl0IGRvZXMgbm90IHVuZGVyc3RhbmQsIGl0DQo+ICAgICBTSE9V TEQgaWdub3JlIHRoYXQgZXh0ZW5zaW9uLuKAnA0KPiBNYXliZSBpdOKAmXMganVzdCBtZSBiZWNh dXNlIEkgbWF5IGhhdmUgbWlzc2VkIHNvbWUgY29udGV4dCBidXQgZG9lcyDigJ5pZ25vcmXigJwN Cj4gbWVhbiBoZXJlIHRoYXQgaXQgc2hvdWxkIGxvZyBpdCBvciBub3Q/DQoNCiJJdCIgKHRoZSBw cmVjZXJ0aWZpY2F0ZSBvciBjZXJ0aWZpY2F0ZSkgbXVzdCBoYXZlIGFscmVhZHkgYmVlbiBsb2dn ZWQsIA0KYmVjYXVzZSB0aGUgY29ycmVzcG9uZGluZyBTQ1QgKHRoYXQgY29udGFpbnMgYSBwb3Rl bnRpYWxseSB1bnJlY29nbml6ZWQgDQpleHRlbnNpb24pIGNvdWxkbid0IG90aGVyd2lzZSBleGlz dC4NCg0KPiAgIDUpIHNlYyA1OiDigJ5NQVkgcmV0cnkgdGhlIHNhbWUNCj4gICAgIHJlcXVlc3Qg d2l0aG91dCBtb2RpZmljYXRpb24gYXQgYSBsYXRlciBkYXRlLuKAnA0KPiBXb3VsZCBpdCBiZSBw b3NzaWJsZSB0byBwcm92aWRlIGEgcmVjb21tZW5kYXRpb24gaG93IGxvbmcgdGhlIGNsaWVudCBz aG91bGQNCj4gd2FpdD8NCg0KVGhlIHZlcnkgbmV4dCBzZW50ZW5jZSBpbiBzZWN0aW9uIDUgYWxy ZWFkeSBzcGVjaWZpZXMgYSBtZWNoYW5pc20gZm9yIA0KZG9pbmcganVzdCB0aGF0Og0KICAgJ05v dGUgdGhhdCBhcyBwZXINCiAgICBbUkZDNzIzMV0sIGluIHRoZSBjYXNlIG9mIGEgNTAzIHJlc3Bv bnNlIHRoZSBsb2cgTUFZIGluY2x1ZGUgYQ0KICAgICJSZXRyeS1BZnRlcjoiIGhlYWRlciBpbiBv cmRlciB0byByZXF1ZXN0IGEgbWluaW11bSB0aW1lIGZvciB0aGUNCiAgICBjbGllbnQgdG8gd2Fp dCBiZWZvcmUgcmV0cnlpbmcgdGhlIHJlcXVlc3QuJw0KDQo+ICAgNikgc2VjIDUuNjog4oCeTG9n cyBNQVkgcmVzdHJpY3QgdGhlIG51bWJlciBvZiBlbnRyaWVzIHRoYXQgY2FuIGJlIHJldHJpZXZl ZCBwZXINCj4gICAgICJnZXQtZW50cmllcyIgcmVxdWVzdC7igJwNCj4gU2hvdWxkIHRoaXMgYmUg YWRkZWQgdG8gc2VjIDQuMT8NCg0KSSBkb24ndCB0aGluayB0aGF0J3MgYSBnb29kIGlkZWEuICBJ IGNhbiBpbWFnaW5lIHRoYXQgb3BlcmF0aW9uYWwgaXNzdWVzIA0KbWlnaHQgY2F1c2UgYSBsb2cg b3BlcmF0b3IgdG8gd2FudCB0byB2YXJ5IHRoaXMgcmVzdHJpY3Rpb24gYXQgYW55IHRpbWUuDQoN CkNsaWVudHMgc2hvdWxkIGFsd2F5cyBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGdldC1lbnRyaWVz IHJlc3BvbnNlcyB0aGF0IA0KY29udGFpbiBmZXdlciBlbnRyaWVzIHRoYW4gdGhleSByZXF1ZXN0 ZWQuDQoNClNlZSBhbHNvIGh0dHBzOi8vdHJhYy5pZXRmLm9yZy90cmFjL3RyYW5zL3RpY2tldC85 NQ0KDQo+ICAgNykgc2VjIDEwLjM6IENvdWxkbuKAmXQgeW91IHVzZSB0aGUgVExTICBTaWduYXR1 cmVTY2hlbWUgUmVnaXN0cnkgZGlyZWN0bHkNCj4gICAoaW5zdGVhZCBvZiBmb3JtaW5nIGFuIG93 biByZWdpc3RyeSk/DQoNCkl0IG1ha2VzIHNlbnNlIHRvIHN5bmNocm9uaXplIHRoZSBzaWduYXR1 cmUgYWxnb3JpdGhtIHZhbHVlcyB3ZSB1c2Ugd2l0aCANCnRoZSBUTFMgU2lnbmF0dXJlQWxnb3Jp dGhtIHJlZ2lzdHJ5LCBiZWNhdXNlIG91ciBkYXRhIHN0cnVjdHVyZXMgYXJlIA0KZGVmaW5lZCBh Y2NvcmRpbmcgdG8gdGhlIGNvbnZlbnRpb25zIGxhaWQgb3V0IGluIHRoZSBUTFMgUkZDLg0KDQpI b3dldmVyLCBJIGRvbid0IHRoaW5rIGl0J3MgYSBnb29kIGlkZWEgdG8gdXNlIHRoZSBUTFMgDQpT aWduYXR1cmVBbGdvcml0aG0gcmVnaXN0cnkgZGlyZWN0bHkuICBJbiA2OTYyLWJpcywgd2UndmUg dGFrZW4gc3RlcHMgdG8gDQptYWtlIGxvZyBhcnRpZmFjdHMgc21hbGxlciAoY29tcGFyZWQgdG8g UkZDNjk2Mik7IHJlbGF0ZWQgdG8gdGhhdCwgd2UndmUgDQpyZW1vdmVkIHRoZSBvcHRpb24gb2Yg bG9ncyBiZWluZyBwZXJtaXR0ZWQgdG8gdXNlIFJTQSBrZXlzL3NpZ25hdHVyZXMuIA0KaHR0cHM6 Ly93d3cuaWFuYS5vcmcvYXNzaWdubWVudHMvdGxzLXBhcmFtZXRlcnMvdGxzLXBhcmFtZXRlcnMu eGh0bWwjdGxzLXBhcmFtZXRlcnMtMTYgDQpwZXJtaXRzIFJTQSwgYW5kIHNldmVyYWwgb3RoZXIg c2lnbmF0dXJlIGFsZ29yaXRobXMgdGhhdCB3ZSBkb24ndCB3aXNoIA0KdG8gcGVybWl0IG9yIHJl Y29tbWVuZCAoaS5lLiAiYW5vbnltb3VzIiwgRFNBLCBHT1NULCBhbmQgIlJlc2VydmVkIGZvciAN ClByaXZhdGUgVXNlIikuDQoNCj4gICA4KSBzZWMgMTAuNDogaSBXb25kZXIgaWYgYW4gUkZDLXJl cXVpcmVkIHBvbGljeSB3b3VsZG7igJl0IGJlIG1vcmUgYXBwcm9wcmlhdGUNCj4gICBmb3IgdGhl IFZlcnNpb25lZFRyYW5zVHlwZXMgcmVnaXN0cnk/DQoNCkluIDY5NjItYmlzIHNlY3Rpb24gMTAu NC4xLCB3ZSBhc2sgdGhlIGFwcG9pbnRlZCBFeHBlcnQgdG8gInJldmlldyB0aGUgDQpwdWJsaWMg c3BlY2lmaWNhdGlvbiB0byBlbnN1cmUgdGhhdCBpdCBpcyBkZXRhaWxlZCBlbm91Z2ggdG8gZW5z dXJlIA0KaW1wbGVtZW50YXRpb24gaW50ZXJvcGVyYWJpbGl0eSIuDQoNCkFGQUlDVCBmcm9tIFJG QzgxMjYsICJSRkMgUmVxdWlyZWQiIGRvZXNuJ3QgaW1wbHkgRXhwZXJ0IFJldmlldywgd2hlcmVh cyANCiJTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIiBkb2VzLiAgU28gSSB0aGluayB3ZSBzaG91bGQg bGVhdmUgaXQgYXMgDQoiU3BlY2lmaWNhdGlvbiBSZXF1aXJlZCIuDQoNCj4gICA5KSBzZWMgMTAu Ni4xOkkgZ3Vlc3MgIHRoZSByZWdpc3RyYXRpb24gcG9saWN5IGlzIEZDRlM/IFJGQyA4MTI2IHJl Y29tbWVuZCB0bw0KPiAgIGFsd2F5cyAoY2xlYXJseSkgbmFtZSB0aGUgcmVnaXN0cnkuDQoNClRo YW5rcy4gIEluIG91ciByZXNwb25zZSB0byBBbGlzc2EgQ29vcGVyJ3MgRElTQ1VTUy9DT01NRU5U cyAoc2VlIA0KaHR0cHM6Ly9naXRodWIuY29tL2dvb2dsZS9jZXJ0aWZpY2F0ZS10cmFuc3BhcmVu Y3ktcmZjcy9wdWxsLzMwOSksIHdlJ3ZlIA0KYWxyZWFkeSBjbGFyaWZpZWQgdGhhdCB0aGUgTG9n IElEIFJlZ2lzdHJ5IGlzIGluZGVlZCBGaXJzdCBDb21lIEZpcnN0IA0KU2VydmVkLg0KDQo+IEFu ZCBmaW5hbGx5IG9uZSBoaWdoZXIgbGV2ZWwgcXVlc3Rpb24gbWFpbmx5IG91dCBvZiBjdXJpb3Np dHk6IHdhcyBpdA0KPiBjb25zaWRlcmVkIHRvIGUuZy4gdXNlIGpzb24gZm9yIGFsbCBkYXRhIHN0 cnVjdHVyZXM/IElzIHRoZXJlIGEgcGVyZm9ybWFuY2UNCj4gcmVhc29uIHRvIG5vdCBkbyB0aGF0 IG9yIHdhc27igJl0IHRoYXQgZXZlbiBkaXNjdXNzZWQ/DQoNClBsZWFzZSBkb24ndCByZXN0YXJ0 IHRoZSBmb3JtYXQgd2Fycy4gIDstKQ0KDQpXZSBtdXN0IHVzZSBBU04uMSBmb3IgYWxsIGRhdGEg c3RydWN0dXJlcywgYmVjYXVzZSBYLjUwOSBjZXJ0aWZpY2F0ZXMgDQphcmUgaW52b2x2ZWQuICBC dXQgd2UgbXVzdCB1c2UgIlRMUyBlbmNvZGluZyIgZm9yIGFsbCBkYXRhIHN0cnVjdHVyZXMsIA0K YmVjYXVzZSBUTFMgaXMgaW52b2x2ZWQuICBCdXQgd2UgbXVzdCB1c2UgSlNPTiBmb3IgYWxsIGRh dGEgc3RydWN0dXJlcywgDQpiZWNhdXNlIEpTT04gaXMgbW9yZSBBUEktZnJpZW5kbHkuDQoNCkl0 IHdhcyBpbXBvc3NpYmxlIHRvIHBsZWFzZSBldmVyeW9uZS4gIFdlIGhhZCB0byBjaG9vc2Ugc29t ZXRoaW5nLCBzbyB3ZSANCmNob3NlIFRMUyBlbmNvZGluZyBmb3IgdGhlIGRhdGEgc3RydWN0dXJl cywgYW5kIEpTT04gZm9yIHRoZSBBUElzLg0KDQpBcyBJIG1lbnRpb25lZCBlYXJsaWVyLCBvbmUg Z29hbCBvZiA2OTYyLWJpcyBpcyB0byBtYWtlIGxvZyBhcnRpZmFjdHMgDQpzbWFsbGVyLiAgVExT IGVuY29kaW5nIGlzIG1vcmUgc3VpdGVkIHRvIHRoaXMgdGhhbiBKU09OLg0KDQotLSANClJvYiBT dHJhZGxpbmcNClNlbmlvciBSZXNlYXJjaCAmIERldmVsb3BtZW50IFNjaWVudGlzdA0KU2VjdGln byBMaW1pdGVkDQoNCg== From nobody Mon Oct 14 08:32:32 2019 Return-Path: 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 5233B12010E; Mon, 14 Oct 2019 08:32:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 ndKDKCfmXa5O; Mon, 14 Oct 2019 08:32:19 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B99512002F; Mon, 14 Oct 2019 08:32:19 -0700 (PDT) Received: from 200116b82c0d110055b7b820b289cd5b.dip.versatel-1u1.de ([2001:16b8:2c0d:1100:55b7:b820:b289:cd5b]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iK2KU-0003Wt-Js; Mon, 14 Oct 2019 17:32:14 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: Date: Mon, 14 Oct 2019 17:32:13 +0200 Cc: The IESG , "draft-ietf-trans-rfc6962-bis@ietf.org" , Paul Wouters , "trans@ietf.org" , "trans-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <155257141035.2645.11460081509986673853.idtracker@ietfa.amsl.com> To: Rob Stradling X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1571067139;c9de65e7; X-HE-SMSGID: 1iK2KU-0003Wt-Js Archived-At: Subject: Re: [Trans] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-trans-rfc6962-bis-31=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Oct 2019 15:32:22 -0000 Hi Rob, Thanks for your replies and edits. I will clear my discuss as soon as = the new version is submitted. Please see some minor comments below! Thanks! Mirja > On 14. Oct 2019, at 16:07, Rob Stradling wrote: >=20 > Hi Mirja. Sorry for the looong delay. >=20 > Comments inline, and I've just posted this PR: > https://github.com/google/certificate-transparency-rfcs/pull/316 >=20 > On 14/03/2019 13:50, Mirja K=C3=BChlewind via Datatracker wrote: >> Mirja K=C3=BChlewind has entered the following ballot position for >> draft-ietf-trans-rfc6962-bis-31: Discuss >>=20 >> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >>=20 >>=20 >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ >>=20 >>=20 >>=20 >> = ---------------------------------------------------------------------- >> DISCUSS: >> = ---------------------------------------------------------------------- >>=20 >> There was a presentation at maprg IETF 103 about the question if CT = helps >> attackers to find new domains. I think this risk should at least be = mentioned >> in the security considerations section. >=20 > Addressed by=20 > = https://github.com/robstradling/certificate-transparency-rfcs/commit/3b2ec= 0a51f8abb4c8c0b985614fefa4291432dd9 >=20 >> = ---------------------------------------------------------------------- >> COMMENT: >> = ---------------------------------------------------------------------- >>=20 >> 1) I found section 2 a bit hard to follow. Would it maybe be = possible to >> provide more textual explanation of the algorithms instead of just = describing >> the steps of the algorithms? Also I was wondering how much much = these >> algorithms are actually =E2=80=9Epart=E2=80=9C of the protocol = spec=E2=80=A6? Are could these be >> rather seen as example algorithms? Maybe that could be further = clarified >=20 > We'll consider these comments on section 2 at a later date, along with=20= > Benjamin Kaduk's comments on section 2. >=20 >> 2) Please expand STH on first occurrence (in sec 4.1) >=20 > Addressed by=20 > = https://github.com/robstradling/certificate-transparency-rfcs/commit/d2d6b= 0ac303af2659e5df538391002f1bf454edb >=20 >> 3) Sec 4.4: =E2=80=9EA log's operator MUST either allocate the OID >> themselves or request an OID from the Log ID Registry (see >> Section 10.6.1).=E2=80=9C >> Isn't there an obligation to register? >=20 > The Log ID Registry is merely a source of OIDs that have short DER=20 > encodings. A log operator may either (1) request an OID from the Log = ID=20 > Registry, or (2) allocate an OID themselves (from an OID arc that they=20= > control, naturally). >=20 > The Registry is not intended to be a global directory of all logs. Could be good to clarify in the text. >=20 >> 4) sec 4.8: =E2=80=9EIf an >> implementation sees an extension that it does not understand, it >> SHOULD ignore that extension.=E2=80=9C >> Maybe it=E2=80=99s just me because I may have missed some context but = does =E2=80=9Eignore=E2=80=9C >> mean here that it should log it or not? >=20 > "It" (the precertificate or certificate) must have already been = logged,=20 > because the corresponding SCT (that contains a potentially = unrecognized=20 > extension) couldn't otherwise exist. Could be good to clarify in the text. >=20 >> 5) sec 5: =E2=80=9EMAY retry the same >> request without modification at a later date.=E2=80=9C >> Would it be possible to provide a recommendation how long the client = should >> wait? >=20 > The very next sentence in section 5 already specifies a mechanism for=20= > doing just that: > 'Note that as per > [RFC7231], in the case of a 503 response the log MAY include a > "Retry-After:" header in order to request a minimum time for the > client to wait before retrying the request.=E2=80=99 I meant, would it make sense to actually provide a default value or = something for this waiting time? >=20 >> 6) sec 5.6: =E2=80=9ELogs MAY restrict the number of entries that = can be retrieved per >> "get-entries" request.=E2=80=9C >> Should this be added to sec 4.1? >=20 > I don't think that's a good idea. I can imagine that operational = issues=20 > might cause a log operator to want to vary this restriction at any = time. >=20 > Clients should always be prepared to receive get-entries responses = that=20 > contain fewer entries than they requested. >=20 > See also https://trac.ietf.org/trac/trans/ticket/95 >=20 >> 7) sec 10.3: Couldn=E2=80=99t you use the TLS SignatureScheme = Registry directly >> (instead of forming an own registry)? >=20 > It makes sense to synchronize the signature algorithm values we use = with=20 > the TLS SignatureAlgorithm registry, because our data structures are=20= > defined according to the conventions laid out in the TLS RFC. >=20 > However, I don't think it's a good idea to use the TLS=20 > SignatureAlgorithm registry directly. In 6962-bis, we've taken steps = to=20 > make log artifacts smaller (compared to RFC6962); related to that, = we've=20 > removed the option of logs being permitted to use RSA keys/signatures.=20= > = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-16=20 > permits RSA, and several other signature algorithms that we don't wish=20= > to permit or recommend (i.e. "anonymous", DSA, GOST, and "Reserved for=20= > Private Use"). >=20 >> 8) sec 10.4: i Wonder if an RFC-required policy wouldn=E2=80=99t be = more appropriate >> for the VersionedTransTypes registry? >=20 > In 6962-bis section 10.4.1, we ask the appointed Expert to "review the=20= > public specification to ensure that it is detailed enough to ensure=20 > implementation interoperability". >=20 > AFAICT from RFC8126, "RFC Required" doesn't imply Expert Review, = whereas=20 > "Specification Required" does. So I think we should leave it as=20 > "Specification Required=E2=80=9D. RFC Required implies that the document got some reviews based on the = respective process. However, I guess I actually wanted to propose IETF Review (and used the = wrong term). That would imply that it had to go through the IETF process = with respective review (and therefore usually it is expected that no = expert review is needed in addition). Anyway this was mainly a comment = to double-check this decision.=20 >=20 >> 9) sec 10.6.1:I guess the registration policy is FCFS? RFC 8126 = recommend to >> always (clearly) name the registry. >=20 > Thanks. In our response to Alissa Cooper's DISCUSS/COMMENTs (see=20 > https://github.com/google/certificate-transparency-rfcs/pull/309), = we've=20 > already clarified that the Log ID Registry is indeed First Come First=20= > Served. >=20 >> And finally one higher level question mainly out of curiosity: was it >> considered to e.g. use json for all data structures? Is there a = performance >> reason to not do that or wasn=E2=80=99t that even discussed? >=20 > Please don't restart the format wars. ;-) Didn=E2=80=99t know that=E2=80=A6=20 >=20 > We must use ASN.1 for all data structures, because X.509 certificates=20= > are involved. But we must use "TLS encoding" for all data structures,=20= > because TLS is involved. But we must use JSON for all data = structures,=20 > because JSON is more API-friendly. >=20 > It was impossible to please everyone. We had to choose something, so = we=20 > chose TLS encoding for the data structures, and JSON for the APIs. >=20 > As I mentioned earlier, one goal of 6962-bis is to make log artifacts=20= > smaller. TLS encoding is more suited to this than JSON. Okay thanks for the background info. As long as this was discussed = that's fine! >=20 > --=20 > Rob Stradling > Senior Research & Development Scientist > Sectigo Limited >=20 From nobody Wed Oct 16 06:37:14 2019 Return-Path: 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 86F221200F9; Wed, 16 Oct 2019 06:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ZAgk-JRdmZC3; Wed, 16 Oct 2019 06:37:04 -0700 (PDT) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-eopbgr680044.outbound.protection.outlook.com [40.107.68.44]) (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 ABCE11200D5; Wed, 16 Oct 2019 06:37:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=N9Nu3erjsH5LiuGs7E/Zh609m8NzgmrEerZo7FilBbFf/4Qm0gPuPnybac7T9ImuGZLrHicZWwz7qKoEuygKsa2I5WSADXkJU4iAOyy8mZXuGNg133nEl5SKvv+fAaQqkBcyDU94yL5OXhQNLPtBOKDs3I+j7KR/8FrF52u4mf7AYtG5dvHtW6FdH/dusrXU3xy22ca1u+nD2zga3+3EZzP1CF3nHuUGhfDhkY7WDmJihQJTtxQG+26vajsgyzvOTy9F6q6p/xIUDuZ0r6wpkxPWorAX93PVdSNE2NmcrBd8tEWuO3T4WwLDgcwJiD0ixMlTUCIU+k/Uj9qDIObjfA== 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=baDe5PejNShTY/ij2+SogtZZmdlwIA+kgI654V+rz6w=; b=hNULd354d0yYksIEAdp1N0N2vtOLC3nprfpk/zOYkjs1/Rt2/pzAuMjyu67NTsGBFVYcH3TGkNKxXh6gzsClMvbH0mi4zPKK2HQtqRCo8WRvbphihM3KGTCFDzCKECdsNoRx7N/OfJSEYlD7J0d/Xmjke8tfACQlR55GHxE0y8qdcfd6LXHO/3wHq8hPOTHkDcDNxBCOASpV7+HVBT4ZEY8JqYkUE9CO0G0arpdzY5rq/GScSS+LjY2z3TIeKQAvUAoR5Oja90QCxKj+YLT+bid8wyVGvDmiPPVviN5NprpV4OdOfpHmBod4Tp/x/R8zmOlRxrxbK3MvEKLXLQc8xA== 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=baDe5PejNShTY/ij2+SogtZZmdlwIA+kgI654V+rz6w=; b=cZsE0Nb3X0TwlazgTTDZO3JoIv5Cc1+N19NdvyCFaarlT7HLUyeSnSCEYKm30u+YDdQlSPNu/R8EXYlZKfBM8l5gA03p6r0eD8SOvmmpnB5af+TTMU5xt6MIm0nSYuUFrTkjIGAbqWQFaw6aRSXi62iEAyfW5x+WulzcMHcps28= Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB2937.namprd17.prod.outlook.com (20.178.228.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.19; Wed, 16 Oct 2019 13:36:59 +0000 Received: from DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695]) by DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695%3]) with mapi id 15.20.2347.023; Wed, 16 Oct 2019 13:36:59 +0000 From: Rob Stradling To: Mirja Kuehlewind CC: The IESG , "draft-ietf-trans-rfc6962-bis@ietf.org" , Paul Wouters , "trans@ietf.org" , "trans-chairs@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10cmFu?= =?utf-8?Q?s-rfc6962-bis-31:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHU2mzZvrQWumqliU+mEnmmbgWJ/adbfJiAgAAXqICAAwRxAA== Date: Wed, 16 Oct 2019 13:36:58 +0000 Message-ID: <1589f7c5-c4cb-4a87-d972-f7664b954d3f@sectigo.com> References: <155257141035.2645.11460081509986673853.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0097.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::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: 89f9c311-d695-481c-2977-08d7523deb1f x-ms-traffictypediagnostic: DM6PR17MB2937: x-ms-exchange-purlcount: 9 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(39850400004)(136003)(396003)(199004)(189003)(54094003)(51914003)(31686004)(966005)(71200400001)(64756008)(66946007)(224303003)(14454004)(476003)(5660300002)(446003)(11346002)(6306002)(2616005)(486006)(99286004)(6246003)(4326008)(66446008)(256004)(31696002)(66556008)(86362001)(14444005)(71190400001)(66476007)(561944003)(6436002)(478600001)(6512007)(66574012)(316002)(25786009)(52116002)(81166006)(7736002)(76176011)(54906003)(6916009)(229853002)(6486002)(386003)(6506007)(53546011)(102836004)(8936002)(186003)(46003)(6116002)(81156014)(305945005)(36756003)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2937; 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: ffoUutox6qJrglnrRCIsfbI8zn3GBLiET4VkuTp7LvtJU7gVAqSxaGzu/yfiF4z/hHvBc6CiydkhrIdpftZ6/mWjy/pJFgMwGpViYRMUb1rpsf6gIsg3qxDxjKAmncph4CX+Qit13cvRJDj0FwLb2Ypz5RccpoZNHLJP2rMHnpgUfb/uNHfTlDaYnwVeTelpTWfXFC3kALniohYfs5pwjukWWlxv72MwrVApAq4Shz+uzRAvMWNEgZ1lfcuje69Tb8Oylxw8E4kOfwtn/W1xFgQavytrsB76VUi+dk5ZSlQ6vmrdftztm5nka/OrWe7aXhEUEXZWMb14mdwlxFMejAR+dRPqPSilMw1iVbeeqThTq/JAtRZStSAiCWZhlBc3aoEcf3h0E32XgBZQC72qXO47t4W8a4PE3GUW0+z5BS2o01DZA2RJ+CTKMYur+AJ5UPo1FqhR04ZVj93Q4ONBPg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 89f9c311-d695-481c-2977-08d7523deb1f X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2019 13:36:58.9314 (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: Jpp0CmMkR8MhjYalYbrfJqqStdj0bTvJENUqydw9NrItrZSi9sb/XTpyg+VxTrdELz7osSYiGpjtcChIPFg6RQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2937 Archived-At: Subject: Re: [Trans] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-trans-rfc6962-bis-31=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 13:37:07 -0000 T24gMTQvMTAvMjAxOSAxNjozMiwgTWlyamEgS3VlaGxld2luZCB3cm90ZToNCj4gSGkgUm9iLA0K PiANCj4gVGhhbmtzIGZvciB5b3VyIHJlcGxpZXMgYW5kIGVkaXRzLiBJIHdpbGwgY2xlYXIgbXkg ZGlzY3VzcyBhcyBzb29uIGFzIHRoZSBuZXcgdmVyc2lvbiBpcyBzdWJtaXR0ZWQuDQoNClRoYW5r cyBNaXJqYS4NCg0KPiBQbGVhc2Ugc2VlIHNvbWUgbWlub3IgY29tbWVudHMgYmVsb3chDQoNClJl cGxpZXMgaW5saW5lLg0KDQo+IFRoYW5rcyENCj4gTWlyamENCj4gDQo+IA0KPj4gT24gMTQuIE9j dCAyMDE5LCBhdCAxNjowNywgUm9iIFN0cmFkbGluZyA8cm9iQHNlY3RpZ28uY29tPiB3cm90ZToN Cj4+DQo+PiBIaSBNaXJqYS4gIFNvcnJ5IGZvciB0aGUgbG9vb25nIGRlbGF5Lg0KPj4NCj4+IENv bW1lbnRzIGlubGluZSwgYW5kIEkndmUganVzdCBwb3N0ZWQgdGhpcyBQUjoNCj4+IGh0dHBzOi8v Z2l0aHViLmNvbS9nb29nbGUvY2VydGlmaWNhdGUtdHJhbnNwYXJlbmN5LXJmY3MvcHVsbC8zMTYN Cj4+DQo+PiBPbiAxNC8wMy8yMDE5IDEzOjUwLCBNaXJqYSBLw7xobGV3aW5kIHZpYSBEYXRhdHJh Y2tlciB3cm90ZToNCj4+PiBNaXJqYSBLw7xobGV3aW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dp bmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPj4+IGRyYWZ0LWlldGYtdHJhbnMtcmZjNjk2Mi1iaXMt MzE6IERpc2N1c3MNCj4+Pg0KPj4+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9y Zy9pZXNnL3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4+PiBmb3IgbW9yZSBpbmZv cm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPj4+DQo+ Pj4NCj4+PiBUaGUgZG9jdW1lbnQsIGFsb25nIHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywg Y2FuIGJlIGZvdW5kIGhlcmU6DQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi10cmFucy1yZmM2OTYyLWJpcy8NCj4+Pg0KPj4+DQo+Pj4NCj4+PiAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+Pj4gRElTQ1VTUzoNCj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+Pj4NCj4+PiBUaGVyZSB3 YXMgYSBwcmVzZW50YXRpb24gYXQgbWFwcmcgSUVURiAxMDMgYWJvdXQgdGhlIHF1ZXN0aW9uIGlm IENUIGhlbHBzDQo+Pj4gYXR0YWNrZXJzIHRvIGZpbmQgbmV3IGRvbWFpbnMuIEkgdGhpbmsgdGhp cyByaXNrIHNob3VsZCBhdCBsZWFzdCBiZSBtZW50aW9uZWQNCj4+PiBpbiB0aGUgc2VjdXJpdHkg Y29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCj4+DQo+PiBBZGRyZXNzZWQgYnkNCj4+IGh0dHBzOi8v Z2l0aHViLmNvbS9yb2JzdHJhZGxpbmcvY2VydGlmaWNhdGUtdHJhbnNwYXJlbmN5LXJmY3MvY29t bWl0LzNiMmVjMGE1MWY4YWJiNGM4YzBiOTg1NjE0ZmVmYTQyOTE0MzJkZDkNCj4+DQo+Pj4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KPj4+IENPTU1FTlQ6DQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+DQo+Pj4gICAx KSBJIGZvdW5kIHNlY3Rpb24gMiBhIGJpdCBoYXJkIHRvIGZvbGxvdy4gV291bGQgaXQgbWF5YmUg YmUgcG9zc2libGUgdG8NCj4+PiAgIHByb3ZpZGUgbW9yZSB0ZXh0dWFsIGV4cGxhbmF0aW9uIG9m IHRoZSBhbGdvcml0aG1zIGluc3RlYWQgb2YganVzdCBkZXNjcmliaW5nDQo+Pj4gICB0aGUgc3Rl cHMgb2YgdGhlIGFsZ29yaXRobXM/IEFsc28gSSB3YXMgd29uZGVyaW5nIGhvdyBtdWNoIG11Y2gg dGhlc2UNCj4+PiAgIGFsZ29yaXRobXMgYXJlIGFjdHVhbGx5IOKAnnBhcnTigJwgb2YgdGhlIHBy b3RvY29sIHNwZWPigKY/IEFyZSBjb3VsZCB0aGVzZSBiZQ0KPj4+ICAgcmF0aGVyIHNlZW4gYXMg ZXhhbXBsZSBhbGdvcml0aG1zPyBNYXliZSB0aGF0IGNvdWxkIGJlIGZ1cnRoZXIgY2xhcmlmaWVk DQo+Pg0KPj4gV2UnbGwgY29uc2lkZXIgdGhlc2UgY29tbWVudHMgb24gc2VjdGlvbiAyIGF0IGEg bGF0ZXIgZGF0ZSwgYWxvbmcgd2l0aA0KPj4gQmVuamFtaW4gS2FkdWsncyBjb21tZW50cyBvbiBz ZWN0aW9uIDIuDQo+Pg0KPj4+ICAgMikgUGxlYXNlIGV4cGFuZCBTVEggb24gZmlyc3Qgb2NjdXJy ZW5jZSAoaW4gc2VjIDQuMSkNCj4+DQo+PiBBZGRyZXNzZWQgYnkNCj4+IGh0dHBzOi8vZ2l0aHVi LmNvbS9yb2JzdHJhZGxpbmcvY2VydGlmaWNhdGUtdHJhbnNwYXJlbmN5LXJmY3MvY29tbWl0L2Qy ZDZiMGFjMzAzYWYyNjU5ZTVkZjUzODM5MTAwMmYxYmY0NTRlZGINCj4+DQo+Pj4gICAzKSBTZWMg NC40OiDigJ5BIGxvZydzIG9wZXJhdG9yIE1VU1QgZWl0aGVyIGFsbG9jYXRlIHRoZSBPSUQNCj4+ PiAgICAgIHRoZW1zZWx2ZXMgb3IgcmVxdWVzdCBhbiBPSUQgZnJvbSB0aGUgTG9nIElEIFJlZ2lz dHJ5IChzZWUNCj4+PiAgICAgIFNlY3Rpb24gMTAuNi4xKS7igJwNCj4+PiBJc24ndCB0aGVyZSBh biBvYmxpZ2F0aW9uIHRvIHJlZ2lzdGVyPw0KPj4NCj4+IFRoZSBMb2cgSUQgUmVnaXN0cnkgaXMg bWVyZWx5IGEgc291cmNlIG9mIE9JRHMgdGhhdCBoYXZlIHNob3J0IERFUg0KPj4gZW5jb2Rpbmdz LiAgQSBsb2cgb3BlcmF0b3IgbWF5IGVpdGhlciAoMSkgcmVxdWVzdCBhbiBPSUQgZnJvbSB0aGUg TG9nIElEDQo+PiBSZWdpc3RyeSwgb3IgKDIpIGFsbG9jYXRlIGFuIE9JRCB0aGVtc2VsdmVzIChm cm9tIGFuIE9JRCBhcmMgdGhhdCB0aGV5DQo+PiBjb250cm9sLCBuYXR1cmFsbHkpLg0KPj4NCj4+ IFRoZSBSZWdpc3RyeSBpcyBub3QgaW50ZW5kZWQgdG8gYmUgYSBnbG9iYWwgZGlyZWN0b3J5IG9m IGFsbCBsb2dzLg0KPiANCj4gQ291bGQgYmUgZ29vZCB0byBjbGFyaWZ5IGluIHRoZSB0ZXh0Lg0K DQpBZGRyZXNzZWQgYnkgDQpodHRwczovL2dpdGh1Yi5jb20vcm9ic3RyYWRsaW5nL2NlcnRpZmlj YXRlLXRyYW5zcGFyZW5jeS1yZmNzL2NvbW1pdC8xOGJlM2JkYzBlYjNhOGY1Yjk1MDQwMDgxY2Nm YWRkY2QyOTI0ZmNiDQoNCj4+PiAgIDQpIHNlYyA0Ljg6IOKAnklmIGFuDQo+Pj4gICAgIGltcGxl bWVudGF0aW9uIHNlZXMgYW4gZXh0ZW5zaW9uIHRoYXQgaXQgZG9lcyBub3QgdW5kZXJzdGFuZCwg aXQNCj4+PiAgICAgU0hPVUxEIGlnbm9yZSB0aGF0IGV4dGVuc2lvbi7igJwNCj4+PiBNYXliZSBp dOKAmXMganVzdCBtZSBiZWNhdXNlIEkgbWF5IGhhdmUgbWlzc2VkIHNvbWUgY29udGV4dCBidXQg ZG9lcyDigJ5pZ25vcmXigJwNCj4+PiBtZWFuIGhlcmUgdGhhdCBpdCBzaG91bGQgbG9nIGl0IG9y IG5vdD8NCj4+DQo+PiAiSXQiICh0aGUgcHJlY2VydGlmaWNhdGUgb3IgY2VydGlmaWNhdGUpIG11 c3QgaGF2ZSBhbHJlYWR5IGJlZW4gbG9nZ2VkLA0KPj4gYmVjYXVzZSB0aGUgY29ycmVzcG9uZGlu ZyBTQ1QgKHRoYXQgY29udGFpbnMgYSBwb3RlbnRpYWxseSB1bnJlY29nbml6ZWQNCj4+IGV4dGVu c2lvbikgY291bGRuJ3Qgb3RoZXJ3aXNlIGV4aXN0Lg0KPiANCj4gQ291bGQgYmUgZ29vZCB0byBj bGFyaWZ5IGluIHRoZSB0ZXh0Lg0KDQpJIHRoaW5rIG90aGVyIHNlY3Rpb25zIG9mIHRoZSBkb2N1 bWVudCBhbHJlYWR5IG1ha2UgaXQgY2xlYXIgdGhhdCBhIA0KY2VydGlmaWNhdGUgb3IgcHJlY2Vy dGlmaWNhdGUgbXVzdCBiZSBzdWJtaXR0ZWQgdG8gKGFuZCBhY2NlcHRlZCBieSkgYSANCmxvZyBi ZWZvcmUgYW4gU0NUIHdpbGwgYmUgcHJvZHVjZWQuDQoNClNlY3Rpb24gMyBzYXlzOg0KICAgIklm IGEgbG9nIGFjY2VwdHMgYSBzdWJtaXNzaW9uLCBpdCB3aWxsIHJldHVybiBhIFNpZ25lZCBDZXJ0 aWZpY2F0ZQ0KICAgIFRpbWVzdGFtcCAoU0NUKSINCg0KU2VjdGlvbiA0IHNheXM6DQogICAiV2hl biBpdCByZWNlaXZlcyBhbmQgYWNjZXB0cyBhIHZhbGlkIHN1Ym1pc3Npb24sIHRoZSBsb2cgTVVT VCByZXR1cm4NCiAgICBhbiBTQ1QgdGhhdCBjb3JyZXNwb25kcyB0byB0aGUgc3VibWl0dGVkIGNl cnRpZmljYXRlIG9yDQogICAgcHJlY2VydGlmaWNhdGUuIg0KDQpJIHRoaW5rIHJlaXRlcmF0aW5n IHRoaXMgcG9pbnQgYWdhaW4gd291bGQgYmUgYm90aCB1bm5lY2Vzc2FyeSBhbmQgb3V0IA0Kb2Yg c2NvcGUgZm9yIHNlY3Rpb24gNC44LCB0aGUgcHVycG9zZSBvZiB3aGljaCBpcyB0byBkZWZpbmUg dGhlIA0Kc3RydWN0dXJlIG9mIGFuIFNDVC4NCg0KPj4+ICAgNSkgc2VjIDU6IOKAnk1BWSByZXRy eSB0aGUgc2FtZQ0KPj4+ICAgICByZXF1ZXN0IHdpdGhvdXQgbW9kaWZpY2F0aW9uIGF0IGEgbGF0 ZXIgZGF0ZS7igJwNCj4+PiBXb3VsZCBpdCBiZSBwb3NzaWJsZSB0byBwcm92aWRlIGEgcmVjb21t ZW5kYXRpb24gaG93IGxvbmcgdGhlIGNsaWVudCBzaG91bGQNCj4+PiB3YWl0Pw0KPj4NCj4+IFRo ZSB2ZXJ5IG5leHQgc2VudGVuY2UgaW4gc2VjdGlvbiA1IGFscmVhZHkgc3BlY2lmaWVzIGEgbWVj aGFuaXNtIGZvcg0KPj4gZG9pbmcganVzdCB0aGF0Og0KPj4gICAgJ05vdGUgdGhhdCBhcyBwZXIN Cj4+ICAgICBbUkZDNzIzMV0sIGluIHRoZSBjYXNlIG9mIGEgNTAzIHJlc3BvbnNlIHRoZSBsb2cg TUFZIGluY2x1ZGUgYQ0KPj4gICAgICJSZXRyeS1BZnRlcjoiIGhlYWRlciBpbiBvcmRlciB0byBy ZXF1ZXN0IGEgbWluaW11bSB0aW1lIGZvciB0aGUNCj4+ICAgICBjbGllbnQgdG8gd2FpdCBiZWZv cmUgcmV0cnlpbmcgdGhlIHJlcXVlc3Qu4oCZDQo+IA0KPiBJIG1lYW50LCB3b3VsZCBpdCBtYWtl IHNlbnNlIHRvIGFjdHVhbGx5IHByb3ZpZGUgYSBkZWZhdWx0IHZhbHVlIG9yIHNvbWV0aGluZyBm b3IgdGhpcyB3YWl0aW5nIHRpbWU/DQoNCldlIGNvdWxkLCBidXQgaXQgd291bGQgYmUgZmFpcmx5 IGFyYml0cmFyeS4gIFNvIHdoeSBib3RoZXI/DQoNClNvbWUgdHJhbnNpZW50IGZhaWx1cmVzIG1h eSBiZSB2ZXJ5IHNob3J0LWxpdmVkLCBidXQgb3RoZXJzIG1heSBsYXN0IGZvciANCmhvdXJzLiAg T25seSB0aGUgbG9nIG9wZXJhdG9yIGNhbiBwb3NzaWJseSBrbm93IGhvdyBsb25nIGEgY2xpZW50 IHNob3VsZCANCndhaXQgYmVmb3JlIHJldHJ5aW5nIGEgcmVxdWVzdCB3b3VsZCBiZSBleHBlY3Rl ZCB0byBzdWNjZWVkLg0KDQo+Pj4gICA2KSBzZWMgNS42OiDigJ5Mb2dzIE1BWSByZXN0cmljdCB0 aGUgbnVtYmVyIG9mIGVudHJpZXMgdGhhdCBjYW4gYmUgcmV0cmlldmVkIHBlcg0KPj4+ICAgICAi Z2V0LWVudHJpZXMiIHJlcXVlc3Qu4oCcDQo+Pj4gU2hvdWxkIHRoaXMgYmUgYWRkZWQgdG8gc2Vj IDQuMT8NCj4+DQo+PiBJIGRvbid0IHRoaW5rIHRoYXQncyBhIGdvb2QgaWRlYS4gIEkgY2FuIGlt YWdpbmUgdGhhdCBvcGVyYXRpb25hbCBpc3N1ZXMNCj4+IG1pZ2h0IGNhdXNlIGEgbG9nIG9wZXJh dG9yIHRvIHdhbnQgdG8gdmFyeSB0aGlzIHJlc3RyaWN0aW9uIGF0IGFueSB0aW1lLg0KPj4NCj4+ IENsaWVudHMgc2hvdWxkIGFsd2F5cyBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGdldC1lbnRyaWVz IHJlc3BvbnNlcyB0aGF0DQo+PiBjb250YWluIGZld2VyIGVudHJpZXMgdGhhbiB0aGV5IHJlcXVl c3RlZC4NCj4+DQo+PiBTZWUgYWxzbyBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy90cmFucy90 aWNrZXQvOTUNCj4+DQo+Pj4gICA3KSBzZWMgMTAuMzogQ291bGRu4oCZdCB5b3UgdXNlIHRoZSBU TFMgIFNpZ25hdHVyZVNjaGVtZSBSZWdpc3RyeSBkaXJlY3RseQ0KPj4+ICAgKGluc3RlYWQgb2Yg Zm9ybWluZyBhbiBvd24gcmVnaXN0cnkpPw0KPj4NCj4+IEl0IG1ha2VzIHNlbnNlIHRvIHN5bmNo cm9uaXplIHRoZSBzaWduYXR1cmUgYWxnb3JpdGhtIHZhbHVlcyB3ZSB1c2Ugd2l0aA0KPj4gdGhl IFRMUyBTaWduYXR1cmVBbGdvcml0aG0gcmVnaXN0cnksIGJlY2F1c2Ugb3VyIGRhdGEgc3RydWN0 dXJlcyBhcmUNCj4+IGRlZmluZWQgYWNjb3JkaW5nIHRvIHRoZSBjb252ZW50aW9ucyBsYWlkIG91 dCBpbiB0aGUgVExTIFJGQy4NCj4+DQo+PiBIb3dldmVyLCBJIGRvbid0IHRoaW5rIGl0J3MgYSBn b29kIGlkZWEgdG8gdXNlIHRoZSBUTFMNCj4+IFNpZ25hdHVyZUFsZ29yaXRobSByZWdpc3RyeSBk aXJlY3RseS4gIEluIDY5NjItYmlzLCB3ZSd2ZSB0YWtlbiBzdGVwcyB0bw0KPj4gbWFrZSBsb2cg YXJ0aWZhY3RzIHNtYWxsZXIgKGNvbXBhcmVkIHRvIFJGQzY5NjIpOyByZWxhdGVkIHRvIHRoYXQs IHdlJ3ZlDQo+PiByZW1vdmVkIHRoZSBvcHRpb24gb2YgbG9ncyBiZWluZyBwZXJtaXR0ZWQgdG8g dXNlIFJTQSBrZXlzL3NpZ25hdHVyZXMuDQo+PiBodHRwczovL3d3dy5pYW5hLm9yZy9hc3NpZ25t ZW50cy90bHMtcGFyYW1ldGVycy90bHMtcGFyYW1ldGVycy54aHRtbCN0bHMtcGFyYW1ldGVycy0x Ng0KPj4gcGVybWl0cyBSU0EsIGFuZCBzZXZlcmFsIG90aGVyIHNpZ25hdHVyZSBhbGdvcml0aG1z IHRoYXQgd2UgZG9uJ3Qgd2lzaA0KPj4gdG8gcGVybWl0IG9yIHJlY29tbWVuZCAoaS5lLiAiYW5v bnltb3VzIiwgRFNBLCBHT1NULCBhbmQgIlJlc2VydmVkIGZvcg0KPj4gUHJpdmF0ZSBVc2UiKS4N Cj4+DQo+Pj4gICA4KSBzZWMgMTAuNDogaSBXb25kZXIgaWYgYW4gUkZDLXJlcXVpcmVkIHBvbGlj eSB3b3VsZG7igJl0IGJlIG1vcmUgYXBwcm9wcmlhdGUNCj4+PiAgIGZvciB0aGUgVmVyc2lvbmVk VHJhbnNUeXBlcyByZWdpc3RyeT8NCj4+DQo+PiBJbiA2OTYyLWJpcyBzZWN0aW9uIDEwLjQuMSwg d2UgYXNrIHRoZSBhcHBvaW50ZWQgRXhwZXJ0IHRvICJyZXZpZXcgdGhlDQo+PiBwdWJsaWMgc3Bl Y2lmaWNhdGlvbiB0byBlbnN1cmUgdGhhdCBpdCBpcyBkZXRhaWxlZCBlbm91Z2ggdG8gZW5zdXJl DQo+PiBpbXBsZW1lbnRhdGlvbiBpbnRlcm9wZXJhYmlsaXR5Ii4NCj4+DQo+PiBBRkFJQ1QgZnJv bSBSRkM4MTI2LCAiUkZDIFJlcXVpcmVkIiBkb2Vzbid0IGltcGx5IEV4cGVydCBSZXZpZXcsIHdo ZXJlYXMNCj4+ICJTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIiBkb2VzLiAgU28gSSB0aGluayB3ZSBz aG91bGQgbGVhdmUgaXQgYXMNCj4+ICJTcGVjaWZpY2F0aW9uIFJlcXVpcmVk4oCdLg0KPiANCj4g UkZDIFJlcXVpcmVkIGltcGxpZXMgdGhhdCB0aGUgZG9jdW1lbnQgZ290IHNvbWUgcmV2aWV3cyBi YXNlZCBvbiB0aGUgcmVzcGVjdGl2ZSBwcm9jZXNzLg0KPiANCj4gSG93ZXZlciwgSSBndWVzcyBJ IGFjdHVhbGx5IHdhbnRlZCB0byBwcm9wb3NlIElFVEYgUmV2aWV3IChhbmQgdXNlZCB0aGUgd3Jv bmcgdGVybSkuIFRoYXQgd291bGQgaW1wbHkgdGhhdCBpdCBoYWQgdG8gZ28gdGhyb3VnaCB0aGUg SUVURiBwcm9jZXNzIHdpdGggcmVzcGVjdGl2ZSByZXZpZXcgKGFuZCB0aGVyZWZvcmUgdXN1YWxs eSBpdCBpcyBleHBlY3RlZCB0aGF0IG5vIGV4cGVydCByZXZpZXcgaXMgbmVlZGVkIGluIGFkZGl0 aW9uKS4gQW55d2F5IHRoaXMgd2FzIG1haW5seSBhIGNvbW1lbnQgdG8gZG91YmxlLWNoZWNrIHRo aXMgZGVjaXNpb24uDQoNCkkgcGVyc29uYWxseSBkb24ndCBoYXZlIGEgcHJlZmVyZW5jZSwgYnV0 IEknbGwgc3RhcnQgYW5vdGhlciBsaXN0IHRocmVhZCANCnRvIGRpc2N1c3MgdGhpcyBwcm9wb3Nh bC4NCg0KPj4+ICAgOSkgc2VjIDEwLjYuMTpJIGd1ZXNzICB0aGUgcmVnaXN0cmF0aW9uIHBvbGlj eSBpcyBGQ0ZTPyBSRkMgODEyNiByZWNvbW1lbmQgdG8NCj4+PiAgIGFsd2F5cyAoY2xlYXJseSkg bmFtZSB0aGUgcmVnaXN0cnkuDQo+Pg0KPj4gVGhhbmtzLiAgSW4gb3VyIHJlc3BvbnNlIHRvIEFs aXNzYSBDb29wZXIncyBESVNDVVNTL0NPTU1FTlRzIChzZWUNCj4+IGh0dHBzOi8vZ2l0aHViLmNv bS9nb29nbGUvY2VydGlmaWNhdGUtdHJhbnNwYXJlbmN5LXJmY3MvcHVsbC8zMDkpLCB3ZSd2ZQ0K Pj4gYWxyZWFkeSBjbGFyaWZpZWQgdGhhdCB0aGUgTG9nIElEIFJlZ2lzdHJ5IGlzIGluZGVlZCBG aXJzdCBDb21lIEZpcnN0DQo+PiBTZXJ2ZWQuDQo+Pg0KPj4+IEFuZCBmaW5hbGx5IG9uZSBoaWdo ZXIgbGV2ZWwgcXVlc3Rpb24gbWFpbmx5IG91dCBvZiBjdXJpb3NpdHk6IHdhcyBpdA0KPj4+IGNv bnNpZGVyZWQgdG8gZS5nLiB1c2UganNvbiBmb3IgYWxsIGRhdGEgc3RydWN0dXJlcz8gSXMgdGhl cmUgYSBwZXJmb3JtYW5jZQ0KPj4+IHJlYXNvbiB0byBub3QgZG8gdGhhdCBvciB3YXNu4oCZdCB0 aGF0IGV2ZW4gZGlzY3Vzc2VkPw0KPj4NCj4+IFBsZWFzZSBkb24ndCByZXN0YXJ0IHRoZSBmb3Jt YXQgd2Fycy4gIDstKQ0KPiANCj4gRGlkbuKAmXQga25vdyB0aGF04oCmDQo+IA0KPj4NCj4+IFdl IG11c3QgdXNlIEFTTi4xIGZvciBhbGwgZGF0YSBzdHJ1Y3R1cmVzLCBiZWNhdXNlIFguNTA5IGNl cnRpZmljYXRlcw0KPj4gYXJlIGludm9sdmVkLiAgQnV0IHdlIG11c3QgdXNlICJUTFMgZW5jb2Rp bmciIGZvciBhbGwgZGF0YSBzdHJ1Y3R1cmVzLA0KPj4gYmVjYXVzZSBUTFMgaXMgaW52b2x2ZWQu ICBCdXQgd2UgbXVzdCB1c2UgSlNPTiBmb3IgYWxsIGRhdGEgc3RydWN0dXJlcywNCj4+IGJlY2F1 c2UgSlNPTiBpcyBtb3JlIEFQSS1mcmllbmRseS4NCj4+DQo+PiBJdCB3YXMgaW1wb3NzaWJsZSB0 byBwbGVhc2UgZXZlcnlvbmUuICBXZSBoYWQgdG8gY2hvb3NlIHNvbWV0aGluZywgc28gd2UNCj4+ IGNob3NlIFRMUyBlbmNvZGluZyBmb3IgdGhlIGRhdGEgc3RydWN0dXJlcywgYW5kIEpTT04gZm9y IHRoZSBBUElzLg0KPj4NCj4+IEFzIEkgbWVudGlvbmVkIGVhcmxpZXIsIG9uZSBnb2FsIG9mIDY5 NjItYmlzIGlzIHRvIG1ha2UgbG9nIGFydGlmYWN0cw0KPj4gc21hbGxlci4gIFRMUyBlbmNvZGlu ZyBpcyBtb3JlIHN1aXRlZCB0byB0aGlzIHRoYW4gSlNPTi4NCj4gDQo+IE9rYXkgdGhhbmtzIGZv ciB0aGUgYmFja2dyb3VuZCBpbmZvLiBBcyBsb25nIGFzIHRoaXMgd2FzIGRpc2N1c3NlZCB0aGF0 J3MgZmluZSENCg0KLS0gDQpSb2IgU3RyYWRsaW5nDQpTZW5pb3IgUmVzZWFyY2ggJiBEZXZlbG9w bWVudCBTY2llbnRpc3QNClNlY3RpZ28gTGltaXRlZA0KDQo= From nobody Wed Oct 16 06:56:21 2019 Return-Path: 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 7CE5E120026 for ; Wed, 16 Oct 2019 06:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 pTnYE_wIKGAK for ; Wed, 16 Oct 2019 06:56:17 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750058.outbound.protection.outlook.com [40.107.75.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BAED12001E for ; Wed, 16 Oct 2019 06:56:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bgnyqRt3fnCgH8WBgGrDb/+eyiFifEzoUE1PU1FUNaumLvxH0bv5h9D3dcWzj7+PHnbx0pWdcn7obmH0FuVn4LlA1t5QuTgpXVwYP0teNL55qh+zDuwJgFKVKq8lxpc/FnXIsqroY40HyOiuCoSn08ip1bxzeGTjboJXm+uE2UdFgYZtSj4AtA67s55mbqQS+gPVVLMW0/PsyLbcw132hb7WAYi+d5hJL2nc2MfqEZfhzLhpuKI5wrDL+tF7YJcSMKDDCITYgRa6euLfWUp8l6cZaTlZ5uOBaKECP3bTU4UPvvR3wpIoaP615NHuKuUtkXGOo13qW+rgsf4+BSsnUQ== 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=UkkbyTfc+hE+0dGC/+9NNALjKymU9KJDsMWa64z/b+s=; b=KFKEnqeurPrwVxA7PLY4zQ6W2upA8UZmepSPWh+0V6L4tXXwavg+c7ctzWyr7/hakwaWlejHnNJ6KUI1zEkjGHKIk//Pg5mkjvlfQXO9nr+V11TC6gvXFTYraRNFqyJChiW9oLf2MRjlnyNw2bYr7TCIAqz+hNdg5cePcgV/JTVgDXHFhZyVk28qySmxnJtIAicnBf5BovbXAT1uhyJoBYdab4UAtdBn7mVzotO79DZ0eLWwWD9TFgaGxG6DhxI5FUOGYYF5S6yCVShRWGVwXJrpEz57Fr01HJY/a6hT4eDWkYMOyFXkzyoEm2EqrUvHHYzMEN9hwiTrXAzCurKvVQ== 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=UkkbyTfc+hE+0dGC/+9NNALjKymU9KJDsMWa64z/b+s=; b=CuiCoDjDB+BZxxY8upostb8f/jnKboWjWXp7iZeQgtgKet/sPaSH3UAaor6PGF/vOAGC7H3ITL935XsjFy4r3L4NSt+rfeRzAunTJCp8cd0evA5Xp7xD9YYNNc/Fu6bmytgt98NkoFHK4BAaJ6uhsYHrr7L4ZxPyGKwxunyWtaE= Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB3963.namprd17.prod.outlook.com (20.180.23.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.23; Wed, 16 Oct 2019 13:56:15 +0000 Received: from DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695]) by DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695%3]) with mapi id 15.20.2347.023; Wed, 16 Oct 2019 13:56:15 +0000 From: Rob Stradling To: "trans@ietf.org" CC: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: Assignment Policy for the "CT VersionedTransTypes" registry Thread-Index: AQHVhCl6Tfu4KIllBUKBUHRfVqQsgQ== Date: Wed, 16 Oct 2019 13:56:15 +0000 Message-ID: <5b95ae17-d18c-e838-6287-3107976876c3@sectigo.com> References: <155257141035.2645.11460081509986673853.idtracker@ietfa.amsl.com> <1589f7c5-c4cb-4a87-d972-f7664b954d3f@sectigo.com> In-Reply-To: <1589f7c5-c4cb-4a87-d972-f7664b954d3f@sectigo.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0060.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:60::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-originating-ip: [2a0e:ac00:25d:300:f68e:38ff:fe7a:a226] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3db8bc4c-dbec-458b-f42f-08d752409c8c x-ms-traffictypediagnostic: DM6PR17MB3963: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(366004)(396003)(346002)(376002)(136003)(54094003)(199004)(189003)(2351001)(305945005)(476003)(446003)(46003)(71190400001)(71200400001)(2616005)(186003)(25786009)(8936002)(11346002)(561944003)(6116002)(5660300002)(6506007)(86362001)(386003)(53546011)(31686004)(966005)(2501003)(316002)(99286004)(36756003)(31696002)(76176011)(7736002)(478600001)(52116002)(102836004)(486006)(8676002)(1730700003)(81156014)(81166006)(6436002)(66946007)(66476007)(4326008)(256004)(6306002)(5640700003)(6512007)(6486002)(14454004)(6916009)(2906002)(66446008)(64756008)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB3963; 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: U+ksX+z2xvr3AQMXkvwHKGWQOJv1BFi6QAgs2CM8HeQaeO/CTs5+Mi/izLBVf2LLK2A9W8GgQb3DZYex1E3q73n50OeX7rPk0hIR5y4SDKg42uGZz8niXvpLgY8lsKWSuxjG1OEiP7FtaK6/LUnLkr03qIlbWYbe5oB3qv1qDVAGM5nSh/droISiZ1zQ0ZQn50EwE+tUZChvxPntPF5TevC+VSycqRXkjGidqlnhJ5Ay0Li10DsM10e+0HVHuuBTAiDiGVakW0r9q2AsIYLJNzs765s7NqWCTe2O0M8sn7o3VhBziQfClMFDgZuhq5rd+nJtfdQpcbJyLgqHLMosQpcK3cCSHT6uuDevfOtkGtjELTyhZ8AZXqJmCSYO6c+eOzOlRziDgfu5JWWRnsAx0OjB17aPEJ093sip/55mQ+GpEpB5cq02Z9tJgPXAuijOQFLhYL2RH/fgJeueBT7HJw== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3db8bc4c-dbec-458b-f42f-08d752409c8c X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2019 13:56:15.6391 (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: GBvVd40Hf3kx4OkuD9EXqBZuZQLbFyZ5ccw68cM/Wg4InFAE8yb6xo8IFpMbAKgvODA8U++2wI23cpRAWWSfTQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3963 Archived-At: Subject: [Trans] Assignment Policy for the "CT VersionedTransTypes" registry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 13:56:19 -0000 TWlyamEgaGFzIHByb3Bvc2VkIHRoYXQgd2UgY2hhbmdlIHRoZSBhc3NpZ25tZW50IHBvbGljeSBm cm9tIA0KIlNwZWNpZmljYXRpb24gUmVxdWlyZWQiIChzZWUgDQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjODEyNiNzZWN0aW9uLTQuNikgdG8gIklFVEYgUmV2aWV3IiAoc2VlIA0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxMjYjc2VjdGlvbi00LjgpLg0KDQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODEyNiNzZWN0aW9uLTQuMTEgc2F5czoNCiAgICJXaGVu IHJldmlld2luZyBhIGRvY3VtZW50IHRoYXQgYXNrcyBJQU5BIHRvIGNyZWF0ZSBhIG5ldyByZWdp c3RyeSBvcg0KICAgIGNoYW5nZSBhIHJlZ2lzdHJhdGlvbiBwb2xpY3kgdG8gYW55IHBvbGljeSBt b3JlIHN0cmluZ2VudCB0aGFuIEV4cGVydA0KICAgIFJldmlldyBvciBTcGVjaWZpY2F0aW9uIFJl cXVpcmVkLCB0aGUgSUVTRyBzaG91bGQgYXNrIGZvcg0KICAgIGp1c3RpZmljYXRpb24gdG8gZW5z dXJlIHRoYXQgbW9yZSByZWxheGVkIHBvbGljaWVzIGhhdmUgYmVlbg0KICAgIGNvbnNpZGVyZWQg YW5kIHRoYXQgdGhlIG1vcmUgc3RyaWN0IHBvbGljeSBpcyB0aGUgcmlnaHQgb25lLiINCg0KQ2Fu IGFueWJvZHkgcHJvdmlkZSBqdXN0aWZpY2F0aW9uIGZvciBhZG9wdGluZyBNaXJqYSdzIHByb3Bv c2FsPw0KDQpPbiAxNi8xMC8yMDE5IDE0OjM2LCBSb2IgU3RyYWRsaW5nIHdyb3RlOg0KPiBPbiAx NC8xMC8yMDE5IDE2OjMyLCBNaXJqYSBLdWVobGV3aW5kIHdyb3RlOg0KPHNuaXA+DQo+Pj4+ICAg IDgpIHNlYyAxMC40OiBpIFdvbmRlciBpZiBhbiBSRkMtcmVxdWlyZWQgcG9saWN5IHdvdWxkbuKA mXQgYmUgbW9yZSBhcHByb3ByaWF0ZQ0KPj4+PiAgICBmb3IgdGhlIFZlcnNpb25lZFRyYW5zVHlw ZXMgcmVnaXN0cnk/DQo+Pj4NCj4+PiBJbiA2OTYyLWJpcyBzZWN0aW9uIDEwLjQuMSwgd2UgYXNr IHRoZSBhcHBvaW50ZWQgRXhwZXJ0IHRvICJyZXZpZXcgdGhlDQo+Pj4gcHVibGljIHNwZWNpZmlj YXRpb24gdG8gZW5zdXJlIHRoYXQgaXQgaXMgZGV0YWlsZWQgZW5vdWdoIHRvIGVuc3VyZQ0KPj4+ IGltcGxlbWVudGF0aW9uIGludGVyb3BlcmFiaWxpdHkiLg0KPj4+DQo+Pj4gQUZBSUNUIGZyb20g UkZDODEyNiwgIlJGQyBSZXF1aXJlZCIgZG9lc24ndCBpbXBseSBFeHBlcnQgUmV2aWV3LCB3aGVy ZWFzDQo+Pj4gIlNwZWNpZmljYXRpb24gUmVxdWlyZWQiIGRvZXMuICBTbyBJIHRoaW5rIHdlIHNo b3VsZCBsZWF2ZSBpdCBhcw0KPj4+ICJTcGVjaWZpY2F0aW9uIFJlcXVpcmVk4oCdLg0KPj4NCj4+ IFJGQyBSZXF1aXJlZCBpbXBsaWVzIHRoYXQgdGhlIGRvY3VtZW50IGdvdCBzb21lIHJldmlld3Mg YmFzZWQgb24gdGhlIHJlc3BlY3RpdmUgcHJvY2Vzcy4NCj4+DQo+PiBIb3dldmVyLCBJIGd1ZXNz IEkgYWN0dWFsbHkgd2FudGVkIHRvIHByb3Bvc2UgSUVURiBSZXZpZXcgKGFuZCB1c2VkIHRoZSB3 cm9uZyB0ZXJtKS4gVGhhdCB3b3VsZCBpbXBseSB0aGF0IGl0IGhhZCB0byBnbyB0aHJvdWdoIHRo ZSBJRVRGIHByb2Nlc3Mgd2l0aCByZXNwZWN0aXZlIHJldmlldyAoYW5kIHRoZXJlZm9yZSB1c3Vh bGx5IGl0IGlzIGV4cGVjdGVkIHRoYXQgbm8gZXhwZXJ0IHJldmlldyBpcyBuZWVkZWQgaW4gYWRk aXRpb24pLiBBbnl3YXkgdGhpcyB3YXMgbWFpbmx5IGEgY29tbWVudCB0byBkb3VibGUtY2hlY2sg dGhpcyBkZWNpc2lvbi4NCj4gDQo+IEkgcGVyc29uYWxseSBkb24ndCBoYXZlIGEgcHJlZmVyZW5j ZSwgYnV0IEknbGwgc3RhcnQgYW5vdGhlciBsaXN0IHRocmVhZA0KPiB0byBkaXNjdXNzIHRoaXMg cHJvcG9zYWwuDQo8c25pcD4NCg0KLS0gDQpSb2IgU3RyYWRsaW5nDQpTZW5pb3IgUmVzZWFyY2gg JiBEZXZlbG9wbWVudCBTY2llbnRpc3QNClNlY3RpZ28gTGltaXRlZA0KDQo= From nobody Wed Oct 16 06:57:02 2019 Return-Path: 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 E510E1200F4 for ; Wed, 16 Oct 2019 06:56:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 I44zqpArnVaO for ; Wed, 16 Oct 2019 06:56:56 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820072.outbound.protection.outlook.com [40.107.82.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4AEA120026 for ; Wed, 16 Oct 2019 06:56:55 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WVwLOBne3MoTf8modghQbDGE3HPE1QbRJ2IYuVOkLwRuibsHwm2bAtfzljWzOeobtwwNDcZL2mDqeTcl9Y5y8Z9ajTYRWklarsUBRN4IFbMdX3aUVAqUJu9Lz+0ERQORQmVbY3QNBnmtK84gAk7kPhoilK5h4wlTuAe2zvhYzSQC1R/NoshZCKJ0hh0NO43RxBjx6YVym447w63zjpryYnRqlcEf5dswP/dnzPUjRyjEL5H8obmkoI1AA+CDzYgSyQ8oj6n5iP5oDaB5iUlQExM0iCXy/xWz43ELC6Hfq2cc3QB4eXQtRQs9zzMjPVVXACxwMwkNBkZ27Lj0XOYCuQ== 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=UkkbyTfc+hE+0dGC/+9NNALjKymU9KJDsMWa64z/b+s=; b=LL/dSvXwHd/95CwK3Bk7nDLFZsb1xKvxWBvKhk9Qv/5xea+bScVWNuxgNtvceGUpI0RjU4hcRxQ8KwUP2z2YGPO208/A9h4iYPFDXrK9UoLTBG4pnP7TRtS0fSoDr6fne3OdF38aCQlnSfS6O17epUjdLsPesTarXNVw5ip07avKlNvjPC1XSbqKNDhCmMDLFL2EHYNRqteEYSQcr21s4u0De7isiphA0DuZZMKSrMtCI9SNJjJmYh7dq1CzqzChVKNk3049JmBQocwW9TPoJvjYznd1NyfUkzXlP1hqUhMyuojGHrCU/HrOX2Vw928EHO7q+XKpoKwlpMPege1RQg== 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=UkkbyTfc+hE+0dGC/+9NNALjKymU9KJDsMWa64z/b+s=; b=A8k3367oLZWV7zjHE714q6Lb269hKvNPL+xFxJ8IQP45J1wUwlwDb5YpFf/iO/Ma06cQZ3h8Nop53yP7wkg7J4xOx+8oNlKo2vOBEf3d+f4Ec/9t7F237Emmw9sspgi8f6WQWJj0LEGHnBVPZFx2pT6xBhkmTTGXBEkTZOXo+Oo= Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB3788.namprd17.prod.outlook.com (20.180.21.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2347.23; Wed, 16 Oct 2019 13:56:53 +0000 Received: from DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695]) by DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695%3]) with mapi id 15.20.2347.023; Wed, 16 Oct 2019 13:56:53 +0000 From: Rob Stradling To: "trans@ietf.org" CC: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: Assignment Policy for the 6962-bis "CT VersionedTransTypes" registry Thread-Index: AQHVhCmQuM6dPQx6OECGVFVH5aWscA== Date: Wed, 16 Oct 2019 13:56:52 +0000 Message-ID: <8dcf429d-cc2a-f3b5-e33c-bdf83d2e11e3@sectigo.com> References: <155257141035.2645.11460081509986673853.idtracker@ietfa.amsl.com> <1589f7c5-c4cb-4a87-d972-f7664b954d3f@sectigo.com> In-Reply-To: <1589f7c5-c4cb-4a87-d972-f7664b954d3f@sectigo.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0058.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:60::22) 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: 13cdb46c-6f62-4473-6363-08d75240b2cf x-ms-traffictypediagnostic: DM6PR17MB3788: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(346002)(376002)(136003)(54094003)(199004)(189003)(2351001)(305945005)(476003)(446003)(71190400001)(46003)(71200400001)(2616005)(25786009)(186003)(11346002)(8936002)(561944003)(6116002)(5660300002)(6506007)(86362001)(31686004)(386003)(53546011)(966005)(316002)(99286004)(2501003)(486006)(36756003)(31696002)(7736002)(76176011)(478600001)(52116002)(102836004)(8676002)(1730700003)(81156014)(81166006)(6436002)(66946007)(66476007)(4326008)(256004)(6306002)(5640700003)(6512007)(6486002)(14454004)(6916009)(2906002)(66446008)(64756008)(66556008); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB3788; 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: Phn+qi6OZssl/K9I6OXJHTAaDABbFTwmWyCDpwgzHgl5YOMfjObFetx85zNFgBi+0gu+vJogQ+VtYD7t1OJUahBTNr1yjLvSnJpHEYpeEhJv/p9fq1J+ceYFZubtcI0nZVuCz2dgctK23ikxScJ+z30rA7Jx4UpHLLcOLNS4xH7QJQ1ANMwBEI46JKdJhuNXbbGuRR38cQ8bh51EUsBFNnkHGbeND6E8499SV9XlNICPPZdwPPVpfrPCRKDo6ELL/LjzM9V17/zBXeinkXd9K9mQfamuaUkubf6ZsBSNp3S/KVPZQaoev4tCpskO0pTlu6OeY6Ib9dO/NKoowxse0Ac+bSSTQrO2iqG3327BLjGtN4BFcnDRty7GSgPQrHyugicosT0Fi/Ys67ub0fEDI4+vUHmqbOCz2WcrVuhBuqw1JVcAGZ0TW9TO8uVllqH9jA/WliVhmW6Jsde8o6WD5Q== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <478EEA09757F6542A637C551ECF4BDE0@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 13cdb46c-6f62-4473-6363-08d75240b2cf X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2019 13:56:52.9004 (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: 1+TVV35PJPy3WZVHQxvYaY2BC1ZWptUnqfNrl7qpIMf905REBWbjo/9fL2QRieYl0jyr/k+Grx7YqFZXOCoeww== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3788 Archived-At: Subject: [Trans] Assignment Policy for the 6962-bis "CT VersionedTransTypes" registry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 13:56:58 -0000 TWlyamEgaGFzIHByb3Bvc2VkIHRoYXQgd2UgY2hhbmdlIHRoZSBhc3NpZ25tZW50IHBvbGljeSBm cm9tIA0KIlNwZWNpZmljYXRpb24gUmVxdWlyZWQiIChzZWUgDQpodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjODEyNiNzZWN0aW9uLTQuNikgdG8gIklFVEYgUmV2aWV3IiAoc2VlIA0KaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzgxMjYjc2VjdGlvbi00LjgpLg0KDQpodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjODEyNiNzZWN0aW9uLTQuMTEgc2F5czoNCiAgICJXaGVu IHJldmlld2luZyBhIGRvY3VtZW50IHRoYXQgYXNrcyBJQU5BIHRvIGNyZWF0ZSBhIG5ldyByZWdp c3RyeSBvcg0KICAgIGNoYW5nZSBhIHJlZ2lzdHJhdGlvbiBwb2xpY3kgdG8gYW55IHBvbGljeSBt b3JlIHN0cmluZ2VudCB0aGFuIEV4cGVydA0KICAgIFJldmlldyBvciBTcGVjaWZpY2F0aW9uIFJl cXVpcmVkLCB0aGUgSUVTRyBzaG91bGQgYXNrIGZvcg0KICAgIGp1c3RpZmljYXRpb24gdG8gZW5z dXJlIHRoYXQgbW9yZSByZWxheGVkIHBvbGljaWVzIGhhdmUgYmVlbg0KICAgIGNvbnNpZGVyZWQg YW5kIHRoYXQgdGhlIG1vcmUgc3RyaWN0IHBvbGljeSBpcyB0aGUgcmlnaHQgb25lLiINCg0KQ2Fu IGFueWJvZHkgcHJvdmlkZSBqdXN0aWZpY2F0aW9uIGZvciBhZG9wdGluZyBNaXJqYSdzIHByb3Bv c2FsPw0KDQpPbiAxNi8xMC8yMDE5IDE0OjM2LCBSb2IgU3RyYWRsaW5nIHdyb3RlOg0KPiBPbiAx NC8xMC8yMDE5IDE2OjMyLCBNaXJqYSBLdWVobGV3aW5kIHdyb3RlOg0KPHNuaXA+DQo+Pj4+ICAg IDgpIHNlYyAxMC40OiBpIFdvbmRlciBpZiBhbiBSRkMtcmVxdWlyZWQgcG9saWN5IHdvdWxkbuKA mXQgYmUgbW9yZSBhcHByb3ByaWF0ZQ0KPj4+PiAgICBmb3IgdGhlIFZlcnNpb25lZFRyYW5zVHlw ZXMgcmVnaXN0cnk/DQo+Pj4NCj4+PiBJbiA2OTYyLWJpcyBzZWN0aW9uIDEwLjQuMSwgd2UgYXNr IHRoZSBhcHBvaW50ZWQgRXhwZXJ0IHRvICJyZXZpZXcgdGhlDQo+Pj4gcHVibGljIHNwZWNpZmlj YXRpb24gdG8gZW5zdXJlIHRoYXQgaXQgaXMgZGV0YWlsZWQgZW5vdWdoIHRvIGVuc3VyZQ0KPj4+ IGltcGxlbWVudGF0aW9uIGludGVyb3BlcmFiaWxpdHkiLg0KPj4+DQo+Pj4gQUZBSUNUIGZyb20g UkZDODEyNiwgIlJGQyBSZXF1aXJlZCIgZG9lc24ndCBpbXBseSBFeHBlcnQgUmV2aWV3LCB3aGVy ZWFzDQo+Pj4gIlNwZWNpZmljYXRpb24gUmVxdWlyZWQiIGRvZXMuICBTbyBJIHRoaW5rIHdlIHNo b3VsZCBsZWF2ZSBpdCBhcw0KPj4+ICJTcGVjaWZpY2F0aW9uIFJlcXVpcmVk4oCdLg0KPj4NCj4+ IFJGQyBSZXF1aXJlZCBpbXBsaWVzIHRoYXQgdGhlIGRvY3VtZW50IGdvdCBzb21lIHJldmlld3Mg YmFzZWQgb24gdGhlIHJlc3BlY3RpdmUgcHJvY2Vzcy4NCj4+DQo+PiBIb3dldmVyLCBJIGd1ZXNz IEkgYWN0dWFsbHkgd2FudGVkIHRvIHByb3Bvc2UgSUVURiBSZXZpZXcgKGFuZCB1c2VkIHRoZSB3 cm9uZyB0ZXJtKS4gVGhhdCB3b3VsZCBpbXBseSB0aGF0IGl0IGhhZCB0byBnbyB0aHJvdWdoIHRo ZSBJRVRGIHByb2Nlc3Mgd2l0aCByZXNwZWN0aXZlIHJldmlldyAoYW5kIHRoZXJlZm9yZSB1c3Vh bGx5IGl0IGlzIGV4cGVjdGVkIHRoYXQgbm8gZXhwZXJ0IHJldmlldyBpcyBuZWVkZWQgaW4gYWRk aXRpb24pLiBBbnl3YXkgdGhpcyB3YXMgbWFpbmx5IGEgY29tbWVudCB0byBkb3VibGUtY2hlY2sg dGhpcyBkZWNpc2lvbi4NCj4gDQo+IEkgcGVyc29uYWxseSBkb24ndCBoYXZlIGEgcHJlZmVyZW5j ZSwgYnV0IEknbGwgc3RhcnQgYW5vdGhlciBsaXN0IHRocmVhZA0KPiB0byBkaXNjdXNzIHRoaXMg cHJvcG9zYWwuDQo8c25pcD4NCg0KLS0gDQpSb2IgU3RyYWRsaW5nDQpTZW5pb3IgUmVzZWFyY2gg JiBEZXZlbG9wbWVudCBTY2llbnRpc3QNClNlY3RpZ28gTGltaXRlZA0KDQo= From nobody Wed Oct 16 10:27:25 2019 Return-Path: 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 C90B7120812 for ; Wed, 16 Oct 2019 10:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 L9mgksD0bFzP for ; Wed, 16 Oct 2019 10:27:22 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E9DCF12080C for ; Wed, 16 Oct 2019 10:27:21 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9GHLvCu001867; Wed, 16 Oct 2019 18:27:19 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=9GByOIlhAso2jFtD5pbfF9Dj8WdYehIP3ZGDKEcddPI=; b=GlM59ADP/8hrJ/MId5Q5MTP8xJkKlZvcvRp6n43x3pRbcPEoFfDMZTRzpJvBcyQD1uPx LeAAThyBCSNToT841Ks0NA1ic5FBqJrOuOdCgbXaI5p5Zk6P21PuCIQADSm+n65MrmDb GyC5qhAsZHN+qK5YwEZmah6CMA/rmd3NmJTICqxzyEOht0uW5OTYEtOLxgCP1J5bD/Wr mNMks/ifmw1sTBPuH/r70fiXi4bpf6WKTWRetnAQbQML9+xlWPBHynGXgGI5NtnVRHt/ Ddr2WiCGgneobd2AVWAy7Ums94ejpMZkqOTNtB4WVqk/sqPSURnXg45PvD++53bAPlvc bw== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2vnp4qm00p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 16 Oct 2019 18:27:19 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9GHI0pI023075; Wed, 16 Oct 2019 10:27:18 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint5.akamai.com with ESMTP id 2vkct8xmsq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 16 Oct 2019 10:27:18 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 16 Oct 2019 13:27:17 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Wed, 16 Oct 2019 13:27:17 -0400 From: "Salz, Rich" To: Rob Stradling , "trans@ietf.org" CC: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Thread-Topic: [Trans] Assignment Policy for the "CT VersionedTransTypes" registry Thread-Index: AQHVhEb1x/vYuTjyuUK2Ch1kpAbChg== Date: Wed, 16 Oct 2019 17:27:17 +0000 Message-ID: <8C1B7D06-575B-439E-BBF5-DF77DF9D469D@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.184] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-16_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=952 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910160144 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-16_07:2019-10-16,2019-10-16 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=937 malwarescore=0 bulkscore=0 clxscore=1011 spamscore=0 priorityscore=1501 impostorscore=0 adultscore=0 phishscore=0 mlxscore=0 lowpriorityscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910160145 Archived-At: Subject: Re: [Trans] Assignment Policy for the "CT VersionedTransTypes" registry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 17:27:24 -0000 DQrvu79PbiAxMC8xNi8xOSwgOTo1NiBBTSwgIlJvYiBTdHJhZGxpbmciIDxyb2JAc2VjdGlnby5j b20+IHdyb3RlOg0KDQogICAgTWlyamEgaGFzIHByb3Bvc2VkIHRoYXQgd2UgY2hhbmdlIHRoZSBh c3NpZ25tZW50IHBvbGljeSBmcm9tIA0KICAgICJTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIiAoc2Vl IA0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MTI2I3NlY3Rpb24tNC42KSB0 byAiSUVURiBSZXZpZXciIChzZWUgDQogICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzgxMjYjc2VjdGlvbi00LjgpLg0KDQpJIGFtIGFnYWluc3Qgc3VjaCBhIGNoYW5nZS4NCg0K From nobody Wed Oct 16 10:58:28 2019 Return-Path: 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 5EBE6120930 for ; Wed, 16 Oct 2019 10:58:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 7w8hjug2Dat5 for ; Wed, 16 Oct 2019 10:58:24 -0700 (PDT) Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 212531200FD for ; Wed, 16 Oct 2019 10:58:24 -0700 (PDT) Received: by mail-pf1-x436.google.com with SMTP id 205so15215793pfw.2 for ; Wed, 16 Oct 2019 10:58:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:references:to:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=ZchpXBvJlIxxUZjrnHUwFqmEzZL64QGe2/adyqyX5m0=; b=QdlATIGkQOdzu4zQa4mOe1N5T2cJhc0VBT5oijNgqFmAUKH9fHJwK16sjklqR2WuZ6 yXPXW9296o84hnIsYdSxXRBChf4FDoJ3CSBixuIlWhuu0/7WT13ZbsvgS2KXHwiSjPmT eSSQUF6IhTWBOMTTgfsUGW6K8q6QI5WikF4LXcAHBF41uzXg45cfehfn7Iq10zh5fPsf 9otgfxx5OyzWTP/+jWJL1fxyYFcQ36vH3z2xTB6aFkWDV0Ln2rV3P7cJ8/uzM086lB9F 42FzKsr1+HBhT6innbnNSmI6QFrIT+Q4oiwcY/GFixcqijz7YKWNY4ZucPY/rxE0PN8x Zf3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=ZchpXBvJlIxxUZjrnHUwFqmEzZL64QGe2/adyqyX5m0=; b=jx/nSiLgyZ2MPC0Wayd0rUqnHbePKDdfHzlq4bHt1JtuC86ckI0PlaTFR1c6KNNSUy lKl1k0YrHlfDqBUET9mSwiMT7P4FZQL6EMGJuDYweYu43/k222uAMk2RuvGi4HpMnEFt cV3Jy90pv4AWH3wJM1d82bgILlLDfiLYvYhy9/imIknz6suuyiu320p/ad5KRY9mWNUO wQp5yHpsLYzo9+/0zJ8bQhi45wDWXPq6rulY8IRL42Qoq6HXc04h6lD+9TaLu4GSNVko g6bBH8ncvDtOYOV+d1R6nsDWACZQihC7xQ+62t+1cU0CBeAM9rD0grWz7RvwCRBGOiGP zeUw== X-Gm-Message-State: APjAAAVA6ajo767rLo9NDVRMrx6XViAb+OzzmRDYpC2gjeu+x9xz/n1j dyQ9S/k3tifPB8rx9rm9ZyR/4Gp6 X-Google-Smtp-Source: APXvYqymEglOeYiKlun4r2GJU9/1+xgcltEu2xbBLdKD4M7gMe8yL4jT0zGfg36eO3M22V2+GTa7pw== X-Received: by 2002:a65:52c3:: with SMTP id z3mr43977790pgp.387.1571248702724; Wed, 16 Oct 2019 10:58:22 -0700 (PDT) Received: from Melindas-MacBook-Pro.local ([8.18.217.202]) by smtp.gmail.com with ESMTPSA id c1sm40282036pfb.135.2019.10.16.10.58.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Oct 2019 10:58:22 -0700 (PDT) References: To: "trans@ietf.org" From: Melinda Shore X-Forwarded-Message-Id: Message-ID: <780c079c-fd58-2c82-8030-ca70d8f06194@gmail.com> Date: Wed, 16 Oct 2019 10:58:21 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] Fwd: [art] Last Call for Comments: draft-nottingham-rfc7320bis (BCP 190 update) X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 17:58:27 -0000 FYI. If you weighed in during the BCP 190 discussion you may want to give this a read during wg last call. Melinda -------- Forwarded Message -------- To: Applications and Real-Time Area Discussion From: Adam Roach Message-ID: Date: Tue, 15 Oct 2019 18:54:52 -0500 Subject: [art] Last Call for Comments: draft-nottingham-rfc7320bis (BCP 190 update) ART community (cc DISPATCH and HTTPBIS, but please respond only to ART): Based on conversations on the DISPATCH and ART mailing lists this past summer [1], and on in-person discussions that took place in Montreal, Mark Nottingham has produced a revision of BCP 190 that takes into account community input on several points. The changes are all intended to be relaxations of previously-enforced restrictions on how URI namespaces could be used. The revised document is at: https://datatracker.ietf.org/doc/draft-nottingham-rfc7320bis/ And diffs from the current, in-force version of BCP 190 can be seen here: https://www.ietf.org/rfcdiff?url1=rfc7320&url2=draft-nottingham-rfc7320bis-02 This message is intended to serve as a final, two-week last call for input from the ART community before the document is put forth for formal IETF consensus. The final consensus document will be published as a replacement of RFC 7320 (formally, it will obsolete it), and will become the new BCP 190. Please provide input on the document on the ART mailing list (art@ietf.org) by Wednesday, October 30th. To prevent the conversation from becoming fragmented, please do not respond to the HTTPBIS or DISPATCH mailing lists on this topic. Thanks! /a ____ [1] https://mailarchive.ietf.org/arch/search/?q=bcp%20190&f_list=art%2Cdispatch _______________________________________________ art mailing list art@ietf.org https://www.ietf.org/mailman/listinfo/art From nobody Wed Oct 16 11:25:52 2019 Return-Path: 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 962191201EF for ; Wed, 16 Oct 2019 11:25:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Rloj_Xy2WTpP for ; Wed, 16 Oct 2019 11:25:50 -0700 (PDT) Received: from mail-pf1-x429.google.com (mail-pf1-x429.google.com [IPv6:2607:f8b0:4864:20::429]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4BD2120116 for ; Wed, 16 Oct 2019 11:25:49 -0700 (PDT) Received: by mail-pf1-x429.google.com with SMTP id y22so15248049pfr.3 for ; Wed, 16 Oct 2019 11:25:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=Ww8oMJn0dnwIuMRVo6MAdqeV67zYhYjKSbh305Ok54o=; b=SdsJWcO2p46aNex7gCEalhuX+InaKeKXtGlXFKgQvuxA5M66Apbj5IesRoWWjYDhsS OcieETIzbEoW5AteWVAKnQBGeDNCku/i5s9R7e08XruyQ0tZtCaTKdN6FCqibndASneL ywE124Ms5TgHRez+HfzDMkFJTiv1luXD6C5g3axlycvTEaCofRQiWP4Nvu9GCjYEJ+DY proqPxOGTdJ63y3BHoqAcP1YmIg6JpbthudiSd2h28q1/z1s3730JomDfvYN848qOPWp xQQk173b9JS09AXgfneZfvY371dLwvCwM1gp6UNAnrn4BzNPh+IgI1T43Sm16Lx/Ml+H c30g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=Ww8oMJn0dnwIuMRVo6MAdqeV67zYhYjKSbh305Ok54o=; b=O3aCw3HSYjh6oainLICQRuUHhNxhTlHujztEXtM6bIXfZM6Oh+YCEfePDIgBmXEpHh zNgLiNx0W7DVthbvlsFA2MfO7S3MYnb5HdfAMWomayVrUVzPT8iBVCCvHJwStdVHMpAa cqmhHHOObu2C6uR5c7ICucad9qCWNJ7WLBTYc4fJRGeYyWMEQObNTaFI1lQajVNfYCo4 21Vzx44U28vPvfjczxwt+H1Fp5A9tNlG4kNsbw+Esm226+wZF7A17KGOZwuVoHgBvToc u6lsV4BMDmfbhHacKp6gmYTNFymszLU+xMZIyRiv9bLVukTmAJaPGAuhDXN1NJ6Hv1dD f3hw== X-Gm-Message-State: APjAAAXsTfjBuIC6fV50crIYh5oojpjQivqdpb72rxIjUbWnBYvHlGzx n/XMlFDOWCaR78rxAgG3U4C71VZv X-Google-Smtp-Source: APXvYqz3YDH96pSguM0tmaDvSc3VTKN38rewpzaMhUxJ2b4lh82u7u5EubFpZgfESN0VJQnGnEHk2A== X-Received: by 2002:a63:709:: with SMTP id 9mr46220771pgh.445.1571250348995; Wed, 16 Oct 2019 11:25:48 -0700 (PDT) Received: from Melindas-MacBook-Pro.local ([2620:11a:c081:20:350b:b102:2b15:c7bd]) by smtp.gmail.com with ESMTPSA id x20sm29086010pfp.120.2019.10.16.11.25.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Oct 2019 11:25:48 -0700 (PDT) To: trans@ietf.org References: <155257141035.2645.11460081509986673853.idtracker@ietfa.amsl.com> <1589f7c5-c4cb-4a87-d972-f7664b954d3f@sectigo.com> <8dcf429d-cc2a-f3b5-e33c-bdf83d2e11e3@sectigo.com> From: Melinda Shore Message-ID: <90e49a2e-6e90-63cb-2158-9a101beb9348@gmail.com> Date: Wed, 16 Oct 2019 11:25:47 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: <8dcf429d-cc2a-f3b5-e33c-bdf83d2e11e3@sectigo.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Assignment Policy for the 6962-bis "CT VersionedTransTypes" registry X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Oct 2019 18:25:51 -0000 On 10/16/19 5:56 AM, Rob Stradling wrote: > Can anybody provide justification for adopting Mirja's proposal? No hats: I don't see it as likely to improve the review, myself. Melinda From nobody Wed Oct 23 02:52:37 2019 Return-Path: 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 151B51207FC; Wed, 23 Oct 2019 02:52:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 vlt-eIs8VNnN; Wed, 23 Oct 2019 02:52:25 -0700 (PDT) Received: from wp513.webpack.hosteurope.de (wp513.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8223::]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B41AD12004E; Wed, 23 Oct 2019 02:52:25 -0700 (PDT) Received: from 200116b8248fd600d8506cad0e6f7019.dip.versatel-1u1.de ([2001:16b8:248f:d600:d850:6cad:e6f:7019]); authenticated by wp513.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1iNDJW-0005za-GC; Wed, 23 Oct 2019 11:52:22 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Mirja Kuehlewind In-Reply-To: <1589f7c5-c4cb-4a87-d972-f7664b954d3f@sectigo.com> Date: Wed, 23 Oct 2019 11:52:21 +0200 Cc: The IESG , "draft-ietf-trans-rfc6962-bis@ietf.org" , Paul Wouters , "trans@ietf.org" , "trans-chairs@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <155257141035.2645.11460081509986673853.idtracker@ietfa.amsl.com> <1589f7c5-c4cb-4a87-d972-f7664b954d3f@sectigo.com> To: Rob Stradling X-Mailer: Apple Mail (2.3445.104.11) X-bounce-key: webpack.hosteurope.de;ietf@kuehlewind.net;1571824345;81e76b5a; X-HE-SMSGID: 1iNDJW-0005za-GC Archived-At: Subject: Re: [Trans] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-trans-rfc6962-bis-31=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 09:52:29 -0000 Hi Rob, Just one more comment regarding the default for the waiting time: I = understand that it is arbitrary but I guess someone implementing CT in = the first place has to make the same arbitrary choice and just select = some value. Of course this value should be configurable but recommending = some default or at least a range or order of value could reduce = surprises. However, this is a just a recommendation from me and it=E2=80=99= s your call! Mirja > On 16. Oct 2019, at 15:36, Rob Stradling wrote: >=20 > On 14/10/2019 16:32, Mirja Kuehlewind wrote: >> Hi Rob, >>=20 >> Thanks for your replies and edits. I will clear my discuss as soon as = the new version is submitted. >=20 > Thanks Mirja. >=20 >> Please see some minor comments below! >=20 > Replies inline. >=20 >> Thanks! >> Mirja >>=20 >>=20 >>> On 14. Oct 2019, at 16:07, Rob Stradling wrote: >>>=20 >>> Hi Mirja. Sorry for the looong delay. >>>=20 >>> Comments inline, and I've just posted this PR: >>> https://github.com/google/certificate-transparency-rfcs/pull/316 >>>=20 >>> On 14/03/2019 13:50, Mirja K=C3=BChlewind via Datatracker wrote: >>>> Mirja K=C3=BChlewind has entered the following ballot position for >>>> draft-ietf-trans-rfc6962-bis-31: Discuss >>>>=20 >>>> Please refer to = https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>>=20 >>>>=20 >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ >>>>=20 >>>>=20 >>>>=20 >>>> = ---------------------------------------------------------------------- >>>> DISCUSS: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> There was a presentation at maprg IETF 103 about the question if CT = helps >>>> attackers to find new domains. I think this risk should at least be = mentioned >>>> in the security considerations section. >>>=20 >>> Addressed by >>> = https://github.com/robstradling/certificate-transparency-rfcs/commit/3b2ec= 0a51f8abb4c8c0b985614fefa4291432dd9 >>>=20 >>>> = ---------------------------------------------------------------------- >>>> COMMENT: >>>> = ---------------------------------------------------------------------- >>>>=20 >>>> 1) I found section 2 a bit hard to follow. Would it maybe be = possible to >>>> provide more textual explanation of the algorithms instead of just = describing >>>> the steps of the algorithms? Also I was wondering how much much = these >>>> algorithms are actually =E2=80=9Epart=E2=80=9C of the protocol = spec=E2=80=A6? Are could these be >>>> rather seen as example algorithms? Maybe that could be further = clarified >>>=20 >>> We'll consider these comments on section 2 at a later date, along = with >>> Benjamin Kaduk's comments on section 2. >>>=20 >>>> 2) Please expand STH on first occurrence (in sec 4.1) >>>=20 >>> Addressed by >>> = https://github.com/robstradling/certificate-transparency-rfcs/commit/d2d6b= 0ac303af2659e5df538391002f1bf454edb >>>=20 >>>> 3) Sec 4.4: =E2=80=9EA log's operator MUST either allocate the OID >>>> themselves or request an OID from the Log ID Registry (see >>>> Section 10.6.1).=E2=80=9C >>>> Isn't there an obligation to register? >>>=20 >>> The Log ID Registry is merely a source of OIDs that have short DER >>> encodings. A log operator may either (1) request an OID from the = Log ID >>> Registry, or (2) allocate an OID themselves (from an OID arc that = they >>> control, naturally). >>>=20 >>> The Registry is not intended to be a global directory of all logs. >>=20 >> Could be good to clarify in the text. >=20 > Addressed by=20 > = https://github.com/robstradling/certificate-transparency-rfcs/commit/18be3= bdc0eb3a8f5b95040081ccfaddcd2924fcb >=20 >>>> 4) sec 4.8: =E2=80=9EIf an >>>> implementation sees an extension that it does not understand, it >>>> SHOULD ignore that extension.=E2=80=9C >>>> Maybe it=E2=80=99s just me because I may have missed some context = but does =E2=80=9Eignore=E2=80=9C >>>> mean here that it should log it or not? >>>=20 >>> "It" (the precertificate or certificate) must have already been = logged, >>> because the corresponding SCT (that contains a potentially = unrecognized >>> extension) couldn't otherwise exist. >>=20 >> Could be good to clarify in the text. >=20 > I think other sections of the document already make it clear that a=20 > certificate or precertificate must be submitted to (and accepted by) a=20= > log before an SCT will be produced. >=20 > Section 3 says: > "If a log accepts a submission, it will return a Signed Certificate > Timestamp (SCT)" >=20 > Section 4 says: > "When it receives and accepts a valid submission, the log MUST = return > an SCT that corresponds to the submitted certificate or > precertificate." >=20 > I think reiterating this point again would be both unnecessary and out=20= > of scope for section 4.8, the purpose of which is to define the=20 > structure of an SCT. >=20 >>>> 5) sec 5: =E2=80=9EMAY retry the same >>>> request without modification at a later date.=E2=80=9C >>>> Would it be possible to provide a recommendation how long the = client should >>>> wait? >>>=20 >>> The very next sentence in section 5 already specifies a mechanism = for >>> doing just that: >>> 'Note that as per >>> [RFC7231], in the case of a 503 response the log MAY include a >>> "Retry-After:" header in order to request a minimum time for the >>> client to wait before retrying the request.=E2=80=99 >>=20 >> I meant, would it make sense to actually provide a default value or = something for this waiting time? >=20 > We could, but it would be fairly arbitrary. So why bother? >=20 > Some transient failures may be very short-lived, but others may last = for=20 > hours. Only the log operator can possibly know how long a client = should=20 > wait before retrying a request would be expected to succeed. >=20 >>>> 6) sec 5.6: =E2=80=9ELogs MAY restrict the number of entries that = can be retrieved per >>>> "get-entries" request.=E2=80=9C >>>> Should this be added to sec 4.1? >>>=20 >>> I don't think that's a good idea. I can imagine that operational = issues >>> might cause a log operator to want to vary this restriction at any = time. >>>=20 >>> Clients should always be prepared to receive get-entries responses = that >>> contain fewer entries than they requested. >>>=20 >>> See also https://trac.ietf.org/trac/trans/ticket/95 >>>=20 >>>> 7) sec 10.3: Couldn=E2=80=99t you use the TLS SignatureScheme = Registry directly >>>> (instead of forming an own registry)? >>>=20 >>> It makes sense to synchronize the signature algorithm values we use = with >>> the TLS SignatureAlgorithm registry, because our data structures are >>> defined according to the conventions laid out in the TLS RFC. >>>=20 >>> However, I don't think it's a good idea to use the TLS >>> SignatureAlgorithm registry directly. In 6962-bis, we've taken = steps to >>> make log artifacts smaller (compared to RFC6962); related to that, = we've >>> removed the option of logs being permitted to use RSA = keys/signatures. >>> = https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-p= arameters-16 >>> permits RSA, and several other signature algorithms that we don't = wish >>> to permit or recommend (i.e. "anonymous", DSA, GOST, and "Reserved = for >>> Private Use"). >>>=20 >>>> 8) sec 10.4: i Wonder if an RFC-required policy wouldn=E2=80=99t = be more appropriate >>>> for the VersionedTransTypes registry? >>>=20 >>> In 6962-bis section 10.4.1, we ask the appointed Expert to "review = the >>> public specification to ensure that it is detailed enough to ensure >>> implementation interoperability". >>>=20 >>> AFAICT from RFC8126, "RFC Required" doesn't imply Expert Review, = whereas >>> "Specification Required" does. So I think we should leave it as >>> "Specification Required=E2=80=9D. >>=20 >> RFC Required implies that the document got some reviews based on the = respective process. >>=20 >> However, I guess I actually wanted to propose IETF Review (and used = the wrong term). That would imply that it had to go through the IETF = process with respective review (and therefore usually it is expected = that no expert review is needed in addition). Anyway this was mainly a = comment to double-check this decision. >=20 > I personally don't have a preference, but I'll start another list = thread=20 > to discuss this proposal. >=20 >>>> 9) sec 10.6.1:I guess the registration policy is FCFS? RFC 8126 = recommend to >>>> always (clearly) name the registry. >>>=20 >>> Thanks. In our response to Alissa Cooper's DISCUSS/COMMENTs (see >>> https://github.com/google/certificate-transparency-rfcs/pull/309), = we've >>> already clarified that the Log ID Registry is indeed First Come = First >>> Served. >>>=20 >>>> And finally one higher level question mainly out of curiosity: was = it >>>> considered to e.g. use json for all data structures? Is there a = performance >>>> reason to not do that or wasn=E2=80=99t that even discussed? >>>=20 >>> Please don't restart the format wars. ;-) >>=20 >> Didn=E2=80=99t know that=E2=80=A6 >>=20 >>>=20 >>> We must use ASN.1 for all data structures, because X.509 = certificates >>> are involved. But we must use "TLS encoding" for all data = structures, >>> because TLS is involved. But we must use JSON for all data = structures, >>> because JSON is more API-friendly. >>>=20 >>> It was impossible to please everyone. We had to choose something, = so we >>> chose TLS encoding for the data structures, and JSON for the APIs. >>>=20 >>> As I mentioned earlier, one goal of 6962-bis is to make log = artifacts >>> smaller. TLS encoding is more suited to this than JSON. >>=20 >> Okay thanks for the background info. As long as this was discussed = that's fine! >=20 > --=20 > Rob Stradling > Senior Research & Development Scientist > Sectigo Limited >=20 From nobody Wed Oct 23 03:15:41 2019 Return-Path: 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 E42E51200DE; Wed, 23 Oct 2019 03:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 Fpm0YNIoGY8F; Wed, 23 Oct 2019 03:15:31 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720046.outbound.protection.outlook.com [40.107.72.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81D3312004E; Wed, 23 Oct 2019 03:15:31 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CYe/f39a1KtM/J7x9vzda9ElzuqgGY6vdOLJMIj2ngHpD6vzXG0NcHhhdxIfGgyl5TUpx14LOCWe2rXIS6YH5Tryo7ExQWyZlYhPewsaduticZLj7kLjAr5HsPAl8dXzs6+uji9EugPbrm/SFOUmayTZjoPb0qtQgUfZ0v7i/BoqnXDyePAOTQZ3KsLe7LrG5ibrDVOPT8HaHfZl77SHaBVqQd972WxAH2k1+n9oVgmcrysdSCXW52wsBxyNl1Ob2ILjTq+7sPSw1vTc30PK6XJlevH19aorSdjskS9uL/aFhk4vTYzRfjBgFq3ey3ZMI0eA+a6WK1JN7NnY6h/9Jg== 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=F7QT7Uc7Vvzq/SYSZzc+I2+9E3ZcA3tGapBdTLjj5rQ=; b=S/zXujbgTCbYlLtif7vtUxXNkjoNBohgCjHdL360Z79jS2J2nxLHfzMI8dfuh9c43rgGyxjNYcHN4gXbcVKi04AbJ1PG1wfWWX+5m5JbsB+rgh7q3s4roKbdxg+wLX4ruXp2WmApqwR1UFol3hT6py6F02Z10Z7IygewVVEwx8JLmh1axq9FXpJKHHrNX8VHqZ6ut6EC6NsUJmWs3dNpPnpkDHSzvW0YsUA2E4KvPpjDZRShS+eZCRd8sUv7IJyVFRDEtMrcHfq5zmjYJf0p/MriXTUZHPkqIH4p1rVWpU2wdDgMDWJyNucOGw+q7jpPbFaJpApwnmEKSODufBFrng== 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=F7QT7Uc7Vvzq/SYSZzc+I2+9E3ZcA3tGapBdTLjj5rQ=; b=bqnLXooEQ9dq2J9Ayvy3oNUlE/SpZuivZB5+c54msR9N0rIXU5KTqzf7n9Rs6hkVoxtXsXnRLxhEhAta6xnvLwhg6bY6KcMtrMPrOmK2UNwS7xlOI1X9qzWQLFnk923NMpDyGTr9Dt3X16+gQXSbqgVeapTrimGd03xi9NxVdkg= Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB2923.namprd17.prod.outlook.com (20.178.228.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2367.24; Wed, 23 Oct 2019 10:15:29 +0000 Received: from DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695]) by DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695%3]) with mapi id 15.20.2367.022; Wed, 23 Oct 2019 10:15:29 +0000 From: Rob Stradling To: "trans@ietf.org" CC: Mirja Kuehlewind , The IESG , "draft-ietf-trans-rfc6962-bis@ietf.org" , Paul Wouters , "trans-chairs@ietf.org" Thread-Topic: =?utf-8?B?TWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQtaWV0Zi10cmFu?= =?utf-8?Q?s-rfc6962-bis-31:_(with_DISCUSS_and_COMMENT)?= Thread-Index: AQHU2mzZvrQWumqliU+mEnmmbgWJ/adbfJiAgAAXqICAAwRxAIAKwZWAgAAGLAA= Date: Wed, 23 Oct 2019 10:15:29 +0000 Message-ID: References: <155257141035.2645.11460081509986673853.idtracker@ietfa.amsl.com> <1589f7c5-c4cb-4a87-d972-f7664b954d3f@sectigo.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0113.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:c::29) 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: 6cccb7c9-cef1-4b00-831a-08d757a1ee25 x-ms-traffictypediagnostic: DM6PR17MB2923: x-ms-exchange-purlcount: 9 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 019919A9E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(346002)(396003)(39860400002)(366004)(376002)(54094003)(51914003)(189003)(199004)(6916009)(66946007)(11346002)(446003)(561944003)(66556008)(64756008)(66476007)(66446008)(224303003)(476003)(486006)(99286004)(186003)(31686004)(386003)(2616005)(6506007)(52116002)(53546011)(31696002)(76176011)(86362001)(316002)(54906003)(6436002)(6486002)(5660300002)(71200400001)(229853002)(5640700003)(71190400001)(6116002)(4326008)(66574012)(6246003)(6512007)(6306002)(2906002)(30864003)(36756003)(46003)(2351001)(305945005)(2501003)(7736002)(102836004)(14444005)(256004)(81166006)(8936002)(81156014)(25786009)(478600001)(966005)(14454004)(1730700003); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB2923; H:DM6PR17MB3162.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: 8QT/t5m+wl4Ky74Pz5gSk1X4m3pYkmX+5jaB43F1rWLJlfjUd234DqX3haS4U+5Z4/nUSt1w6zNu9HQbaZly6FV7Ry1+tTBRHo6g60G4RSKNKpL1hYtYnKuOrOx81b0xCet9nfnp2EWhPnNCyLaLMFmQYR9Gpma2jpTU4zyFpbVzZ22b7R67FViaIV133Bh/uyHZiYbCDFC9myiaCrCWcXVnIBg/4ohTGWaDLZnrKHanWNsP02SvNkrezUOMxW98KGj+xBAf9ZRFVIC/5xRvJnhBblKEyoyDvdq6SySk8hL8cP5DBXA7NVDeHOtjs9NosI1EhAI7BVXy5guqB3ZoIFb8StWkFqY1pRgkxpu8ijOGB0zXo+JlXJYq+2ChoHsXQKTPCd39QQ6qOKGOR/OCS97P45iVxVXPtCiTvJ1etiRpYKkV80V9uCzJEAFaWuF4Hc7P82BuzkbKY9o20hoIEbGKv3kiuVI7THbe7qcnMmc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <1FDE0A37937CF34A926C28055B19612F@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 6cccb7c9-cef1-4b00-831a-08d757a1ee25 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2019 10:15:29.5300 (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: G2Hgk5t26z2GMb2gugw9/sjdoaeMQD+/un3DCDDvDjchs445zr0e8akfq3BMvgE65g9oRxL+hjV7o0l6OU2TlQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB2923 Archived-At: Subject: Re: [Trans] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-trans-rfc6962-bis-31=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 10:15:35 -0000 T24gMjMvMTAvMjAxOSAxMDo1MiwgTWlyamEgS3VlaGxld2luZCB3cm90ZToNCj4gSGkgUm9iLA0K PiANCj4gSnVzdCBvbmUgbW9yZSBjb21tZW50IHJlZ2FyZGluZyB0aGUgZGVmYXVsdCBmb3IgdGhl IHdhaXRpbmcgdGltZTogSSB1bmRlcnN0YW5kIHRoYXQgaXQgaXMgYXJiaXRyYXJ5IGJ1dCBJIGd1 ZXNzIHNvbWVvbmUgaW1wbGVtZW50aW5nIENUIGluIHRoZSBmaXJzdCBwbGFjZSBoYXMgdG8gbWFr ZSB0aGUgc2FtZSBhcmJpdHJhcnkgY2hvaWNlIGFuZCBqdXN0IHNlbGVjdCBzb21lIHZhbHVlLiBP ZiBjb3Vyc2UgdGhpcyB2YWx1ZSBzaG91bGQgYmUgY29uZmlndXJhYmxlIGJ1dCByZWNvbW1lbmRp bmcgc29tZSBkZWZhdWx0IG9yIGF0IGxlYXN0IGEgcmFuZ2Ugb3Igb3JkZXIgb2YgdmFsdWUgY291 bGQgcmVkdWNlIHN1cnByaXNlcy4gSG93ZXZlciwgdGhpcyBpcyBhIGp1c3QgYSByZWNvbW1lbmRh dGlvbiBmcm9tIG1lIGFuZCBpdOKAmXMgeW91ciBjYWxsIQ0KDQpXb3VsZCBhbnlvbmUgZWxzZSBs aWtlIHRvIGNvbW1lbnQgb24gd2hldGhlciB0aGV5IGFncmVlIG9yIGRpc2FncmVlIHdpdGggDQp0 aGlzIHJlY29tbWVuZGF0aW9uPw0KDQpJZiB5b3UgYWdyZWUsIHRoZW4gcGxlYXNlIHByb3Bvc2Ug YSBkZWZhdWx0IHdhaXRpbmcgdGltZSAoZm9yIHNpdHVhdGlvbnMgDQp3aGVyZSB0aGUgbG9nIHNl cnZlciBkb2VzIG5vdCBzZW5kIGFuIGV4cGxpY2l0ICJSZXRyeS1BZnRlciIgaGVhZGVyKS4NCg0K VGhhbmtzLg0KDQo+IE1pcmphDQo+IA0KPiANCj4+IE9uIDE2LiBPY3QgMjAxOSwgYXQgMTU6MzYs IFJvYiBTdHJhZGxpbmcgPHJvYkBzZWN0aWdvLmNvbT4gd3JvdGU6DQo+Pg0KPj4gT24gMTQvMTAv MjAxOSAxNjozMiwgTWlyamEgS3VlaGxld2luZCB3cm90ZToNCj4+PiBIaSBSb2IsDQo+Pj4NCj4+ PiBUaGFua3MgZm9yIHlvdXIgcmVwbGllcyBhbmQgZWRpdHMuIEkgd2lsbCBjbGVhciBteSBkaXNj dXNzIGFzIHNvb24gYXMgdGhlIG5ldyB2ZXJzaW9uIGlzIHN1Ym1pdHRlZC4NCj4+DQo+PiBUaGFu a3MgTWlyamEuDQo+Pg0KPj4+IFBsZWFzZSBzZWUgc29tZSBtaW5vciBjb21tZW50cyBiZWxvdyEN Cj4+DQo+PiBSZXBsaWVzIGlubGluZS4NCj4+DQo+Pj4gVGhhbmtzIQ0KPj4+IE1pcmphDQo+Pj4N Cj4+Pg0KPj4+PiBPbiAxNC4gT2N0IDIwMTksIGF0IDE2OjA3LCBSb2IgU3RyYWRsaW5nIDxyb2JA c2VjdGlnby5jb20+IHdyb3RlOg0KPj4+Pg0KPj4+PiBIaSBNaXJqYS4gIFNvcnJ5IGZvciB0aGUg bG9vb25nIGRlbGF5Lg0KPj4+Pg0KPj4+PiBDb21tZW50cyBpbmxpbmUsIGFuZCBJJ3ZlIGp1c3Qg cG9zdGVkIHRoaXMgUFI6DQo+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9nb29nbGUvY2VydGlmaWNh dGUtdHJhbnNwYXJlbmN5LXJmY3MvcHVsbC8zMTYNCj4+Pj4NCj4+Pj4gT24gMTQvMDMvMjAxOSAx Mzo1MCwgTWlyamEgS8O8aGxld2luZCB2aWEgRGF0YXRyYWNrZXIgd3JvdGU6DQo+Pj4+PiBNaXJq YSBLw7xobGV3aW5kIGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZv cg0KPj4+Pj4gZHJhZnQtaWV0Zi10cmFucy1yZmM2OTYyLWJpcy0zMTogRGlzY3Vzcw0KPj4+Pj4N Cj4+Pj4+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNnL3N0YXRlbWVu dC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4+Pj4+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0 IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVOVCBwb3NpdGlvbnMuDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+ IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUg Zm91bmQgaGVyZToNCj4+Pj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0 LWlldGYtdHJhbnMtcmZjNjk2Mi1iaXMvDQo+Pj4+Pg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+PiAtLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+Pj4+PiBESVNDVVNTOg0KPj4+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+Pj4NCj4+ Pj4+IFRoZXJlIHdhcyBhIHByZXNlbnRhdGlvbiBhdCBtYXByZyBJRVRGIDEwMyBhYm91dCB0aGUg cXVlc3Rpb24gaWYgQ1QgaGVscHMNCj4+Pj4+IGF0dGFja2VycyB0byBmaW5kIG5ldyBkb21haW5z LiBJIHRoaW5rIHRoaXMgcmlzayBzaG91bGQgYXQgbGVhc3QgYmUgbWVudGlvbmVkDQo+Pj4+PiBp biB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCj4+Pj4NCj4+Pj4gQWRkcmVz c2VkIGJ5DQo+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9yb2JzdHJhZGxpbmcvY2VydGlmaWNhdGUt dHJhbnNwYXJlbmN5LXJmY3MvY29tbWl0LzNiMmVjMGE1MWY4YWJiNGM4YzBiOTg1NjE0ZmVmYTQy OTE0MzJkZDkNCj4+Pj4NCj4+Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+Pj4+IENPTU1FTlQ6DQo+Pj4+ PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+Pj4+Pg0KPj4+Pj4gICAxKSBJIGZvdW5kIHNlY3Rpb24gMiBhIGJp dCBoYXJkIHRvIGZvbGxvdy4gV291bGQgaXQgbWF5YmUgYmUgcG9zc2libGUgdG8NCj4+Pj4+ICAg cHJvdmlkZSBtb3JlIHRleHR1YWwgZXhwbGFuYXRpb24gb2YgdGhlIGFsZ29yaXRobXMgaW5zdGVh ZCBvZiBqdXN0IGRlc2NyaWJpbmcNCj4+Pj4+ICAgdGhlIHN0ZXBzIG9mIHRoZSBhbGdvcml0aG1z PyBBbHNvIEkgd2FzIHdvbmRlcmluZyBob3cgbXVjaCBtdWNoIHRoZXNlDQo+Pj4+PiAgIGFsZ29y aXRobXMgYXJlIGFjdHVhbGx5IOKAnnBhcnTigJwgb2YgdGhlIHByb3RvY29sIHNwZWPigKY/IEFy ZSBjb3VsZCB0aGVzZSBiZQ0KPj4+Pj4gICByYXRoZXIgc2VlbiBhcyBleGFtcGxlIGFsZ29yaXRo bXM/IE1heWJlIHRoYXQgY291bGQgYmUgZnVydGhlciBjbGFyaWZpZWQNCj4+Pj4NCj4+Pj4gV2Un bGwgY29uc2lkZXIgdGhlc2UgY29tbWVudHMgb24gc2VjdGlvbiAyIGF0IGEgbGF0ZXIgZGF0ZSwg YWxvbmcgd2l0aA0KPj4+PiBCZW5qYW1pbiBLYWR1aydzIGNvbW1lbnRzIG9uIHNlY3Rpb24gMi4N Cj4+Pj4NCj4+Pj4+ICAgMikgUGxlYXNlIGV4cGFuZCBTVEggb24gZmlyc3Qgb2NjdXJyZW5jZSAo aW4gc2VjIDQuMSkNCj4+Pj4NCj4+Pj4gQWRkcmVzc2VkIGJ5DQo+Pj4+IGh0dHBzOi8vZ2l0aHVi LmNvbS9yb2JzdHJhZGxpbmcvY2VydGlmaWNhdGUtdHJhbnNwYXJlbmN5LXJmY3MvY29tbWl0L2Qy ZDZiMGFjMzAzYWYyNjU5ZTVkZjUzODM5MTAwMmYxYmY0NTRlZGINCj4+Pj4NCj4+Pj4+ICAgMykg U2VjIDQuNDog4oCeQSBsb2cncyBvcGVyYXRvciBNVVNUIGVpdGhlciBhbGxvY2F0ZSB0aGUgT0lE DQo+Pj4+PiAgICAgIHRoZW1zZWx2ZXMgb3IgcmVxdWVzdCBhbiBPSUQgZnJvbSB0aGUgTG9nIElE IFJlZ2lzdHJ5IChzZWUNCj4+Pj4+ICAgICAgU2VjdGlvbiAxMC42LjEpLuKAnA0KPj4+Pj4gSXNu J3QgdGhlcmUgYW4gb2JsaWdhdGlvbiB0byByZWdpc3Rlcj8NCj4+Pj4NCj4+Pj4gVGhlIExvZyBJ RCBSZWdpc3RyeSBpcyBtZXJlbHkgYSBzb3VyY2Ugb2YgT0lEcyB0aGF0IGhhdmUgc2hvcnQgREVS DQo+Pj4+IGVuY29kaW5ncy4gIEEgbG9nIG9wZXJhdG9yIG1heSBlaXRoZXIgKDEpIHJlcXVlc3Qg YW4gT0lEIGZyb20gdGhlIExvZyBJRA0KPj4+PiBSZWdpc3RyeSwgb3IgKDIpIGFsbG9jYXRlIGFu IE9JRCB0aGVtc2VsdmVzIChmcm9tIGFuIE9JRCBhcmMgdGhhdCB0aGV5DQo+Pj4+IGNvbnRyb2ws IG5hdHVyYWxseSkuDQo+Pj4+DQo+Pj4+IFRoZSBSZWdpc3RyeSBpcyBub3QgaW50ZW5kZWQgdG8g YmUgYSBnbG9iYWwgZGlyZWN0b3J5IG9mIGFsbCBsb2dzLg0KPj4+DQo+Pj4gQ291bGQgYmUgZ29v ZCB0byBjbGFyaWZ5IGluIHRoZSB0ZXh0Lg0KPj4NCj4+IEFkZHJlc3NlZCBieQ0KPj4gaHR0cHM6 Ly9naXRodWIuY29tL3JvYnN0cmFkbGluZy9jZXJ0aWZpY2F0ZS10cmFuc3BhcmVuY3ktcmZjcy9j b21taXQvMThiZTNiZGMwZWIzYThmNWI5NTA0MDA4MWNjZmFkZGNkMjkyNGZjYg0KPj4NCj4+Pj4+ ICAgNCkgc2VjIDQuODog4oCeSWYgYW4NCj4+Pj4+ICAgICBpbXBsZW1lbnRhdGlvbiBzZWVzIGFu IGV4dGVuc2lvbiB0aGF0IGl0IGRvZXMgbm90IHVuZGVyc3RhbmQsIGl0DQo+Pj4+PiAgICAgU0hP VUxEIGlnbm9yZSB0aGF0IGV4dGVuc2lvbi7igJwNCj4+Pj4+IE1heWJlIGl04oCZcyBqdXN0IG1l IGJlY2F1c2UgSSBtYXkgaGF2ZSBtaXNzZWQgc29tZSBjb250ZXh0IGJ1dCBkb2VzIOKAnmlnbm9y ZeKAnA0KPj4+Pj4gbWVhbiBoZXJlIHRoYXQgaXQgc2hvdWxkIGxvZyBpdCBvciBub3Q/DQo+Pj4+ DQo+Pj4+ICJJdCIgKHRoZSBwcmVjZXJ0aWZpY2F0ZSBvciBjZXJ0aWZpY2F0ZSkgbXVzdCBoYXZl IGFscmVhZHkgYmVlbiBsb2dnZWQsDQo+Pj4+IGJlY2F1c2UgdGhlIGNvcnJlc3BvbmRpbmcgU0NU ICh0aGF0IGNvbnRhaW5zIGEgcG90ZW50aWFsbHkgdW5yZWNvZ25pemVkDQo+Pj4+IGV4dGVuc2lv bikgY291bGRuJ3Qgb3RoZXJ3aXNlIGV4aXN0Lg0KPj4+DQo+Pj4gQ291bGQgYmUgZ29vZCB0byBj bGFyaWZ5IGluIHRoZSB0ZXh0Lg0KPj4NCj4+IEkgdGhpbmsgb3RoZXIgc2VjdGlvbnMgb2YgdGhl IGRvY3VtZW50IGFscmVhZHkgbWFrZSBpdCBjbGVhciB0aGF0IGENCj4+IGNlcnRpZmljYXRlIG9y IHByZWNlcnRpZmljYXRlIG11c3QgYmUgc3VibWl0dGVkIHRvIChhbmQgYWNjZXB0ZWQgYnkpIGEN Cj4+IGxvZyBiZWZvcmUgYW4gU0NUIHdpbGwgYmUgcHJvZHVjZWQuDQo+Pg0KPj4gU2VjdGlvbiAz IHNheXM6DQo+PiAgICAiSWYgYSBsb2cgYWNjZXB0cyBhIHN1Ym1pc3Npb24sIGl0IHdpbGwgcmV0 dXJuIGEgU2lnbmVkIENlcnRpZmljYXRlDQo+PiAgICAgVGltZXN0YW1wIChTQ1QpIg0KPj4NCj4+ IFNlY3Rpb24gNCBzYXlzOg0KPj4gICAgIldoZW4gaXQgcmVjZWl2ZXMgYW5kIGFjY2VwdHMgYSB2 YWxpZCBzdWJtaXNzaW9uLCB0aGUgbG9nIE1VU1QgcmV0dXJuDQo+PiAgICAgYW4gU0NUIHRoYXQg Y29ycmVzcG9uZHMgdG8gdGhlIHN1Ym1pdHRlZCBjZXJ0aWZpY2F0ZSBvcg0KPj4gICAgIHByZWNl cnRpZmljYXRlLiINCj4+DQo+PiBJIHRoaW5rIHJlaXRlcmF0aW5nIHRoaXMgcG9pbnQgYWdhaW4g d291bGQgYmUgYm90aCB1bm5lY2Vzc2FyeSBhbmQgb3V0DQo+PiBvZiBzY29wZSBmb3Igc2VjdGlv biA0LjgsIHRoZSBwdXJwb3NlIG9mIHdoaWNoIGlzIHRvIGRlZmluZSB0aGUNCj4+IHN0cnVjdHVy ZSBvZiBhbiBTQ1QuDQo+Pg0KPj4+Pj4gICA1KSBzZWMgNTog4oCeTUFZIHJldHJ5IHRoZSBzYW1l DQo+Pj4+PiAgICAgcmVxdWVzdCB3aXRob3V0IG1vZGlmaWNhdGlvbiBhdCBhIGxhdGVyIGRhdGUu 4oCcDQo+Pj4+PiBXb3VsZCBpdCBiZSBwb3NzaWJsZSB0byBwcm92aWRlIGEgcmVjb21tZW5kYXRp b24gaG93IGxvbmcgdGhlIGNsaWVudCBzaG91bGQNCj4+Pj4+IHdhaXQ/DQo+Pj4+DQo+Pj4+IFRo ZSB2ZXJ5IG5leHQgc2VudGVuY2UgaW4gc2VjdGlvbiA1IGFscmVhZHkgc3BlY2lmaWVzIGEgbWVj aGFuaXNtIGZvcg0KPj4+PiBkb2luZyBqdXN0IHRoYXQ6DQo+Pj4+ICAgICdOb3RlIHRoYXQgYXMg cGVyDQo+Pj4+ICAgICBbUkZDNzIzMV0sIGluIHRoZSBjYXNlIG9mIGEgNTAzIHJlc3BvbnNlIHRo ZSBsb2cgTUFZIGluY2x1ZGUgYQ0KPj4+PiAgICAgIlJldHJ5LUFmdGVyOiIgaGVhZGVyIGluIG9y ZGVyIHRvIHJlcXVlc3QgYSBtaW5pbXVtIHRpbWUgZm9yIHRoZQ0KPj4+PiAgICAgY2xpZW50IHRv IHdhaXQgYmVmb3JlIHJldHJ5aW5nIHRoZSByZXF1ZXN0LuKAmQ0KPj4+DQo+Pj4gSSBtZWFudCwg d291bGQgaXQgbWFrZSBzZW5zZSB0byBhY3R1YWxseSBwcm92aWRlIGEgZGVmYXVsdCB2YWx1ZSBv ciBzb21ldGhpbmcgZm9yIHRoaXMgd2FpdGluZyB0aW1lPw0KPj4NCj4+IFdlIGNvdWxkLCBidXQg aXQgd291bGQgYmUgZmFpcmx5IGFyYml0cmFyeS4gIFNvIHdoeSBib3RoZXI/DQo+Pg0KPj4gU29t ZSB0cmFuc2llbnQgZmFpbHVyZXMgbWF5IGJlIHZlcnkgc2hvcnQtbGl2ZWQsIGJ1dCBvdGhlcnMg bWF5IGxhc3QgZm9yDQo+PiBob3Vycy4gIE9ubHkgdGhlIGxvZyBvcGVyYXRvciBjYW4gcG9zc2li bHkga25vdyBob3cgbG9uZyBhIGNsaWVudCBzaG91bGQNCj4+IHdhaXQgYmVmb3JlIHJldHJ5aW5n IGEgcmVxdWVzdCB3b3VsZCBiZSBleHBlY3RlZCB0byBzdWNjZWVkLg0KPj4NCj4+Pj4+ICAgNikg c2VjIDUuNjog4oCeTG9ncyBNQVkgcmVzdHJpY3QgdGhlIG51bWJlciBvZiBlbnRyaWVzIHRoYXQg Y2FuIGJlIHJldHJpZXZlZCBwZXINCj4+Pj4+ICAgICAiZ2V0LWVudHJpZXMiIHJlcXVlc3Qu4oCc DQo+Pj4+PiBTaG91bGQgdGhpcyBiZSBhZGRlZCB0byBzZWMgNC4xPw0KPj4+Pg0KPj4+PiBJIGRv bid0IHRoaW5rIHRoYXQncyBhIGdvb2QgaWRlYS4gIEkgY2FuIGltYWdpbmUgdGhhdCBvcGVyYXRp b25hbCBpc3N1ZXMNCj4+Pj4gbWlnaHQgY2F1c2UgYSBsb2cgb3BlcmF0b3IgdG8gd2FudCB0byB2 YXJ5IHRoaXMgcmVzdHJpY3Rpb24gYXQgYW55IHRpbWUuDQo+Pj4+DQo+Pj4+IENsaWVudHMgc2hv dWxkIGFsd2F5cyBiZSBwcmVwYXJlZCB0byByZWNlaXZlIGdldC1lbnRyaWVzIHJlc3BvbnNlcyB0 aGF0DQo+Pj4+IGNvbnRhaW4gZmV3ZXIgZW50cmllcyB0aGFuIHRoZXkgcmVxdWVzdGVkLg0KPj4+ Pg0KPj4+PiBTZWUgYWxzbyBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy90cmFucy90aWNrZXQv OTUNCj4+Pj4NCj4+Pj4+ICAgNykgc2VjIDEwLjM6IENvdWxkbuKAmXQgeW91IHVzZSB0aGUgVExT ICBTaWduYXR1cmVTY2hlbWUgUmVnaXN0cnkgZGlyZWN0bHkNCj4+Pj4+ICAgKGluc3RlYWQgb2Yg Zm9ybWluZyBhbiBvd24gcmVnaXN0cnkpPw0KPj4+Pg0KPj4+PiBJdCBtYWtlcyBzZW5zZSB0byBz eW5jaHJvbml6ZSB0aGUgc2lnbmF0dXJlIGFsZ29yaXRobSB2YWx1ZXMgd2UgdXNlIHdpdGgNCj4+ Pj4gdGhlIFRMUyBTaWduYXR1cmVBbGdvcml0aG0gcmVnaXN0cnksIGJlY2F1c2Ugb3VyIGRhdGEg c3RydWN0dXJlcyBhcmUNCj4+Pj4gZGVmaW5lZCBhY2NvcmRpbmcgdG8gdGhlIGNvbnZlbnRpb25z IGxhaWQgb3V0IGluIHRoZSBUTFMgUkZDLg0KPj4+Pg0KPj4+PiBIb3dldmVyLCBJIGRvbid0IHRo aW5rIGl0J3MgYSBnb29kIGlkZWEgdG8gdXNlIHRoZSBUTFMNCj4+Pj4gU2lnbmF0dXJlQWxnb3Jp dGhtIHJlZ2lzdHJ5IGRpcmVjdGx5LiAgSW4gNjk2Mi1iaXMsIHdlJ3ZlIHRha2VuIHN0ZXBzIHRv DQo+Pj4+IG1ha2UgbG9nIGFydGlmYWN0cyBzbWFsbGVyIChjb21wYXJlZCB0byBSRkM2OTYyKTsg cmVsYXRlZCB0byB0aGF0LCB3ZSd2ZQ0KPj4+PiByZW1vdmVkIHRoZSBvcHRpb24gb2YgbG9ncyBi ZWluZyBwZXJtaXR0ZWQgdG8gdXNlIFJTQSBrZXlzL3NpZ25hdHVyZXMuDQo+Pj4+IGh0dHBzOi8v d3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Rscy1wYXJhbWV0ZXJzL3Rscy1wYXJhbWV0ZXJzLnho dG1sI3Rscy1wYXJhbWV0ZXJzLTE2DQo+Pj4+IHBlcm1pdHMgUlNBLCBhbmQgc2V2ZXJhbCBvdGhl ciBzaWduYXR1cmUgYWxnb3JpdGhtcyB0aGF0IHdlIGRvbid0IHdpc2gNCj4+Pj4gdG8gcGVybWl0 IG9yIHJlY29tbWVuZCAoaS5lLiAiYW5vbnltb3VzIiwgRFNBLCBHT1NULCBhbmQgIlJlc2VydmVk IGZvcg0KPj4+PiBQcml2YXRlIFVzZSIpLg0KPj4+Pg0KPj4+Pj4gICA4KSBzZWMgMTAuNDogaSBX b25kZXIgaWYgYW4gUkZDLXJlcXVpcmVkIHBvbGljeSB3b3VsZG7igJl0IGJlIG1vcmUgYXBwcm9w cmlhdGUNCj4+Pj4+ICAgZm9yIHRoZSBWZXJzaW9uZWRUcmFuc1R5cGVzIHJlZ2lzdHJ5Pw0KPj4+ Pg0KPj4+PiBJbiA2OTYyLWJpcyBzZWN0aW9uIDEwLjQuMSwgd2UgYXNrIHRoZSBhcHBvaW50ZWQg RXhwZXJ0IHRvICJyZXZpZXcgdGhlDQo+Pj4+IHB1YmxpYyBzcGVjaWZpY2F0aW9uIHRvIGVuc3Vy ZSB0aGF0IGl0IGlzIGRldGFpbGVkIGVub3VnaCB0byBlbnN1cmUNCj4+Pj4gaW1wbGVtZW50YXRp b24gaW50ZXJvcGVyYWJpbGl0eSIuDQo+Pj4+DQo+Pj4+IEFGQUlDVCBmcm9tIFJGQzgxMjYsICJS RkMgUmVxdWlyZWQiIGRvZXNuJ3QgaW1wbHkgRXhwZXJ0IFJldmlldywgd2hlcmVhcw0KPj4+PiAi U3BlY2lmaWNhdGlvbiBSZXF1aXJlZCIgZG9lcy4gIFNvIEkgdGhpbmsgd2Ugc2hvdWxkIGxlYXZl IGl0IGFzDQo+Pj4+ICJTcGVjaWZpY2F0aW9uIFJlcXVpcmVk4oCdLg0KPj4+DQo+Pj4gUkZDIFJl cXVpcmVkIGltcGxpZXMgdGhhdCB0aGUgZG9jdW1lbnQgZ290IHNvbWUgcmV2aWV3cyBiYXNlZCBv biB0aGUgcmVzcGVjdGl2ZSBwcm9jZXNzLg0KPj4+DQo+Pj4gSG93ZXZlciwgSSBndWVzcyBJIGFj dHVhbGx5IHdhbnRlZCB0byBwcm9wb3NlIElFVEYgUmV2aWV3IChhbmQgdXNlZCB0aGUgd3Jvbmcg dGVybSkuIFRoYXQgd291bGQgaW1wbHkgdGhhdCBpdCBoYWQgdG8gZ28gdGhyb3VnaCB0aGUgSUVU RiBwcm9jZXNzIHdpdGggcmVzcGVjdGl2ZSByZXZpZXcgKGFuZCB0aGVyZWZvcmUgdXN1YWxseSBp dCBpcyBleHBlY3RlZCB0aGF0IG5vIGV4cGVydCByZXZpZXcgaXMgbmVlZGVkIGluIGFkZGl0aW9u KS4gQW55d2F5IHRoaXMgd2FzIG1haW5seSBhIGNvbW1lbnQgdG8gZG91YmxlLWNoZWNrIHRoaXMg ZGVjaXNpb24uDQo+Pg0KPj4gSSBwZXJzb25hbGx5IGRvbid0IGhhdmUgYSBwcmVmZXJlbmNlLCBi dXQgSSdsbCBzdGFydCBhbm90aGVyIGxpc3QgdGhyZWFkDQo+PiB0byBkaXNjdXNzIHRoaXMgcHJv cG9zYWwuDQo+Pg0KPj4+Pj4gICA5KSBzZWMgMTAuNi4xOkkgZ3Vlc3MgIHRoZSByZWdpc3RyYXRp b24gcG9saWN5IGlzIEZDRlM/IFJGQyA4MTI2IHJlY29tbWVuZCB0bw0KPj4+Pj4gICBhbHdheXMg KGNsZWFybHkpIG5hbWUgdGhlIHJlZ2lzdHJ5Lg0KPj4+Pg0KPj4+PiBUaGFua3MuICBJbiBvdXIg cmVzcG9uc2UgdG8gQWxpc3NhIENvb3BlcidzIERJU0NVU1MvQ09NTUVOVHMgKHNlZQ0KPj4+PiBo dHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlL2NlcnRpZmljYXRlLXRyYW5zcGFyZW5jeS1yZmNzL3B1 bGwvMzA5KSwgd2UndmUNCj4+Pj4gYWxyZWFkeSBjbGFyaWZpZWQgdGhhdCB0aGUgTG9nIElEIFJl Z2lzdHJ5IGlzIGluZGVlZCBGaXJzdCBDb21lIEZpcnN0DQo+Pj4+IFNlcnZlZC4NCj4+Pj4NCj4+ Pj4+IEFuZCBmaW5hbGx5IG9uZSBoaWdoZXIgbGV2ZWwgcXVlc3Rpb24gbWFpbmx5IG91dCBvZiBj dXJpb3NpdHk6IHdhcyBpdA0KPj4+Pj4gY29uc2lkZXJlZCB0byBlLmcuIHVzZSBqc29uIGZvciBh bGwgZGF0YSBzdHJ1Y3R1cmVzPyBJcyB0aGVyZSBhIHBlcmZvcm1hbmNlDQo+Pj4+PiByZWFzb24g dG8gbm90IGRvIHRoYXQgb3Igd2FzbuKAmXQgdGhhdCBldmVuIGRpc2N1c3NlZD8NCj4+Pj4NCj4+ Pj4gUGxlYXNlIGRvbid0IHJlc3RhcnQgdGhlIGZvcm1hdCB3YXJzLiAgOy0pDQo+Pj4NCj4+PiBE aWRu4oCZdCBrbm93IHRoYXTigKYNCj4+Pg0KPj4+Pg0KPj4+PiBXZSBtdXN0IHVzZSBBU04uMSBm b3IgYWxsIGRhdGEgc3RydWN0dXJlcywgYmVjYXVzZSBYLjUwOSBjZXJ0aWZpY2F0ZXMNCj4+Pj4g YXJlIGludm9sdmVkLiAgQnV0IHdlIG11c3QgdXNlICJUTFMgZW5jb2RpbmciIGZvciBhbGwgZGF0 YSBzdHJ1Y3R1cmVzLA0KPj4+PiBiZWNhdXNlIFRMUyBpcyBpbnZvbHZlZC4gIEJ1dCB3ZSBtdXN0 IHVzZSBKU09OIGZvciBhbGwgZGF0YSBzdHJ1Y3R1cmVzLA0KPj4+PiBiZWNhdXNlIEpTT04gaXMg bW9yZSBBUEktZnJpZW5kbHkuDQo+Pj4+DQo+Pj4+IEl0IHdhcyBpbXBvc3NpYmxlIHRvIHBsZWFz ZSBldmVyeW9uZS4gIFdlIGhhZCB0byBjaG9vc2Ugc29tZXRoaW5nLCBzbyB3ZQ0KPj4+PiBjaG9z ZSBUTFMgZW5jb2RpbmcgZm9yIHRoZSBkYXRhIHN0cnVjdHVyZXMsIGFuZCBKU09OIGZvciB0aGUg QVBJcy4NCj4+Pj4NCj4+Pj4gQXMgSSBtZW50aW9uZWQgZWFybGllciwgb25lIGdvYWwgb2YgNjk2 Mi1iaXMgaXMgdG8gbWFrZSBsb2cgYXJ0aWZhY3RzDQo+Pj4+IHNtYWxsZXIuICBUTFMgZW5jb2Rp bmcgaXMgbW9yZSBzdWl0ZWQgdG8gdGhpcyB0aGFuIEpTT04uDQo+Pj4NCj4+PiBPa2F5IHRoYW5r cyBmb3IgdGhlIGJhY2tncm91bmQgaW5mby4gQXMgbG9uZyBhcyB0aGlzIHdhcyBkaXNjdXNzZWQg dGhhdCdzIGZpbmUhDQo+Pg0KPj4gLS0NCj4+IFJvYiBTdHJhZGxpbmcNCj4+IFNlbmlvciBSZXNl YXJjaCAmIERldmVsb3BtZW50IFNjaWVudGlzdA0KPj4gU2VjdGlnbyBMaW1pdGVkDQo+Pg0KPiAN Cg0KLS0gDQpSb2IgU3RyYWRsaW5nDQpTZW5pb3IgUmVzZWFyY2ggJiBEZXZlbG9wbWVudCBTY2ll bnRpc3QNCkVtYWlsOiByb2JAc2VjdGlnby5jb20NCkJyYWRmb3JkLCBVSw0KT2ZmaWNlOiArNDQx Mjc0MDI0NzA3DQpTZWN0aWdvIExpbWl0ZWQNCg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkgZmlsZXMg YXNzb2NpYXRlZCB3aXRoIGl0IG1heSBjb250YWluIGxlZ2FsbHkgDQpwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwsIG9yIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUg DQppbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90IHBlcm1pdHRlZCB0byB1c2UsIGNvcHks IG9yIGZvcndhcmQgaXQsIA0KaW4gd2hvbGUgb3IgaW4gcGFydCB3aXRob3V0IHRoZSBleHByZXNz IGNvbnNlbnQgb2YgdGhlIHNlbmRlci4gUGxlYXNlIA0Kbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVw bHkgZW1haWwsIGRpc3JlZ2FyZCB0aGUgZm9yZWdvaW5nIG1lc3NhZ2VzLCBhbmQgDQpkZWxldGUg aXQgaW1tZWRpYXRlbHkuDQo= From nobody Wed Oct 23 05:22:49 2019 Return-Path: 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 AE1D3120846; Wed, 23 Oct 2019 05:22:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 g4OYd_i4cwkm; Wed, 23 Oct 2019 05:22:33 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 91BB61200D8; Wed, 23 Oct 2019 05:22:33 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x9NCLOds030058; Wed, 23 Oct 2019 13:22:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=UF5XxuH0rZZT0OkvQzbViGEHC4CJ+tdXrHp0HJ7kggE=; b=EgxI3owlI9Rp7te+Fz3+pJ5+XC5TfN9GcJjGUOats0v01L3X2gHSrA81QwaiZYUNpER4 tErCd8lAALMoXqVX1+QKbcA8BfZ0RMIsOgKurPgnrrwNVYiCuWuXGd9LPqg8UtzSWSle WpJPXRmu33xFIxX3vgpiFj5FWxHhzJFyREfaql70yb1zFMdGZ2xmGIIbj/g7mpt337Sk c58updRsYJ+VoFMynfEtOZhh6pkLXNrY1qmegZEfKIQWMTxdwL0zZGrxu5ABn+lP8hQY bcEB/qz8INWIKGu7CWfwzXDv0/upWfWM93ExzqfairwLijFoIXI2uPvoVmo7OwKgPBef 6g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2vqsr9vdp3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Oct 2019 13:22:31 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9NCGm9C025953; Wed, 23 Oct 2019 08:22:30 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2vqwtwhap9-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 23 Oct 2019 08:22:30 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 23 Oct 2019 08:22:29 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 23 Oct 2019 08:22:29 -0400 From: "Salz, Rich" To: Rob Stradling , "trans@ietf.org" CC: "draft-ietf-trans-rfc6962-bis@ietf.org" , Paul Wouters , "Mirja Kuehlewind" , The IESG , "trans-chairs@ietf.org" Thread-Topic: =?utf-8?B?W1RyYW5zXSAgTWlyamEgS8O8aGxld2luZCdzIERpc2N1c3Mgb24gZHJhZnQt?= =?utf-8?B?aWV0Zi10cmFucy1yZmM2OTYyLWJpcy0zMTogKHdpdGggRElTQ1VTUyBhbmQg?= =?utf-8?Q?COMMENT)?= Thread-Index: AQHViZyJbSzCz55vp0esRfE6eHWGyQ== Date: Wed, 23 Oct 2019 12:22:28 +0000 Message-ID: <2B1C3261-7034-45D9-A70D-EA194C11C5E5@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.221] Content-Type: text/plain; charset="utf-8" Content-ID: <3F6C68F242BA9F4FAE0DF9CEBC84FA79@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-23_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910230126 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-23_03:2019-10-23,2019-10-23 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 impostorscore=0 adultscore=0 phishscore=0 mlxlogscore=999 spamscore=0 priorityscore=1501 malwarescore=0 suspectscore=0 lowpriorityscore=0 clxscore=1011 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910230127 Archived-At: Subject: Re: [Trans] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-trans-rfc6962-bis-31=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 12:22:36 -0000 SG93IGFib3V0ICJTZXJ2ZXJzIG1heSB3aXNoIHRvIHNlbmQgYSBSZXRyeS1BZnRlciBoZWFkZXIi ID8NCg0KDQrvu79PbiAxMC8yMy8xOSwgNjoxNSBBTSwgIlJvYiBTdHJhZGxpbmciIDxyb2JAc2Vj dGlnby5jb20+IHdyb3RlOg0KDQogICAgT24gMjMvMTAvMjAxOSAxMDo1MiwgTWlyamEgS3VlaGxl d2luZCB3cm90ZToNCiAgICA+IEhpIFJvYiwNCiAgICA+IA0KICAgID4gSnVzdCBvbmUgbW9yZSBj b21tZW50IHJlZ2FyZGluZyB0aGUgZGVmYXVsdCBmb3IgdGhlIHdhaXRpbmcgdGltZTogSSB1bmRl cnN0YW5kIHRoYXQgaXQgaXMgYXJiaXRyYXJ5IGJ1dCBJIGd1ZXNzIHNvbWVvbmUgaW1wbGVtZW50 aW5nIENUIGluIHRoZSBmaXJzdCBwbGFjZSBoYXMgdG8gbWFrZSB0aGUgc2FtZSBhcmJpdHJhcnkg Y2hvaWNlIGFuZCBqdXN0IHNlbGVjdCBzb21lIHZhbHVlLiBPZiBjb3Vyc2UgdGhpcyB2YWx1ZSBz aG91bGQgYmUgY29uZmlndXJhYmxlIGJ1dCByZWNvbW1lbmRpbmcgc29tZSBkZWZhdWx0IG9yIGF0 IGxlYXN0IGEgcmFuZ2Ugb3Igb3JkZXIgb2YgdmFsdWUgY291bGQgcmVkdWNlIHN1cnByaXNlcy4g SG93ZXZlciwgdGhpcyBpcyBhIGp1c3QgYSByZWNvbW1lbmRhdGlvbiBmcm9tIG1lIGFuZCBpdOKA mXMgeW91ciBjYWxsIQ0KICAgIA0KICAgIFdvdWxkIGFueW9uZSBlbHNlIGxpa2UgdG8gY29tbWVu dCBvbiB3aGV0aGVyIHRoZXkgYWdyZWUgb3IgZGlzYWdyZWUgd2l0aCANCiAgICB0aGlzIHJlY29t bWVuZGF0aW9uPw0KICAgIA0KICAgIElmIHlvdSBhZ3JlZSwgdGhlbiBwbGVhc2UgcHJvcG9zZSBh IGRlZmF1bHQgd2FpdGluZyB0aW1lIChmb3Igc2l0dWF0aW9ucyANCiAgICB3aGVyZSB0aGUgbG9n IHNlcnZlciBkb2VzIG5vdCBzZW5kIGFuIGV4cGxpY2l0ICJSZXRyeS1BZnRlciIgaGVhZGVyKS4N CiAgICANCiAgICBUaGFua3MuDQogICAgDQogICAgPiBNaXJqYQ0KICAgID4gDQogICAgPiANCiAg ICA+PiBPbiAxNi4gT2N0IDIwMTksIGF0IDE1OjM2LCBSb2IgU3RyYWRsaW5nIDxyb2JAc2VjdGln by5jb20+IHdyb3RlOg0KICAgID4+DQogICAgPj4gT24gMTQvMTAvMjAxOSAxNjozMiwgTWlyamEg S3VlaGxld2luZCB3cm90ZToNCiAgICA+Pj4gSGkgUm9iLA0KICAgID4+Pg0KICAgID4+PiBUaGFu a3MgZm9yIHlvdXIgcmVwbGllcyBhbmQgZWRpdHMuIEkgd2lsbCBjbGVhciBteSBkaXNjdXNzIGFz IHNvb24gYXMgdGhlIG5ldyB2ZXJzaW9uIGlzIHN1Ym1pdHRlZC4NCiAgICA+Pg0KICAgID4+IFRo YW5rcyBNaXJqYS4NCiAgICA+Pg0KICAgID4+PiBQbGVhc2Ugc2VlIHNvbWUgbWlub3IgY29tbWVu dHMgYmVsb3chDQogICAgPj4NCiAgICA+PiBSZXBsaWVzIGlubGluZS4NCiAgICA+Pg0KICAgID4+ PiBUaGFua3MhDQogICAgPj4+IE1pcmphDQogICAgPj4+DQogICAgPj4+DQogICAgPj4+PiBPbiAx NC4gT2N0IDIwMTksIGF0IDE2OjA3LCBSb2IgU3RyYWRsaW5nIDxyb2JAc2VjdGlnby5jb20+IHdy b3RlOg0KICAgID4+Pj4NCiAgICA+Pj4+IEhpIE1pcmphLiAgU29ycnkgZm9yIHRoZSBsb29vbmcg ZGVsYXkuDQogICAgPj4+Pg0KICAgID4+Pj4gQ29tbWVudHMgaW5saW5lLCBhbmQgSSd2ZSBqdXN0 IHBvc3RlZCB0aGlzIFBSOg0KICAgID4+Pj4gaHR0cHM6Ly9naXRodWIuY29tL2dvb2dsZS9jZXJ0 aWZpY2F0ZS10cmFuc3BhcmVuY3ktcmZjcy9wdWxsLzMxNg0KICAgID4+Pj4NCiAgICA+Pj4+IE9u IDE0LzAzLzIwMTkgMTM6NTAsIE1pcmphIEvDvGhsZXdpbmQgdmlhIERhdGF0cmFja2VyIHdyb3Rl Og0KICAgID4+Pj4+IE1pcmphIEvDvGhsZXdpbmQgaGFzIGVudGVyZWQgdGhlIGZvbGxvd2luZyBi YWxsb3QgcG9zaXRpb24gZm9yDQogICAgPj4+Pj4gZHJhZnQtaWV0Zi10cmFucy1yZmM2OTYyLWJp cy0zMTogRGlzY3Vzcw0KICAgID4+Pj4+DQogICAgPj4+Pj4gUGxlYXNlIHJlZmVyIHRvIGh0dHBz Oi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVyaWEuaHRtbA0KICAg ID4+Pj4+IGZvciBtb3JlIGluZm9ybWF0aW9uIGFib3V0IElFU0cgRElTQ1VTUyBhbmQgQ09NTUVO VCBwb3NpdGlvbnMuDQogICAgPj4+Pj4NCiAgICA+Pj4+Pg0KICAgID4+Pj4+IFRoZSBkb2N1bWVu dCwgYWxvbmcgd2l0aCBvdGhlciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToN CiAgICA+Pj4+PiBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXRy YW5zLXJmYzY5NjItYmlzLw0KICAgID4+Pj4+DQogICAgPj4+Pj4NCiAgICA+Pj4+Pg0KICAgID4+ Pj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCiAgICA+Pj4+PiBESVNDVVNTOg0KICAgID4+Pj4+IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NCiAgICA+Pj4+Pg0KICAgID4+Pj4+IFRoZXJlIHdhcyBhIHByZXNlbnRhdGlvbiBhdCBt YXByZyBJRVRGIDEwMyBhYm91dCB0aGUgcXVlc3Rpb24gaWYgQ1QgaGVscHMNCiAgICA+Pj4+PiBh dHRhY2tlcnMgdG8gZmluZCBuZXcgZG9tYWlucy4gSSB0aGluayB0aGlzIHJpc2sgc2hvdWxkIGF0 IGxlYXN0IGJlIG1lbnRpb25lZA0KICAgID4+Pj4+IGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0 aW9ucyBzZWN0aW9uLg0KICAgID4+Pj4NCiAgICA+Pj4+IEFkZHJlc3NlZCBieQ0KICAgID4+Pj4g aHR0cHM6Ly9naXRodWIuY29tL3JvYnN0cmFkbGluZy9jZXJ0aWZpY2F0ZS10cmFuc3BhcmVuY3kt cmZjcy9jb21taXQvM2IyZWMwYTUxZjhhYmI0YzhjMGI5ODU2MTRmZWZhNDI5MTQzMmRkOQ0KICAg ID4+Pj4NCiAgICA+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPj4+Pj4gQ09NTUVOVDoNCiAgICA+ Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQogICAgPj4+Pj4NCiAgICA+Pj4+PiAgIDEpIEkgZm91bmQgc2Vj dGlvbiAyIGEgYml0IGhhcmQgdG8gZm9sbG93LiBXb3VsZCBpdCBtYXliZSBiZSBwb3NzaWJsZSB0 bw0KICAgID4+Pj4+ICAgcHJvdmlkZSBtb3JlIHRleHR1YWwgZXhwbGFuYXRpb24gb2YgdGhlIGFs Z29yaXRobXMgaW5zdGVhZCBvZiBqdXN0IGRlc2NyaWJpbmcNCiAgICA+Pj4+PiAgIHRoZSBzdGVw cyBvZiB0aGUgYWxnb3JpdGhtcz8gQWxzbyBJIHdhcyB3b25kZXJpbmcgaG93IG11Y2ggbXVjaCB0 aGVzZQ0KICAgID4+Pj4+ICAgYWxnb3JpdGhtcyBhcmUgYWN0dWFsbHkg4oCecGFydOKAnCBvZiB0 aGUgcHJvdG9jb2wgc3BlY+KApj8gQXJlIGNvdWxkIHRoZXNlIGJlDQogICAgPj4+Pj4gICByYXRo ZXIgc2VlbiBhcyBleGFtcGxlIGFsZ29yaXRobXM/IE1heWJlIHRoYXQgY291bGQgYmUgZnVydGhl ciBjbGFyaWZpZWQNCiAgICA+Pj4+DQogICAgPj4+PiBXZSdsbCBjb25zaWRlciB0aGVzZSBjb21t ZW50cyBvbiBzZWN0aW9uIDIgYXQgYSBsYXRlciBkYXRlLCBhbG9uZyB3aXRoDQogICAgPj4+PiBC ZW5qYW1pbiBLYWR1aydzIGNvbW1lbnRzIG9uIHNlY3Rpb24gMi4NCiAgICA+Pj4+DQogICAgPj4+ Pj4gICAyKSBQbGVhc2UgZXhwYW5kIFNUSCBvbiBmaXJzdCBvY2N1cnJlbmNlIChpbiBzZWMgNC4x KQ0KICAgID4+Pj4NCiAgICA+Pj4+IEFkZHJlc3NlZCBieQ0KICAgID4+Pj4gaHR0cHM6Ly9naXRo dWIuY29tL3JvYnN0cmFkbGluZy9jZXJ0aWZpY2F0ZS10cmFuc3BhcmVuY3ktcmZjcy9jb21taXQv ZDJkNmIwYWMzMDNhZjI2NTllNWRmNTM4MzkxMDAyZjFiZjQ1NGVkYg0KICAgID4+Pj4NCiAgICA+ Pj4+PiAgIDMpIFNlYyA0LjQ6IOKAnkEgbG9nJ3Mgb3BlcmF0b3IgTVVTVCBlaXRoZXIgYWxsb2Nh dGUgdGhlIE9JRA0KICAgID4+Pj4+ICAgICAgdGhlbXNlbHZlcyBvciByZXF1ZXN0IGFuIE9JRCBm cm9tIHRoZSBMb2cgSUQgUmVnaXN0cnkgKHNlZQ0KICAgID4+Pj4+ICAgICAgU2VjdGlvbiAxMC42 LjEpLuKAnA0KICAgID4+Pj4+IElzbid0IHRoZXJlIGFuIG9ibGlnYXRpb24gdG8gcmVnaXN0ZXI/ DQogICAgPj4+Pg0KICAgID4+Pj4gVGhlIExvZyBJRCBSZWdpc3RyeSBpcyBtZXJlbHkgYSBzb3Vy Y2Ugb2YgT0lEcyB0aGF0IGhhdmUgc2hvcnQgREVSDQogICAgPj4+PiBlbmNvZGluZ3MuICBBIGxv ZyBvcGVyYXRvciBtYXkgZWl0aGVyICgxKSByZXF1ZXN0IGFuIE9JRCBmcm9tIHRoZSBMb2cgSUQN CiAgICA+Pj4+IFJlZ2lzdHJ5LCBvciAoMikgYWxsb2NhdGUgYW4gT0lEIHRoZW1zZWx2ZXMgKGZy b20gYW4gT0lEIGFyYyB0aGF0IHRoZXkNCiAgICA+Pj4+IGNvbnRyb2wsIG5hdHVyYWxseSkuDQog ICAgPj4+Pg0KICAgID4+Pj4gVGhlIFJlZ2lzdHJ5IGlzIG5vdCBpbnRlbmRlZCB0byBiZSBhIGds b2JhbCBkaXJlY3Rvcnkgb2YgYWxsIGxvZ3MuDQogICAgPj4+DQogICAgPj4+IENvdWxkIGJlIGdv b2QgdG8gY2xhcmlmeSBpbiB0aGUgdGV4dC4NCiAgICA+Pg0KICAgID4+IEFkZHJlc3NlZCBieQ0K ICAgID4+IGh0dHBzOi8vZ2l0aHViLmNvbS9yb2JzdHJhZGxpbmcvY2VydGlmaWNhdGUtdHJhbnNw YXJlbmN5LXJmY3MvY29tbWl0LzE4YmUzYmRjMGViM2E4ZjViOTUwNDAwODFjY2ZhZGRjZDI5MjRm Y2INCiAgICA+Pg0KICAgID4+Pj4+ICAgNCkgc2VjIDQuODog4oCeSWYgYW4NCiAgICA+Pj4+PiAg ICAgaW1wbGVtZW50YXRpb24gc2VlcyBhbiBleHRlbnNpb24gdGhhdCBpdCBkb2VzIG5vdCB1bmRl cnN0YW5kLCBpdA0KICAgID4+Pj4+ICAgICBTSE9VTEQgaWdub3JlIHRoYXQgZXh0ZW5zaW9uLuKA nA0KICAgID4+Pj4+IE1heWJlIGl04oCZcyBqdXN0IG1lIGJlY2F1c2UgSSBtYXkgaGF2ZSBtaXNz ZWQgc29tZSBjb250ZXh0IGJ1dCBkb2VzIOKAnmlnbm9yZeKAnA0KICAgID4+Pj4+IG1lYW4gaGVy ZSB0aGF0IGl0IHNob3VsZCBsb2cgaXQgb3Igbm90Pw0KICAgID4+Pj4NCiAgICA+Pj4+ICJJdCIg KHRoZSBwcmVjZXJ0aWZpY2F0ZSBvciBjZXJ0aWZpY2F0ZSkgbXVzdCBoYXZlIGFscmVhZHkgYmVl biBsb2dnZWQsDQogICAgPj4+PiBiZWNhdXNlIHRoZSBjb3JyZXNwb25kaW5nIFNDVCAodGhhdCBj b250YWlucyBhIHBvdGVudGlhbGx5IHVucmVjb2duaXplZA0KICAgID4+Pj4gZXh0ZW5zaW9uKSBj b3VsZG4ndCBvdGhlcndpc2UgZXhpc3QuDQogICAgPj4+DQogICAgPj4+IENvdWxkIGJlIGdvb2Qg dG8gY2xhcmlmeSBpbiB0aGUgdGV4dC4NCiAgICA+Pg0KICAgID4+IEkgdGhpbmsgb3RoZXIgc2Vj dGlvbnMgb2YgdGhlIGRvY3VtZW50IGFscmVhZHkgbWFrZSBpdCBjbGVhciB0aGF0IGENCiAgICA+ PiBjZXJ0aWZpY2F0ZSBvciBwcmVjZXJ0aWZpY2F0ZSBtdXN0IGJlIHN1Ym1pdHRlZCB0byAoYW5k IGFjY2VwdGVkIGJ5KSBhDQogICAgPj4gbG9nIGJlZm9yZSBhbiBTQ1Qgd2lsbCBiZSBwcm9kdWNl ZC4NCiAgICA+Pg0KICAgID4+IFNlY3Rpb24gMyBzYXlzOg0KICAgID4+ICAgICJJZiBhIGxvZyBh Y2NlcHRzIGEgc3VibWlzc2lvbiwgaXQgd2lsbCByZXR1cm4gYSBTaWduZWQgQ2VydGlmaWNhdGUN CiAgICA+PiAgICAgVGltZXN0YW1wIChTQ1QpIg0KICAgID4+DQogICAgPj4gU2VjdGlvbiA0IHNh eXM6DQogICAgPj4gICAgIldoZW4gaXQgcmVjZWl2ZXMgYW5kIGFjY2VwdHMgYSB2YWxpZCBzdWJt aXNzaW9uLCB0aGUgbG9nIE1VU1QgcmV0dXJuDQogICAgPj4gICAgIGFuIFNDVCB0aGF0IGNvcnJl c3BvbmRzIHRvIHRoZSBzdWJtaXR0ZWQgY2VydGlmaWNhdGUgb3INCiAgICA+PiAgICAgcHJlY2Vy dGlmaWNhdGUuIg0KICAgID4+DQogICAgPj4gSSB0aGluayByZWl0ZXJhdGluZyB0aGlzIHBvaW50 IGFnYWluIHdvdWxkIGJlIGJvdGggdW5uZWNlc3NhcnkgYW5kIG91dA0KICAgID4+IG9mIHNjb3Bl IGZvciBzZWN0aW9uIDQuOCwgdGhlIHB1cnBvc2Ugb2Ygd2hpY2ggaXMgdG8gZGVmaW5lIHRoZQ0K ICAgID4+IHN0cnVjdHVyZSBvZiBhbiBTQ1QuDQogICAgPj4NCiAgICA+Pj4+PiAgIDUpIHNlYyA1 OiDigJ5NQVkgcmV0cnkgdGhlIHNhbWUNCiAgICA+Pj4+PiAgICAgcmVxdWVzdCB3aXRob3V0IG1v ZGlmaWNhdGlvbiBhdCBhIGxhdGVyIGRhdGUu4oCcDQogICAgPj4+Pj4gV291bGQgaXQgYmUgcG9z c2libGUgdG8gcHJvdmlkZSBhIHJlY29tbWVuZGF0aW9uIGhvdyBsb25nIHRoZSBjbGllbnQgc2hv dWxkDQogICAgPj4+Pj4gd2FpdD8NCiAgICA+Pj4+DQogICAgPj4+PiBUaGUgdmVyeSBuZXh0IHNl bnRlbmNlIGluIHNlY3Rpb24gNSBhbHJlYWR5IHNwZWNpZmllcyBhIG1lY2hhbmlzbSBmb3INCiAg ICA+Pj4+IGRvaW5nIGp1c3QgdGhhdDoNCiAgICA+Pj4+ICAgICdOb3RlIHRoYXQgYXMgcGVyDQog ICAgPj4+PiAgICAgW1JGQzcyMzFdLCBpbiB0aGUgY2FzZSBvZiBhIDUwMyByZXNwb25zZSB0aGUg bG9nIE1BWSBpbmNsdWRlIGENCiAgICA+Pj4+ICAgICAiUmV0cnktQWZ0ZXI6IiBoZWFkZXIgaW4g b3JkZXIgdG8gcmVxdWVzdCBhIG1pbmltdW0gdGltZSBmb3IgdGhlDQogICAgPj4+PiAgICAgY2xp ZW50IHRvIHdhaXQgYmVmb3JlIHJldHJ5aW5nIHRoZSByZXF1ZXN0LuKAmQ0KICAgID4+Pg0KICAg ID4+PiBJIG1lYW50LCB3b3VsZCBpdCBtYWtlIHNlbnNlIHRvIGFjdHVhbGx5IHByb3ZpZGUgYSBk ZWZhdWx0IHZhbHVlIG9yIHNvbWV0aGluZyBmb3IgdGhpcyB3YWl0aW5nIHRpbWU/DQogICAgPj4N CiAgICA+PiBXZSBjb3VsZCwgYnV0IGl0IHdvdWxkIGJlIGZhaXJseSBhcmJpdHJhcnkuICBTbyB3 aHkgYm90aGVyPw0KICAgID4+DQogICAgPj4gU29tZSB0cmFuc2llbnQgZmFpbHVyZXMgbWF5IGJl IHZlcnkgc2hvcnQtbGl2ZWQsIGJ1dCBvdGhlcnMgbWF5IGxhc3QgZm9yDQogICAgPj4gaG91cnMu ICBPbmx5IHRoZSBsb2cgb3BlcmF0b3IgY2FuIHBvc3NpYmx5IGtub3cgaG93IGxvbmcgYSBjbGll bnQgc2hvdWxkDQogICAgPj4gd2FpdCBiZWZvcmUgcmV0cnlpbmcgYSByZXF1ZXN0IHdvdWxkIGJl IGV4cGVjdGVkIHRvIHN1Y2NlZWQuDQogICAgPj4NCiAgICA+Pj4+PiAgIDYpIHNlYyA1LjY6IOKA nkxvZ3MgTUFZIHJlc3RyaWN0IHRoZSBudW1iZXIgb2YgZW50cmllcyB0aGF0IGNhbiBiZSByZXRy aWV2ZWQgcGVyDQogICAgPj4+Pj4gICAgICJnZXQtZW50cmllcyIgcmVxdWVzdC7igJwNCiAgICA+ Pj4+PiBTaG91bGQgdGhpcyBiZSBhZGRlZCB0byBzZWMgNC4xPw0KICAgID4+Pj4NCiAgICA+Pj4+ IEkgZG9uJ3QgdGhpbmsgdGhhdCdzIGEgZ29vZCBpZGVhLiAgSSBjYW4gaW1hZ2luZSB0aGF0IG9w ZXJhdGlvbmFsIGlzc3Vlcw0KICAgID4+Pj4gbWlnaHQgY2F1c2UgYSBsb2cgb3BlcmF0b3IgdG8g d2FudCB0byB2YXJ5IHRoaXMgcmVzdHJpY3Rpb24gYXQgYW55IHRpbWUuDQogICAgPj4+Pg0KICAg ID4+Pj4gQ2xpZW50cyBzaG91bGQgYWx3YXlzIGJlIHByZXBhcmVkIHRvIHJlY2VpdmUgZ2V0LWVu dHJpZXMgcmVzcG9uc2VzIHRoYXQNCiAgICA+Pj4+IGNvbnRhaW4gZmV3ZXIgZW50cmllcyB0aGFu IHRoZXkgcmVxdWVzdGVkLg0KICAgID4+Pj4NCiAgICA+Pj4+IFNlZSBhbHNvIGh0dHBzOi8vdHJh Yy5pZXRmLm9yZy90cmFjL3RyYW5zL3RpY2tldC85NQ0KICAgID4+Pj4NCiAgICA+Pj4+PiAgIDcp IHNlYyAxMC4zOiBDb3VsZG7igJl0IHlvdSB1c2UgdGhlIFRMUyAgU2lnbmF0dXJlU2NoZW1lIFJl Z2lzdHJ5IGRpcmVjdGx5DQogICAgPj4+Pj4gICAoaW5zdGVhZCBvZiBmb3JtaW5nIGFuIG93biBy ZWdpc3RyeSk/DQogICAgPj4+Pg0KICAgID4+Pj4gSXQgbWFrZXMgc2Vuc2UgdG8gc3luY2hyb25p emUgdGhlIHNpZ25hdHVyZSBhbGdvcml0aG0gdmFsdWVzIHdlIHVzZSB3aXRoDQogICAgPj4+PiB0 aGUgVExTIFNpZ25hdHVyZUFsZ29yaXRobSByZWdpc3RyeSwgYmVjYXVzZSBvdXIgZGF0YSBzdHJ1 Y3R1cmVzIGFyZQ0KICAgID4+Pj4gZGVmaW5lZCBhY2NvcmRpbmcgdG8gdGhlIGNvbnZlbnRpb25z IGxhaWQgb3V0IGluIHRoZSBUTFMgUkZDLg0KICAgID4+Pj4NCiAgICA+Pj4+IEhvd2V2ZXIsIEkg ZG9uJ3QgdGhpbmsgaXQncyBhIGdvb2QgaWRlYSB0byB1c2UgdGhlIFRMUw0KICAgID4+Pj4gU2ln bmF0dXJlQWxnb3JpdGhtIHJlZ2lzdHJ5IGRpcmVjdGx5LiAgSW4gNjk2Mi1iaXMsIHdlJ3ZlIHRh a2VuIHN0ZXBzIHRvDQogICAgPj4+PiBtYWtlIGxvZyBhcnRpZmFjdHMgc21hbGxlciAoY29tcGFy ZWQgdG8gUkZDNjk2Mik7IHJlbGF0ZWQgdG8gdGhhdCwgd2UndmUNCiAgICA+Pj4+IHJlbW92ZWQg dGhlIG9wdGlvbiBvZiBsb2dzIGJlaW5nIHBlcm1pdHRlZCB0byB1c2UgUlNBIGtleXMvc2lnbmF0 dXJlcy4NCiAgICA+Pj4+IGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3Rscy1wYXJh bWV0ZXJzL3Rscy1wYXJhbWV0ZXJzLnhodG1sI3Rscy1wYXJhbWV0ZXJzLTE2DQogICAgPj4+PiBw ZXJtaXRzIFJTQSwgYW5kIHNldmVyYWwgb3RoZXIgc2lnbmF0dXJlIGFsZ29yaXRobXMgdGhhdCB3 ZSBkb24ndCB3aXNoDQogICAgPj4+PiB0byBwZXJtaXQgb3IgcmVjb21tZW5kIChpLmUuICJhbm9u eW1vdXMiLCBEU0EsIEdPU1QsIGFuZCAiUmVzZXJ2ZWQgZm9yDQogICAgPj4+PiBQcml2YXRlIFVz ZSIpLg0KICAgID4+Pj4NCiAgICA+Pj4+PiAgIDgpIHNlYyAxMC40OiBpIFdvbmRlciBpZiBhbiBS RkMtcmVxdWlyZWQgcG9saWN5IHdvdWxkbuKAmXQgYmUgbW9yZSBhcHByb3ByaWF0ZQ0KICAgID4+ Pj4+ICAgZm9yIHRoZSBWZXJzaW9uZWRUcmFuc1R5cGVzIHJlZ2lzdHJ5Pw0KICAgID4+Pj4NCiAg ICA+Pj4+IEluIDY5NjItYmlzIHNlY3Rpb24gMTAuNC4xLCB3ZSBhc2sgdGhlIGFwcG9pbnRlZCBF eHBlcnQgdG8gInJldmlldyB0aGUNCiAgICA+Pj4+IHB1YmxpYyBzcGVjaWZpY2F0aW9uIHRvIGVu c3VyZSB0aGF0IGl0IGlzIGRldGFpbGVkIGVub3VnaCB0byBlbnN1cmUNCiAgICA+Pj4+IGltcGxl bWVudGF0aW9uIGludGVyb3BlcmFiaWxpdHkiLg0KICAgID4+Pj4NCiAgICA+Pj4+IEFGQUlDVCBm cm9tIFJGQzgxMjYsICJSRkMgUmVxdWlyZWQiIGRvZXNuJ3QgaW1wbHkgRXhwZXJ0IFJldmlldywg d2hlcmVhcw0KICAgID4+Pj4gIlNwZWNpZmljYXRpb24gUmVxdWlyZWQiIGRvZXMuICBTbyBJIHRo aW5rIHdlIHNob3VsZCBsZWF2ZSBpdCBhcw0KICAgID4+Pj4gIlNwZWNpZmljYXRpb24gUmVxdWly ZWTigJ0uDQogICAgPj4+DQogICAgPj4+IFJGQyBSZXF1aXJlZCBpbXBsaWVzIHRoYXQgdGhlIGRv Y3VtZW50IGdvdCBzb21lIHJldmlld3MgYmFzZWQgb24gdGhlIHJlc3BlY3RpdmUgcHJvY2Vzcy4N CiAgICA+Pj4NCiAgICA+Pj4gSG93ZXZlciwgSSBndWVzcyBJIGFjdHVhbGx5IHdhbnRlZCB0byBw cm9wb3NlIElFVEYgUmV2aWV3IChhbmQgdXNlZCB0aGUgd3JvbmcgdGVybSkuIFRoYXQgd291bGQg aW1wbHkgdGhhdCBpdCBoYWQgdG8gZ28gdGhyb3VnaCB0aGUgSUVURiBwcm9jZXNzIHdpdGggcmVz cGVjdGl2ZSByZXZpZXcgKGFuZCB0aGVyZWZvcmUgdXN1YWxseSBpdCBpcyBleHBlY3RlZCB0aGF0 IG5vIGV4cGVydCByZXZpZXcgaXMgbmVlZGVkIGluIGFkZGl0aW9uKS4gQW55d2F5IHRoaXMgd2Fz IG1haW5seSBhIGNvbW1lbnQgdG8gZG91YmxlLWNoZWNrIHRoaXMgZGVjaXNpb24uDQogICAgPj4N CiAgICA+PiBJIHBlcnNvbmFsbHkgZG9uJ3QgaGF2ZSBhIHByZWZlcmVuY2UsIGJ1dCBJJ2xsIHN0 YXJ0IGFub3RoZXIgbGlzdCB0aHJlYWQNCiAgICA+PiB0byBkaXNjdXNzIHRoaXMgcHJvcG9zYWwu DQogICAgPj4NCiAgICA+Pj4+PiAgIDkpIHNlYyAxMC42LjE6SSBndWVzcyAgdGhlIHJlZ2lzdHJh dGlvbiBwb2xpY3kgaXMgRkNGUz8gUkZDIDgxMjYgcmVjb21tZW5kIHRvDQogICAgPj4+Pj4gICBh bHdheXMgKGNsZWFybHkpIG5hbWUgdGhlIHJlZ2lzdHJ5Lg0KICAgID4+Pj4NCiAgICA+Pj4+IFRo YW5rcy4gIEluIG91ciByZXNwb25zZSB0byBBbGlzc2EgQ29vcGVyJ3MgRElTQ1VTUy9DT01NRU5U cyAoc2VlDQogICAgPj4+PiBodHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlL2NlcnRpZmljYXRlLXRy YW5zcGFyZW5jeS1yZmNzL3B1bGwvMzA5KSwgd2UndmUNCiAgICA+Pj4+IGFscmVhZHkgY2xhcmlm aWVkIHRoYXQgdGhlIExvZyBJRCBSZWdpc3RyeSBpcyBpbmRlZWQgRmlyc3QgQ29tZSBGaXJzdA0K ICAgID4+Pj4gU2VydmVkLg0KICAgID4+Pj4NCiAgICA+Pj4+PiBBbmQgZmluYWxseSBvbmUgaGln aGVyIGxldmVsIHF1ZXN0aW9uIG1haW5seSBvdXQgb2YgY3VyaW9zaXR5OiB3YXMgaXQNCiAgICA+ Pj4+PiBjb25zaWRlcmVkIHRvIGUuZy4gdXNlIGpzb24gZm9yIGFsbCBkYXRhIHN0cnVjdHVyZXM/ IElzIHRoZXJlIGEgcGVyZm9ybWFuY2UNCiAgICA+Pj4+PiByZWFzb24gdG8gbm90IGRvIHRoYXQg b3Igd2FzbuKAmXQgdGhhdCBldmVuIGRpc2N1c3NlZD8NCiAgICA+Pj4+DQogICAgPj4+PiBQbGVh c2UgZG9uJ3QgcmVzdGFydCB0aGUgZm9ybWF0IHdhcnMuICA7LSkNCiAgICA+Pj4NCiAgICA+Pj4g RGlkbuKAmXQga25vdyB0aGF04oCmDQogICAgPj4+DQogICAgPj4+Pg0KICAgID4+Pj4gV2UgbXVz dCB1c2UgQVNOLjEgZm9yIGFsbCBkYXRhIHN0cnVjdHVyZXMsIGJlY2F1c2UgWC41MDkgY2VydGlm aWNhdGVzDQogICAgPj4+PiBhcmUgaW52b2x2ZWQuICBCdXQgd2UgbXVzdCB1c2UgIlRMUyBlbmNv ZGluZyIgZm9yIGFsbCBkYXRhIHN0cnVjdHVyZXMsDQogICAgPj4+PiBiZWNhdXNlIFRMUyBpcyBp bnZvbHZlZC4gIEJ1dCB3ZSBtdXN0IHVzZSBKU09OIGZvciBhbGwgZGF0YSBzdHJ1Y3R1cmVzLA0K ICAgID4+Pj4gYmVjYXVzZSBKU09OIGlzIG1vcmUgQVBJLWZyaWVuZGx5Lg0KICAgID4+Pj4NCiAg ICA+Pj4+IEl0IHdhcyBpbXBvc3NpYmxlIHRvIHBsZWFzZSBldmVyeW9uZS4gIFdlIGhhZCB0byBj aG9vc2Ugc29tZXRoaW5nLCBzbyB3ZQ0KICAgID4+Pj4gY2hvc2UgVExTIGVuY29kaW5nIGZvciB0 aGUgZGF0YSBzdHJ1Y3R1cmVzLCBhbmQgSlNPTiBmb3IgdGhlIEFQSXMuDQogICAgPj4+Pg0KICAg ID4+Pj4gQXMgSSBtZW50aW9uZWQgZWFybGllciwgb25lIGdvYWwgb2YgNjk2Mi1iaXMgaXMgdG8g bWFrZSBsb2cgYXJ0aWZhY3RzDQogICAgPj4+PiBzbWFsbGVyLiAgVExTIGVuY29kaW5nIGlzIG1v cmUgc3VpdGVkIHRvIHRoaXMgdGhhbiBKU09OLg0KICAgID4+Pg0KICAgID4+PiBPa2F5IHRoYW5r cyBmb3IgdGhlIGJhY2tncm91bmQgaW5mby4gQXMgbG9uZyBhcyB0aGlzIHdhcyBkaXNjdXNzZWQg dGhhdCdzIGZpbmUhDQogICAgPj4NCiAgICA+PiAtLQ0KICAgID4+IFJvYiBTdHJhZGxpbmcNCiAg ICA+PiBTZW5pb3IgUmVzZWFyY2ggJiBEZXZlbG9wbWVudCBTY2llbnRpc3QNCiAgICA+PiBTZWN0 aWdvIExpbWl0ZWQNCiAgICA+Pg0KICAgID4gDQogICAgDQogICAgLS0gDQogICAgUm9iIFN0cmFk bGluZw0KICAgIFNlbmlvciBSZXNlYXJjaCAmIERldmVsb3BtZW50IFNjaWVudGlzdA0KICAgIEVt YWlsOiByb2JAc2VjdGlnby5jb20NCiAgICBCcmFkZm9yZCwgVUsNCiAgICBPZmZpY2U6ICs0NDEy NzQwMjQ3MDcNCiAgICBTZWN0aWdvIExpbWl0ZWQNCiAgICANCiAgICBUaGlzIG1lc3NhZ2UgYW5k IGFueSBmaWxlcyBhc3NvY2lhdGVkIHdpdGggaXQgbWF5IGNvbnRhaW4gbGVnYWxseSANCiAgICBw cml2aWxlZ2VkLCBjb25maWRlbnRpYWwsIG9yIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLiBJZiB5 b3UgYXJlIG5vdCB0aGUgDQogICAgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIG5vdCBwZXJt aXR0ZWQgdG8gdXNlLCBjb3B5LCBvciBmb3J3YXJkIGl0LCANCiAgICBpbiB3aG9sZSBvciBpbiBw YXJ0IHdpdGhvdXQgdGhlIGV4cHJlc3MgY29uc2VudCBvZiB0aGUgc2VuZGVyLiBQbGVhc2UgDQog ICAgbm90aWZ5IHRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwsIGRpc3JlZ2FyZCB0aGUgZm9yZWdv aW5nIG1lc3NhZ2VzLCBhbmQgDQogICAgZGVsZXRlIGl0IGltbWVkaWF0ZWx5Lg0KICAgIF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgVHJhbnMgbWFp bGluZyBsaXN0DQogICAgVHJhbnNAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3RyYW5zDQogICAgDQoNCg== From nobody Wed Oct 23 07:54:25 2019 Return-Path: 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 7EA8712082B for ; Wed, 23 Oct 2019 07:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 W1UPNHb9cMIz for ; Wed, 23 Oct 2019 07:54:10 -0700 (PDT) Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C01CD12088B for ; Wed, 23 Oct 2019 07:53:53 -0700 (PDT) Received: by mail-yb1-xb32.google.com with SMTP id s7so6392524ybq.7 for ; Wed, 23 Oct 2019 07:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e2+5PtHrYgq43l9Oak9r4Rn87ublXMsSVj3Lr/oZ3GQ=; b=Z/C3lCqjhey4pzKBWfcLGoLDkEkAaKp9uHKziTlF78TDSNI3CeDSPle7iSRmIAdx3+ hkPrfErxkPj9tOIS3pgTCR6rxA9DlZJKtl6YbWau8rsI1LGF+aapWFFrn5LPyN9ynp9C hsYYC3wGTsob2Ywrb8ZVuCVVX5ofFP+QIO+dNuFPTnB35iciCl/3OXjYv/5HC5czzeUt Fm35UAZg6kCvL4vr5eHl4ZKM9eQXLLiGfnX9YVp2Sz7pYhwh+ektVEl+tkeffoiByZ5K 400Mmfa2TSQ+jO+gmw9mhDv+qnJd7No38blJu3L5m8o7YTD5UOokGqzYLLhx9717HaUk 900Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e2+5PtHrYgq43l9Oak9r4Rn87ublXMsSVj3Lr/oZ3GQ=; b=pszjns86EmAel/8Oby3N4ipqbxI9ZltEJSdcwZ/xCR5OuYTdSrMVGa3AeDbYTbECZC JVM8kruqUb4FqZZpxsJyqc0OQ53YPp58bTSRXFi0uEaEZ7jb2bx+aMbbg6QnSbRd8OV7 OVoq0O1EBVRZ9koNIIOYqCLRBpZKBKSn/kpsNBP0DI5VZGlLW+OwjWzqPj2yow+87GIq ESbRKzyy1QIk9GSlbkL0LaW94CcMGyJ56EiOnJUP6YQZf6UV881AjNu2XcSvijjwDu/T KKiB+JiicMpks4wxyYJ7uMhvIKquGbPyUXviZbs+2JGKQ+tYK+VGtw5y0OYGngeFr+Fp 09vw== X-Gm-Message-State: APjAAAULQn+laIAdXyk0oThZTGwjk4eGwqZUugsgJWox427XYhO1//Kv 3SDUgrvyVAdiv2/wy2EpOyJQ9pgHv3XYsz4rRdjPwOLhZTg= X-Google-Smtp-Source: APXvYqwIZGa0d1/9l2aMFH+PqGvRpN7xwuC89PEKGP4ERm5TeSV5NGMAdiJJLZla4GVRItmp9rsVJczBiaLsbv9R+pA= X-Received: by 2002:a25:ae48:: with SMTP id g8mr6526815ybe.419.1571842432240; Wed, 23 Oct 2019 07:53:52 -0700 (PDT) MIME-Version: 1.0 References: <2B1C3261-7034-45D9-A70D-EA194C11C5E5@akamai.com> In-Reply-To: <2B1C3261-7034-45D9-A70D-EA194C11C5E5@akamai.com> From: Eran Messeri Date: Wed, 23 Oct 2019 15:53:25 +0100 Message-ID: To: "Salz, Rich" Cc: Rob Stradling , "trans@ietf.org" , "draft-ietf-trans-rfc6962-bis@ietf.org" , Paul Wouters , Mirja Kuehlewind , The IESG , "trans-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000d159a805959515ee" Archived-At: Subject: Re: [Trans] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-trans-rfc6962-bis-31=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 14:54:17 -0000 --000000000000d159a805959515ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I second Rich's suggestion. The problem I see with recommending a retry time is that a request could fail due to one of two reasons: * Transient failure: Some RPC to some backend service errored so re-trying soon after the original request is likely to succeed. * More permanent failure: On-going outage that will take a while to resolve (e.g. people working to resolve it). And each of the reasons would merit a different time-out. If I had to pick a number, 60 seconds _seems_ like a reasonable retry delay, but I'm more than happy to learn of circumstances where this would be excessive / too short. On Wed, Oct 23, 2019 at 1:22 PM Salz, Rich wrote: > How about "Servers may wish to send a Retry-After header" ? > > > =EF=BB=BFOn 10/23/19, 6:15 AM, "Rob Stradling" wrote: > > On 23/10/2019 10:52, Mirja Kuehlewind wrote: > > Hi Rob, > > > > Just one more comment regarding the default for the waiting time: I > understand that it is arbitrary but I guess someone implementing CT in th= e > first place has to make the same arbitrary choice and just select some > value. Of course this value should be configurable but recommending some > default or at least a range or order of value could reduce surprises. > However, this is a just a recommendation from me and it=E2=80=99s your ca= ll! > > Would anyone else like to comment on whether they agree or disagree > with > this recommendation? > > If you agree, then please propose a default waiting time (for > situations > where the log server does not send an explicit "Retry-After" header). > > Thanks. > > > Mirja > > > > > >> On 16. Oct 2019, at 15:36, Rob Stradling wrote: > >> > >> On 14/10/2019 16:32, Mirja Kuehlewind wrote: > >>> Hi Rob, > >>> > >>> Thanks for your replies and edits. I will clear my discuss as soo= n > as the new version is submitted. > >> > >> Thanks Mirja. > >> > >>> Please see some minor comments below! > >> > >> Replies inline. > >> > >>> Thanks! > >>> Mirja > >>> > >>> > >>>> On 14. Oct 2019, at 16:07, Rob Stradling wrote= : > >>>> > >>>> Hi Mirja. Sorry for the looong delay. > >>>> > >>>> Comments inline, and I've just posted this PR: > >>>> https://github.com/google/certificate-transparency-rfcs/pull/316 > >>>> > >>>> On 14/03/2019 13:50, Mirja K=C3=BChlewind via Datatracker wrote: > >>>>> Mirja K=C3=BChlewind has entered the following ballot position = for > >>>>> draft-ietf-trans-rfc6962-bis-31: Discuss > >>>>> > >>>>> Please refer to > https://www.ietf.org/iesg/statement/discuss-criteria.html > >>>>> for more information about IESG DISCUSS and COMMENT positions. > >>>>> > >>>>> > >>>>> The document, along with other ballot positions, can be found > here: > >>>>> https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/ > >>>>> > >>>>> > >>>>> > >>>>> > ---------------------------------------------------------------------- > >>>>> DISCUSS: > >>>>> > ---------------------------------------------------------------------- > >>>>> > >>>>> There was a presentation at maprg IETF 103 about the question i= f > CT helps > >>>>> attackers to find new domains. I think this risk should at leas= t > be mentioned > >>>>> in the security considerations section. > >>>> > >>>> Addressed by > >>>> > https://github.com/robstradling/certificate-transparency-rfcs/commit/3b2e= c0a51f8abb4c8c0b985614fefa4291432dd9 > >>>> > >>>>> > ---------------------------------------------------------------------- > >>>>> COMMENT: > >>>>> > ---------------------------------------------------------------------- > >>>>> > >>>>> 1) I found section 2 a bit hard to follow. Would it maybe be > possible to > >>>>> provide more textual explanation of the algorithms instead of > just describing > >>>>> the steps of the algorithms? Also I was wondering how much > much these > >>>>> algorithms are actually =E2=80=9Epart=E2=80=9C of the protoco= l spec=E2=80=A6? Are > could these be > >>>>> rather seen as example algorithms? Maybe that could be furthe= r > clarified > >>>> > >>>> We'll consider these comments on section 2 at a later date, alon= g > with > >>>> Benjamin Kaduk's comments on section 2. > >>>> > >>>>> 2) Please expand STH on first occurrence (in sec 4.1) > >>>> > >>>> Addressed by > >>>> > https://github.com/robstradling/certificate-transparency-rfcs/commit/d2d6= b0ac303af2659e5df538391002f1bf454edb > >>>> > >>>>> 3) Sec 4.4: =E2=80=9EA log's operator MUST either allocate th= e OID > >>>>> themselves or request an OID from the Log ID Registry (see > >>>>> Section 10.6.1).=E2=80=9C > >>>>> Isn't there an obligation to register? > >>>> > >>>> The Log ID Registry is merely a source of OIDs that have short D= ER > >>>> encodings. A log operator may either (1) request an OID from th= e > Log ID > >>>> Registry, or (2) allocate an OID themselves (from an OID arc tha= t > they > >>>> control, naturally). > >>>> > >>>> The Registry is not intended to be a global directory of all log= s. > >>> > >>> Could be good to clarify in the text. > >> > >> Addressed by > >> > https://github.com/robstradling/certificate-transparency-rfcs/commit/18be= 3bdc0eb3a8f5b95040081ccfaddcd2924fcb > >> > >>>>> 4) sec 4.8: =E2=80=9EIf an > >>>>> implementation sees an extension that it does not > understand, it > >>>>> SHOULD ignore that extension.=E2=80=9C > >>>>> Maybe it=E2=80=99s just me because I may have missed some conte= xt but > does =E2=80=9Eignore=E2=80=9C > >>>>> mean here that it should log it or not? > >>>> > >>>> "It" (the precertificate or certificate) must have already been > logged, > >>>> because the corresponding SCT (that contains a potentially > unrecognized > >>>> extension) couldn't otherwise exist. > >>> > >>> Could be good to clarify in the text. > >> > >> I think other sections of the document already make it clear that = a > >> certificate or precertificate must be submitted to (and accepted > by) a > >> log before an SCT will be produced. > >> > >> Section 3 says: > >> "If a log accepts a submission, it will return a Signed > Certificate > >> Timestamp (SCT)" > >> > >> Section 4 says: > >> "When it receives and accepts a valid submission, the log MUST > return > >> an SCT that corresponds to the submitted certificate or > >> precertificate." > >> > >> I think reiterating this point again would be both unnecessary and > out > >> of scope for section 4.8, the purpose of which is to define the > >> structure of an SCT. > >> > >>>>> 5) sec 5: =E2=80=9EMAY retry the same > >>>>> request without modification at a later date.=E2=80=9C > >>>>> Would it be possible to provide a recommendation how long the > client should > >>>>> wait? > >>>> > >>>> The very next sentence in section 5 already specifies a mechanis= m > for > >>>> doing just that: > >>>> 'Note that as per > >>>> [RFC7231], in the case of a 503 response the log MAY include= a > >>>> "Retry-After:" header in order to request a minimum time for > the > >>>> client to wait before retrying the request.=E2=80=99 > >>> > >>> I meant, would it make sense to actually provide a default value > or something for this waiting time? > >> > >> We could, but it would be fairly arbitrary. So why bother? > >> > >> Some transient failures may be very short-lived, but others may > last for > >> hours. Only the log operator can possibly know how long a client > should > >> wait before retrying a request would be expected to succeed. > >> > >>>>> 6) sec 5.6: =E2=80=9ELogs MAY restrict the number of entries = that can > be retrieved per > >>>>> "get-entries" request.=E2=80=9C > >>>>> Should this be added to sec 4.1? > >>>> > >>>> I don't think that's a good idea. I can imagine that operationa= l > issues > >>>> might cause a log operator to want to vary this restriction at > any time. > >>>> > >>>> Clients should always be prepared to receive get-entries > responses that > >>>> contain fewer entries than they requested. > >>>> > >>>> See also https://trac.ietf.org/trac/trans/ticket/95 > >>>> > >>>>> 7) sec 10.3: Couldn=E2=80=99t you use the TLS SignatureSchem= e > Registry directly > >>>>> (instead of forming an own registry)? > >>>> > >>>> It makes sense to synchronize the signature algorithm values we > use with > >>>> the TLS SignatureAlgorithm registry, because our data structures > are > >>>> defined according to the conventions laid out in the TLS RFC. > >>>> > >>>> However, I don't think it's a good idea to use the TLS > >>>> SignatureAlgorithm registry directly. In 6962-bis, we've taken > steps to > >>>> make log artifacts smaller (compared to RFC6962); related to > that, we've > >>>> removed the option of logs being permitted to use RSA > keys/signatures. > >>>> > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-= parameters-16 > >>>> permits RSA, and several other signature algorithms that we don'= t > wish > >>>> to permit or recommend (i.e. "anonymous", DSA, GOST, and > "Reserved for > >>>> Private Use"). > >>>> > >>>>> 8) sec 10.4: i Wonder if an RFC-required policy wouldn=E2=80= =99t be > more appropriate > >>>>> for the VersionedTransTypes registry? > >>>> > >>>> In 6962-bis section 10.4.1, we ask the appointed Expert to > "review the > >>>> public specification to ensure that it is detailed enough to > ensure > >>>> implementation interoperability". > >>>> > >>>> AFAICT from RFC8126, "RFC Required" doesn't imply Expert Review, > whereas > >>>> "Specification Required" does. So I think we should leave it as > >>>> "Specification Required=E2=80=9D. > >>> > >>> RFC Required implies that the document got some reviews based on > the respective process. > >>> > >>> However, I guess I actually wanted to propose IETF Review (and > used the wrong term). That would imply that it had to go through the IETF > process with respective review (and therefore usually it is expected that > no expert review is needed in addition). Anyway this was mainly a comment > to double-check this decision. > >> > >> I personally don't have a preference, but I'll start another list > thread > >> to discuss this proposal. > >> > >>>>> 9) sec 10.6.1:I guess the registration policy is FCFS? RFC > 8126 recommend to > >>>>> always (clearly) name the registry. > >>>> > >>>> Thanks. In our response to Alissa Cooper's DISCUSS/COMMENTs (se= e > >>>> https://github.com/google/certificate-transparency-rfcs/pull/309= ), > we've > >>>> already clarified that the Log ID Registry is indeed First Come > First > >>>> Served. > >>>> > >>>>> And finally one higher level question mainly out of curiosity: > was it > >>>>> considered to e.g. use json for all data structures? Is there a > performance > >>>>> reason to not do that or wasn=E2=80=99t that even discussed? > >>>> > >>>> Please don't restart the format wars. ;-) > >>> > >>> Didn=E2=80=99t know that=E2=80=A6 > >>> > >>>> > >>>> We must use ASN.1 for all data structures, because X.509 > certificates > >>>> are involved. But we must use "TLS encoding" for all data > structures, > >>>> because TLS is involved. But we must use JSON for all data > structures, > >>>> because JSON is more API-friendly. > >>>> > >>>> It was impossible to please everyone. We had to choose > something, so we > >>>> chose TLS encoding for the data structures, and JSON for the API= s. > >>>> > >>>> As I mentioned earlier, one goal of 6962-bis is to make log > artifacts > >>>> smaller. TLS encoding is more suited to this than JSON. > >>> > >>> Okay thanks for the background info. As long as this was discusse= d > that's fine! > >> > >> -- > >> Rob Stradling > >> Senior Research & Development Scientist > >> Sectigo Limited > >> > > > > -- > Rob Stradling > Senior Research & Development Scientist > Email: rob@sectigo.com > Bradford, UK > Office: +441274024707 <+44%201274%20024707> > 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 > > > --000000000000d159a805959515ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I second Rich's suggestion.

The pro= blem I see with recommending a retry time is that a request could fail due = to one of two reasons:
* Transient failure: Some RPC to some back= end service errored so re-trying soon after the original request is likely = to succeed.
* More permanent failure: On-going outage that will t= ake a while to resolve (e.g. people working to resolve it).

<= /div>
And each of the reasons would merit a different time-out.

If I had to pick a number, 60 seconds _seems_ like a reas= onable retry delay, but I'm more than happy to learn of circumstances w= here this would be excessive / too short.

On Wed, Oct 23, 2019 at 1:22= PM Salz, Rich <rsalz@akamai.com= > wrote:
How = about "Servers may wish to send a Retry-After header" ?


=EF=BB=BFOn 10/23/19, 6:15 AM, "Rob Stradling" <rob@sectigo.com> wrote:

=C2=A0 =C2=A0 On 23/10/2019 10:52, Mirja Kuehlewind wrote:
=C2=A0 =C2=A0 > Hi Rob,
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Just one more comment regarding the default for the wait= ing time: I understand that it is arbitrary but I guess someone implementin= g CT in the first place has to make the same arbitrary choice and just sele= ct some value. Of course this value should be configurable but recommending= some default or at least a range or order of value could reduce surprises.= However, this is a just a recommendation from me and it=E2=80=99s your cal= l!

=C2=A0 =C2=A0 Would anyone else like to comment on whether they agree or di= sagree with
=C2=A0 =C2=A0 this recommendation?

=C2=A0 =C2=A0 If you agree, then please propose a default waiting time (for= situations
=C2=A0 =C2=A0 where the log server does not send an explicit "Retry-Af= ter" header).

=C2=A0 =C2=A0 Thanks.

=C2=A0 =C2=A0 > Mirja
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >> On 16. Oct 2019, at 15:36, Rob Stradling <rob@sectigo.com> wrote= :
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> On 14/10/2019 16:32, Mirja Kuehlewind wrote:
=C2=A0 =C2=A0 >>> Hi Rob,
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> Thanks for your replies and edits. I will clear = my discuss as soon as the new version is submitted.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Thanks Mirja.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>> Please see some minor comments below!
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Replies inline.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>> Thanks!
=C2=A0 =C2=A0 >>> Mirja
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>>> On 14. Oct 2019, at 16:07, Rob Stradling <= ;rob@sectigo.com&g= t; wrote:
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> Hi Mirja.=C2=A0 Sorry for the looong delay.<= br> =C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> Comments inline, and I've just posted th= is PR:
=C2=A0 =C2=A0 >>>> https= ://github.com/google/certificate-transparency-rfcs/pull/316
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> On 14/03/2019 13:50, Mirja K=C3=BChlewind vi= a Datatracker wrote:
=C2=A0 =C2=A0 >>>>> Mirja K=C3=BChlewind has entered the fol= lowing ballot position for
=C2=A0 =C2=A0 >>>>> draft-ietf-trans-rfc6962-bis-31: Discuss=
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
=C2=A0 =C2=A0 >>>>> for more information about IESG DISCUSS = and COMMENT positions.
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> The document, along with other ballot po= sitions, can be found here:
=C2=A0 =C2=A0 >>>>> htt= ps://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis/
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> ----------------------------------------= ------------------------------
=C2=A0 =C2=A0 >>>>> DISCUSS:
=C2=A0 =C2=A0 >>>>> ----------------------------------------= ------------------------------
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>> There was a presentation at maprg IETF 1= 03 about the question if CT helps
=C2=A0 =C2=A0 >>>>> attackers to find new domains. I think t= his risk should at least be mentioned
=C2=A0 =C2=A0 >>>>> in the security considerations section.<= br> =C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> Addressed by
=C2=A0 =C2=A0 >>>> https://github.com/robstradling/cer= tificate-transparency-rfcs/commit/3b2ec0a51f8abb4c8c0b985614fefa4291432dd9<= /a>
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>>> ----------------------------------------= ------------------------------
=C2=A0 =C2=A0 >>>>> COMMENT:
=C2=A0 =C2=A0 >>>>> ----------------------------------------= ------------------------------
=C2=A0 =C2=A0 >>>>>
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A01) I found section 2 a bit h= ard to follow. Would it maybe be possible to
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0provide more textual explana= tion of the algorithms instead of just describing
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0the steps of the algorithms?= Also I was wondering how much much these
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0algorithms are actually =E2= =80=9Epart=E2=80=9C of the protocol spec=E2=80=A6? Are could these be
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0rather seen as example algor= ithms? Maybe that could be further clarified
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> We'll consider these comments on section= 2 at a later date, along with
=C2=A0 =C2=A0 >>>> Benjamin Kaduk's comments on section 2.<= br> =C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A02) Please expand STH on firs= t occurrence (in sec 4.1)
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> Addressed by
=C2=A0 =C2=A0 >>>> https://github.com/robstradling/cer= tificate-transparency-rfcs/commit/d2d6b0ac303af2659e5df538391002f1bf454edb<= /a>
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A03) Sec 4.4: =E2=80=9EA log&#= 39;s operator MUST either allocate the OID
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0 =C2=A0 themselves or reques= t an OID from the Log ID Registry (see
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0 =C2=A0 Section 10.6.1).=E2= =80=9C
=C2=A0 =C2=A0 >>>>> Isn't there an obligation to registe= r?
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> The Log ID Registry is merely a source of OI= Ds that have short DER
=C2=A0 =C2=A0 >>>> encodings.=C2=A0 A log operator may either (= 1) request an OID from the Log ID
=C2=A0 =C2=A0 >>>> Registry, or (2) allocate an OID themselves = (from an OID arc that they
=C2=A0 =C2=A0 >>>> control, naturally).
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> The Registry is not intended to be a global = directory of all logs.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> Could be good to clarify in the text.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Addressed by
=C2=A0 =C2=A0 >> https://github.com/robstradling/certifica= te-transparency-rfcs/commit/18be3bdc0eb3a8f5b95040081ccfaddcd2924fcb =C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A04) sec 4.8: =E2=80=9EIf an =C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0 =C2=A0implementation sees a= n extension that it does not understand, it
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0 =C2=A0SHOULD ignore that ex= tension.=E2=80=9C
=C2=A0 =C2=A0 >>>>> Maybe it=E2=80=99s just me because I may= have missed some context but does =E2=80=9Eignore=E2=80=9C
=C2=A0 =C2=A0 >>>>> mean here that it should log it or not?<= br> =C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> "It" (the precertificate or certif= icate) must have already been logged,
=C2=A0 =C2=A0 >>>> because the corresponding SCT (that contains= a potentially unrecognized
=C2=A0 =C2=A0 >>>> extension) couldn't otherwise exist.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> Could be good to clarify in the text.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I think other sections of the document already make = it clear that a
=C2=A0 =C2=A0 >> certificate or precertificate must be submitted to (= and accepted by) a
=C2=A0 =C2=A0 >> log before an SCT will be produced.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Section 3 says:
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 "If a log accepts a submission, it= will return a Signed Certificate
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0Timestamp (SCT)"
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Section 4 says:
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 "When it receives and accepts a va= lid submission, the log MUST return
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0an SCT that corresponds to the su= bmitted certificate or
=C2=A0 =C2=A0 >>=C2=A0 =C2=A0 =C2=A0precertificate."
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I think reiterating this point again would be both u= nnecessary and out
=C2=A0 =C2=A0 >> of scope for section 4.8, the purpose of which is to= define the
=C2=A0 =C2=A0 >> structure of an SCT.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A05) sec 5: =E2=80=9EMAY retry= the same
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0 =C2=A0request without modif= ication at a later date.=E2=80=9C
=C2=A0 =C2=A0 >>>>> Would it be possible to provide a recomm= endation how long the client should
=C2=A0 =C2=A0 >>>>> wait?
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> The very next sentence in section 5 already = specifies a mechanism for
=C2=A0 =C2=A0 >>>> doing just that:
=C2=A0 =C2=A0 >>>>=C2=A0 =C2=A0 'Note that as per
=C2=A0 =C2=A0 >>>>=C2=A0 =C2=A0 =C2=A0[RFC7231], in the case of= a 503 response the log MAY include a
=C2=A0 =C2=A0 >>>>=C2=A0 =C2=A0 =C2=A0"Retry-After:" = header in order to request a minimum time for the
=C2=A0 =C2=A0 >>>>=C2=A0 =C2=A0 =C2=A0client to wait before ret= rying the request.=E2=80=99
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> I meant, would it make sense to actually provide= a default value or something for this waiting time?
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> We could, but it would be fairly arbitrary.=C2=A0 So= why bother?
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> Some transient failures may be very short-lived, but= others may last for
=C2=A0 =C2=A0 >> hours.=C2=A0 Only the log operator can possibly know= how long a client should
=C2=A0 =C2=A0 >> wait before retrying a request would be expected to = succeed.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A06) sec 5.6: =E2=80=9ELogs MA= Y restrict the number of entries that can be retrieved per
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0 =C2=A0"get-entries&quo= t; request.=E2=80=9C
=C2=A0 =C2=A0 >>>>> Should this be added to sec 4.1?
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> I don't think that's a good idea.=C2= =A0 I can imagine that operational issues
=C2=A0 =C2=A0 >>>> might cause a log operator to want to vary t= his restriction at any time.
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> Clients should always be prepared to receive= get-entries responses that
=C2=A0 =C2=A0 >>>> contain fewer entries than they requested. =C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> See also https://trac.ietf.= org/trac/trans/ticket/95
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A07) sec 10.3: Couldn=E2=80=99= t you use the TLS=C2=A0 SignatureScheme Registry directly
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0(instead of forming an own r= egistry)?
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> It makes sense to synchronize the signature = algorithm values we use with
=C2=A0 =C2=A0 >>>> the TLS SignatureAlgorithm registry, because= our data structures are
=C2=A0 =C2=A0 >>>> defined according to the conventions laid ou= t in the TLS RFC.
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> However, I don't think it's a good i= dea to use the TLS
=C2=A0 =C2=A0 >>>> SignatureAlgorithm registry directly.=C2=A0 = In 6962-bis, we've taken steps to
=C2=A0 =C2=A0 >>>> make log artifacts smaller (compared to RFC6= 962); related to that, we've
=C2=A0 =C2=A0 >>>> removed the option of logs being permitted t= o use RSA keys/signatures.
=C2=A0 =C2=A0 >>>> https://www.iana.org/assignments/tls-parameters/tls-parame= ters.xhtml#tls-parameters-16
=C2=A0 =C2=A0 >>>> permits RSA, and several other signature alg= orithms that we don't wish
=C2=A0 =C2=A0 >>>> to permit or recommend (i.e. "anonymous= ", DSA, GOST, and "Reserved for
=C2=A0 =C2=A0 >>>> Private Use").
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A08) sec 10.4: i Wonder if an = RFC-required policy wouldn=E2=80=99t be more appropriate
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0for the VersionedTransTypes = registry?
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> In 6962-bis section 10.4.1, we ask the appoi= nted Expert to "review the
=C2=A0 =C2=A0 >>>> public specification to ensure that it is de= tailed enough to ensure
=C2=A0 =C2=A0 >>>> implementation interoperability".
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> AFAICT from RFC8126, "RFC Required"= ; doesn't imply Expert Review, whereas
=C2=A0 =C2=A0 >>>> "Specification Required" does.=C2= =A0 So I think we should leave it as
=C2=A0 =C2=A0 >>>> "Specification Required=E2=80=9D.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> RFC Required implies that the document got some = reviews based on the respective process.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> However, I guess I actually wanted to propose IE= TF Review (and used the wrong term). That would imply that it had to go thr= ough the IETF process with respective review (and therefore usually it is e= xpected that no expert review is needed in addition). Anyway this was mainl= y a comment to double-check this decision.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> I personally don't have a preference, but I'= ll start another list thread
=C2=A0 =C2=A0 >> to discuss this proposal.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A09) sec 10.6.1:I guess=C2=A0 = the registration policy is FCFS? RFC 8126 recommend to
=C2=A0 =C2=A0 >>>>>=C2=A0 =C2=A0always (clearly) name the re= gistry.
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> Thanks.=C2=A0 In our response to Alissa Coop= er's DISCUSS/COMMENTs (see
=C2=A0 =C2=A0 >>>> https= ://github.com/google/certificate-transparency-rfcs/pull/309), we've=
=C2=A0 =C2=A0 >>>> already clarified that the Log ID Registry i= s indeed First Come First
=C2=A0 =C2=A0 >>>> Served.
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>>> And finally one higher level question ma= inly out of curiosity: was it
=C2=A0 =C2=A0 >>>>> considered to e.g. use json for all data= structures? Is there a performance
=C2=A0 =C2=A0 >>>>> reason to not do that or wasn=E2=80=99t = that even discussed?
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> Please don't restart the format wars.=C2= =A0 ;-)
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> Didn=E2=80=99t know that=E2=80=A6
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> We must use ASN.1 for all data structures, b= ecause X.509 certificates
=C2=A0 =C2=A0 >>>> are involved.=C2=A0 But we must use "TL= S encoding" for all data structures,
=C2=A0 =C2=A0 >>>> because TLS is involved.=C2=A0 But we must u= se JSON for all data structures,
=C2=A0 =C2=A0 >>>> because JSON is more API-friendly.
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> It was impossible to please everyone.=C2=A0 = We had to choose something, so we
=C2=A0 =C2=A0 >>>> chose TLS encoding for the data structures, = and JSON for the APIs.
=C2=A0 =C2=A0 >>>>
=C2=A0 =C2=A0 >>>> As I mentioned earlier, one goal of 6962-bis= is to make log artifacts
=C2=A0 =C2=A0 >>>> smaller.=C2=A0 TLS encoding is more suited t= o this than JSON.
=C2=A0 =C2=A0 >>>
=C2=A0 =C2=A0 >>> Okay thanks for the background info. As long as = this was discussed that's fine!
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> --
=C2=A0 =C2=A0 >> Rob Stradling
=C2=A0 =C2=A0 >> Senior Research & Development Scientist
=C2=A0 =C2=A0 >> Sectigo Limited
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >

=C2=A0 =C2=A0 --
=C2=A0 =C2=A0 Rob Stradling
=C2=A0 =C2=A0 Senior Research & Development Scientist
=C2=A0 =C2=A0 Email: r= ob@sectigo.com
=C2=A0 =C2=A0 Bradford, UK
=C2=A0 =C2=A0 Office: +441274024707
=C2=A0 =C2=A0 Sectigo Limited

=C2=A0 =C2=A0 This message and any files associated with it may contain leg= ally
=C2=A0 =C2=A0 privileged, confidential, or proprietary information. If you = are not the
=C2=A0 =C2=A0 intended recipient, you are not permitted to use, copy, or fo= rward it,
=C2=A0 =C2=A0 in whole or in part without the express consent of the sender= . Please
=C2=A0 =C2=A0 notify the sender by reply email, disregard the foregoing mes= sages, and
=C2=A0 =C2=A0 delete it immediately.
=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Trans mailing list
=C2=A0 =C2=A0 Trans@iet= f.org
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/tra= ns


--000000000000d159a805959515ee-- From nobody Wed Oct 23 07:54:33 2019 Return-Path: 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 5B6021209A2; Wed, 23 Oct 2019 07:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 vniplmNdvHqn; Wed, 23 Oct 2019 07:54:22 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780085.outbound.protection.outlook.com [40.107.78.85]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EEC06120831; Wed, 23 Oct 2019 07:54:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JSDRdfqrLJKIAtvSY5PjQkEzO3KoSNo7j4YAnv7bCJEczCv/BlJGJDXh4Lsbe9zMlovRjXhnha1TVcWehZOAD+WxNJQTRmhcXVRItkVYPfW2r3BsdkpW1VdtdkLvndTktMS4Chf/+8FYP+tsi50C3rVqszuZ6M5cnAl0FL0I7IwEhFUpG+RX8Y0XGLceBfxdmXS/VNPfU9XdPI6vMoFNy/ALYXivr990bscp0tKU+d7/EzlSyNxnhI30k7Zqov6n2e5oiEi33A6Lzyqo0nhuMrpl0od2O8dfV4Bl7+FaCnfPgnLV75GHyMrLUmN/xCVNUMU5QJjDlChjk3U1UHgVNw== 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=XUO1GQTzzT7nT18+9LQdP1jmYyK0vjTuucRfr6stcXs=; b=gK5oLiQa5P+nL7zRzv51cs11zcKmYXfVwP02j/lVABmT9A6s1+4lGQE8ZcYOwCh2sTehiYhNnxyAXU8AJnQ1aMXVCNyxC6VOYNWRRr3DcdVYP5A/ahupvzhLD9bpFaKuoO2TetxBcsGyGVcC1hbbvIy+x7wgedEXtoaI+dNY73ditWmSDZd/Sxybyz9kTdWAScMMp4d6B6KQhlQouu4nviTYt1BFP27tBfEd2OJ2s2v09OfogIV5NpEsI2L2yrsMz7xLBW1kQ4ZFwvZ/NwbpsTlxloGFva5I6wuizd5H2Bml78Mdvi+aLAj9BEMkIBN31zsVxT5aFFgyY0vvq9qjWA== 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=XUO1GQTzzT7nT18+9LQdP1jmYyK0vjTuucRfr6stcXs=; b=AuwTe1PcPOCEoQhq4PrJ9Qsdz19mJOY9AYGxMCLcgzBIMBJKzVYILLtobjcFCaQvpXhROS+smSlar/IkWOEmUKnAtOGHTW9cWmqiHt777TreYA1U0VdrKPrLkvzC7TnQtpipcPD9FveWsnIwYQzp3gwVFOsvmh2t8vkGfEOTMWo= Received: from DM6PR17MB3162.namprd17.prod.outlook.com (20.176.124.223) by DM6PR17MB3228.namprd17.prod.outlook.com (20.176.125.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2367.20; Wed, 23 Oct 2019 14:54:14 +0000 Received: from DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695]) by DM6PR17MB3162.namprd17.prod.outlook.com ([fe80::20eb:41b7:b275:1695%3]) with mapi id 15.20.2367.022; Wed, 23 Oct 2019 14:54:14 +0000 From: Rob Stradling To: "Salz, Rich" , "trans@ietf.org" CC: "draft-ietf-trans-rfc6962-bis@ietf.org" , Paul Wouters , Mirja Kuehlewind , The IESG , "trans-chairs@ietf.org" Thread-Topic: =?utf-8?B?W1RyYW5zXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1p?= =?utf-8?B?ZXRmLXRyYW5zLXJmYzY5NjItYmlzLTMxOiAod2l0aCBESVNDVVNTIGFuZCBD?= =?utf-8?Q?OMMENT)?= Thread-Index: AQHVibG8QY8WWwsgqECj/APv190WmQ== Date: Wed, 23 Oct 2019 14:54:13 +0000 Message-ID: <26133e7a-b47a-ed38-29e4-68d89b9a5cbf@sectigo.com> References: <2B1C3261-7034-45D9-A70D-EA194C11C5E5@akamai.com> In-Reply-To: <2B1C3261-7034-45D9-A70D-EA194C11C5E5@akamai.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0436.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:e::16) 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: b2e2455d-c579-4664-b74e-08d757c8dead x-ms-traffictypediagnostic: DM6PR17MB3228: x-ms-exchange-purlcount: 10 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 019919A9E4 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(346002)(376002)(136003)(396003)(199004)(189003)(54094003)(51914003)(8936002)(46003)(99286004)(386003)(2616005)(53546011)(446003)(66946007)(110136005)(54906003)(66556008)(64756008)(31696002)(76176011)(224303003)(66476007)(66446008)(14444005)(6506007)(11346002)(486006)(102836004)(14454004)(561944003)(476003)(81156014)(81166006)(2906002)(30864003)(52116002)(186003)(966005)(5660300002)(36756003)(6486002)(256004)(6436002)(229853002)(478600001)(6116002)(6306002)(71200400001)(6512007)(71190400001)(86362001)(316002)(25786009)(6246003)(2501003)(4326008)(305945005)(31686004)(66574012)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM6PR17MB3228; 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: qVSOeYRYhTgCmaNr87LDJf4pGPNhTI2iqSAhjXKjCr9H0UXTRne4I2aJsgbj4OZaDj0gLF5H0M0qA8I+/CUAyUr3ob5KAh3QCkzJVC5mw4/MTH1xHVuNTwNXjKDQX7E9n7o79k8AwxONk6MCI8ehODSNpE0wPT7wdAQVZw4nT/fEtCO/5B44caQkCgBooC68IQrCzZUfzP+XpLngQ2BST6w1tIz6kFZ/WMahNZp+91iTsDeZgEIRCK2IVaBIz4x65ugxr1nq2zHnyEmZRD+MYkIXIbm6DsnMmzvwqoJi352Uxdb+khNcv3PBRy4JP7VjCCbYmsbtRdSpdNkjJHGb0mLYkFuyGBXo0daUVlAfl4uj/l2gwTdpmEX4gU4oXy4EAifAyfRV2tsFiZ82iebNeWq3QJXQh0Idui6V9RNr0dRckjQSclIofXKsL7FkUVFhwmtZKHA0drhYhb1ooHWmyR3ljpbLWikJ5uxr6Y+wFfE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <2F6B8C109F93D04EA02E5DA0A3C7057C@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: b2e2455d-c579-4664-b74e-08d757c8dead X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2019 14:54:13.9565 (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: lCtpkCo/N6sh+DRVPSRqGqdVNAusPxXXTsxsAhyvAOSfPaIieMszcHCSg77zDYehFeEBrnfTAW4zvdy7rLLDLw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR17MB3228 Archived-At: Subject: Re: [Trans] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-trans-rfc6962-bis-31=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 14:54:31 -0000 T24gMjMvMTAvMjAxOSAxMzoyMiwgU2FseiwgUmljaCB3cm90ZToNCj4gSG93IGFib3V0ICJTZXJ2 ZXJzIG1heSB3aXNoIHRvIHNlbmQgYSBSZXRyeS1BZnRlciBoZWFkZXIiID8NCg0KSGkgUmljaC4g IFRoYXQncyBhbHJlYWR5IHRoZXJlLiAgVGhlIGN1cnJlbnQgdGV4dCBpczoNCg0KICAgIENsaWVu dHMgU0hPVUxEIHRyZWF0ICI1MDAgSW50ZXJuYWwgU2VydmVyIEVycm9yIiBhbmQgIjUwMyBTZXJ2 aWNlDQogICAgVW5hdmFpbGFibGUiIHJlc3BvbnNlcyBhcyB0cmFuc2llbnQgZmFpbHVyZXMgYW5k IE1BWSByZXRyeSB0aGUgc2FtZQ0KICAgIHJlcXVlc3Qgd2l0aG91dCBtb2RpZmljYXRpb24gYXQg YSBsYXRlciBkYXRlLiAgTm90ZSB0aGF0IGFzIHBlcg0KICAgIFtSRkM3MjMxXSwgaW4gdGhlIGNh c2Ugb2YgYSA1MDMgcmVzcG9uc2UgdGhlIGxvZyBNQVkgaW5jbHVkZSBhDQogICAgIlJldHJ5LUFm dGVyOiIgaGVhZGVyIGluIG9yZGVyIHRvIHJlcXVlc3QgYSBtaW5pbXVtIHRpbWUgZm9yIHRoZQ0K ICAgIGNsaWVudCB0byB3YWl0IGJlZm9yZSByZXRyeWluZyB0aGUgcmVxdWVzdC4NCg0KTWlyamEg aXMgcmVjb21tZW5kaW5nIHRoYXQgd2UgYWxzbyBzcGVjaWZ5IGluIC1iaXMgYSBkZWZhdWx0IChh bmQgDQpjb21wbGV0ZWx5IGFyYml0cmFyeSkgd2FpdGluZyB0aW1lLCBmb3Igc2l0dWF0aW9ucyB3 aGVyZSB0aGUgbG9nIHNlcnZlciANCmRvZXMgbm90IHNlbmQgYW4gZXhwbGljaXQgIlJldHJ5LUFm dGVyIiBoZWFkZXIuICBEbyB5b3UgaGF2ZSBhIHZpZXcgb24gdGhhdD8NCg0KPiDvu79PbiAxMC8y My8xOSwgNjoxNSBBTSwgIlJvYiBTdHJhZGxpbmciIDxyb2JAc2VjdGlnby5jb20+IHdyb3RlOg0K PiANCj4gICAgICBPbiAyMy8xMC8yMDE5IDEwOjUyLCBNaXJqYSBLdWVobGV3aW5kIHdyb3RlOg0K PiAgICAgID4gSGkgUm9iLA0KPiAgICAgID4NCj4gICAgICA+IEp1c3Qgb25lIG1vcmUgY29tbWVu dCByZWdhcmRpbmcgdGhlIGRlZmF1bHQgZm9yIHRoZSB3YWl0aW5nIHRpbWU6IEkgdW5kZXJzdGFu ZCB0aGF0IGl0IGlzIGFyYml0cmFyeSBidXQgSSBndWVzcyBzb21lb25lIGltcGxlbWVudGluZyBD VCBpbiB0aGUgZmlyc3QgcGxhY2UgaGFzIHRvIG1ha2UgdGhlIHNhbWUgYXJiaXRyYXJ5IGNob2lj ZSBhbmQganVzdCBzZWxlY3Qgc29tZSB2YWx1ZS4gT2YgY291cnNlIHRoaXMgdmFsdWUgc2hvdWxk IGJlIGNvbmZpZ3VyYWJsZSBidXQgcmVjb21tZW5kaW5nIHNvbWUgZGVmYXVsdCBvciBhdCBsZWFz dCBhIHJhbmdlIG9yIG9yZGVyIG9mIHZhbHVlIGNvdWxkIHJlZHVjZSBzdXJwcmlzZXMuIEhvd2V2 ZXIsIHRoaXMgaXMgYSBqdXN0IGEgcmVjb21tZW5kYXRpb24gZnJvbSBtZSBhbmQgaXTigJlzIHlv dXIgY2FsbCENCj4gDQo+ICAgICAgV291bGQgYW55b25lIGVsc2UgbGlrZSB0byBjb21tZW50IG9u IHdoZXRoZXIgdGhleSBhZ3JlZSBvciBkaXNhZ3JlZSB3aXRoDQo+ICAgICAgdGhpcyByZWNvbW1l bmRhdGlvbj8NCj4gDQo+ICAgICAgSWYgeW91IGFncmVlLCB0aGVuIHBsZWFzZSBwcm9wb3NlIGEg ZGVmYXVsdCB3YWl0aW5nIHRpbWUgKGZvciBzaXR1YXRpb25zDQo+ICAgICAgd2hlcmUgdGhlIGxv ZyBzZXJ2ZXIgZG9lcyBub3Qgc2VuZCBhbiBleHBsaWNpdCAiUmV0cnktQWZ0ZXIiIGhlYWRlciku DQo+IA0KPiAgICAgIFRoYW5rcy4NCj4gDQo+ICAgICAgPiBNaXJqYQ0KPiAgICAgID4NCj4gICAg ICA+DQo+ICAgICAgPj4gT24gMTYuIE9jdCAyMDE5LCBhdCAxNTozNiwgUm9iIFN0cmFkbGluZyA8 cm9iQHNlY3RpZ28uY29tPiB3cm90ZToNCj4gICAgICA+Pg0KPiAgICAgID4+IE9uIDE0LzEwLzIw MTkgMTY6MzIsIE1pcmphIEt1ZWhsZXdpbmQgd3JvdGU6DQo+ICAgICAgPj4+IEhpIFJvYiwNCj4g ICAgICA+Pj4NCj4gICAgICA+Pj4gVGhhbmtzIGZvciB5b3VyIHJlcGxpZXMgYW5kIGVkaXRzLiBJ IHdpbGwgY2xlYXIgbXkgZGlzY3VzcyBhcyBzb29uIGFzIHRoZSBuZXcgdmVyc2lvbiBpcyBzdWJt aXR0ZWQuDQo+ICAgICAgPj4NCj4gICAgICA+PiBUaGFua3MgTWlyamEuDQo+ICAgICAgPj4NCj4g ICAgICA+Pj4gUGxlYXNlIHNlZSBzb21lIG1pbm9yIGNvbW1lbnRzIGJlbG93IQ0KPiAgICAgID4+ DQo+ICAgICAgPj4gUmVwbGllcyBpbmxpbmUuDQo+ICAgICAgPj4NCj4gICAgICA+Pj4gVGhhbmtz IQ0KPiAgICAgID4+PiBNaXJqYQ0KPiAgICAgID4+Pg0KPiAgICAgID4+Pg0KPiAgICAgID4+Pj4g T24gMTQuIE9jdCAyMDE5LCBhdCAxNjowNywgUm9iIFN0cmFkbGluZyA8cm9iQHNlY3RpZ28uY29t PiB3cm90ZToNCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiBIaSBNaXJqYS4gIFNvcnJ5IGZvciB0 aGUgbG9vb25nIGRlbGF5Lg0KPiAgICAgID4+Pj4NCj4gICAgICA+Pj4+IENvbW1lbnRzIGlubGlu ZSwgYW5kIEkndmUganVzdCBwb3N0ZWQgdGhpcyBQUjoNCj4gICAgICA+Pj4+IGh0dHBzOi8vZ2l0 aHViLmNvbS9nb29nbGUvY2VydGlmaWNhdGUtdHJhbnNwYXJlbmN5LXJmY3MvcHVsbC8zMTYNCj4g ICAgICA+Pj4+DQo+ICAgICAgPj4+PiBPbiAxNC8wMy8yMDE5IDEzOjUwLCBNaXJqYSBLw7xobGV3 aW5kIHZpYSBEYXRhdHJhY2tlciB3cm90ZToNCj4gICAgICA+Pj4+PiBNaXJqYSBLw7xobGV3aW5k IGhhcyBlbnRlcmVkIHRoZSBmb2xsb3dpbmcgYmFsbG90IHBvc2l0aW9uIGZvcg0KPiAgICAgID4+ Pj4+IGRyYWZ0LWlldGYtdHJhbnMtcmZjNjk2Mi1iaXMtMzE6IERpc2N1c3MNCj4gICAgICA+Pj4+ Pg0KPiAgICAgID4+Pj4+IFBsZWFzZSByZWZlciB0byBodHRwczovL3d3dy5pZXRmLm9yZy9pZXNn L3N0YXRlbWVudC9kaXNjdXNzLWNyaXRlcmlhLmh0bWwNCj4gICAgICA+Pj4+PiBmb3IgbW9yZSBp bmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENPTU1FTlQgcG9zaXRpb25zLg0KPiAg ICAgID4+Pj4+DQo+ICAgICAgPj4+Pj4NCj4gICAgICA+Pj4+PiBUaGUgZG9jdW1lbnQsIGFsb25n IHdpdGggb3RoZXIgYmFsbG90IHBvc2l0aW9ucywgY2FuIGJlIGZvdW5kIGhlcmU6DQo+ICAgICAg Pj4+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10cmFucy1y ZmM2OTYyLWJpcy8NCj4gICAgICA+Pj4+Pg0KPiAgICAgID4+Pj4+DQo+ICAgICAgPj4+Pj4NCj4g ICAgICA+Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgICAgPj4+Pj4gRElTQ1VTUzoNCj4gICAgICA+ Pj4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+ICAgICAgPj4+Pj4NCj4gICAgICA+Pj4+PiBUaGVyZSB3YXMg YSBwcmVzZW50YXRpb24gYXQgbWFwcmcgSUVURiAxMDMgYWJvdXQgdGhlIHF1ZXN0aW9uIGlmIENU IGhlbHBzDQo+ICAgICAgPj4+Pj4gYXR0YWNrZXJzIHRvIGZpbmQgbmV3IGRvbWFpbnMuIEkgdGhp bmsgdGhpcyByaXNrIHNob3VsZCBhdCBsZWFzdCBiZSBtZW50aW9uZWQNCj4gICAgICA+Pj4+PiBp biB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbi4NCj4gICAgICA+Pj4+DQo+ICAg ICAgPj4+PiBBZGRyZXNzZWQgYnkNCj4gICAgICA+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9yb2Jz dHJhZGxpbmcvY2VydGlmaWNhdGUtdHJhbnNwYXJlbmN5LXJmY3MvY29tbWl0LzNiMmVjMGE1MWY4 YWJiNGM4YzBiOTg1NjE0ZmVmYTQyOTE0MzJkZDkNCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+Pj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiAgICAgID4+Pj4+IENPTU1FTlQ6DQo+ICAgICAgPj4+Pj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPiAgICAgID4+Pj4+DQo+ICAgICAgPj4+Pj4gICAxKSBJIGZvdW5kIHNlY3Rpb24g MiBhIGJpdCBoYXJkIHRvIGZvbGxvdy4gV291bGQgaXQgbWF5YmUgYmUgcG9zc2libGUgdG8NCj4g ICAgICA+Pj4+PiAgIHByb3ZpZGUgbW9yZSB0ZXh0dWFsIGV4cGxhbmF0aW9uIG9mIHRoZSBhbGdv cml0aG1zIGluc3RlYWQgb2YganVzdCBkZXNjcmliaW5nDQo+ICAgICAgPj4+Pj4gICB0aGUgc3Rl cHMgb2YgdGhlIGFsZ29yaXRobXM/IEFsc28gSSB3YXMgd29uZGVyaW5nIGhvdyBtdWNoIG11Y2gg dGhlc2UNCj4gICAgICA+Pj4+PiAgIGFsZ29yaXRobXMgYXJlIGFjdHVhbGx5IOKAnnBhcnTigJwg b2YgdGhlIHByb3RvY29sIHNwZWPigKY/IEFyZSBjb3VsZCB0aGVzZSBiZQ0KPiAgICAgID4+Pj4+ ICAgcmF0aGVyIHNlZW4gYXMgZXhhbXBsZSBhbGdvcml0aG1zPyBNYXliZSB0aGF0IGNvdWxkIGJl IGZ1cnRoZXIgY2xhcmlmaWVkDQo+ICAgICAgPj4+Pg0KPiAgICAgID4+Pj4gV2UnbGwgY29uc2lk ZXIgdGhlc2UgY29tbWVudHMgb24gc2VjdGlvbiAyIGF0IGEgbGF0ZXIgZGF0ZSwgYWxvbmcgd2l0 aA0KPiAgICAgID4+Pj4gQmVuamFtaW4gS2FkdWsncyBjb21tZW50cyBvbiBzZWN0aW9uIDIuDQo+ ICAgICAgPj4+Pg0KPiAgICAgID4+Pj4+ICAgMikgUGxlYXNlIGV4cGFuZCBTVEggb24gZmlyc3Qg b2NjdXJyZW5jZSAoaW4gc2VjIDQuMSkNCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiBBZGRyZXNz ZWQgYnkNCj4gICAgICA+Pj4+IGh0dHBzOi8vZ2l0aHViLmNvbS9yb2JzdHJhZGxpbmcvY2VydGlm aWNhdGUtdHJhbnNwYXJlbmN5LXJmY3MvY29tbWl0L2QyZDZiMGFjMzAzYWYyNjU5ZTVkZjUzODM5 MTAwMmYxYmY0NTRlZGINCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+Pj4gICAzKSBTZWMgNC40OiDi gJ5BIGxvZydzIG9wZXJhdG9yIE1VU1QgZWl0aGVyIGFsbG9jYXRlIHRoZSBPSUQNCj4gICAgICA+ Pj4+PiAgICAgIHRoZW1zZWx2ZXMgb3IgcmVxdWVzdCBhbiBPSUQgZnJvbSB0aGUgTG9nIElEIFJl Z2lzdHJ5IChzZWUNCj4gICAgICA+Pj4+PiAgICAgIFNlY3Rpb24gMTAuNi4xKS7igJwNCj4gICAg ICA+Pj4+PiBJc24ndCB0aGVyZSBhbiBvYmxpZ2F0aW9uIHRvIHJlZ2lzdGVyPw0KPiAgICAgID4+ Pj4NCj4gICAgICA+Pj4+IFRoZSBMb2cgSUQgUmVnaXN0cnkgaXMgbWVyZWx5IGEgc291cmNlIG9m IE9JRHMgdGhhdCBoYXZlIHNob3J0IERFUg0KPiAgICAgID4+Pj4gZW5jb2RpbmdzLiAgQSBsb2cg b3BlcmF0b3IgbWF5IGVpdGhlciAoMSkgcmVxdWVzdCBhbiBPSUQgZnJvbSB0aGUgTG9nIElEDQo+ ICAgICAgPj4+PiBSZWdpc3RyeSwgb3IgKDIpIGFsbG9jYXRlIGFuIE9JRCB0aGVtc2VsdmVzIChm cm9tIGFuIE9JRCBhcmMgdGhhdCB0aGV5DQo+ICAgICAgPj4+PiBjb250cm9sLCBuYXR1cmFsbHkp Lg0KPiAgICAgID4+Pj4NCj4gICAgICA+Pj4+IFRoZSBSZWdpc3RyeSBpcyBub3QgaW50ZW5kZWQg dG8gYmUgYSBnbG9iYWwgZGlyZWN0b3J5IG9mIGFsbCBsb2dzLg0KPiAgICAgID4+Pg0KPiAgICAg ID4+PiBDb3VsZCBiZSBnb29kIHRvIGNsYXJpZnkgaW4gdGhlIHRleHQuDQo+ICAgICAgPj4NCj4g ICAgICA+PiBBZGRyZXNzZWQgYnkNCj4gICAgICA+PiBodHRwczovL2dpdGh1Yi5jb20vcm9ic3Ry YWRsaW5nL2NlcnRpZmljYXRlLXRyYW5zcGFyZW5jeS1yZmNzL2NvbW1pdC8xOGJlM2JkYzBlYjNh OGY1Yjk1MDQwMDgxY2NmYWRkY2QyOTI0ZmNiDQo+ICAgICAgPj4NCj4gICAgICA+Pj4+PiAgIDQp IHNlYyA0Ljg6IOKAnklmIGFuDQo+ICAgICAgPj4+Pj4gICAgIGltcGxlbWVudGF0aW9uIHNlZXMg YW4gZXh0ZW5zaW9uIHRoYXQgaXQgZG9lcyBub3QgdW5kZXJzdGFuZCwgaXQNCj4gICAgICA+Pj4+ PiAgICAgU0hPVUxEIGlnbm9yZSB0aGF0IGV4dGVuc2lvbi7igJwNCj4gICAgICA+Pj4+PiBNYXli ZSBpdOKAmXMganVzdCBtZSBiZWNhdXNlIEkgbWF5IGhhdmUgbWlzc2VkIHNvbWUgY29udGV4dCBi dXQgZG9lcyDigJ5pZ25vcmXigJwNCj4gICAgICA+Pj4+PiBtZWFuIGhlcmUgdGhhdCBpdCBzaG91 bGQgbG9nIGl0IG9yIG5vdD8NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiAiSXQiICh0aGUgcHJl Y2VydGlmaWNhdGUgb3IgY2VydGlmaWNhdGUpIG11c3QgaGF2ZSBhbHJlYWR5IGJlZW4gbG9nZ2Vk LA0KPiAgICAgID4+Pj4gYmVjYXVzZSB0aGUgY29ycmVzcG9uZGluZyBTQ1QgKHRoYXQgY29udGFp bnMgYSBwb3RlbnRpYWxseSB1bnJlY29nbml6ZWQNCj4gICAgICA+Pj4+IGV4dGVuc2lvbikgY291 bGRuJ3Qgb3RoZXJ3aXNlIGV4aXN0Lg0KPiAgICAgID4+Pg0KPiAgICAgID4+PiBDb3VsZCBiZSBn b29kIHRvIGNsYXJpZnkgaW4gdGhlIHRleHQuDQo+ICAgICAgPj4NCj4gICAgICA+PiBJIHRoaW5r IG90aGVyIHNlY3Rpb25zIG9mIHRoZSBkb2N1bWVudCBhbHJlYWR5IG1ha2UgaXQgY2xlYXIgdGhh dCBhDQo+ICAgICAgPj4gY2VydGlmaWNhdGUgb3IgcHJlY2VydGlmaWNhdGUgbXVzdCBiZSBzdWJt aXR0ZWQgdG8gKGFuZCBhY2NlcHRlZCBieSkgYQ0KPiAgICAgID4+IGxvZyBiZWZvcmUgYW4gU0NU IHdpbGwgYmUgcHJvZHVjZWQuDQo+ICAgICAgPj4NCj4gICAgICA+PiBTZWN0aW9uIDMgc2F5czoN Cj4gICAgICA+PiAgICAiSWYgYSBsb2cgYWNjZXB0cyBhIHN1Ym1pc3Npb24sIGl0IHdpbGwgcmV0 dXJuIGEgU2lnbmVkIENlcnRpZmljYXRlDQo+ICAgICAgPj4gICAgIFRpbWVzdGFtcCAoU0NUKSIN Cj4gICAgICA+Pg0KPiAgICAgID4+IFNlY3Rpb24gNCBzYXlzOg0KPiAgICAgID4+ICAgICJXaGVu IGl0IHJlY2VpdmVzIGFuZCBhY2NlcHRzIGEgdmFsaWQgc3VibWlzc2lvbiwgdGhlIGxvZyBNVVNU IHJldHVybg0KPiAgICAgID4+ICAgICBhbiBTQ1QgdGhhdCBjb3JyZXNwb25kcyB0byB0aGUgc3Vi bWl0dGVkIGNlcnRpZmljYXRlIG9yDQo+ICAgICAgPj4gICAgIHByZWNlcnRpZmljYXRlLiINCj4g ICAgICA+Pg0KPiAgICAgID4+IEkgdGhpbmsgcmVpdGVyYXRpbmcgdGhpcyBwb2ludCBhZ2FpbiB3 b3VsZCBiZSBib3RoIHVubmVjZXNzYXJ5IGFuZCBvdXQNCj4gICAgICA+PiBvZiBzY29wZSBmb3Ig c2VjdGlvbiA0LjgsIHRoZSBwdXJwb3NlIG9mIHdoaWNoIGlzIHRvIGRlZmluZSB0aGUNCj4gICAg ICA+PiBzdHJ1Y3R1cmUgb2YgYW4gU0NULg0KPiAgICAgID4+DQo+ICAgICAgPj4+Pj4gICA1KSBz ZWMgNTog4oCeTUFZIHJldHJ5IHRoZSBzYW1lDQo+ICAgICAgPj4+Pj4gICAgIHJlcXVlc3Qgd2l0 aG91dCBtb2RpZmljYXRpb24gYXQgYSBsYXRlciBkYXRlLuKAnA0KPiAgICAgID4+Pj4+IFdvdWxk IGl0IGJlIHBvc3NpYmxlIHRvIHByb3ZpZGUgYSByZWNvbW1lbmRhdGlvbiBob3cgbG9uZyB0aGUg Y2xpZW50IHNob3VsZA0KPiAgICAgID4+Pj4+IHdhaXQ/DQo+ICAgICAgPj4+Pg0KPiAgICAgID4+ Pj4gVGhlIHZlcnkgbmV4dCBzZW50ZW5jZSBpbiBzZWN0aW9uIDUgYWxyZWFkeSBzcGVjaWZpZXMg YSBtZWNoYW5pc20gZm9yDQo+ICAgICAgPj4+PiBkb2luZyBqdXN0IHRoYXQ6DQo+ICAgICAgPj4+ PiAgICAnTm90ZSB0aGF0IGFzIHBlcg0KPiAgICAgID4+Pj4gICAgIFtSRkM3MjMxXSwgaW4gdGhl IGNhc2Ugb2YgYSA1MDMgcmVzcG9uc2UgdGhlIGxvZyBNQVkgaW5jbHVkZSBhDQo+ICAgICAgPj4+ PiAgICAgIlJldHJ5LUFmdGVyOiIgaGVhZGVyIGluIG9yZGVyIHRvIHJlcXVlc3QgYSBtaW5pbXVt IHRpbWUgZm9yIHRoZQ0KPiAgICAgID4+Pj4gICAgIGNsaWVudCB0byB3YWl0IGJlZm9yZSByZXRy eWluZyB0aGUgcmVxdWVzdC7igJkNCj4gICAgICA+Pj4NCj4gICAgICA+Pj4gSSBtZWFudCwgd291 bGQgaXQgbWFrZSBzZW5zZSB0byBhY3R1YWxseSBwcm92aWRlIGEgZGVmYXVsdCB2YWx1ZSBvciBz b21ldGhpbmcgZm9yIHRoaXMgd2FpdGluZyB0aW1lPw0KPiAgICAgID4+DQo+ICAgICAgPj4gV2Ug Y291bGQsIGJ1dCBpdCB3b3VsZCBiZSBmYWlybHkgYXJiaXRyYXJ5LiAgU28gd2h5IGJvdGhlcj8N Cj4gICAgICA+Pg0KPiAgICAgID4+IFNvbWUgdHJhbnNpZW50IGZhaWx1cmVzIG1heSBiZSB2ZXJ5 IHNob3J0LWxpdmVkLCBidXQgb3RoZXJzIG1heSBsYXN0IGZvcg0KPiAgICAgID4+IGhvdXJzLiAg T25seSB0aGUgbG9nIG9wZXJhdG9yIGNhbiBwb3NzaWJseSBrbm93IGhvdyBsb25nIGEgY2xpZW50 IHNob3VsZA0KPiAgICAgID4+IHdhaXQgYmVmb3JlIHJldHJ5aW5nIGEgcmVxdWVzdCB3b3VsZCBi ZSBleHBlY3RlZCB0byBzdWNjZWVkLg0KPiAgICAgID4+DQo+ICAgICAgPj4+Pj4gICA2KSBzZWMg NS42OiDigJ5Mb2dzIE1BWSByZXN0cmljdCB0aGUgbnVtYmVyIG9mIGVudHJpZXMgdGhhdCBjYW4g YmUgcmV0cmlldmVkIHBlcg0KPiAgICAgID4+Pj4+ICAgICAiZ2V0LWVudHJpZXMiIHJlcXVlc3Qu 4oCcDQo+ICAgICAgPj4+Pj4gU2hvdWxkIHRoaXMgYmUgYWRkZWQgdG8gc2VjIDQuMT8NCj4gICAg ICA+Pj4+DQo+ICAgICAgPj4+PiBJIGRvbid0IHRoaW5rIHRoYXQncyBhIGdvb2QgaWRlYS4gIEkg Y2FuIGltYWdpbmUgdGhhdCBvcGVyYXRpb25hbCBpc3N1ZXMNCj4gICAgICA+Pj4+IG1pZ2h0IGNh dXNlIGEgbG9nIG9wZXJhdG9yIHRvIHdhbnQgdG8gdmFyeSB0aGlzIHJlc3RyaWN0aW9uIGF0IGFu eSB0aW1lLg0KPiAgICAgID4+Pj4NCj4gICAgICA+Pj4+IENsaWVudHMgc2hvdWxkIGFsd2F5cyBi ZSBwcmVwYXJlZCB0byByZWNlaXZlIGdldC1lbnRyaWVzIHJlc3BvbnNlcyB0aGF0DQo+ICAgICAg Pj4+PiBjb250YWluIGZld2VyIGVudHJpZXMgdGhhbiB0aGV5IHJlcXVlc3RlZC4NCj4gICAgICA+ Pj4+DQo+ICAgICAgPj4+PiBTZWUgYWxzbyBodHRwczovL3RyYWMuaWV0Zi5vcmcvdHJhYy90cmFu cy90aWNrZXQvOTUNCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+Pj4gICA3KSBzZWMgMTAuMzogQ291 bGRu4oCZdCB5b3UgdXNlIHRoZSBUTFMgIFNpZ25hdHVyZVNjaGVtZSBSZWdpc3RyeSBkaXJlY3Rs eQ0KPiAgICAgID4+Pj4+ICAgKGluc3RlYWQgb2YgZm9ybWluZyBhbiBvd24gcmVnaXN0cnkpPw0K PiAgICAgID4+Pj4NCj4gICAgICA+Pj4+IEl0IG1ha2VzIHNlbnNlIHRvIHN5bmNocm9uaXplIHRo ZSBzaWduYXR1cmUgYWxnb3JpdGhtIHZhbHVlcyB3ZSB1c2Ugd2l0aA0KPiAgICAgID4+Pj4gdGhl IFRMUyBTaWduYXR1cmVBbGdvcml0aG0gcmVnaXN0cnksIGJlY2F1c2Ugb3VyIGRhdGEgc3RydWN0 dXJlcyBhcmUNCj4gICAgICA+Pj4+IGRlZmluZWQgYWNjb3JkaW5nIHRvIHRoZSBjb252ZW50aW9u cyBsYWlkIG91dCBpbiB0aGUgVExTIFJGQy4NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiBIb3dl dmVyLCBJIGRvbid0IHRoaW5rIGl0J3MgYSBnb29kIGlkZWEgdG8gdXNlIHRoZSBUTFMNCj4gICAg ICA+Pj4+IFNpZ25hdHVyZUFsZ29yaXRobSByZWdpc3RyeSBkaXJlY3RseS4gIEluIDY5NjItYmlz LCB3ZSd2ZSB0YWtlbiBzdGVwcyB0bw0KPiAgICAgID4+Pj4gbWFrZSBsb2cgYXJ0aWZhY3RzIHNt YWxsZXIgKGNvbXBhcmVkIHRvIFJGQzY5NjIpOyByZWxhdGVkIHRvIHRoYXQsIHdlJ3ZlDQo+ICAg ICAgPj4+PiByZW1vdmVkIHRoZSBvcHRpb24gb2YgbG9ncyBiZWluZyBwZXJtaXR0ZWQgdG8gdXNl IFJTQSBrZXlzL3NpZ25hdHVyZXMuDQo+ICAgICAgPj4+PiBodHRwczovL3d3dy5pYW5hLm9yZy9h c3NpZ25tZW50cy90bHMtcGFyYW1ldGVycy90bHMtcGFyYW1ldGVycy54aHRtbCN0bHMtcGFyYW1l dGVycy0xNg0KPiAgICAgID4+Pj4gcGVybWl0cyBSU0EsIGFuZCBzZXZlcmFsIG90aGVyIHNpZ25h dHVyZSBhbGdvcml0aG1zIHRoYXQgd2UgZG9uJ3Qgd2lzaA0KPiAgICAgID4+Pj4gdG8gcGVybWl0 IG9yIHJlY29tbWVuZCAoaS5lLiAiYW5vbnltb3VzIiwgRFNBLCBHT1NULCBhbmQgIlJlc2VydmVk IGZvcg0KPiAgICAgID4+Pj4gUHJpdmF0ZSBVc2UiKS4NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+ Pj4gICA4KSBzZWMgMTAuNDogaSBXb25kZXIgaWYgYW4gUkZDLXJlcXVpcmVkIHBvbGljeSB3b3Vs ZG7igJl0IGJlIG1vcmUgYXBwcm9wcmlhdGUNCj4gICAgICA+Pj4+PiAgIGZvciB0aGUgVmVyc2lv bmVkVHJhbnNUeXBlcyByZWdpc3RyeT8NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiBJbiA2OTYy LWJpcyBzZWN0aW9uIDEwLjQuMSwgd2UgYXNrIHRoZSBhcHBvaW50ZWQgRXhwZXJ0IHRvICJyZXZp ZXcgdGhlDQo+ICAgICAgPj4+PiBwdWJsaWMgc3BlY2lmaWNhdGlvbiB0byBlbnN1cmUgdGhhdCBp dCBpcyBkZXRhaWxlZCBlbm91Z2ggdG8gZW5zdXJlDQo+ICAgICAgPj4+PiBpbXBsZW1lbnRhdGlv biBpbnRlcm9wZXJhYmlsaXR5Ii4NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiBBRkFJQ1QgZnJv bSBSRkM4MTI2LCAiUkZDIFJlcXVpcmVkIiBkb2Vzbid0IGltcGx5IEV4cGVydCBSZXZpZXcsIHdo ZXJlYXMNCj4gICAgICA+Pj4+ICJTcGVjaWZpY2F0aW9uIFJlcXVpcmVkIiBkb2VzLiAgU28gSSB0 aGluayB3ZSBzaG91bGQgbGVhdmUgaXQgYXMNCj4gICAgICA+Pj4+ICJTcGVjaWZpY2F0aW9uIFJl cXVpcmVk4oCdLg0KPiAgICAgID4+Pg0KPiAgICAgID4+PiBSRkMgUmVxdWlyZWQgaW1wbGllcyB0 aGF0IHRoZSBkb2N1bWVudCBnb3Qgc29tZSByZXZpZXdzIGJhc2VkIG9uIHRoZSByZXNwZWN0aXZl IHByb2Nlc3MuDQo+ICAgICAgPj4+DQo+ICAgICAgPj4+IEhvd2V2ZXIsIEkgZ3Vlc3MgSSBhY3R1 YWxseSB3YW50ZWQgdG8gcHJvcG9zZSBJRVRGIFJldmlldyAoYW5kIHVzZWQgdGhlIHdyb25nIHRl cm0pLiBUaGF0IHdvdWxkIGltcGx5IHRoYXQgaXQgaGFkIHRvIGdvIHRocm91Z2ggdGhlIElFVEYg cHJvY2VzcyB3aXRoIHJlc3BlY3RpdmUgcmV2aWV3IChhbmQgdGhlcmVmb3JlIHVzdWFsbHkgaXQg aXMgZXhwZWN0ZWQgdGhhdCBubyBleHBlcnQgcmV2aWV3IGlzIG5lZWRlZCBpbiBhZGRpdGlvbiku IEFueXdheSB0aGlzIHdhcyBtYWlubHkgYSBjb21tZW50IHRvIGRvdWJsZS1jaGVjayB0aGlzIGRl Y2lzaW9uLg0KPiAgICAgID4+DQo+ICAgICAgPj4gSSBwZXJzb25hbGx5IGRvbid0IGhhdmUgYSBw cmVmZXJlbmNlLCBidXQgSSdsbCBzdGFydCBhbm90aGVyIGxpc3QgdGhyZWFkDQo+ICAgICAgPj4g dG8gZGlzY3VzcyB0aGlzIHByb3Bvc2FsLg0KPiAgICAgID4+DQo+ICAgICAgPj4+Pj4gICA5KSBz ZWMgMTAuNi4xOkkgZ3Vlc3MgIHRoZSByZWdpc3RyYXRpb24gcG9saWN5IGlzIEZDRlM/IFJGQyA4 MTI2IHJlY29tbWVuZCB0bw0KPiAgICAgID4+Pj4+ICAgYWx3YXlzIChjbGVhcmx5KSBuYW1lIHRo ZSByZWdpc3RyeS4NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiBUaGFua3MuICBJbiBvdXIgcmVz cG9uc2UgdG8gQWxpc3NhIENvb3BlcidzIERJU0NVU1MvQ09NTUVOVHMgKHNlZQ0KPiAgICAgID4+ Pj4gaHR0cHM6Ly9naXRodWIuY29tL2dvb2dsZS9jZXJ0aWZpY2F0ZS10cmFuc3BhcmVuY3ktcmZj cy9wdWxsLzMwOSksIHdlJ3ZlDQo+ICAgICAgPj4+PiBhbHJlYWR5IGNsYXJpZmllZCB0aGF0IHRo ZSBMb2cgSUQgUmVnaXN0cnkgaXMgaW5kZWVkIEZpcnN0IENvbWUgRmlyc3QNCj4gICAgICA+Pj4+ IFNlcnZlZC4NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+Pj4gQW5kIGZpbmFsbHkgb25lIGhpZ2hl ciBsZXZlbCBxdWVzdGlvbiBtYWlubHkgb3V0IG9mIGN1cmlvc2l0eTogd2FzIGl0DQo+ICAgICAg Pj4+Pj4gY29uc2lkZXJlZCB0byBlLmcuIHVzZSBqc29uIGZvciBhbGwgZGF0YSBzdHJ1Y3R1cmVz PyBJcyB0aGVyZSBhIHBlcmZvcm1hbmNlDQo+ICAgICAgPj4+Pj4gcmVhc29uIHRvIG5vdCBkbyB0 aGF0IG9yIHdhc27igJl0IHRoYXQgZXZlbiBkaXNjdXNzZWQ/DQo+ICAgICAgPj4+Pg0KPiAgICAg ID4+Pj4gUGxlYXNlIGRvbid0IHJlc3RhcnQgdGhlIGZvcm1hdCB3YXJzLiAgOy0pDQo+ICAgICAg Pj4+DQo+ICAgICAgPj4+IERpZG7igJl0IGtub3cgdGhhdOKApg0KPiAgICAgID4+Pg0KPiAgICAg ID4+Pj4NCj4gICAgICA+Pj4+IFdlIG11c3QgdXNlIEFTTi4xIGZvciBhbGwgZGF0YSBzdHJ1Y3R1 cmVzLCBiZWNhdXNlIFguNTA5IGNlcnRpZmljYXRlcw0KPiAgICAgID4+Pj4gYXJlIGludm9sdmVk LiAgQnV0IHdlIG11c3QgdXNlICJUTFMgZW5jb2RpbmciIGZvciBhbGwgZGF0YSBzdHJ1Y3R1cmVz LA0KPiAgICAgID4+Pj4gYmVjYXVzZSBUTFMgaXMgaW52b2x2ZWQuICBCdXQgd2UgbXVzdCB1c2Ug SlNPTiBmb3IgYWxsIGRhdGEgc3RydWN0dXJlcywNCj4gICAgICA+Pj4+IGJlY2F1c2UgSlNPTiBp cyBtb3JlIEFQSS1mcmllbmRseS4NCj4gICAgICA+Pj4+DQo+ICAgICAgPj4+PiBJdCB3YXMgaW1w b3NzaWJsZSB0byBwbGVhc2UgZXZlcnlvbmUuICBXZSBoYWQgdG8gY2hvb3NlIHNvbWV0aGluZywg c28gd2UNCj4gICAgICA+Pj4+IGNob3NlIFRMUyBlbmNvZGluZyBmb3IgdGhlIGRhdGEgc3RydWN0 dXJlcywgYW5kIEpTT04gZm9yIHRoZSBBUElzLg0KPiAgICAgID4+Pj4NCj4gICAgICA+Pj4+IEFz IEkgbWVudGlvbmVkIGVhcmxpZXIsIG9uZSBnb2FsIG9mIDY5NjItYmlzIGlzIHRvIG1ha2UgbG9n IGFydGlmYWN0cw0KPiAgICAgID4+Pj4gc21hbGxlci4gIFRMUyBlbmNvZGluZyBpcyBtb3JlIHN1 aXRlZCB0byB0aGlzIHRoYW4gSlNPTi4NCj4gICAgICA+Pj4NCj4gICAgICA+Pj4gT2theSB0aGFu a3MgZm9yIHRoZSBiYWNrZ3JvdW5kIGluZm8uIEFzIGxvbmcgYXMgdGhpcyB3YXMgZGlzY3Vzc2Vk IHRoYXQncyBmaW5lIQ0KPiAgICAgID4+DQo+ICAgICAgPj4gLS0NCj4gICAgICA+PiBSb2IgU3Ry YWRsaW5nDQo+ICAgICAgPj4gU2VuaW9yIFJlc2VhcmNoICYgRGV2ZWxvcG1lbnQgU2NpZW50aXN0 DQo+ICAgICAgPj4gU2VjdGlnbyBMaW1pdGVkDQo+ICAgICAgPj4NCj4gICAgICA+DQo+IA0KPiAg ICAgIC0tDQo+ICAgICAgUm9iIFN0cmFkbGluZw0KPiAgICAgIFNlbmlvciBSZXNlYXJjaCAmIERl dmVsb3BtZW50IFNjaWVudGlzdA0KPiAgICAgIEVtYWlsOiByb2JAc2VjdGlnby5jb20NCj4gICAg ICBCcmFkZm9yZCwgVUsNCj4gICAgICBPZmZpY2U6ICs0NDEyNzQwMjQ3MDcNCj4gICAgICBTZWN0 aWdvIExpbWl0ZWQNCj4gDQo+ICAgICAgVGhpcyBtZXNzYWdlIGFuZCBhbnkgZmlsZXMgYXNzb2Np YXRlZCB3aXRoIGl0IG1heSBjb250YWluIGxlZ2FsbHkNCj4gICAgICBwcml2aWxlZ2VkLCBjb25m aWRlbnRpYWwsIG9yIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5vdCB0aGUN Cj4gICAgICBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90IHBlcm1pdHRlZCB0byB1c2Us IGNvcHksIG9yIGZvcndhcmQgaXQsDQo+ICAgICAgaW4gd2hvbGUgb3IgaW4gcGFydCB3aXRob3V0 IHRoZSBleHByZXNzIGNvbnNlbnQgb2YgdGhlIHNlbmRlci4gUGxlYXNlDQo+ICAgICAgbm90aWZ5 IHRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwsIGRpc3JlZ2FyZCB0aGUgZm9yZWdvaW5nIG1lc3Nh Z2VzLCBhbmQNCj4gICAgICBkZWxldGUgaXQgaW1tZWRpYXRlbHkuDQo+ICAgICAgX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICAgICBUcmFucyBtYWls aW5nIGxpc3QNCj4gICAgICBUcmFuc0BpZXRmLm9yZw0KPiAgICAgIGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdHJhbnMNCj4gDQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBUcmFucyBtYWlsaW5nIGxpc3QNCj4gVHJh bnNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90cmFu cw0KPiANCg0KLS0gDQpSb2IgU3RyYWRsaW5nDQpTZW5pb3IgUmVzZWFyY2ggJiBEZXZlbG9wbWVu dCBTY2llbnRpc3QNCkVtYWlsOiByb2JAc2VjdGlnby5jb20NCkJyYWRmb3JkLCBVSw0KT2ZmaWNl OiArNDQxMjc0MDI0NzA3DQpTZWN0aWdvIExpbWl0ZWQNCg0KVGhpcyBtZXNzYWdlIGFuZCBhbnkg ZmlsZXMgYXNzb2NpYXRlZCB3aXRoIGl0IG1heSBjb250YWluIGxlZ2FsbHkgDQpwcml2aWxlZ2Vk LCBjb25maWRlbnRpYWwsIG9yIHByb3ByaWV0YXJ5IGluZm9ybWF0aW9uLiBJZiB5b3UgYXJlIG5v dCB0aGUgDQppbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgbm90IHBlcm1pdHRlZCB0byB1c2Us IGNvcHksIG9yIGZvcndhcmQgaXQsIA0KaW4gd2hvbGUgb3IgaW4gcGFydCB3aXRob3V0IHRoZSBl eHByZXNzIGNvbnNlbnQgb2YgdGhlIHNlbmRlci4gUGxlYXNlIA0Kbm90aWZ5IHRoZSBzZW5kZXIg YnkgcmVwbHkgZW1haWwsIGRpc3JlZ2FyZCB0aGUgZm9yZWdvaW5nIG1lc3NhZ2VzLCBhbmQgDQpk ZWxldGUgaXQgaW1tZWRpYXRlbHkuDQo= From nobody Wed Oct 23 08:16:27 2019 Return-Path: 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 8896B12083E; Wed, 23 Oct 2019 08:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 GKqF6fWI0mf4; Wed, 23 Oct 2019 08:16:23 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [67.231.157.127]) (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 AB836120823; Wed, 23 Oct 2019 08:16:23 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x9NF8In8002404; Wed, 23 Oct 2019 16:15:22 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=Q+TKmD/PQopm5YR2cmrP5y9icpZJR1pHck3hiS4n3MY=; b=SzKIR2dIfAiw5ayIfXgSQJsHS1NdJQNcy4sHbuqVKtxSwOmeyZEuihBPdE0HAMoABoAN 4Tta3kH6o5Owqmx2kCRu1d8NFtudGrysaCsY55WT0DNA/pnbtVIP7geNZm3E0EyXXd8E QDWQLFLZ2MrxM0c/GDNFQbnO5NhmvXB79Ah6EjGfWm+GKTNdh3VtFT3fVNPkNsoHD9Bm qYlPwVczX2mM6wZjoukY9DFFRDspx+tlCT7pz/5c9Mpqh5Nu+JNV2ZtY/Ruz7cpYdtBl qdK65rCqiBDaTbPc03XLAjTp0vasegD8jemfM8xrZ3Qeead4ZglA6aCAguzl7puMt5Bu 6Q== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2vsrvpq2wu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 23 Oct 2019 16:15:22 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x9NF2Gah028847; Wed, 23 Oct 2019 11:15:21 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2vqwtwj44d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 23 Oct 2019 11:15:21 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 23 Oct 2019 11:15:20 -0400 Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1473.005; Wed, 23 Oct 2019 11:15:20 -0400 From: "Salz, Rich" To: Rob Stradling , "trans@ietf.org" CC: "draft-ietf-trans-rfc6962-bis@ietf.org" , Paul Wouters , "Mirja Kuehlewind" , The IESG , "trans-chairs@ietf.org" Thread-Topic: =?utf-8?B?W1RyYW5zXSBNaXJqYSBLw7xobGV3aW5kJ3MgRGlzY3VzcyBvbiBkcmFmdC1p?= =?utf-8?B?ZXRmLXRyYW5zLXJmYzY5NjItYmlzLTMxOiAod2l0aCBESVNDVVNTIGFuZCBD?= =?utf-8?Q?OMMENT)?= Thread-Index: AQHVibHFktURBy7Al0KOX7a9wZdzN6doVfmA Date: Wed, 23 Oct 2019 15:15:19 +0000 Message-ID: <6389E75F-4354-433C-809A-858869616283@akamai.com> References: <2B1C3261-7034-45D9-A70D-EA194C11C5E5@akamai.com> <26133e7a-b47a-ed38-29e4-68d89b9a5cbf@sectigo.com> In-Reply-To: <26133e7a-b47a-ed38-29e4-68d89b9a5cbf@sectigo.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.39] Content-Type: text/plain; charset="utf-8" Content-ID: <70B207AFF3794C4C8F7E088FD6585685@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-23_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=995 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910230152 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-23_04:2019-10-23,2019-10-23 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 lowpriorityscore=0 mlxlogscore=978 adultscore=0 bulkscore=0 phishscore=0 spamscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 mlxscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910230153 Archived-At: Subject: Re: [Trans] =?utf-8?q?Mirja_K=C3=BChlewind=27s_Discuss_on_draft-ietf?= =?utf-8?q?-trans-rfc6962-bis-31=3A_=28with_DISCUSS_and_COMMENT=29?= X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Oct 2019 15:16:26 -0000 PiAgICAgICAgcmVxdWVzdCB3aXRob3V0IG1vZGlmaWNhdGlvbiBhdCBhIGxhdGVyIGRhdGUuICBO b3RlIHRoYXQgYXMgcGVyDQogICAgICAgIFtSRkM3MjMxXSwgaW4gdGhlIGNhc2Ugb2YgYSA1MDMg cmVzcG9uc2UgdGhlIGxvZyBNQVkgaW5jbHVkZSBhDQogICAgICAgICJSZXRyeS1BZnRlcjoiIGhl YWRlciBpbiBvcmRlciB0byByZXF1ZXN0IGEgbWluaW11bSB0aW1lIGZvciB0aGUNCiAgICAgICAg Y2xpZW50IHRvIHdhaXQgYmVmb3JlIHJldHJ5aW5nIHRoZSByZXF1ZXN0Lg0KICANClNvcnJ5IGNh Y2hlLW1pc3MgOikNCiAgDQo+ICAgIE1pcmphIGlzIHJlY29tbWVuZGluZyB0aGF0IHdlIGFsc28g c3BlY2lmeSBpbiAtYmlzIGEgZGVmYXVsdCAoYW5kIA0KICAgIGNvbXBsZXRlbHkgYXJiaXRyYXJ5 KSB3YWl0aW5nIHRpbWUsIGZvciBzaXR1YXRpb25zIHdoZXJlIHRoZSBsb2cgc2VydmVyIA0KICAg IGRvZXMgbm90IHNlbmQgYW4gZXhwbGljaXQgIlJldHJ5LUFmdGVyIiBoZWFkZXIuICBEbyB5b3Ug aGF2ZSBhIHZpZXcgb24gdGhhdD8NCiAgDQpJIGFtIG9wcG9zZWQgdG8gdGhpcyBjaGFuZ2UuDQoN Cg0K