From nobody Mon Jul 1 12:37: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 C077E120177 for ; Mon, 1 Jul 2019 12:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name 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 mRNL6Ifey4lR for ; Mon, 1 Jul 2019 12:37:04 -0700 (PDT) Received: from thomson.beanwood.com (thomson.beanwood.com [IPv6:2600:1f16:719:be00:5c48:f083:d884:d130]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AC9D120170 for ; Mon, 1 Jul 2019 12:37:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1562009823; bh=Sy5sjN6+FYQWc9bM4kvIWp10T4wifu2IDYAlCqxnI8U=; h=Date:From:To:Subject:In-Reply-To:References; b=n/2Mqjm3H8NJAFb/SPwey/XrbISZbfxCqXc9YWlYP4kbhqZxI2gLQ96VDZdLENkoN bncQ9k8SLrsFGi0pGNkbENIB8MFlE9MPsmJxGPDNp0L0nAQWL5Zardnj2Nxvf/80Nr aWKXxllclweV3N/WVk2w3CCAg3TK8+lfQgbCfkNleepkVjgSId9ObNRvjBOw1MZn8x RjVLH8ivu1h6icH19D5Y4jXqNVNzdBhQ+OFjPyrfy7WWbLPNIYeNyjIs8+bi7jw9co bH/jwjLxJ5W6WGKTXeiyT38KmFGDElENVmau5bHii/DF85KXUHYHhKsV6x9EZnbmSg CTt6P6yMPncfA== Date: Mon, 1 Jul 2019 12:37:01 -0700 From: Andrew Ayer To: "trans@ietf.org" Message-Id: <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> In-Reply-To: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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, 01 Jul 2019 19:37:06 -0000 I also think .well-known URLs are a bad idea, for the same reasons as Jacob. I think directories are even worse. Although they've been used successfully in ACME, CT has different needs which make directories unsuitable. ACME's usage pattern is to make a series of related requests over a short time period to drive a certificate request to issuance, with the client maintaining state between each request. This makes it natural for a client to fetch the directory once at the beginning of an issuance "session" and use it for the duration, since the cost of fetching the directory is amortized over all the requests, and the directory is unlikely to become invalid during the session. However, CT's usage pattern is to make a lot of unrelated one-off requests spread over a long period of time - e.g. submitting a (pre)certificate, fetching an inclusion proof, fetching the latest STH to send to auditors. Clients would have to either fetch a new directory for every request (doubling the number of requests made to the log) or cache directories in long-term state (which requires dealing with cached directories going stale, and requires keeping long-term state which might not otherwise be necessary). ACME's use of directories is underspecified since it doesn't say how long a directory remains valid. It's not a big deal for ACME because ACME servers are presumed to be sane, or people would switch to another CA. However, CT is meant to be an adversarial protocol and has to anticipate logs doing crazy things like constantly changing their directory in an effort to stymie auditing and hide misbehavior. Thus, CT's use of directories would need to be quite well specified. It is not a change that should be rushed at the last minute without a chance for people to carefully examine and poke holes in it. CT clients already need to be configured with a number of parameters for each log - MMD, hash algorithm, public key, log ID, and so on. Adding a directory would bifurcate log metadata between the existing parameter set and the new directory object. I propose satisfying BCP 190 by simply specifying the URL for each endpoint as a separate log parameter. This is a very minimal change to the protocol and avoids the problems above. Regards, Andrew From nobody Tue Jul 2 06:18: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 A581412022A for ; Tue, 2 Jul 2019 06:18:00 -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, 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 (1024-bit key) header.d=primekey.com header.b=BE5z5v5y; dkim=pass (1024-bit key) header.d=primekey.com header.b=BE5z5v5y 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 BcZyiWDF1RuR for ; Tue, 2 Jul 2019 06:17:58 -0700 (PDT) Received: from mail.primekey.com (mail.primekey.com [84.55.121.163]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E3B1201ED for ; Tue, 2 Jul 2019 06:17:57 -0700 (PDT) Received: from mail.primekey.com (localhost [127.0.0.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPS id C22C56AA0082 for ; Tue, 2 Jul 2019 15:17:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1562073469; bh=HhqwaeUriuNXeghxwGxtdMKuskVJi57KzYPy5iZGx1Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BE5z5v5yk7arAzllnyhNEww7uEe0+8/zGCEDtbyCrRXUSKGHV2XHzGgoTmu5ZgHeF K6jYXm0JwbwkwOrYIMVGeJEF5OFpaNwBbGFD94Pi88YgRFgazZgTZz42iHUyhyiQm7 csHuXy8TxQXcJ1ipYs1a0xpla1FxGnluHcyvmzJU= Received: from [192.168.1.101] (c-b21f4f25-74736162.cust.telenor.se [178.31.79.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.primekey.com (Postfix) with ESMTPSA id 97F006AA006D for ; Tue, 2 Jul 2019 15:17:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=primekey.com; s=mail; t=1562073469; bh=HhqwaeUriuNXeghxwGxtdMKuskVJi57KzYPy5iZGx1Y=; h=Subject:To:References:From:Date:In-Reply-To:From; b=BE5z5v5yk7arAzllnyhNEww7uEe0+8/zGCEDtbyCrRXUSKGHV2XHzGgoTmu5ZgHeF K6jYXm0JwbwkwOrYIMVGeJEF5OFpaNwBbGFD94Pi88YgRFgazZgTZz42iHUyhyiQm7 csHuXy8TxQXcJ1ipYs1a0xpla1FxGnluHcyvmzJU= To: trans@ietf.org References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> From: Tomas Gustavsson Openpgp: preference=signencrypt Autocrypt: addr=tomas.gustavsson@primekey.com; prefer-encrypt=mutual; keydata= mQENBEyuwwYBCAD31Jsxn1lf7rnFc7y3Ol+TE7pU7ohO78kMdoVrZdAMnU9W0P33GedbU+kF 8/RFq7HlXV8a91RkgtdcMAK8tSdtBKDGZCOJZm5qOZ/EHikY8k/7s1wgSQSF4hYSG/IABCCA W139joDFl4L3buWyk2lsYX1HDBpuXGDL5HFyu165T0ZVlt23T04xmAwpIHUViKUWw1QYnlRz s66Desn2WeP+X8/QlqF1zOTUXbgrThB1X/Oh2+wzP08HVoTQCzlrEMeb9x2k+oa8PtVdnflh nZKBtyyBkZxRoHG3tNKcaf7JLoadSXcSKSKvfApcsxpP2JpkQgIhLi3JWik/Z+RR2WD1ABEB AAG0MFRvbWFzIEd1c3RhdnNzb24gPHRvbWFzLmd1c3RhdnNzb25AcHJpbWVrZXkuY29tPokB NwQTAQgAIQUCWX8yTAIbIwULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBibcSbAEP+QGAU CAC82dn8XCQ8Ei7gxQAdRSc2imaP/388i/ObDMYhNhg5j4gXs3tkfxuCvhwkzskUFgOtmaEy uz/gIiVjQIsjQrHh5tl9M0q2tqbDHJpWfE6/SkXPUmTqQ0VGyq1MmZ3/zg2jSoll74qBSfdH V7sWugRXeCBxfaPeYo8DdPCGi27yrdL8zb3xkJ3BxPcDGNdkLm+Yza+qAOrssCD7MSLN+6Sd ML5Xcmw6pgRPlQ0aCsM7scrwgBNb7KrwxaqBxqwcuqF0NMgNjeiEHi2Oj3HOZdYU4Blk2GFq 9zHuCzTWumgNOlfksZ9K3ZMJBn6KLPot5bVXIKdnHwWRzoKMDxkSZjM5uQENBEyuwwYBCADZ 98eCFQ64zKo1OKkUgEJHO1JdsiqRO1znu6KyaTcd2vXfOCGkFFVBL+vjzzyyYV7Sg1/AaG4r l9TKJCwvx8mUmTJkKQspTfOj6AY33bmfMB/8LBYj2BjtxXyMucPjNTJqbL2r1HeGPV2nwyof MAyo2qcYuiLs20Ob7U8vooOV3GDDKEkXtJYZzTEU6qabGsepGIvMu770OZwvm4akQiCGe5sQ 4+/UH1pMZQNi+/fGbONFx+TUVMM8EkXD6dQ5WoL+xPabPjqiUmR7EBvg0uocr70Ag93tWk1d 4RgFcicjwMFcPg4TZ8Y/3Y7Nmbyo14+4SMNfNPFLgQMawL+cLLkdABEBAAGJAR8EGAECAAkC GwwFAlYXhXUACgkQYm3EmwBD/kA2igf/QNpPe7sLt3KdRD3x4cStxGjLCWyj7x1YLVnV4Nnu TvaNhC+KHx3uG39y1x3PJQwslpeSQ6JipOUmxeQjjGJGQZLV41L1PCJVhCL98Dinr6dJkYB7 cAVhfmW8PI51jiANExLZu8U5gnthj5CGv4428ODQgSoRI0demG3HmVCNrKdap+orhT8zRkq8 DuHTO01U7PKsfvQ2k8AqSAC/JjMOs1mpFe032IApXxlZkE+33Q3dE5BiJmICYg8hsRXvpKTm ZMCdNZJUQLq+XNpg6RtAPQIPMmCepXrE9M/KuH+jFS2G5+Hx5VBSM644E1G2i+HOPCVdHjof iaNi3V/ItEG3jw== Message-ID: <232ef21a-7833-e8d2-b24e-4732611eedee@primekey.com> Date: Tue, 2 Jul 2019 15:17:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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: Tue, 02 Jul 2019 13:18:01 -0000 +1 for not liking .well-known URIs. From an implementor, .well-known URIs have been hard, probably badly designed (i.e. RFC 7030), simply making multi-tenancy, or multi-configuration hard by enforcing a single end-point for each FQDN. We're actually bypassing .well-known, making it possible to use normal URLs instead in some cases (in addition to the specified and limited .well-known of course) Agree with Andrew, with CT where you need to get and configure parameters from the log anyhow, and getting the URL as part of that is the most flexible way. This allows the server operator/implementor full freedom in their architecture, load balancing, etc. Regards, Tomas On 2019-07-01 21:37, Andrew Ayer wrote: > I also think .well-known URLs are a bad idea, for the same reasons > as Jacob. > > I think directories are even worse. Although they've been used > successfully in ACME, CT has different needs which make directories > unsuitable. ACME's usage pattern is to make a series of related > requests over a short time period to drive a certificate request to > issuance, with the client maintaining state between each request. > This makes it natural for a client to fetch the directory once at the > beginning of an issuance "session" and use it for the duration, since > the cost of fetching the directory is amortized over all the requests, > and the directory is unlikely to become invalid during the session. > > However, CT's usage pattern is to make a lot of unrelated one-off > requests spread over a long period of time - e.g. submitting a > (pre)certificate, fetching an inclusion proof, fetching the latest STH > to send to auditors. Clients would have to either fetch a new directory > for every request (doubling the number of requests made to the log) or > cache directories in long-term state (which requires dealing with > cached directories going stale, and requires keeping long-term state > which might not otherwise be necessary). > > ACME's use of directories is underspecified since it doesn't say how > long a directory remains valid. It's not a big deal for ACME because > ACME servers are presumed to be sane, or people would switch to another > CA. However, CT is meant to be an adversarial protocol and has to > anticipate logs doing crazy things like constantly changing their > directory in an effort to stymie auditing and hide misbehavior. > > Thus, CT's use of directories would need to be quite well specified. > It is not a change that should be rushed at the last minute without a > chance for people to carefully examine and poke holes in it. > > CT clients already need to be configured with a number of parameters > for each log - MMD, hash algorithm, public key, log ID, and so on. > Adding a directory would bifurcate log metadata between the existing > parameter set and the new directory object. > > I propose satisfying BCP 190 by simply specifying the URL for each > endpoint as a separate log parameter. This is a very minimal change to > the protocol and avoids the problems above. > > Regards, > Andrew > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > From nobody Tue Jul 2 08:08:05 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 39B7412011A for ; Tue, 2 Jul 2019 08:08:04 -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 USH8ypINzJ-d for ; Tue, 2 Jul 2019 08:08:00 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-eopbgr750075.outbound.protection.outlook.com [40.107.75.75]) (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 8342F120118 for ; Tue, 2 Jul 2019 08:08:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-comodoca-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KjouB+YlReuMysCCd4IIlQ56eEm/tHc9Ge2LVUuNc+c=; b=jJb4aNyBN/MrE0eBeehNDTFpylJbqypDlFqnJluAYdNVlmFoHIdGvu0bSmhvew3btrXepLw9PlexpLcYRq2gpBbEVejx5qTLMpY7bxFZ3l4vN3oY2bIsOOdZJ1VuuCeOUckeR7mCFiUO5yKe0MNJAp/AIcjn8QuU5umvQXeVT5U= Received: from DM5PR17MB1211.namprd17.prod.outlook.com (10.173.132.148) by DM5PR17MB1980.namprd17.prod.outlook.com (10.173.129.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Tue, 2 Jul 2019 15:07:57 +0000 Received: from DM5PR17MB1211.namprd17.prod.outlook.com ([fe80::b556:345c:94cf:7258]) by DM5PR17MB1211.namprd17.prod.outlook.com ([fe80::b556:345c:94cf:7258%6]) with mapi id 15.20.2032.019; Tue, 2 Jul 2019 15:07:57 +0000 From: Rob Stradling To: Andrew Ayer , "trans@ietf.org" Thread-Topic: [Trans] Directory instead of .well-known for URL structure Thread-Index: AQHVJ7g3xV77fgqjj0ive+Voenofmqa2OUSAgAFHIIA= Date: Tue, 2 Jul 2019 15:07:57 +0000 Message-ID: <2cbff182-7c7a-4c55-b2d2-a67f41dd7436@sectigo.com> References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> In-Reply-To: <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LNXP265CA0059.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5d::23) To DM5PR17MB1211.namprd17.prod.outlook.com (2603:10b6:3:8b::20) 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: d0fa041d-05a5-4417-4742-08d6feff10bd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR17MB1980; x-ms-traffictypediagnostic: DM5PR17MB1980: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 008663486A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(136003)(396003)(39850400004)(199004)(189003)(110136005)(25786009)(53546011)(478600001)(76176011)(102836004)(5660300002)(6306002)(6512007)(99286004)(386003)(316002)(66476007)(6506007)(68736007)(6486002)(66446008)(66556008)(64756008)(6436002)(73956011)(31686004)(229853002)(6246003)(52116002)(46003)(66946007)(476003)(486006)(446003)(11346002)(2616005)(305945005)(7736002)(81166006)(966005)(14454004)(2501003)(2906002)(36756003)(81156014)(31696002)(6116002)(14444005)(186003)(71190400001)(53936002)(8936002)(86362001)(71200400001)(256004)(8676002)(142923001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR17MB1980; H:DM5PR17MB1211.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: jvQTIViKY/gse1nIXas6TtEAo7rUYpwjRlfPg0qJN3Tp8WL4/+Ltmn0KtP5LXBlpgUWtd3UPfu60BSxl4UTzzGdIrUnzL98C21o7ASwqH9MjqfhHoVHhGoFzjmvV6xky8avsKl8C2Ch5wKvkO7B0eKV7gVK3ZmGzDdSk4MEUmBS/Whk+RsHjod8dHXuNlPAQnBCxafBKIh6TEvdRKByPlH8nx8wbg08iT+5xrVYI8vWhsU8q+XrtZW+OccPyGBV0yWBES8bRldmwPkvP+BnysACS6SfE/J0RL/E8oam+F3W3fQs2yiT7CYC6vKet1m6JTsyJ01pYDcQT05fEIb6HQll6HUuZbvyCoyrcmf7TkmEbELbqJfaVx/tGX27o1/84a19J3syjW5MWI6AIApaZYoOQ/huIgflEpNAhsBC1jCg= Content-Type: text/plain; charset="utf-8" Content-ID: <729F9365550CCF47BB8EB988EAE5D1DF@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: d0fa041d-05a5-4417-4742-08d6feff10bd X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Jul 2019 15:07:57.5823 (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: robs@comodoca.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR17MB1980 Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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: Tue, 02 Jul 2019 15:08:04 -0000 QW5kcmV3LCB0aGFua3MgZm9yIHlvdXIgYW5hbHlzaXMuICBDb21tZW50cyBpbmxpbmUuLi4NCg0K T24gMDEvMDcvMjAxOSAyMDozNywgQW5kcmV3IEF5ZXIgd3JvdGU6DQo+IEkgYWxzbyB0aGluayAu d2VsbC1rbm93biBVUkxzIGFyZSBhIGJhZCBpZGVhLCBmb3IgdGhlIHNhbWUgcmVhc29ucw0KPiBh cyBKYWNvYi4NCj4gDQo+IEkgdGhpbmsgZGlyZWN0b3JpZXMgYXJlIGV2ZW4gd29yc2UuICBBbHRo b3VnaCB0aGV5J3ZlIGJlZW4gdXNlZA0KPiBzdWNjZXNzZnVsbHkgaW4gQUNNRSwgQ1QgaGFzIGRp ZmZlcmVudCBuZWVkcyB3aGljaCBtYWtlIGRpcmVjdG9yaWVzDQo+IHVuc3VpdGFibGUuICBBQ01F J3MgdXNhZ2UgcGF0dGVybiBpcyB0byBtYWtlIGEgc2VyaWVzIG9mIHJlbGF0ZWQNCj4gcmVxdWVz dHMgb3ZlciBhIHNob3J0IHRpbWUgcGVyaW9kIHRvIGRyaXZlIGEgY2VydGlmaWNhdGUgcmVxdWVz dCB0bw0KPiBpc3N1YW5jZSwgd2l0aCB0aGUgY2xpZW50IG1haW50YWluaW5nIHN0YXRlIGJldHdl ZW4gZWFjaCByZXF1ZXN0Lg0KPiBUaGlzIG1ha2VzIGl0IG5hdHVyYWwgZm9yIGEgY2xpZW50IHRv IGZldGNoIHRoZSBkaXJlY3Rvcnkgb25jZSBhdCB0aGUNCj4gYmVnaW5uaW5nIG9mIGFuIGlzc3Vh bmNlICJzZXNzaW9uIiBhbmQgdXNlIGl0IGZvciB0aGUgZHVyYXRpb24sIHNpbmNlDQo+IHRoZSBj b3N0IG9mIGZldGNoaW5nIHRoZSBkaXJlY3RvcnkgaXMgYW1vcnRpemVkIG92ZXIgYWxsIHRoZSBy ZXF1ZXN0cywNCj4gYW5kIHRoZSBkaXJlY3RvcnkgaXMgdW5saWtlbHkgdG8gYmVjb21lIGludmFs aWQgZHVyaW5nIHRoZSBzZXNzaW9uLg0KPiANCj4gSG93ZXZlciwgQ1QncyB1c2FnZSBwYXR0ZXJu IGlzIHRvIG1ha2UgYSBsb3Qgb2YgdW5yZWxhdGVkIG9uZS1vZmYNCj4gcmVxdWVzdHMgc3ByZWFk IG92ZXIgYSBsb25nIHBlcmlvZCBvZiB0aW1lIC0gZS5nLiBzdWJtaXR0aW5nIGENCj4gKHByZSlj ZXJ0aWZpY2F0ZSwgZmV0Y2hpbmcgYW4gaW5jbHVzaW9uIHByb29mLCBmZXRjaGluZyB0aGUgbGF0 ZXN0IFNUSA0KPiB0byBzZW5kIHRvIGF1ZGl0b3JzLiBDbGllbnRzIHdvdWxkIGhhdmUgdG8gZWl0 aGVyIGZldGNoIGEgbmV3IGRpcmVjdG9yeQ0KPiBmb3IgZXZlcnkgcmVxdWVzdCAoZG91Ymxpbmcg dGhlIG51bWJlciBvZiByZXF1ZXN0cyBtYWRlIHRvIHRoZSBsb2cpIG9yDQo+IGNhY2hlIGRpcmVj dG9yaWVzIGluIGxvbmctdGVybSBzdGF0ZSAod2hpY2ggcmVxdWlyZXMgZGVhbGluZyB3aXRoDQo+ IGNhY2hlZCBkaXJlY3RvcmllcyBnb2luZyBzdGFsZSwgYW5kIHJlcXVpcmVzIGtlZXBpbmcgbG9u Zy10ZXJtIHN0YXRlDQo+IHdoaWNoIG1pZ2h0IG5vdCBvdGhlcndpc2UgYmUgbmVjZXNzYXJ5KS4N Cj4gDQo+IEFDTUUncyB1c2Ugb2YgZGlyZWN0b3JpZXMgaXMgdW5kZXJzcGVjaWZpZWQgc2luY2Ug aXQgZG9lc24ndCBzYXkgaG93DQo+IGxvbmcgYSBkaXJlY3RvcnkgcmVtYWlucyB2YWxpZC4gIEl0 J3Mgbm90IGEgYmlnIGRlYWwgZm9yIEFDTUUgYmVjYXVzZQ0KPiBBQ01FIHNlcnZlcnMgYXJlIHBy ZXN1bWVkIHRvIGJlIHNhbmUsIG9yIHBlb3BsZSB3b3VsZCBzd2l0Y2ggdG8gYW5vdGhlcg0KPiBD QS4NCg0KSXQncyBub3QgYmVlbiBhIGJpZyBkZWFsIGZvciBBQ01FLi4ueWV0LiAgQnV0IHdoeSBs ZWF2ZSBpdCB0byBjaGFuY2U/DQoNCkkganVzdCBmaWxlZCB0aGlzIGVycmF0dW0gYWdhaW5zdCBS RkM4NTU1Og0KaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhL2VpZDU3NzENCg0KPiBI b3dldmVyLCBDVCBpcyBtZWFudCB0byBiZSBhbiBhZHZlcnNhcmlhbCBwcm90b2NvbCBhbmQgaGFz IHRvDQo+IGFudGljaXBhdGUgbG9ncyBkb2luZyBjcmF6eSB0aGluZ3MgbGlrZSBjb25zdGFudGx5 IGNoYW5naW5nIHRoZWlyDQo+IGRpcmVjdG9yeSBpbiBhbiBlZmZvcnQgdG8gc3R5bWllIGF1ZGl0 aW5nIGFuZCBoaWRlIG1pc2JlaGF2aW9yLg0KPiANCj4gVGh1cywgQ1QncyB1c2Ugb2YgZGlyZWN0 b3JpZXMgd291bGQgbmVlZCB0byBiZSBxdWl0ZSB3ZWxsIHNwZWNpZmllZC4NCj4gSXQgaXMgbm90 IGEgY2hhbmdlIHRoYXQgc2hvdWxkIGJlIHJ1c2hlZCBhdCB0aGUgbGFzdCBtaW51dGUgd2l0aG91 dCBhDQo+IGNoYW5jZSBmb3IgcGVvcGxlIHRvIGNhcmVmdWxseSBleGFtaW5lIGFuZCBwb2tlIGhv bGVzIGluIGl0Lg0KDQpBZ3JlZWQuDQoNCj4gQ1QgY2xpZW50cyBhbHJlYWR5IG5lZWQgdG8gYmUg Y29uZmlndXJlZCB3aXRoIGEgbnVtYmVyIG9mIHBhcmFtZXRlcnMNCj4gZm9yIGVhY2ggbG9nIC0g TU1ELCBoYXNoIGFsZ29yaXRobSwgcHVibGljIGtleSwgbG9nIElELCBhbmQgc28gb24uDQo+IEFk ZGluZyBhIGRpcmVjdG9yeSB3b3VsZCBiaWZ1cmNhdGUgbG9nIG1ldGFkYXRhIGJldHdlZW4gdGhl IGV4aXN0aW5nDQo+IHBhcmFtZXRlciBzZXQgYW5kIHRoZSBuZXcgZGlyZWN0b3J5IG9iamVjdC4N Cj4gDQo+IEkgcHJvcG9zZSBzYXRpc2Z5aW5nIEJDUCAxOTAgYnkgc2ltcGx5IHNwZWNpZnlpbmcg dGhlIFVSTCBmb3IgZWFjaA0KPiBlbmRwb2ludCBhcyBhIHNlcGFyYXRlIGxvZyBwYXJhbWV0ZXIu ICBUaGlzIGlzIGEgdmVyeSBtaW5pbWFsIGNoYW5nZSB0bw0KPiB0aGUgcHJvdG9jb2wgYW5kIGF2 b2lkcyB0aGUgcHJvYmxlbXMgYWJvdmUuDQoNCkkgYWdyZWUgdGhhdCBpdCB3b3VsZCBtYWtlIHNl bnNlIHRvIHJlcXVpcmUgZWFjaCBlbmRwb2ludCB0byBiZSANCnNwZWNpZmllZCBhcyBhIGxvZyBw YXJhbWV0ZXIuICBZb3VyIHBvaW50IGFib3V0IGJpZnVyY2F0aW9uIGlzIHdlbGwgbWFkZS4NCg0K U28gdGhlbiBJIHRoaW5rIHRoZSBxdWVzdGlvbiBpczogU2hvdWxkIDY5NjItYmlzIHNwZWNpZnkg YSAiZGlyZWN0b3J5IiANCmVuZHBvaW50IHRoYXQgcmV0dXJucyBhIEpTT04gc3RydWN0dXJlIHRo YXQgY29udGFpbnMgYWxsIG9mIHRoZSBsb2cncyANCnBhcmFtZXRlcnMgKGluY2x1ZGluZyBlYWNo IG9mIHRoZSBlbmRwb2ludCBVUkxzKT8gIE9yIHNob3VsZCA2OTYyLWJpcyANCm5vdCBtYW5kYXRl IGFueSBwYXJ0aWN1bGFyIGZvcm1hdCBieSB3aGljaCBsb2cgb3BlcmF0b3JzIHNob3VsZCANCmRp c3RyaWJ1dGUgdGhpcyBpbmZvcm1hdGlvbj8NCg0KQ3VycmVudGx5LCA2OTYyLWJpcyBkb2Vzbid0 IG1hbmRhdGUgYSBmb3JtYXQsIGJ1dCBpdCBkb2VzIHBvaW50IHRvIGFuIA0KZXhhbXBsZSBmb3Jt YXQ6DQogICAiW0pTT04uTWV0YWRhdGFdIGlzIGFuIGV4YW1wbGUgb2YgYSBtZXRhZGF0YSBmb3Jt YXQgd2hpY2ggaW5jbHVkZXMgdGhlDQogICAgYWJvdmUgZWxlbWVudHMuIg0KDQpTYWRseSwgdGhp cyBjbGFpbSBpcyBub3QgY3VycmVudGx5IHRydWUsIGJlY2F1c2UgW0pTT04uTWV0YWRhdGFdIA0K KGh0dHBzOi8vd3d3LmdzdGF0aWMuY29tL2N0L2xvZ19saXN0L2xvZ19saXN0X3NjaGVtYS5qc29u KSBkb2VzIG5vdCANCmN1cnJlbnRseSAiaW5jbHVkZSB0aGUgYWJvdmUgZWxlbWVudHMiLiAgV2Ug c2hvdWxkIGZpeCB0aGlzIHNvbWVob3cuIA0KQnV0IGhvdz8NCg0KQWxzbywgaG93IG9mdGVuIGlz IGEgQ1QgY2xpZW50IGV4cGVjdGVkIHRvIHJlZnJlc2ggbG9nIG1ldGFkYXRhIGl0IGhhcyANCm9i dGFpbmVkIGZyb20gKGZvciBleGFtcGxlKSBbSlNPTi5NZXRhZGF0YV0gPw0KSXMgaXQgd2lzZSB0 byB1bmRlcnNwZWNpZnkgdGhpcz8NCg0KPiBSZWdhcmRzLA0KPiBBbmRyZXcNCg0KLS0gDQpSb2Ig U3RyYWRsaW5nDQpTZW5pb3IgUmVzZWFyY2ggJiBEZXZlbG9wbWVudCBTY2llbnRpc3QNClNlY3Rp Z28gTGltaXRlZA0KDQo= From nobody Tue Jul 2 10:52:12 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 703EC1206C8 for ; Tue, 2 Jul 2019 10:52:10 -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=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 HVwYw0v8rYGj for ; Tue, 2 Jul 2019 10:52:07 -0700 (PDT) Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) (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 9DF1F1206B8 for ; Tue, 2 Jul 2019 10:52:07 -0700 (PDT) Received: by mail-ot1-x32b.google.com with SMTP id s20so18091963otp.4 for ; Tue, 02 Jul 2019 10:52:07 -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=MhPc162XPaSGHQcdX0W+ObBwe12/7lM7MNB9jF0P3vM=; b=veow4O9c4t3DPvze+5Rn2IoVfPRvYibPb1z3YeB836LYWZ3qrA/tjhlQQ43iXBGX/q awg4EA5fG/4+Z3zZM7jpHNL865Odzqk3JgXW1ObitEdxSWkvWMKPV9fM3yjV0foe2afH oiQKPkQcJb2SNdo+fmSroPrAN1IkAyyxkUQV45q/epD3WkMerO5tPJ5G89+RcWmaSZKx BbFuJGprDrODeXwR8yD2qybPpRG1hk966q7CSRiKjM0I6V+Wqbb8rNmfOTUhzdQKSBx1 3pPP+J8jE7VMB6COWlLoPgMablsDXX5osDRM7y0wQKlNfNANvz+mN/IqsbhWb04h1Wp3 xZxA== 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=MhPc162XPaSGHQcdX0W+ObBwe12/7lM7MNB9jF0P3vM=; b=FWeZtywiahRvWLeVXyR2tEuDfFdiFljLJBDCeQJVDw6QyDmT6+Xoj3PMVyFPB4lvR0 /RBhtJwpCyfQ03+YSZHz7aC8aBHSbAmDhEzGUkBjVPPE2oUH7iRbf0NsD51XsU15wSNJ LN+vm/68Qge5cDdJHMHob28+yTlNVilnKZXGQvOfwwM32b4Dn0iqXIBMi1zAkeOma3SZ 5jCjzlcKpUTfo9Arx045I80EIJBGQOnTtxQmLytF8lkxf9AserupDJI++jmPJVD3cSJs n/3sAD6ZkA90O6XcK/OTUpbFlJYXD30R9moQN2FrPNfOiGRatokAWB1aa2VKDpkm4lXp AYvA== X-Gm-Message-State: APjAAAWuGDuooMkASHLimscEJehCEfwcnBiCpYIjRiOtfIpHwiU1fnG/ yawqbRkADqxqNfdnAxeIvG82bVCVRYZbnnf0Sf6adg== X-Google-Smtp-Source: APXvYqzLJX4JVQgrmIQmLD+IwU1Da7h8Mnqctzgtn5ikAJ1IxiQkxSkLXgNB29et5p+HK+wwkCIJYO36EiIMwBS0dac= X-Received: by 2002:a9d:774a:: with SMTP id t10mr23350962otl.228.1562089926400; Tue, 02 Jul 2019 10:52:06 -0700 (PDT) MIME-Version: 1.0 References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> <2cbff182-7c7a-4c55-b2d2-a67f41dd7436@sectigo.com> In-Reply-To: <2cbff182-7c7a-4c55-b2d2-a67f41dd7436@sectigo.com> From: Rob Percival Date: Tue, 2 Jul 2019 18:51:53 +0100 Message-ID: To: Rob Stradling Cc: Andrew Ayer , "trans@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002c3ff1058cb6672e" Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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: Tue, 02 Jul 2019 17:52:11 -0000 --0000000000002c3ff1058cb6672e Content-Type: text/plain; charset="UTF-8" FYI: That JSON schema is planned for deprecation; a new version was proposed last year and, following a period for feedback, parties have been slowly migrating to the new schema: https://groups.google.com/a/chromium.org/d/topic/ct-policy/26dmpWdaSHM/discussion That thread would be a good place to propose schema changes. On Tue, 2 Jul 2019, 16:08 Rob Stradling, wrote: > Andrew, thanks for your analysis. Comments inline... > > On 01/07/2019 20:37, Andrew Ayer wrote: > > I also think .well-known URLs are a bad idea, for the same reasons > > as Jacob. > > > > I think directories are even worse. Although they've been used > > successfully in ACME, CT has different needs which make directories > > unsuitable. ACME's usage pattern is to make a series of related > > requests over a short time period to drive a certificate request to > > issuance, with the client maintaining state between each request. > > This makes it natural for a client to fetch the directory once at the > > beginning of an issuance "session" and use it for the duration, since > > the cost of fetching the directory is amortized over all the requests, > > and the directory is unlikely to become invalid during the session. > > > > However, CT's usage pattern is to make a lot of unrelated one-off > > requests spread over a long period of time - e.g. submitting a > > (pre)certificate, fetching an inclusion proof, fetching the latest STH > > to send to auditors. Clients would have to either fetch a new directory > > for every request (doubling the number of requests made to the log) or > > cache directories in long-term state (which requires dealing with > > cached directories going stale, and requires keeping long-term state > > which might not otherwise be necessary). > > > > ACME's use of directories is underspecified since it doesn't say how > > long a directory remains valid. It's not a big deal for ACME because > > ACME servers are presumed to be sane, or people would switch to another > > CA. > > It's not been a big deal for ACME...yet. But why leave it to chance? > > I just filed this erratum against RFC8555: > https://www.rfc-editor.org/errata/eid5771 > > > However, CT is meant to be an adversarial protocol and has to > > anticipate logs doing crazy things like constantly changing their > > directory in an effort to stymie auditing and hide misbehavior. > > > > Thus, CT's use of directories would need to be quite well specified. > > It is not a change that should be rushed at the last minute without a > > chance for people to carefully examine and poke holes in it. > > Agreed. > > > CT clients already need to be configured with a number of parameters > > for each log - MMD, hash algorithm, public key, log ID, and so on. > > Adding a directory would bifurcate log metadata between the existing > > parameter set and the new directory object. > > > > I propose satisfying BCP 190 by simply specifying the URL for each > > endpoint as a separate log parameter. This is a very minimal change to > > the protocol and avoids the problems above. > > I agree that it would make sense to require each endpoint to be > specified as a log parameter. Your point about bifurcation is well made. > > So then I think the question is: Should 6962-bis specify a "directory" > endpoint that returns a JSON structure that contains all of the log's > parameters (including each of the endpoint URLs)? Or should 6962-bis > not mandate any particular format by which log operators should > distribute this information? > > Currently, 6962-bis doesn't mandate a format, but it does point to an > example format: > "[JSON.Metadata] is an example of a metadata format which includes the > above elements." > > Sadly, this claim is not currently true, because [JSON.Metadata] > (https://www.gstatic.com/ct/log_list/log_list_schema.json) does not > currently "include the above elements". We should fix this somehow. > But how? > > Also, how often is a CT client expected to refresh log metadata it has > obtained from (for example) [JSON.Metadata] ? > Is it wise to underspecify this? > > > Regards, > > Andrew > > -- > Rob Stradling > Senior Research & Development Scientist > Sectigo Limited > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --0000000000002c3ff1058cb6672e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
FYI: That JSON schema is planned for deprecation; a = new version was proposed last year and, following a period for feedback, pa= rties have been slowly migrating to the new schema:=C2=A0https://groups.google.com/a/chromium.org/d/topic/ct-policy/26dmpWdaSHM/dis= cussion

That thread = would be a good place to propose schema changes.
On Tue, 2 Jul 2019, 16:08 Rob Stradling, <rob@sectigo.com> wrote:
Andrew, thanks for your analysis.=C2=A0 Comments inline...

On 01/07/2019 20:37, Andrew Ayer wrote:
> I also think .well-known URLs are a bad idea, for the same reasons
> as Jacob.
>
> I think directories are even worse.=C2=A0 Although they've been us= ed
> successfully in ACME, CT has different needs which make directories > unsuitable.=C2=A0 ACME's usage pattern is to make a series of rela= ted
> requests over a short time period to drive a certificate request to > issuance, with the client maintaining state between each request.
> This makes it natural for a client to fetch the directory once at the<= br> > beginning of an issuance "session" and use it for the durati= on, since
> the cost of fetching the directory is amortized over all the requests,=
> and the directory is unlikely to become invalid during the session. >
> However, CT's usage pattern is to make a lot of unrelated one-off<= br> > requests spread over a long period of time - e.g. submitting a
> (pre)certificate, fetching an inclusion proof, fetching the latest STH=
> to send to auditors. Clients would have to either fetch a new director= y
> for every request (doubling the number of requests made to the log) or=
> cache directories in long-term state (which requires dealing with
> cached directories going stale, and requires keeping long-term state > which might not otherwise be necessary).
>
> ACME's use of directories is underspecified since it doesn't s= ay how
> long a directory remains valid.=C2=A0 It's not a big deal for ACME= because
> ACME servers are presumed to be sane, or people would switch to anothe= r
> CA.

It's not been a big deal for ACME...yet.=C2=A0 But why leave it to chan= ce?

I just filed this erratum against RFC8555:
https://www.rfc-editor.org/errata/eid5771
> However, CT is meant to be an adversarial protocol and has to
> anticipate logs doing crazy things like constantly changing their
> directory in an effort to stymie auditing and hide misbehavior.
>
> Thus, CT's use of directories would need to be quite well specifie= d.
> It is not a change that should be rushed at the last minute without a<= br> > chance for people to carefully examine and poke holes in it.

Agreed.

> CT clients already need to be configured with a number of parameters > for each log - MMD, hash algorithm, public key, log ID, and so on.
> Adding a directory would bifurcate log metadata between the existing > parameter set and the new directory object.
>
> I propose satisfying BCP 190 by simply specifying the URL for each
> endpoint as a separate log parameter.=C2=A0 This is a very minimal cha= nge to
> the protocol and avoids the problems above.

I agree that it would make sense to require each endpoint to be
specified as a log parameter.=C2=A0 Your point about bifurcation is well ma= de.

So then I think the question is: Should 6962-bis specify a "directory&= quot;
endpoint that returns a JSON structure that contains all of the log's <= br> parameters (including each of the endpoint URLs)?=C2=A0 Or should 6962-bis =
not mandate any particular format by which log operators should
distribute this information?

Currently, 6962-bis doesn't mandate a format, but it does point to an <= br> example format:
=C2=A0 =C2=A0"[JSON.Metadata] is an example of a metadata format which= includes the
=C2=A0 =C2=A0 above elements."

Sadly, this claim is not currently true, because [JSON.Metadata]
(https://www.gstatic.com/ct/log= _list/log_list_schema.json) does not
currently "include the above elements".=C2=A0 We should fix this = somehow.
But how?

Also, how often is a CT client expected to refresh log metadata it has
obtained from (for example) [JSON.Metadata] ?
Is it wise to underspecify this?

> Regards,
> Andrew

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

_______________________________________________
Trans mailing list
Tran= s@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--0000000000002c3ff1058cb6672e-- From nobody Wed Jul 3 06:52:08 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 4A829120059 for ; Wed, 3 Jul 2019 06:52: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 Ba3k2f3WSqdT for ; Wed, 3 Jul 2019 06:52:03 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730043.outbound.protection.outlook.com [40.107.73.43]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88B211200B1 for ; Wed, 3 Jul 2019 06:52:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-comodoca-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=24boGzH2wwqk02AO7kkTI+oXLst00CrVP40RHWFFitw=; b=BYTi0pYqLtEpD08sWcp4EaWVU9WCJjnaaBarDinh3qT6/go+xzAPHGHng79rnED9Mw/0hsjzlWBBjrMB7w4S71/4mJnul1YNp4WaMeWULQz6H7WHrnmQY31Qs7KKlkPwtS8E03LotoyN4j5OhDKkVA/NdkAhuPVABGa6uP3UYVw= Received: from DM5PR17MB1211.namprd17.prod.outlook.com (10.173.132.148) by DM5PR17MB1641.namprd17.prod.outlook.com (10.175.224.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.20; Wed, 3 Jul 2019 13:52:01 +0000 Received: from DM5PR17MB1211.namprd17.prod.outlook.com ([fe80::b556:345c:94cf:7258]) by DM5PR17MB1211.namprd17.prod.outlook.com ([fe80::b556:345c:94cf:7258%6]) with mapi id 15.20.2052.010; Wed, 3 Jul 2019 13:52:01 +0000 From: Rob Stradling To: Rob Percival , "trans@ietf.org" CC: Andrew Ayer Thread-Topic: [Trans] Directory instead of .well-known for URL structure Thread-Index: AQHVJ7g3xV77fgqjj0ive+Voenofmqa2OUSAgAFHIICAAC3VgIABT0mA Date: Wed, 3 Jul 2019 13:52:01 +0000 Message-ID: <047d5a04-4176-6651-b200-6ce7ce8a8266@sectigo.com> References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> <2cbff182-7c7a-4c55-b2d2-a67f41dd7436@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: LO2P265CA0204.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:9e::24) To DM5PR17MB1211.namprd17.prod.outlook.com (2603:10b6:3:8b::20) 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: 3c2c7b1c-3d6b-4c5e-c8d1-08d6ffbd9f91 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR17MB1641; x-ms-traffictypediagnostic: DM5PR17MB1641: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00872B689F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(39850400004)(396003)(136003)(376002)(366004)(346002)(189003)(199004)(53546011)(386003)(8936002)(6506007)(76176011)(102836004)(966005)(25786009)(2616005)(4326008)(476003)(14454004)(186003)(5660300002)(68736007)(31686004)(486006)(6116002)(2906002)(11346002)(99286004)(52116002)(110136005)(66476007)(36756003)(7736002)(229853002)(316002)(66446008)(446003)(8676002)(6306002)(6246003)(31696002)(256004)(86362001)(14444005)(64756008)(305945005)(53936002)(478600001)(81166006)(81156014)(66556008)(73956011)(6486002)(71190400001)(66946007)(6512007)(46003)(2501003)(6436002)(71200400001)(142923001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR17MB1641; H:DM5PR17MB1211.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-message-info: kjwu2/PNRplTR/5AILGWpnjJbdc8WwrYgpXFu4okfnG9X4G70EkCr3UIiPST7wLVECvqiLZK1MkNjof0KfxkMZ49APfrJhIHOlOGXdMx5KtMPDr9IRCx+wpNJpQ72AMHBcaA9x5+jFiwvtUSRyn44xo8ZCQ0eOwFlTnvnPeudaCYxWWdJ/wfIJkbYKAvjyLpKSMiASaUSw/aZoGwaVSfza1UQ098lmgYxOowzvPLZxsA7/aWWyi3j1biwOqamGMUNG7XFNrjDSgPwso+228KFb2fWKysY1GADmZJTvMCYThdWEyTbKkL6zn9iwqPJ2RGhnAo4MbEXHdbjVFdQV92nbgYnCJUiyg8y+FySCDeZTIW4MVq4RKUmqaXdkU68YBTdXgvGyvVGIkwY2kKKHIFWiQy5uAT+TONJpf3LjvW/O0= 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: 3c2c7b1c-3d6b-4c5e-c8d1-08d6ffbd9f91 X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2019 13:52:01.3409 (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: robs@comodoca.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR17MB1641 Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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, 03 Jul 2019 13:52:06 -0000 VGhhbmtzIFJvYi4gIEJvdGggdGhlIHRvLWJlLWRlcHJlY2F0ZWQgYW5kIG5ldyBzY2hlbWFzIGFy ZSBvZiBjb3Vyc2UgDQpmb2N1c2VkIG9uIENUIHYxIChSRkM2OTYyKSwgc28gSVNUTSB0aGF0IG5l aXRoZXIgb2YgdGhlbSBhcmUgc3VpdGFibGUgDQpjYW5kaWRhdGVzIGZvciA2OTYyLWJpcyB0byBw b2ludCBhdC4NCg0KTWF5YmUgd2Ugc2hvdWxkIHNpbXBseSByZW1vdmUgdGhlICJbSlNPTi5NZXRh ZGF0YV0gaXMgYW4gZXhhbXBsZSBvZiBhIA0KbWV0YWRhdGEgZm9ybWF0IHdoaWNoIGluY2x1ZGVz IHRoZSBhYm92ZSBlbGVtZW50cyIgc2VudGVuY2UgZnJvbSA2OTYyLWJpcy4NCg0KT24gMDIvMDcv MjAxOSAxODo1MSwgUm9iIFBlcmNpdmFsIHdyb3RlOg0KPiBGWUk6IFRoYXQgSlNPTiBzY2hlbWEg aXMgcGxhbm5lZCBmb3IgZGVwcmVjYXRpb247IGEgbmV3IHZlcnNpb24gd2FzIA0KPiBwcm9wb3Nl ZCBsYXN0IHllYXIgYW5kLCBmb2xsb3dpbmcgYSBwZXJpb2QgZm9yIGZlZWRiYWNrLCBwYXJ0aWVz IGhhdmUgDQo+IGJlZW4gc2xvd2x5IG1pZ3JhdGluZyB0byB0aGUgbmV3IHNjaGVtYTogDQo+IGh0 dHBzOi8vZ3JvdXBzLmdvb2dsZS5jb20vYS9jaHJvbWl1bS5vcmcvZC90b3BpYy9jdC1wb2xpY3kv MjZkbXBXZGFTSE0vZGlzY3Vzc2lvbg0KPiANCj4gVGhhdCB0aHJlYWQgd291bGQgYmUgYSBnb29k IHBsYWNlIHRvIHByb3Bvc2Ugc2NoZW1hIGNoYW5nZXMuDQo+IA0KPiBPbiBUdWUsIDIgSnVsIDIw MTksIDE2OjA4IFJvYiBTdHJhZGxpbmcsIDxyb2JAc2VjdGlnby5jb20gDQo+IDxtYWlsdG86cm9i QHNlY3RpZ28uY29tPj4gd3JvdGU6DQo+IA0KPiAgICAgQW5kcmV3LCB0aGFua3MgZm9yIHlvdXIg YW5hbHlzaXMuwqAgQ29tbWVudHMgaW5saW5lLi4uDQo+IA0KPiAgICAgT24gMDEvMDcvMjAxOSAy MDozNywgQW5kcmV3IEF5ZXIgd3JvdGU6DQo+ICAgICAgPiBJIGFsc28gdGhpbmsgLndlbGwta25v d24gVVJMcyBhcmUgYSBiYWQgaWRlYSwgZm9yIHRoZSBzYW1lIHJlYXNvbnMNCj4gICAgICA+IGFz IEphY29iLg0KPiAgICAgID4NCj4gICAgICA+IEkgdGhpbmsgZGlyZWN0b3JpZXMgYXJlIGV2ZW4g d29yc2UuwqAgQWx0aG91Z2ggdGhleSd2ZSBiZWVuIHVzZWQNCj4gICAgICA+IHN1Y2Nlc3NmdWxs eSBpbiBBQ01FLCBDVCBoYXMgZGlmZmVyZW50IG5lZWRzIHdoaWNoIG1ha2UgZGlyZWN0b3JpZXMN Cj4gICAgICA+IHVuc3VpdGFibGUuwqAgQUNNRSdzIHVzYWdlIHBhdHRlcm4gaXMgdG8gbWFrZSBh IHNlcmllcyBvZiByZWxhdGVkDQo+ICAgICAgPiByZXF1ZXN0cyBvdmVyIGEgc2hvcnQgdGltZSBw ZXJpb2QgdG8gZHJpdmUgYSBjZXJ0aWZpY2F0ZSByZXF1ZXN0IHRvDQo+ICAgICAgPiBpc3N1YW5j ZSwgd2l0aCB0aGUgY2xpZW50IG1haW50YWluaW5nIHN0YXRlIGJldHdlZW4gZWFjaCByZXF1ZXN0 Lg0KPiAgICAgID4gVGhpcyBtYWtlcyBpdCBuYXR1cmFsIGZvciBhIGNsaWVudCB0byBmZXRjaCB0 aGUgZGlyZWN0b3J5IG9uY2UgYXQgdGhlDQo+ICAgICAgPiBiZWdpbm5pbmcgb2YgYW4gaXNzdWFu Y2UgInNlc3Npb24iIGFuZCB1c2UgaXQgZm9yIHRoZSBkdXJhdGlvbiwgc2luY2UNCj4gICAgICA+ IHRoZSBjb3N0IG9mIGZldGNoaW5nIHRoZSBkaXJlY3RvcnkgaXMgYW1vcnRpemVkIG92ZXIgYWxs IHRoZQ0KPiAgICAgcmVxdWVzdHMsDQo+ICAgICAgPiBhbmQgdGhlIGRpcmVjdG9yeSBpcyB1bmxp a2VseSB0byBiZWNvbWUgaW52YWxpZCBkdXJpbmcgdGhlIHNlc3Npb24uDQo+ICAgICAgPg0KPiAg ICAgID4gSG93ZXZlciwgQ1QncyB1c2FnZSBwYXR0ZXJuIGlzIHRvIG1ha2UgYSBsb3Qgb2YgdW5y ZWxhdGVkIG9uZS1vZmYNCj4gICAgICA+IHJlcXVlc3RzIHNwcmVhZCBvdmVyIGEgbG9uZyBwZXJp b2Qgb2YgdGltZSAtIGUuZy4gc3VibWl0dGluZyBhDQo+ICAgICAgPiAocHJlKWNlcnRpZmljYXRl LCBmZXRjaGluZyBhbiBpbmNsdXNpb24gcHJvb2YsIGZldGNoaW5nIHRoZQ0KPiAgICAgbGF0ZXN0 IFNUSA0KPiAgICAgID4gdG8gc2VuZCB0byBhdWRpdG9ycy4gQ2xpZW50cyB3b3VsZCBoYXZlIHRv IGVpdGhlciBmZXRjaCBhIG5ldw0KPiAgICAgZGlyZWN0b3J5DQo+ICAgICAgPiBmb3IgZXZlcnkg cmVxdWVzdCAoZG91YmxpbmcgdGhlIG51bWJlciBvZiByZXF1ZXN0cyBtYWRlIHRvIHRoZQ0KPiAg ICAgbG9nKSBvcg0KPiAgICAgID4gY2FjaGUgZGlyZWN0b3JpZXMgaW4gbG9uZy10ZXJtIHN0YXRl ICh3aGljaCByZXF1aXJlcyBkZWFsaW5nIHdpdGgNCj4gICAgICA+IGNhY2hlZCBkaXJlY3Rvcmll cyBnb2luZyBzdGFsZSwgYW5kIHJlcXVpcmVzIGtlZXBpbmcgbG9uZy10ZXJtIHN0YXRlDQo+ICAg ICAgPiB3aGljaCBtaWdodCBub3Qgb3RoZXJ3aXNlIGJlIG5lY2Vzc2FyeSkuDQo+ICAgICAgPg0K PiAgICAgID4gQUNNRSdzIHVzZSBvZiBkaXJlY3RvcmllcyBpcyB1bmRlcnNwZWNpZmllZCBzaW5j ZSBpdCBkb2Vzbid0IHNheSBob3cNCj4gICAgICA+IGxvbmcgYSBkaXJlY3RvcnkgcmVtYWlucyB2 YWxpZC7CoCBJdCdzIG5vdCBhIGJpZyBkZWFsIGZvciBBQ01FIGJlY2F1c2UNCj4gICAgICA+IEFD TUUgc2VydmVycyBhcmUgcHJlc3VtZWQgdG8gYmUgc2FuZSwgb3IgcGVvcGxlIHdvdWxkIHN3aXRj aCB0bw0KPiAgICAgYW5vdGhlcg0KPiAgICAgID4gQ0EuDQo+IA0KPiAgICAgSXQncyBub3QgYmVl biBhIGJpZyBkZWFsIGZvciBBQ01FLi4ueWV0LsKgIEJ1dCB3aHkgbGVhdmUgaXQgdG8gY2hhbmNl Pw0KPiANCj4gICAgIEkganVzdCBmaWxlZCB0aGlzIGVycmF0dW0gYWdhaW5zdCBSRkM4NTU1Og0K PiAgICAgaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhL2VpZDU3NzENCj4gDQo+ICAg ICAgPiBIb3dldmVyLCBDVCBpcyBtZWFudCB0byBiZSBhbiBhZHZlcnNhcmlhbCBwcm90b2NvbCBh bmQgaGFzIHRvDQo+ICAgICAgPiBhbnRpY2lwYXRlIGxvZ3MgZG9pbmcgY3JhenkgdGhpbmdzIGxp a2UgY29uc3RhbnRseSBjaGFuZ2luZyB0aGVpcg0KPiAgICAgID4gZGlyZWN0b3J5IGluIGFuIGVm Zm9ydCB0byBzdHltaWUgYXVkaXRpbmcgYW5kIGhpZGUgbWlzYmVoYXZpb3IuDQo+ICAgICAgPg0K PiAgICAgID4gVGh1cywgQ1QncyB1c2Ugb2YgZGlyZWN0b3JpZXMgd291bGQgbmVlZCB0byBiZSBx dWl0ZSB3ZWxsIHNwZWNpZmllZC4NCj4gICAgICA+IEl0IGlzIG5vdCBhIGNoYW5nZSB0aGF0IHNo b3VsZCBiZSBydXNoZWQgYXQgdGhlIGxhc3QgbWludXRlIHdpdGhvdXQgYQ0KPiAgICAgID4gY2hh bmNlIGZvciBwZW9wbGUgdG8gY2FyZWZ1bGx5IGV4YW1pbmUgYW5kIHBva2UgaG9sZXMgaW4gaXQu DQo+IA0KPiAgICAgQWdyZWVkLg0KPiANCj4gICAgICA+IENUIGNsaWVudHMgYWxyZWFkeSBuZWVk IHRvIGJlIGNvbmZpZ3VyZWQgd2l0aCBhIG51bWJlciBvZiBwYXJhbWV0ZXJzDQo+ICAgICAgPiBm b3IgZWFjaCBsb2cgLSBNTUQsIGhhc2ggYWxnb3JpdGhtLCBwdWJsaWMga2V5LCBsb2cgSUQsIGFu ZCBzbyBvbi4NCj4gICAgICA+IEFkZGluZyBhIGRpcmVjdG9yeSB3b3VsZCBiaWZ1cmNhdGUgbG9n IG1ldGFkYXRhIGJldHdlZW4gdGhlIGV4aXN0aW5nDQo+ICAgICAgPiBwYXJhbWV0ZXIgc2V0IGFu ZCB0aGUgbmV3IGRpcmVjdG9yeSBvYmplY3QuDQo+ICAgICAgPg0KPiAgICAgID4gSSBwcm9wb3Nl IHNhdGlzZnlpbmcgQkNQIDE5MCBieSBzaW1wbHkgc3BlY2lmeWluZyB0aGUgVVJMIGZvciBlYWNo DQo+ICAgICAgPiBlbmRwb2ludCBhcyBhIHNlcGFyYXRlIGxvZyBwYXJhbWV0ZXIuwqAgVGhpcyBp cyBhIHZlcnkgbWluaW1hbA0KPiAgICAgY2hhbmdlIHRvDQo+ICAgICAgPiB0aGUgcHJvdG9jb2wg YW5kIGF2b2lkcyB0aGUgcHJvYmxlbXMgYWJvdmUuDQo+IA0KPiAgICAgSSBhZ3JlZSB0aGF0IGl0 IHdvdWxkIG1ha2Ugc2Vuc2UgdG8gcmVxdWlyZSBlYWNoIGVuZHBvaW50IHRvIGJlDQo+ICAgICBz cGVjaWZpZWQgYXMgYSBsb2cgcGFyYW1ldGVyLsKgIFlvdXIgcG9pbnQgYWJvdXQgYmlmdXJjYXRp b24gaXMgd2VsbA0KPiAgICAgbWFkZS4NCj4gDQo+ICAgICBTbyB0aGVuIEkgdGhpbmsgdGhlIHF1 ZXN0aW9uIGlzOiBTaG91bGQgNjk2Mi1iaXMgc3BlY2lmeSBhICJkaXJlY3RvcnkiDQo+ICAgICBl bmRwb2ludCB0aGF0IHJldHVybnMgYSBKU09OIHN0cnVjdHVyZSB0aGF0IGNvbnRhaW5zIGFsbCBv ZiB0aGUgbG9nJ3MNCj4gICAgIHBhcmFtZXRlcnMgKGluY2x1ZGluZyBlYWNoIG9mIHRoZSBlbmRw b2ludCBVUkxzKT/CoCBPciBzaG91bGQgNjk2Mi1iaXMNCj4gICAgIG5vdCBtYW5kYXRlIGFueSBw YXJ0aWN1bGFyIGZvcm1hdCBieSB3aGljaCBsb2cgb3BlcmF0b3JzIHNob3VsZA0KPiAgICAgZGlz dHJpYnV0ZSB0aGlzIGluZm9ybWF0aW9uPw0KPiANCj4gICAgIEN1cnJlbnRseSwgNjk2Mi1iaXMg ZG9lc24ndCBtYW5kYXRlIGEgZm9ybWF0LCBidXQgaXQgZG9lcyBwb2ludCB0byBhbg0KPiAgICAg ZXhhbXBsZSBmb3JtYXQ6DQo+ICAgICAgwqAgwqAiW0pTT04uTWV0YWRhdGFdIGlzIGFuIGV4YW1w bGUgb2YgYSBtZXRhZGF0YSBmb3JtYXQgd2hpY2gNCj4gICAgIGluY2x1ZGVzIHRoZQ0KPiAgICAg IMKgIMKgIGFib3ZlIGVsZW1lbnRzLiINCj4gDQo+ICAgICBTYWRseSwgdGhpcyBjbGFpbSBpcyBu b3QgY3VycmVudGx5IHRydWUsIGJlY2F1c2UgW0pTT04uTWV0YWRhdGFdDQo+ICAgICAoaHR0cHM6 Ly93d3cuZ3N0YXRpYy5jb20vY3QvbG9nX2xpc3QvbG9nX2xpc3Rfc2NoZW1hLmpzb24pIGRvZXMg bm90DQo+ICAgICBjdXJyZW50bHkgImluY2x1ZGUgdGhlIGFib3ZlIGVsZW1lbnRzIi7CoCBXZSBz aG91bGQgZml4IHRoaXMgc29tZWhvdy4NCj4gICAgIEJ1dCBob3c/DQo+IA0KPiAgICAgQWxzbywg aG93IG9mdGVuIGlzIGEgQ1QgY2xpZW50IGV4cGVjdGVkIHRvIHJlZnJlc2ggbG9nIG1ldGFkYXRh IGl0IGhhcw0KPiAgICAgb2J0YWluZWQgZnJvbSAoZm9yIGV4YW1wbGUpIFtKU09OLk1ldGFkYXRh XSA/DQo+ICAgICBJcyBpdCB3aXNlIHRvIHVuZGVyc3BlY2lmeSB0aGlzPw0KPiANCj4gICAgICA+ IFJlZ2FyZHMsDQo+ICAgICAgPiBBbmRyZXcNCj4gDQo+ICAgICAtLSANCj4gICAgIFJvYiBTdHJh ZGxpbmcNCj4gICAgIFNlbmlvciBSZXNlYXJjaCAmIERldmVsb3BtZW50IFNjaWVudGlzdA0KPiAg ICAgU2VjdGlnbyBMaW1pdGVkDQo+IA0KPiAgICAgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gICAgIFRyYW5zIG1haWxpbmcgbGlzdA0KPiAgICAgVHJh bnNAaWV0Zi5vcmcgPG1haWx0bzpUcmFuc0BpZXRmLm9yZz4NCj4gICAgIGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdHJhbnMNCj4gDQoNCi0tIA0KUm9iIFN0cmFkbGluZw0K U2VuaW9yIFJlc2VhcmNoICYgRGV2ZWxvcG1lbnQgU2NpZW50aXN0DQpFbWFpbDogcm9iQHNlY3Rp Z28uY29tDQpCcmFkZm9yZCwgVUsNCk9mZmljZTogKzQ0MTI3NDAyNDcwNw0KU2VjdGlnbyBMaW1p dGVkDQoNClRoaXMgbWVzc2FnZSBhbmQgYW55IGZpbGVzIGFzc29jaWF0ZWQgd2l0aCBpdCBtYXkg Y29udGFpbiBsZWdhbGx5IA0KcHJpdmlsZWdlZCwgY29uZmlkZW50aWFsLCBvciBwcm9wcmlldGFy eSBpbmZvcm1hdGlvbi4gSWYgeW91IGFyZSBub3QgdGhlIA0KaW50ZW5kZWQgcmVjaXBpZW50LCB5 b3UgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gdXNlLCBjb3B5LCBvciBmb3J3YXJkIGl0LCANCmluIHdo b2xlIG9yIGluIHBhcnQgd2l0aG91dCB0aGUgZXhwcmVzcyBjb25zZW50IG9mIHRoZSBzZW5kZXIu IFBsZWFzZSANCm5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJlcGx5IGVtYWlsLCBkaXNyZWdhcmQgdGhl IGZvcmVnb2luZyBtZXNzYWdlcywgYW5kIA0KZGVsZXRlIGl0IGltbWVkaWF0ZWx5Lg0K From nobody Wed Jul 3 09:04: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 8CA3012068B for ; Wed, 3 Jul 2019 09:04:36 -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=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 5QpEE8X3TKif for ; Wed, 3 Jul 2019 09:04:32 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 A318212064F for ; Wed, 3 Jul 2019 09:04:32 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id a15so4083021qtn.7 for ; Wed, 03 Jul 2019 09:04:32 -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=BCWWq3EIcTy1UhYIEo5bkSyn4HvBTqSw+pj0VmIAvPY=; b=n73zkZnlLO1lSNrRBhfdlPWkhlXFsSBvVGc8iVLWeIYwsA61n4PlV9ieyA7qTWofWA mdidfHD7UomzH7jCbazhalxHT8T9ecMTdldMX6dwFl1Sxnl6CI+acFMgBnYVNvS6jF1y dfMgV17lhWssq3WI3Y/RD3PoPfXEycxA7aoTXDRfqfkmLvMwBInjf6fj9OMhwi6np+zD zwMD0N/AejvqBoKtmR1P+s9SMldtlPuv4RvI6o1o/WthJN2L52oUFhE5IBuzUo13tA4J 1EyzywQyCsgR32yGSzeUluTYjXbNMr8lYML8Ytq6AbrTrSgbm7zVKx+rEb79dL1fv9Ab MJ6w== 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=BCWWq3EIcTy1UhYIEo5bkSyn4HvBTqSw+pj0VmIAvPY=; b=TOsiV+2F2wC88ZJAOldrxKEmLe0KoTTjw5NaTmfahoTbNIHLHNE/CKmYc36eVLHjWf hBUlzBrnVnUjywPPCIK3ib9EwelP3kLFJ8geH5RnEurSYrfnly+vnNMTMsn+SXkFJ9pN TA3Je3hVY+dfYuyNLpvQBK+/+LsNerJOTZdES0EzOVQDQXAFzpQzPKpGHevVDslDnEVL UzrUkOJk3E2ytGB/HkcLRJUBFVEWR6cScnoN2lmqfWO9A6GiX72gzLvC5hi3QFzD3Dvk vQNhzVIEi6sRk4v+y268CZLbwmxmNUT/0d7B4BG7WFY03vcaudMpyYkfBeUrpEbV/EiM o0Mg== X-Gm-Message-State: APjAAAXHZ28eeWgmkXIrEliR5+1DqlW59TIudqnmZbLqqKY/tEIUUb4V +5vbgllJw80u2fXTyNQLaH01l1G+HLddQqo93umQ+A== X-Google-Smtp-Source: APXvYqyeHISkfNkqD4vr6nUOsL+eNKP7DdVKw+sQf7XpAJud1fPRl8/gFLoWhurMgTMfDSbwsZ+7E4q+cn76Dy/j/Dc= X-Received: by 2002:a25:738a:: with SMTP id o132mr8609651ybc.139.1562169871182; Wed, 03 Jul 2019 09:04:31 -0700 (PDT) MIME-Version: 1.0 References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> <2cbff182-7c7a-4c55-b2d2-a67f41dd7436@sectigo.com> <047d5a04-4176-6651-b200-6ce7ce8a8266@sectigo.com> In-Reply-To: <047d5a04-4176-6651-b200-6ce7ce8a8266@sectigo.com> From: Eran Messeri Date: Wed, 3 Jul 2019 17:04:04 +0100 Message-ID: To: Rob Stradling Cc: Rob Percival , "trans@ietf.org" , Andrew Ayer Content-Type: multipart/alternative; boundary="00000000000040bf42058cc904d1" Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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, 03 Jul 2019 16:04:41 -0000 --00000000000040bf42058cc904d1 Content-Type: text/plain; charset="UTF-8" I support Andrew Ayer and Rob Stradling's suggestion to " require each endpoint to be specified as a log parameter." The reasons outlined make a lot of sense from an implementation perspective, our experience with RFC6962 suggest that absent caching mechanisms, logs would face significant load if all clients were to audit them. Adding a requirement to fetch a directory would increase the load for (as far as I can tell) no good reason. I think under-specifying it right now is the only option as we have no specification of the log metadata. I don't think it's too big of a deal as when people start implementing 6962-bis I expect the log metadata format will evolve based on the existing schemas and, if necessary, could be standardized. On Wed, Jul 3, 2019 at 2:52 PM Rob Stradling wrote: > Thanks Rob. Both the to-be-deprecated and new schemas are of course > focused on CT v1 (RFC6962), so ISTM that neither of them are suitable > candidates for 6962-bis to point at. > > Maybe we should simply remove the "[JSON.Metadata] is an example of a > metadata format which includes the above elements" sentence from 6962-bis. > > On 02/07/2019 18:51, Rob Percival wrote: > > FYI: That JSON schema is planned for deprecation; a new version was > > proposed last year and, following a period for feedback, parties have > > been slowly migrating to the new schema: > > > https://groups.google.com/a/chromium.org/d/topic/ct-policy/26dmpWdaSHM/discussion > > > > That thread would be a good place to propose schema changes. > > > > On Tue, 2 Jul 2019, 16:08 Rob Stradling, > > wrote: > > > > Andrew, thanks for your analysis. Comments inline... > > > > On 01/07/2019 20:37, Andrew Ayer wrote: > > > I also think .well-known URLs are a bad idea, for the same reasons > > > as Jacob. > > > > > > I think directories are even worse. Although they've been used > > > successfully in ACME, CT has different needs which make > directories > > > unsuitable. ACME's usage pattern is to make a series of related > > > requests over a short time period to drive a certificate request > to > > > issuance, with the client maintaining state between each request. > > > This makes it natural for a client to fetch the directory once at > the > > > beginning of an issuance "session" and use it for the duration, > since > > > the cost of fetching the directory is amortized over all the > > requests, > > > and the directory is unlikely to become invalid during the > session. > > > > > > However, CT's usage pattern is to make a lot of unrelated one-off > > > requests spread over a long period of time - e.g. submitting a > > > (pre)certificate, fetching an inclusion proof, fetching the > > latest STH > > > to send to auditors. Clients would have to either fetch a new > > directory > > > for every request (doubling the number of requests made to the > > log) or > > > cache directories in long-term state (which requires dealing with > > > cached directories going stale, and requires keeping long-term > state > > > which might not otherwise be necessary). > > > > > > ACME's use of directories is underspecified since it doesn't say > how > > > long a directory remains valid. It's not a big deal for ACME > because > > > ACME servers are presumed to be sane, or people would switch to > > another > > > CA. > > > > It's not been a big deal for ACME...yet. But why leave it to chance? > > > > I just filed this erratum against RFC8555: > > https://www.rfc-editor.org/errata/eid5771 > > > > > However, CT is meant to be an adversarial protocol and has to > > > anticipate logs doing crazy things like constantly changing their > > > directory in an effort to stymie auditing and hide misbehavior. > > > > > > Thus, CT's use of directories would need to be quite well > specified. > > > It is not a change that should be rushed at the last minute > without a > > > chance for people to carefully examine and poke holes in it. > > > > Agreed. > > > > > CT clients already need to be configured with a number of > parameters > > > for each log - MMD, hash algorithm, public key, log ID, and so on. > > > Adding a directory would bifurcate log metadata between the > existing > > > parameter set and the new directory object. > > > > > > I propose satisfying BCP 190 by simply specifying the URL for each > > > endpoint as a separate log parameter. This is a very minimal > > change to > > > the protocol and avoids the problems above. > > > > I agree that it would make sense to require each endpoint to be > > specified as a log parameter. Your point about bifurcation is well > > made. > > > > So then I think the question is: Should 6962-bis specify a > "directory" > > endpoint that returns a JSON structure that contains all of the log's > > parameters (including each of the endpoint URLs)? Or should 6962-bis > > not mandate any particular format by which log operators should > > distribute this information? > > > > Currently, 6962-bis doesn't mandate a format, but it does point to an > > example format: > > "[JSON.Metadata] is an example of a metadata format which > > includes the > > above elements." > > > > Sadly, this claim is not currently true, because [JSON.Metadata] > > (https://www.gstatic.com/ct/log_list/log_list_schema.json) does not > > currently "include the above elements". We should fix this somehow. > > But how? > > > > Also, how often is a CT client expected to refresh log metadata it > has > > obtained from (for example) [JSON.Metadata] ? > > Is it wise to underspecify this? > > > > > Regards, > > > Andrew > > > > -- > > 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 > --00000000000040bf42058cc904d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I support Andrew Ayer and Rob Stradling's suggestion t= o " require each endpoint to be specified as a log parameter."=C2= =A0

The reasons outlined make a lot of sense from an imp= lementation perspective, our experience with RFC6962 suggest that absent ca= ching mechanisms, logs would face significant load if all clients were to a= udit them. Adding a requirement to fetch a directory would increase the loa= d for (as far as I can tell) no good reason.

I thi= nk under-specifying it right now is the only option as we have no specifica= tion of the log metadata. I don't think it's too big of a deal as w= hen people start implementing 6962-bis I expect the log metadata format wil= l evolve based on the existing schemas and, if necessary, could be standard= ized.


On Wed, Jul 3, 2019 at 2:52 PM Rob Stradling = <rob@sectigo.com> wrote:
Thanks Rob.=C2=A0 Bot= h the to-be-deprecated and new schemas are of course
focused on CT v1 (RFC6962), so ISTM that neither of them are suitable
candidates for 6962-bis to point at.

Maybe we should simply remove the "[JSON.Metadata] is an example of a =
metadata format which includes the above elements" sentence from 6962-= bis.

On 02/07/2019 18:51, Rob Percival wrote:
> FYI: That JSON schema is planned for deprecation; a new version was > proposed last year and, following a period for feedback, parties have =
> been slowly migrating to the new schema:
> https://groups= .google.com/a/chromium.org/d/topic/ct-policy/26dmpWdaSHM/discussion
>
> That thread would be a good place to propose schema changes.
>
> On Tue, 2 Jul 2019, 16:08 Rob Stradling, <rob@sectigo.com
> <mailto:rob@se= ctigo.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0Andrew, thanks for your analysis.=C2=A0 Comments in= line...
>
>=C2=A0 =C2=A0 =C2=A0On 01/07/2019 20:37, Andrew Ayer wrote:
>=C2=A0 =C2=A0 =C2=A0 > I also think .well-known URLs are a bad idea,= for the same reasons
>=C2=A0 =C2=A0 =C2=A0 > as Jacob.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I think directories are even worse.=C2=A0 Alt= hough they've been used
>=C2=A0 =C2=A0 =C2=A0 > successfully in ACME, CT has different needs = which make directories
>=C2=A0 =C2=A0 =C2=A0 > unsuitable.=C2=A0 ACME's usage pattern is= to make a series of related
>=C2=A0 =C2=A0 =C2=A0 > requests over a short time period to drive a = certificate request to
>=C2=A0 =C2=A0 =C2=A0 > issuance, with the client maintaining state b= etween each request.
>=C2=A0 =C2=A0 =C2=A0 > This makes it natural for a client to fetch t= he directory once at the
>=C2=A0 =C2=A0 =C2=A0 > beginning of an issuance "session" = and use it for the duration, since
>=C2=A0 =C2=A0 =C2=A0 > the cost of fetching the directory is amortiz= ed over all the
>=C2=A0 =C2=A0 =C2=A0requests,
>=C2=A0 =C2=A0 =C2=A0 > and the directory is unlikely to become inval= id during the session.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > However, CT's usage pattern is to make a = lot of unrelated one-off
>=C2=A0 =C2=A0 =C2=A0 > requests spread over a long period of time - = e.g. submitting a
>=C2=A0 =C2=A0 =C2=A0 > (pre)certificate, fetching an inclusion proof= , fetching the
>=C2=A0 =C2=A0 =C2=A0latest STH
>=C2=A0 =C2=A0 =C2=A0 > to send to auditors. Clients would have to ei= ther fetch a new
>=C2=A0 =C2=A0 =C2=A0directory
>=C2=A0 =C2=A0 =C2=A0 > for every request (doubling the number of req= uests made to the
>=C2=A0 =C2=A0 =C2=A0log) or
>=C2=A0 =C2=A0 =C2=A0 > cache directories in long-term state (which r= equires dealing with
>=C2=A0 =C2=A0 =C2=A0 > cached directories going stale, and requires = keeping long-term state
>=C2=A0 =C2=A0 =C2=A0 > which might not otherwise be necessary).
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > ACME's use of directories is underspecifi= ed since it doesn't say how
>=C2=A0 =C2=A0 =C2=A0 > long a directory remains valid.=C2=A0 It'= s not a big deal for ACME because
>=C2=A0 =C2=A0 =C2=A0 > ACME servers are presumed to be sane, or peop= le would switch to
>=C2=A0 =C2=A0 =C2=A0another
>=C2=A0 =C2=A0 =C2=A0 > CA.
>
>=C2=A0 =C2=A0 =C2=A0It's not been a big deal for ACME...yet.=C2=A0 = But why leave it to chance?
>
>=C2=A0 =C2=A0 =C2=A0I just filed this erratum against RFC8555:
>=C2=A0 =C2=A0 =C2=A0https://www.rfc-editor.org/errata/e= id5771
>
>=C2=A0 =C2=A0 =C2=A0 > However, CT is meant to be an adversarial pro= tocol and has to
>=C2=A0 =C2=A0 =C2=A0 > anticipate logs doing crazy things like const= antly changing their
>=C2=A0 =C2=A0 =C2=A0 > directory in an effort to stymie auditing and= hide misbehavior.
>=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > Thus, CT's use of directories would need = to be quite well specified.
>=C2=A0 =C2=A0 =C2=A0 > It is not a change that should be rushed at t= he last minute without a
>=C2=A0 =C2=A0 =C2=A0 > chance for people to carefully examine and po= ke holes in it.
>
>=C2=A0 =C2=A0 =C2=A0Agreed.
>
>=C2=A0 =C2=A0 =C2=A0 > CT clients already need to be configured with= a number of parameters
>=C2=A0 =C2=A0 =C2=A0 > for each log - MMD, hash algorithm, public ke= y, log ID, and so on.
>=C2=A0 =C2=A0 =C2=A0 > Adding a directory would bifurcate log metada= ta between the existing
>=C2=A0 =C2=A0 =C2=A0 > parameter set and the new directory object. >=C2=A0 =C2=A0 =C2=A0 >
>=C2=A0 =C2=A0 =C2=A0 > I propose satisfying BCP 190 by simply specif= ying the URL for each
>=C2=A0 =C2=A0 =C2=A0 > endpoint as a separate log parameter.=C2=A0 T= his is a very minimal
>=C2=A0 =C2=A0 =C2=A0change to
>=C2=A0 =C2=A0 =C2=A0 > the protocol and avoids the problems above. >
>=C2=A0 =C2=A0 =C2=A0I agree that it would make sense to require each en= dpoint to be
>=C2=A0 =C2=A0 =C2=A0specified as a log parameter.=C2=A0 Your point abou= t bifurcation is well
>=C2=A0 =C2=A0 =C2=A0made.
>
>=C2=A0 =C2=A0 =C2=A0So then I think the question is: Should 6962-bis sp= ecify a "directory"
>=C2=A0 =C2=A0 =C2=A0endpoint that returns a JSON structure that contain= s all of the log's
>=C2=A0 =C2=A0 =C2=A0parameters (including each of the endpoint URLs)?= =C2=A0 Or should 6962-bis
>=C2=A0 =C2=A0 =C2=A0not mandate any particular format by which log oper= ators should
>=C2=A0 =C2=A0 =C2=A0distribute this information?
>
>=C2=A0 =C2=A0 =C2=A0Currently, 6962-bis doesn't mandate a format, b= ut it does point to an
>=C2=A0 =C2=A0 =C2=A0example format:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"[JSON.Metadata] is an example o= f a metadata format which
>=C2=A0 =C2=A0 =C2=A0includes the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 above elements."
>
>=C2=A0 =C2=A0 =C2=A0Sadly, this claim is not currently true, because [J= SON.Metadata]
>=C2=A0 =C2=A0 =C2=A0(https://www.gstatic= .com/ct/log_list/log_list_schema.json) does not
>=C2=A0 =C2=A0 =C2=A0currently "include the above elements".= =C2=A0 We should fix this somehow.
>=C2=A0 =C2=A0 =C2=A0But how?
>
>=C2=A0 =C2=A0 =C2=A0Also, how often is a CT client expected to refresh = log metadata it has
>=C2=A0 =C2=A0 =C2=A0obtained from (for example) [JSON.Metadata] ?
>=C2=A0 =C2=A0 =C2=A0Is it wise to underspecify this?
>
>=C2=A0 =C2=A0 =C2=A0 > Regards,
>=C2=A0 =C2=A0 =C2=A0 > Andrew
>
>=C2=A0 =C2=A0 =C2=A0--
>=C2=A0 =C2=A0 =C2=A0Rob Stradling
>=C2=A0 =C2=A0 =C2=A0Senior Research & Development Scientist
>=C2=A0 =C2=A0 =C2=A0Sectigo Limited
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0Trans mailing list
>=C2=A0 =C2=A0 =C2=A0Trans@ietf.org <mailto:Trans@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/list= info/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
--00000000000040bf42058cc904d1-- From nobody Wed Jul 3 09:29: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 99ECC1203CF for ; Wed, 3 Jul 2019 09:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=andrewayer.name 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 CDgN4WPytmFM for ; Wed, 3 Jul 2019 09:29:41 -0700 (PDT) Received: from thomson.beanwood.com (thomson.beanwood.com [18.220.42.202]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD43F120361 for ; Wed, 3 Jul 2019 09:29:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1562171380; bh=tA2gAatXk8nObkhLObV5QPfEp6yRcLkCLDiSgNRQgeY=; h=Date:From:To:Subject:In-Reply-To:References; b=h6bGQLon0KCpgFLrqZudsBzA1JmZR7ZFIU5xwRydJ+reyspkFo2mmuwvPXTLc/goT gZOuoo6XUo6mYYwvwEedq/2iosldHTkfCQzKKEIv6tGbIsOG58mgTTPKBfQt6PNNyY 5szyzF4ogBrExVpukS9LCgcZ/OOn+ToidSbyjqNfbeUxi0bTstLVozMdvnSnQdwIvY aSeKhQ9TzfUWyqz+PeIR0trHf9JgE6y8acmIafIMaoJ9PuBbusuJYg6cy6K+821S5M ipwUIeGp+WRJ7E42NXMPvklK5QgfB2VKriOAdc7aZwioVIY+3mInnOIG+3xb+Ngkyx f+3FeQitBsj6g== Date: Wed, 3 Jul 2019 09:29:38 -0700 From: Andrew Ayer To: "trans@ietf.org" Message-Id: <20190703092938.a19bf6ad88155f0b82c9fca5@andrewayer.name> In-Reply-To: References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> <2cbff182-7c7a-4c55-b2d2-a67f41dd7436@sectigo.com> <047d5a04-4176-6651-b200-6ce7ce8a8266@sectigo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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, 03 Jul 2019 16:29:50 -0000 On Wed, 3 Jul 2019 17:04:04 +0100 Eran Messeri wrote: > I think under-specifying it right now is the only option as we have no > specification of the log metadata. I don't think it's too big of a > deal as when people start implementing 6962-bis I expect the log > metadata format will evolve based on the existing schemas and, if > necessary, could be standardized. Agreed. Regards, Andrew From nobody Thu Jul 4 07:53:40 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 C26C41201D1 for ; Thu, 4 Jul 2019 07:53:38 -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 6-I4D-CX57ez for ; Thu, 4 Jul 2019 07:53:36 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-eopbgr800085.outbound.protection.outlook.com [40.107.80.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 A27AE120142 for ; Thu, 4 Jul 2019 07:53:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-comodoca-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rqAHKotgxLgtRLyMiYLefe7A92nlolOM72QYcSTXzh0=; b=ZYsfcodkssuywnzkEr9B64gpQtoVypCiW7JIQOr7Vk7HAw+fTvqkxRus5ZQksAt9QJV2SXLjIeUEBXpNe80giiVntStZ+RjIe+vksv3AvEgoheIkDXX3Oye59ZAToeMspFCIhL7bhr4g+NXrcE37rSgwrQk1DZn37+Dt4rB1oWI= Received: from DM5PR17MB1211.namprd17.prod.outlook.com (10.173.132.148) by DM5PR17MB1515.namprd17.prod.outlook.com (10.175.221.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Thu, 4 Jul 2019 14:53:34 +0000 Received: from DM5PR17MB1211.namprd17.prod.outlook.com ([fe80::b556:345c:94cf:7258]) by DM5PR17MB1211.namprd17.prod.outlook.com ([fe80::b556:345c:94cf:7258%6]) with mapi id 15.20.2052.010; Thu, 4 Jul 2019 14:53:34 +0000 From: Rob Stradling To: Andrew Ayer , "trans@ietf.org" Thread-Topic: [Trans] Directory instead of .well-known for URL structure Thread-Index: AQHVJ7g3xV77fgqjj0ive+Voenofmqa2OUSAgAFHIICAAC3VgIABT0mAgAAk7ACAAAclAIABd3eA Date: Thu, 4 Jul 2019 14:53:34 +0000 Message-ID: <83f686e3-4e15-32a1-5a5f-ffb90822ae89@sectigo.com> References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> <2cbff182-7c7a-4c55-b2d2-a67f41dd7436@sectigo.com> <047d5a04-4176-6651-b200-6ce7ce8a8266@sectigo.com> <20190703092938.a19bf6ad88155f0b82c9fca5@andrewayer.name> In-Reply-To: <20190703092938.a19bf6ad88155f0b82c9fca5@andrewayer.name> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0320.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a4::20) To DM5PR17MB1211.namprd17.prod.outlook.com (2603:10b6:3:8b::20) 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: d510df41-bb65-458e-50b3-08d7008f6318 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR17MB1515; x-ms-traffictypediagnostic: DM5PR17MB1515: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0088C92887 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(366004)(39850400004)(376002)(346002)(199004)(189003)(6306002)(6512007)(53936002)(6246003)(2906002)(5660300002)(4744005)(478600001)(966005)(71200400001)(8936002)(71190400001)(68736007)(81156014)(25786009)(7736002)(81166006)(305945005)(8676002)(66556008)(66946007)(73956011)(53546011)(446003)(486006)(11346002)(476003)(2616005)(66446008)(6436002)(229853002)(6116002)(6486002)(256004)(66476007)(36756003)(64756008)(2501003)(31686004)(31696002)(386003)(52116002)(102836004)(6506007)(76176011)(46003)(99286004)(186003)(86362001)(110136005)(14454004)(316002)(142923001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR17MB1515; H:DM5PR17MB1211.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: sectigo.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4XKQ7El/OSuh0RRauIAxaOr9F8HJ3qBAsuCumPfWhy17SR3COJkM4w9+PvwHk4XQjsb4tdplRs1uHzegWyKyrik5KxBWmHYFMsov2GA90IDaIqAZGA8wJArtLgY2COtBXGGZr/1cyRhk/9mqiymhEpuF7VPg5q7GgNRjF3/mecYs3UPij84CFpyoMrGcl8e5rGvwOJMDCKectJT8jdDnObfKJBUxIN9XthwCKtQU0hSw8Pig324UY/DVgGkGwV8mQVf9ltMqExSJ1GCzrJTvWciCHSoAfTKtgZAVL1exOuMesWgkH2jSrN8Hj15aNYaWwHnbtMzmvoQCcfjBFCldZ15DjBq5e1uxYtMTzAOdxs/6S/M0uv7G0QKSadF/qsY29GKD1/+wtSRRbXBWEomghePwY01MDfmAAIQUo4szQ9o= Content-Type: text/plain; charset="utf-8" Content-ID: <1120E2E07FD2E644B1B5D95B60093084@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: d510df41-bb65-458e-50b3-08d7008f6318 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Jul 2019 14:53:34.3919 (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: robs@comodoca.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR17MB1515 Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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, 04 Jul 2019 14:53:39 -0000 U0dUTS4gIEhvdyBkb2VzIHRoaXMgbG9vaz8NCg0KaHR0cHM6Ly9naXRodWIuY29tL2dvb2dsZS9j ZXJ0aWZpY2F0ZS10cmFuc3BhcmVuY3ktcmZjcy9wdWxsLzMxMQ0KDQpPbiAwMy8wNy8yMDE5IDE3 OjI5LCBBbmRyZXcgQXllciB3cm90ZToNCj4gT24gV2VkLCAzIEp1bCAyMDE5IDE3OjA0OjA0ICsw MTAwDQo+IEVyYW4gTWVzc2VyaSA8ZXJhbm09NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPiB3 cm90ZToNCj4gDQo+PiBJIHRoaW5rIHVuZGVyLXNwZWNpZnlpbmcgaXQgcmlnaHQgbm93IGlzIHRo ZSBvbmx5IG9wdGlvbiBhcyB3ZSBoYXZlIG5vDQo+PiBzcGVjaWZpY2F0aW9uIG9mIHRoZSBsb2cg bWV0YWRhdGEuIEkgZG9uJ3QgdGhpbmsgaXQncyB0b28gYmlnIG9mIGENCj4+IGRlYWwgYXMgd2hl biBwZW9wbGUgc3RhcnQgaW1wbGVtZW50aW5nIDY5NjItYmlzIEkgZXhwZWN0IHRoZSBsb2cNCj4+ IG1ldGFkYXRhIGZvcm1hdCB3aWxsIGV2b2x2ZSBiYXNlZCBvbiB0aGUgZXhpc3Rpbmcgc2NoZW1h cyBhbmQsIGlmDQo+PiBuZWNlc3NhcnksIGNvdWxkIGJlIHN0YW5kYXJkaXplZC4NCj4gDQo+IEFn cmVlZC4NCj4gDQo+IFJlZ2FyZHMsDQo+IEFuZHJldw0KDQotLSANClJvYiBTdHJhZGxpbmcNClNl bmlvciBSZXNlYXJjaCAmIERldmVsb3BtZW50IFNjaWVudGlzdA0KU2VjdGlnbyBMaW1pdGVkDQoN Cg== From nobody Thu Jul 4 07:59:29 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 B3CF7120274 for ; Thu, 4 Jul 2019 07:59:26 -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=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 9DFR4FS9dJoc for ; Thu, 4 Jul 2019 07:59:24 -0700 (PDT) Received: from mail-yw1-xc34.google.com (mail-yw1-xc34.google.com [IPv6:2607:f8b0:4864:20::c34]) (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 4BDAD12025C for ; Thu, 4 Jul 2019 07:59:24 -0700 (PDT) Received: by mail-yw1-xc34.google.com with SMTP id m16so1428445ywh.12 for ; Thu, 04 Jul 2019 07:59:24 -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=BC6hL2EvgX1EUBXYqZ5FVL/2HlA94JWFlpcBuTBn/oA=; b=njI4fcdryPxEPAwFNBVsAtF6PPUWsJA5/eLKDqcDhUrHWPayOU9CEWtC4MnBuRrFH2 STaSottrCoExpQDOJvcEI8KfcXV2odbN5ReSlc7+cqFP+DwDUTOTEsc0aVWKsUIzQqES 1UvOiOxhb4Sdc1pGdbShxo8urIofKYhPkpcEkFpTW+ZW3CKkuea3EpgzVPXq/oYy6N23 X/UVSal+5SiWPx/YamR6Xi6vWB1oqFkdz4qlhbmeN0XKyWsS8Yt84uVlB19cJSJmmgGs LGPO76dzzUNnb6jypAZgco4SusaNeK46/8SyXUAiYpfhHtVi2f5zxEjM6vm+gMnnaWMx 6tXA== 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=BC6hL2EvgX1EUBXYqZ5FVL/2HlA94JWFlpcBuTBn/oA=; b=PhznA6QhXyRJ3ne54NEYxoA4JFEQi17M7szEbCgJDNScwbIIF4iqqCAT387PlwsgS2 jggweFbu+dhx7JYrTjhFQCVjONfv9+FWFHVVEHd889DsptAPtWXD5Rj8j6Wuu9+K/FVm yZFiimrzBoEz6yi2Ay3vln3B8s8VtrXKFsQgfe8afhVPpcojVR1kbd5DExeHPB0nzNLr WlujZ5nyYweQ7ysrAAXbBQYW22yvXkNLOX09TMHCJZ3PFQlW1MK5GFMQz2QmhgDKjMfk GpBur8laGbiyBJ+pOPzL5qs7qBiwGH1HwVICm91vJQB3IyrFaSZ00hUbzWc5N3d6+7PJ nd+g== X-Gm-Message-State: APjAAAVHN32XaHnHQtOKHwwWYJLyi91iO/4dHWUcEWigiNCzeHCVD19T UH8jke+r28BZhtoZbsncr5CoYGX1pJifbe/cMzpBcQ== X-Google-Smtp-Source: APXvYqwbmz/trYPM53mhPVUDWxNjD89R849I4DnLV4iRpg3eS0Y+fPMKVhhzniAyhhenWZaJ8TmXdsWSBQITG16YYFU= X-Received: by 2002:a81:4b56:: with SMTP id y83mr27768244ywa.269.1562252363089; Thu, 04 Jul 2019 07:59:23 -0700 (PDT) MIME-Version: 1.0 References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> <2cbff182-7c7a-4c55-b2d2-a67f41dd7436@sectigo.com> <047d5a04-4176-6651-b200-6ce7ce8a8266@sectigo.com> <20190703092938.a19bf6ad88155f0b82c9fca5@andrewayer.name> <83f686e3-4e15-32a1-5a5f-ffb90822ae89@sectigo.com> In-Reply-To: <83f686e3-4e15-32a1-5a5f-ffb90822ae89@sectigo.com> From: Eran Messeri Date: Thu, 4 Jul 2019 15:58:56 +0100 Message-ID: To: Rob Stradling Cc: Andrew Ayer , "trans@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002734b1058cdc3975" Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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, 04 Jul 2019 14:59:27 -0000 --0000000000002734b1058cdc3975 Content-Type: text/plain; charset="UTF-8" Looks good to me. On Thu, Jul 4, 2019 at 3:53 PM Rob Stradling wrote: > SGTM. How does this look? > > https://github.com/google/certificate-transparency-rfcs/pull/311 > > On 03/07/2019 17:29, Andrew Ayer wrote: > > On Wed, 3 Jul 2019 17:04:04 +0100 > > Eran Messeri wrote: > > > >> I think under-specifying it right now is the only option as we have no > >> specification of the log metadata. I don't think it's too big of a > >> deal as when people start implementing 6962-bis I expect the log > >> metadata format will evolve based on the existing schemas and, if > >> necessary, could be standardized. > > > > Agreed. > > > > Regards, > > Andrew > > -- > Rob Stradling > Senior Research & Development Scientist > Sectigo Limited > > _______________________________________________ > Trans mailing list > Trans@ietf.org > https://www.ietf.org/mailman/listinfo/trans > --0000000000002734b1058cdc3975 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Looks good to me.

On Thu, Jul 4, 2019 at 3:53 PM Rob Stradl= ing <rob@sectigo.com> wrote:
SGTM.=C2=A0 How d= oes this look?

https://github.com/google/certificat= e-transparency-rfcs/pull/311

On 03/07/2019 17:29, Andrew Ayer wrote:
> On Wed, 3 Jul 2019 17:04:04 +0100
> Eran Messeri <eranm=3D40google.com@dmarc.ietf.org> wrote:
>
>> I think under-specifying it right now is the only option as we hav= e no
>> specification of the log metadata. I don't think it's too = big of a
>> deal as when people start implementing 6962-bis I expect the log >> metadata format will evolve based on the existing schemas and, if<= br> >> necessary, could be standardized.
>
> Agreed.
>
> Regards,
> Andrew

--
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited

_______________________________________________
Trans mailing list
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans
--0000000000002734b1058cdc3975-- From nobody Fri Jul 5 04:44:47 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 DB5D312004D for ; Fri, 5 Jul 2019 04:44:45 -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 E6MEjqlODkRQ for ; Fri, 5 Jul 2019 04:44:43 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820070.outbound.protection.outlook.com [40.107.82.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAE75120018 for ; Fri, 5 Jul 2019 04:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comodoca.onmicrosoft.com; s=selector1-comodoca-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gCmXfi7JQNWrussz8D8Wq1PlaHE0IQ/YDarsNotCXSk=; b=ZfY0NNPShg0gTzg4REsUp+gLKdeIxwDpIcFQdbCpyyqBG22PxXhudAZjntHUtxoCYOXBIdBWE3sAWhy6EmO9qvxhcdYICV7IqnUXfExnIJQHLc9nCDEZ7ehVDmWnPd76+lQkdaNsmK2JjT6IREFR+sZV38AJX4OzmaFHXgcz9fo= Received: from DM5PR17MB1211.namprd17.prod.outlook.com (10.173.132.148) by DM5PR17MB1338.namprd17.prod.outlook.com (10.173.134.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Fri, 5 Jul 2019 11:44:38 +0000 Received: from DM5PR17MB1211.namprd17.prod.outlook.com ([fe80::b556:345c:94cf:7258]) by DM5PR17MB1211.namprd17.prod.outlook.com ([fe80::b556:345c:94cf:7258%6]) with mapi id 15.20.2052.010; Fri, 5 Jul 2019 11:44:38 +0000 From: Rob Stradling To: "trans@ietf.org" CC: Eran Messeri , Andrew Ayer Thread-Topic: [Trans] Directory instead of .well-known for URL structure Thread-Index: AQHVJ7g3xV77fgqjj0ive+Voenofmqa2OUSAgAFHIICAAC3VgIABT0mAgAAk7ACAAAclAIABd3eAgAABhgCAAVwGgA== Date: Fri, 5 Jul 2019 11:44:38 +0000 Message-ID: <8eb2939b-c6b1-a80b-787f-4d3c02b73f8b@sectigo.com> References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> <2cbff182-7c7a-4c55-b2d2-a67f41dd7436@sectigo.com> <047d5a04-4176-6651-b200-6ce7ce8a8266@sectigo.com> <20190703092938.a19bf6ad88155f0b82c9fca5@andrewayer.name> <83f686e3-4e15-32a1-5a5f-ffb90822ae89@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: LO2P265CA0388.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:f::16) To DM5PR17MB1211.namprd17.prod.outlook.com (2603:10b6:3:8b::20) 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: 1ee5e77d-184d-40fc-f1b5-08d7013e28fa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR17MB1338; x-ms-traffictypediagnostic: DM5PR17MB1338: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(396003)(366004)(376002)(346002)(136003)(189003)(199004)(5660300002)(71190400001)(71200400001)(7736002)(2906002)(54906003)(102836004)(4326008)(46003)(2351001)(186003)(316002)(8936002)(31696002)(66446008)(64756008)(66556008)(66476007)(6916009)(81166006)(66946007)(73956011)(486006)(14454004)(81156014)(1730700003)(256004)(8676002)(86362001)(305945005)(2616005)(11346002)(446003)(476003)(2501003)(6116002)(478600001)(76176011)(31686004)(99286004)(68736007)(5640700003)(6306002)(53936002)(52116002)(6436002)(6512007)(6486002)(386003)(966005)(229853002)(53546011)(25786009)(6506007)(6246003)(36756003)(142923001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR17MB1338; H:DM5PR17MB1211.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-message-info: 87XeHXEa7rMOZn61XPI7ZqQIq/dKFZDUXo+Ecfic5eCCxkg2kEFcKq0A4voTtvj/+OcI446mF3iyh1qVTNP0fX+LFU25F79Pqop5iER881Q8SkUqyhq5j4kGMlIqBCOrIEsSxjsag/DsM8E8k4l0frJszd/BaF4Fo+FK1h95AmZj87PRxJNyyEv0m0Su97zjH1uENFXruBuu+Gn2qBBIGyxIPnnduuDOsiIOYIUgXpjqmDwp0jQ/RRPjMx4P4g6HlqRVtuy5RveVkCf5maCUKPV0d5y39sq02gxx5XIPaLZUzWJLYUq2wFSj6sNQFe/w2JOTCWXsPfxwDdg3rdz0gtxXxXDGVSDvquNr6PbjGOZN4ZgRZbfUBKreCDsz3zwLmBegzjJsnUVfsQdE7GtsAowIiwF2Nc3wWXHOh6cncZw= 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: 1ee5e77d-184d-40fc-f1b5-08d7013e28fa X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 11:44:38.6251 (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: robs@comodoca.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR17MB1338 Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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, 05 Jul 2019 11:44:46 -0000 SmFtZXMgTWFuYWdlciBjb21tZW50ZWQgb24gdGhpcyBQUiBbMV06DQoNCiJUaGUgbG9nIHBhcmFt ZXRlcnMgYXJlIG5vdCBVUkxzLCBidXQgVVJMIHRlbXBsYXRlcy4NClRoZSB2YXJpYWJsZXMgdGhh dCBjYW4gYXBwZWFyIGluIHRoZSB0ZW1wbGF0ZXMgbmVlZCB0byBiZSBkZWZpbmVkIGFzIA0Kd2Vs bC4gVGhhdCBpcywgJ2ZpcnN0JywgJ3NlY29uZCcsICdoYXNoJywgJ3N0YXJ0LCBhbmQgJ2VuZCcg Zm9yIHZhcmlvdXMgDQp0ZW1wbGF0ZXMuDQpPdGhlcndpc2UgdGhlIHNwZWMgaXMgc3RpbGwgZm9y Y2luZyBVUkwgc3RydWN0dXJlIG9uIHNlcnZlcnMgKGllIA0KdmFyaWFibGVzIE1VU1QgYmUgcXVl cnlzdHJpbmcgZmllbGRzIHdpdGggdGhlc2UgZ2l2ZW4gbmFtZXMpLiINCg0KSG93IGRvIGZvbGtz IGZlZWwgYWJvdXQgdGhpcz8NCg0KDQpbMV0gDQpodHRwczovL2dpdGh1Yi5jb20vZ29vZ2xlL2Nl cnRpZmljYXRlLXRyYW5zcGFyZW5jeS1yZmNzL3B1bGwvMzExI3B1bGxyZXF1ZXN0cmV2aWV3LTI1 ODE4NDg2NQ0KDQpPbiAwNC8wNy8yMDE5IDE1OjU4LCBFcmFuIE1lc3Nlcmkgd3JvdGU6DQo+IExv b2tzIGdvb2QgdG8gbWUuDQo+IA0KPiBPbiBUaHUsIEp1bCA0LCAyMDE5IGF0IDM6NTMgUE0gUm9i IFN0cmFkbGluZyA8cm9iQHNlY3RpZ28uY29tIA0KPiA8bWFpbHRvOnJvYkBzZWN0aWdvLmNvbT4+ IHdyb3RlOg0KPiANCj4gICAgIFNHVE0uwqAgSG93IGRvZXMgdGhpcyBsb29rPw0KPiANCj4gICAg IGh0dHBzOi8vZ2l0aHViLmNvbS9nb29nbGUvY2VydGlmaWNhdGUtdHJhbnNwYXJlbmN5LXJmY3Mv cHVsbC8zMTENCj4gDQo+ICAgICBPbiAwMy8wNy8yMDE5IDE3OjI5LCBBbmRyZXcgQXllciB3cm90 ZToNCj4gICAgICA+IE9uIFdlZCwgMyBKdWwgMjAxOSAxNzowNDowNCArMDEwMA0KPiAgICAgID4g RXJhbiBNZXNzZXJpIDxlcmFubT00MGdvb2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcNCj4gICAgIDxt YWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPj4gd3JvdGU6DQo+ICAgICAgPg0KPiAg ICAgID4+IEkgdGhpbmsgdW5kZXItc3BlY2lmeWluZyBpdCByaWdodCBub3cgaXMgdGhlIG9ubHkg b3B0aW9uIGFzIHdlDQo+ICAgICBoYXZlIG5vDQo+ICAgICAgPj4gc3BlY2lmaWNhdGlvbiBvZiB0 aGUgbG9nIG1ldGFkYXRhLiBJIGRvbid0IHRoaW5rIGl0J3MgdG9vIGJpZyBvZiBhDQo+ICAgICAg Pj4gZGVhbCBhcyB3aGVuIHBlb3BsZSBzdGFydCBpbXBsZW1lbnRpbmcgNjk2Mi1iaXMgSSBleHBl Y3QgdGhlIGxvZw0KPiAgICAgID4+IG1ldGFkYXRhIGZvcm1hdCB3aWxsIGV2b2x2ZSBiYXNlZCBv biB0aGUgZXhpc3Rpbmcgc2NoZW1hcyBhbmQsIGlmDQo+ICAgICAgPj4gbmVjZXNzYXJ5LCBjb3Vs ZCBiZSBzdGFuZGFyZGl6ZWQuDQo+ICAgICAgPg0KPiAgICAgID4gQWdyZWVkLg0KPiAgICAgID4N Cj4gICAgICA+IFJlZ2FyZHMsDQo+ICAgICAgPiBBbmRyZXcNCg0KLS0gDQpSb2IgU3RyYWRsaW5n DQpTZW5pb3IgUmVzZWFyY2ggJiBEZXZlbG9wbWVudCBTY2llbnRpc3QNClNlY3RpZ28gTGltaXRl ZA0KDQo= From nobody Mon Jul 8 15:34:48 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 0FED912037C for ; Mon, 8 Jul 2019 15:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.003 X-Spam-Level: X-Spam-Status: No, score=-7.003 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_HI=-5, 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=eff.org 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 dx4Z0gZkcK6P for ; Mon, 8 Jul 2019 15:34:35 -0700 (PDT) Received: from mail2.eff.org (mail2.eff.org [173.239.79.204]) (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 935C31203AB for ; Mon, 8 Jul 2019 15:34:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=eff.org; s=mail2; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=UnK/8nhgXfFwfzIXEjCL46fTsTTshEkIutyyiS7+CE4=; b=Pi+QaXQp9mffyo0optyygshy24 inlc3hztfSriVBl+SFHgeJ21AsddnuzJ1sDQP+lW40HYlZhcaEJ7L1HOXAgaLKjdp3W4VjHC7QuOt vJQLUuB7onU5fkDxfpQJGcF9fijNSKM2PqIrmXLhBJmH0Y9c1tCCtE7XNLuxAPu5rdQ4=; Received: ; Mon, 08 Jul 2019 15:34:34 -0700 To: trans@ietf.org References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> <2cbff182-7c7a-4c55-b2d2-a67f41dd7436@sectigo.com> <047d5a04-4176-6651-b200-6ce7ce8a8266@sectigo.com> <20190703092938.a19bf6ad88155f0b82c9fca5@andrewayer.name> <83f686e3-4e15-32a1-5a5f-ffb90822ae89@sectigo.com> <8eb2939b-c6b1-a80b-787f-4d3c02b73f8b@sectigo.com> From: Jacob Hoffman-Andrews Message-ID: <7cda0748-fcc0-0eb0-7a96-57a6f72b0a8d@eff.org> Date: Mon, 8 Jul 2019 15:34:33 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <8eb2939b-c6b1-a80b-787f-4d3c02b73f8b@sectigo.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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, 08 Jul 2019 22:34:46 -0000 On 7/5/19 4:44 AM, Rob Stradling wrote: > James Manager commented on this PR [1]: > > "The log parameters are not URLs, but URL templates. > The variables that can appear in the templates need to be defined as > well. That is, 'first', 'second', 'hash', 'start, and 'end' for various > templates. > Otherwise the spec is still forcing URL structure on servers (ie > variables MUST be querystring fields with these given names)." > > How do folks feel about this? > > > [1] > https://github.com/google/certificate-transparency-rfcs/pull/311#pullrequestreview-258184865 This is a good point. At this point we've examined a good number of alternatives (.well-known, directory, and log parameters), and found that they all introduce significant complexity and implementation problems. On the other hand, RFC 6960, which specifies paths and parameters under a common URL root, has been working terrifically in production for many years. No implementer has complained about any sort of difficulty in implementing that particular path structure. I think we should appeal to "rough consensus and running code," and say that BCP 190 does not add value here. Worse, it threatens to tie us into pretzels trying to work around it. From nobody Mon Jul 8 17:51: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 7F7D6120045 for ; Mon, 8 Jul 2019 17:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=andrewayer.name 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 NC1T8tAQZoxy for ; Mon, 8 Jul 2019 17:51:18 -0700 (PDT) Received: from thomson.beanwood.com (thomson.beanwood.com [18.220.42.202]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965FD12023F for ; Mon, 8 Jul 2019 17:51:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1562633477; bh=xNccySOVqVm/oGU0UmFIrhhaRU/qAxT/f9ILND7K9w4=; h=Date:From:To:Subject:In-Reply-To:References; b=BxvIoEp3LrU93Ehg6pYM0TQo4HIbY3OzCDmZnJrvUdzs4JE6LBWRj8yy3K7KiFOHB u+3J7KjsUwZIWSjNdLnwv3JTdwmqXIyXyRWOchrK2ytY5uvFqa9JU29NySwLjeM/IL nbHXs7Bx4nZGDnDOLEICUdBC9dcUJCQkUf7uu1dtnnah30D0ggWwWIo8Vhdqcv3/bQ UOjrNRkP22skEXIt46IjXb440tqeTolb/3CgBqUuj5Pxmk3FrnKjdBeucmbSx9s/dD jvwRHLpGEDCmhXCQ9d8wFZnHy/fgutAMWhCNuthUzgagLX6DSukIbA457VJgD4BN6N D6XjlSUbb3irA== Date: Mon, 8 Jul 2019 17:57:45 -0700 From: Andrew Ayer To: "trans@ietf.org" Message-Id: <20190708175745.563c1e39f82c3b176900043e@andrewayer.name> In-Reply-To: <8eb2939b-c6b1-a80b-787f-4d3c02b73f8b@sectigo.com> References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> <2cbff182-7c7a-4c55-b2d2-a67f41dd7436@sectigo.com> <047d5a04-4176-6651-b200-6ce7ce8a8266@sectigo.com> <20190703092938.a19bf6ad88155f0b82c9fca5@andrewayer.name> <83f686e3-4e15-32a1-5a5f-ffb90822ae89@sectigo.com> <8eb2939b-c6b1-a80b-787f-4d3c02b73f8b@sectigo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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: Tue, 09 Jul 2019 00:51:21 -0000 On Fri, 5 Jul 2019 11:44:38 +0000 Rob Stradling wrote: > James Manager commented on this PR [1]: > > "The log parameters are not URLs, but URL templates. > The variables that can appear in the templates need to be defined as > well. That is, 'first', 'second', 'hash', 'start, and 'end' for > various templates. > Otherwise the spec is still forcing URL structure on servers (ie > variables MUST be querystring fields with these given names)." > > How do folks feel about this? I'm opposed to using URL templates, as it would increase client complexity by forcing them to include template interpolation logic. This WG has already reached consensus that BCP 190 compliance is unnecessary for CT, as years of real-world experience with RFC6962 deployment has showed that no log operator needs the additional flexibility that BCP 190 aims to provide. I think we should go further and say that BCP 190 compliance is detrimental to CT, as we've explored several options to add compliance and they all make CT worse - by *reducing* flexibility for log operators in a way that actually causes them problems (well-known), increasing the load on logs (directories), or by adding complexity to clients (URL templates). I doubt that the intent of BCP 190 was to make protocols worse. I hope we can move forward without BCP 190 compliance in CT. Regards, Andrew From nobody Mon Jul 8 22:21: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 545911201D0 for ; Mon, 8 Jul 2019 22:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.107 X-Spam-Level: X-Spam-Status: No, score=-0.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.247, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, HTML_MESSAGE=0.001, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 KAy-o3yzNZ21 for ; Mon, 8 Jul 2019 22:21:24 -0700 (PDT) Received: from mail-ed1-f52.google.com (mail-ed1-f52.google.com [209.85.208.52]) (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 9F73A1200EC for ; Mon, 8 Jul 2019 22:21:23 -0700 (PDT) Received: by mail-ed1-f52.google.com with SMTP id w20so16505729edd.2 for ; Mon, 08 Jul 2019 22:21:23 -0700 (PDT) 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=pEMlajfhqyAbNiKl9WgyEahbmX5/kwZWkMvAn8SUhFI=; b=GSkHUnqE9iUvLA6T2acFBMFN7vfFY+gty94OnJp+TZYDNGyvTZWDzBcpjg3mvEYNJ6 ui23H15NMCv5MddSzyQWO8+PeHjtYlj0x1Br3gUOFshEB9veLBzbGLEqxVq51v5h8KXO qltRsgJ3r/nwRAOBznYMG8zNsEm/A6iH2gQHtGN3hopGyLMSzdZBPrfHZ5+tNd8XSlJN boVvspjd50x02b6l4qwUUiA82ypFHBva/vO+Jy3UE4CP+4rffuAbCTRuOOsIXUOuwAME SsniIFxImgB8nzQhKBz51HsOsCaHBWEP+TfgEEFqk1mtQST1n+H1Q3sAfQIpnk+Pnahp 1UPA== X-Gm-Message-State: APjAAAWdVzvtEbp9ZjfHQiZJ/SkQk/ySSVf1rr7gh9OkGq4LVCCy292J n0nTQUCqY2ARcfAddzyx6aNeL5A7 X-Google-Smtp-Source: APXvYqzglktECYyYf6882m4n92jAYKnqAfBsn03xkHc7F5UuqYKr/+WlmJfUxLTCCTEhr2oRtcMhgA== X-Received: by 2002:a17:906:4354:: with SMTP id z20mr19276418ejm.163.1562649681729; Mon, 08 Jul 2019 22:21:21 -0700 (PDT) Received: from mail-wr1-f43.google.com (mail-wr1-f43.google.com. [209.85.221.43]) by smtp.gmail.com with ESMTPSA id q18sm3808481ejm.5.2019.07.08.22.21.21 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 22:21:21 -0700 (PDT) Received: by mail-wr1-f43.google.com with SMTP id g17so9323447wrr.5 for ; Mon, 08 Jul 2019 22:21:21 -0700 (PDT) X-Received: by 2002:adf:ab4a:: with SMTP id r10mr20569075wrc.95.1562649680963; Mon, 08 Jul 2019 22:21:20 -0700 (PDT) MIME-Version: 1.0 References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <20190701123701.b3ba6b44ef85a74da6209e64@andrewayer.name> <2cbff182-7c7a-4c55-b2d2-a67f41dd7436@sectigo.com> <047d5a04-4176-6651-b200-6ce7ce8a8266@sectigo.com> <20190703092938.a19bf6ad88155f0b82c9fca5@andrewayer.name> <83f686e3-4e15-32a1-5a5f-ffb90822ae89@sectigo.com> <8eb2939b-c6b1-a80b-787f-4d3c02b73f8b@sectigo.com> <20190708175745.563c1e39f82c3b176900043e@andrewayer.name> In-Reply-To: <20190708175745.563c1e39f82c3b176900043e@andrewayer.name> From: Ryan Sleevi Date: Tue, 9 Jul 2019 01:21:11 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Andrew Ayer Cc: "trans@ietf.org" Content-Type: multipart/alternative; boundary="000000000000246d5e058d38bbcb" Archived-At: Subject: Re: [Trans] Directory instead of .well-known for URL structure 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: Tue, 09 Jul 2019 05:21:25 -0000 --000000000000246d5e058d38bbcb Content-Type: text/plain; charset="UTF-8" On Mon, Jul 8, 2019 at 8:51 PM Andrew Ayer wrote: > On Fri, 5 Jul 2019 11:44:38 +0000 > Rob Stradling wrote: > > > James Manager commented on this PR [1]: > > > > "The log parameters are not URLs, but URL templates. > > The variables that can appear in the templates need to be defined as > > well. That is, 'first', 'second', 'hash', 'start, and 'end' for > > various templates. > > Otherwise the spec is still forcing URL structure on servers (ie > > variables MUST be querystring fields with these given names)." > > > > How do folks feel about this? > > I'm opposed to using URL templates, as it would increase client > complexity by forcing them to include template interpolation logic. > > This WG has already reached consensus that BCP 190 compliance is > unnecessary for CT, as years of real-world experience with RFC6962 > deployment has showed that no log operator needs the additional > flexibility that BCP 190 aims to provide. I think we should go further > and say that BCP 190 compliance is detrimental to CT, as we've > explored several options to add compliance and they all make CT worse - > by *reducing* flexibility for log operators in a way that actually > causes them problems (well-known), increasing the load on logs > (directories), or by adding complexity to clients (URL templates). I > doubt that the intent of BCP 190 was to make protocols worse. I hope > we can move forward without BCP 190 compliance in CT. > As Andrew mentioned, many of the suggestions seem to concretely make the ecosystem less reliable, by making it easier for Log Operators to exploit the non-cryptographically-verifiable portions of the protocol. A significant motivating factor in the development of Chrome's CT Policy, for example, was to attempt to profile down the extant RFC 6962 flexibility, such as with HTTP error codes and the ability to request payments or authorization for "public" data, in order to ensure that the Logs it used were themselves useful to clients. These, in turn, are themselves arguably security considerations that impact the overall utility of CT. I agree with the discussion about the reasons against .well-known and directories; they highlight real tradeoffs that cause more harm than good. .well-known should be tightly controlled and restricted; and thus, as a practical matter, makes it difficult to impossible to host CT Logs on a number of domains or server infrastructures. Similarly, as noted, directories pass on costs not only to clients, but to the monitoring ecosystem and to those that wish to ensure Logs adhere to a stated set of operational policies and practices. As it relates to URL templates, I'm less opposed, if only because I expect that a natural consequence of this would be to use policy to profile the URL templates into a predictable form in order to provide the necessary security and reliability. As a consequence, I don't anticipate clients ever needing to implement these, except those clients which might interact with CT Logs that are limited in scope or application, and not widely used. Functionally, this means that the flexibility intended by the use of URL templates is unlikely to be realized in practice in running code. As a consequence, it's a joint of flexibility that will quickly rust shut, because keeping it well-oiled is counterintuitively hostile to the ecosystem. Hopefully that provides a compelling argument against adopting some of said flexibility. However, if there is consensus to do so, despite the various arguments against, I would prefer the URL templates so that they can be most easily profiled away with limited impact to clients and with the least 'industry' profiling of the applicable standard. --000000000000246d5e058d38bbcb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Jul 8, 2019 at 8:51 PM Andrew= Ayer <agwa@andrewayer.name&= gt; wrote:
On Fr= i, 5 Jul 2019 11:44:38 +0000
Rob Stradling <rob@= sectigo.com> wrote:

> James Manager commented on this PR [1]:
>
> "The log parameters are not URLs, but URL templates.
> The variables that can appear in the templates need to be defined as <= br> > well. That is, 'first', 'second', 'hash', '= ;start, and 'end' for
> various templates.
> Otherwise the spec is still forcing URL structure on servers (ie
> variables MUST be querystring fields with these given names)." >
> How do folks feel about this?

I'm opposed to using URL templates, as it would increase client
complexity by forcing them to include template interpolation logic.

This WG has already reached consensus that BCP 190 compliance is
unnecessary for CT, as years of real-world experience with RFC6962
deployment has showed that no log operator needs the additional
flexibility that BCP 190 aims to provide.=C2=A0 I think we should go furthe= r
and say that BCP 190 compliance is detrimental to CT, as we've
explored several options to add compliance and they all make CT worse -
by *reducing* flexibility for log operators in a way that actually
causes them problems (well-known), increasing the load on logs
(directories), or by adding complexity to clients (URL templates).=C2=A0 I<= br> doubt that the intent of BCP 190 was to make protocols worse.=C2=A0 I hope<= br> we can move forward without BCP 190 compliance in CT.
=
As Andrew mentioned, many of the suggestions seem to concret= ely make the ecosystem less reliable, by making it easier for Log Operators= to exploit the non-cryptographically-verifiable portions of the protocol. = A significant motivating factor in the development of Chrome's CT Polic= y, for example, was to attempt to profile down the extant RFC 6962 flexibil= ity, such as with HTTP error codes and the ability to request payments or a= uthorization for "public" data, in order to ensure that the Logs = it used were themselves useful to clients. These, in turn, are themselves a= rguably security considerations that impact the overall utility of CT.

I agree with the discussion about the reasons against = .well-known and directories; they highlight real tradeoffs that cause more = harm than good. .well-known should be tightly controlled and restricted; an= d thus, as a practical matter, makes it difficult to impossible to host CT = Logs on a number of domains or server infrastructures. Similarly, as noted,= directories pass on costs not only to clients, but to the monitoring ecosy= stem and to those that wish to ensure Logs adhere to a stated set of operat= ional policies and practices.

As it relates to URL= templates, I'm less opposed, if only because I expect that a natural c= onsequence of this would be to use policy to profile the URL templates into= a predictable form in order to provide the necessary security and reliabil= ity. As a consequence, I don't anticipate clients ever needing to imple= ment these, except those clients which might interact with CT Logs that are= limited in scope or application, and not widely used. Functionally, this m= eans that the flexibility intended by the use of URL templates is unlikely = to be realized in practice in running code. As a consequence, it's a jo= int of flexibility that will quickly rust shut, because keeping it well-oil= ed is counterintuitively hostile to the ecosystem.

Hopefully that provides a compelling argument against adopting some of sai= d flexibility. However, if there is consensus to do so, despite the various= arguments against, I would prefer the URL templates so that they can be mo= st easily profiled away with limited impact to clients and with the least &= #39;industry' profiling of the applicable standard.
--000000000000246d5e058d38bbcb-- From nobody Thu Jul 11 15:26:54 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 6F4471200F8 for ; Thu, 11 Jul 2019 15:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.704 X-Spam-Level: X-Spam-Status: No, score=-0.704 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, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 Mylgawp6bhaL for ; Thu, 11 Jul 2019 15:26:52 -0700 (PDT) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 260661200DB for ; Thu, 11 Jul 2019 15:26:52 -0700 (PDT) Received: by mail-pl1-x633.google.com with SMTP id m9so3729521pls.8 for ; Thu, 11 Jul 2019 15:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=a3KdaxkFNliklQSn31lKqOj9jxuST1jpTIWgz/tYmPw=; b=AykUNz4FE6MVp+l+4jEMDgJfIVHg0FntKCNfSrpfxxRkdCdXClDU1mRfU2u2dfoj97 Uvjuec3HM2+GDQ52kySDfrn56YNmY5UmOzzbRmO6JQdz5co78JlvPe0ta4cY3tjL3CKM +rkH7uivl0gM7YuWVnjmUDjmRP+CECjClQ5sBvGPIKTJinKoyIEOPrt7vRRPEoe+2YoK /3XPaNimxk+E+pDnwSv38cTJy1GxstQ2Su/018VwADIChRxZfvzDSL/5ljUtkA+CNq4x 8RFSb+oOXeh/Ynpd3LsWtwdWWb2xzPnWLMMQQLMROS7Az7fPPPKGdb7Ei9HML3PGrvhW D3PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=a3KdaxkFNliklQSn31lKqOj9jxuST1jpTIWgz/tYmPw=; b=s869rBcZD3c2Q0o4aHOqlgMnT5X3qbtVrK690N32gWmwH4YTb+N2eQrLqMD2DTjNNm 30zBH6YJE/ATb38f3YbZA26bHyO4XkjJ+9QYxwX9IbFUVQqUyYjmxb/LoIzxL4Ih91Iv N8w00LhvAoNj4lm+Mrb/dwt2MON6JlBPT2xtj+64FaRKgc4g6AWzxPYqMilMOnte3dYT bUtG6QytWZvVKtEI1rWxCrmos8oFm+a0khPkoNQx71sG8pMtcKgO7CA57gFmJmsExFDI O6drRPLTN17JPYvWRPMv4+HE7tMreJ/awOLy0dxK6Dly/VoFlLZ+W9vu5cq0wD2oYZL3 HICw== X-Gm-Message-State: APjAAAXENDkYRMj/jhDmgIGNfQtELDt1aiDOpRA6tH94PyGwUxyAZv42 7t5ntYBaUuDsHH03zjEmGPkOevsC X-Google-Smtp-Source: APXvYqy1mf1nUqMMGKoROO5cBUn+DdQ7ZDBYSsP+eR/T8eXus2GIX5hmSfvH3rEkPG0twBGbFTMkjQ== X-Received: by 2002:a17:902:2a68:: with SMTP id i95mr7371829plb.167.1562884011283; Thu, 11 Jul 2019 15:26:51 -0700 (PDT) Received: from aspen.local (63-140-64-252.dynamic.lte.acsalaska.net. [63.140.64.252]) by smtp.gmail.com with ESMTPSA id 21sm6111164pjh.25.2019.07.11.15.26.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Jul 2019 15:26:50 -0700 (PDT) To: "trans@ietf.org" From: Melinda Shore Message-ID: <90d308a9-2619-631c-4b78-67ce77918dff@gmail.com> Date: Thu, 11 Jul 2019 14:26:49 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [Trans] 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: Thu, 11 Jul 2019 22:26:54 -0000 Hi, all: While we've got agreement among the cohort that BCP 190 conformance would be onerous and it does not bring any advantages to us, there is a DISCUSS on that that's preventing the document from progressing. I exchanged email with Adam and for now the way forward is for us to work to get consensus in the ART area that BCP 190 requirements should be relaxed. Rob is drafting email to the ART mailing list, and we've got 10 minutes on the ART agenda in Montreal (Monday at 18:10 in the Laurier room) for discussion. Melinda -- Melinda Shore melinda.shore@gmail.com Software longa, hardware brevis From nobody Fri Jul 12 12:03: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 79225120869 for ; Fri, 12 Jul 2019 12:03:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 iyoqtH7YU3ZA for ; Fri, 12 Jul 2019 12:03:03 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 A75171201E0 for ; Fri, 12 Jul 2019 12:03:03 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x6CJ2umP042627 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 12 Jul 2019 14:02:58 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1562958179; bh=dCPY2B3vaeotzCDTuPKKbiRGV0DznPc1W2yMpqy+efU=; h=Subject:To:References:From:Date:In-Reply-To; b=evFdso8KOCvvlS5QbidlJjs0azKVJzovMp2kt+0uauNvsSKHBdNRar95JFQYFUxH0 5t1DdXT/h+/FUoZYYc/CP1kudYyMn2eXBiWGqFSZNAFpoj1POYTlQJFIR29jsIr3QP 5G2aCsq6o3NKydSvWRvzOOdmO0YxnrJjX8p2zX08= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Melinda Shore , "trans@ietf.org" References: <90d308a9-2619-631c-4b78-67ce77918dff@gmail.com> From: Adam Roach Message-ID: <5213bc63-46e7-51a9-6982-8baba84d604d@nostrum.com> Date: Fri, 12 Jul 2019 14:02:51 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 In-Reply-To: <90d308a9-2619-631c-4b78-67ce77918dff@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Trans] 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: Fri, 12 Jul 2019 19:03:06 -0000 On 7/11/19 5:26 PM, Melinda Shore wrote: > While we've got agreement among the cohort that BCP 190 > conformance would be onerous and it does not bring any > advantages to us... As advice to people planning to engage in this conversation, I would like to point out that the purpose of BCP 190 has never been to provide advantages to protocol designers. That is, in fact, the opposite of its purpose. The purpose of BCP 190 is to provide protections to the URI namespace and the people who own its governance (e.g., domain owners) *against* protocol designers. You will have far more success communicating with those people who think the current text in BCP 190 is correct if you keep this in mind, and frame your arguments accordingly. /a From nobody Mon Jul 15 07:46: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 2D866120157 for ; Mon, 15 Jul 2019 07:46:39 -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 4kcAWEo_NBc0 for ; Mon, 15 Jul 2019 07:46:37 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-eopbgr780040.outbound.protection.outlook.com [40.107.78.40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE1BB120116 for ; Mon, 15 Jul 2019 07:46:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ODkJ3dKLwgNIMED/BKZwTg5C57DfkML1l9/Pygg9r45QrjzHua3GBQW66maimLrg6KLSQeECSQd8bOn8pthrX35TwOtKwtApIr05q4szQX6nuixUMTqpb6oZ773PvQUPnbBORJ3Q81ynHhCi9O5+tJGn+icr5QV9ysxeqQHPE29Nr1L64n4OD5v/vRUStgbYDxIZV2fPoJSVrJmG0sLkTQ60t63wKdOnai9tqiOZ8+jCINffy+xl4VIOKsXFp1EL/ZMyWWLcqrAaE0JZILJwb9FpFeYkMCIS4Rlq0u6wZMLUCApG1brhpS5pUdZ57YEp4Cb+XMwf50XIeqs8uxJD1w== 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=sV3Pf2HFF1ft3/Uo9Ay21kMItTOqdkQXUgIirxZ6zlc=; b=GFVpqg9IOg3NxNSKDDz9oL2pNdIVSTAGarr6aFRp3uYrq/GZCX85Y6ga1yBcQLVQ6nzQn3zHJBrG/DcsJeaSk5UYYRy2O9IDeJiZQCWzKwRhmXJ3XoCdofd6mrWoHa14XeGbnIu//olgzrPLif9v61xQfnRKgMrmDql2dT2n3vmZfh2zv2KXjhzOPwC+Nf00Cyjmj/Yfyr9UDBBfStnAw/bly52BBpYPlYHrJGBLlfykkKamDR0rPpzR/EqabpBZ/1kGMqN666CRk5WqcP+WvE6Pj9Eb2EFd9xlbOU8+zDnvqxmnUPMcrWd2IkK1K8WsQWUM7KfTC9pozXVt0Y4luw== 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=selector1-comodoca-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sV3Pf2HFF1ft3/Uo9Ay21kMItTOqdkQXUgIirxZ6zlc=; b=U9U6H6u6RA2T5odNnUvsTz/qpn4P0AMNrlqVwJFV6Ett1I88Ph0S5PhQ9yEYLVHctB8mTEjDAJFrFyUSxeSKmrGSsnP0cynVhYF4DUr74W961wT9VD41TxLdQ+n1dAiZncJzpVW4F9xQoVjk1QH6109L3cmMWXfNHw/cEY16N6c= Received: from DM5PR17MB1211.namprd17.prod.outlook.com (10.173.132.148) by DM5PR17MB1545.namprd17.prod.outlook.com (10.175.222.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Mon, 15 Jul 2019 14:46:35 +0000 Received: from DM5PR17MB1211.namprd17.prod.outlook.com ([fe80::b556:345c:94cf:7258]) by DM5PR17MB1211.namprd17.prod.outlook.com ([fe80::b556:345c:94cf:7258%6]) with mapi id 15.20.2073.012; Mon, 15 Jul 2019 14:46:35 +0000 From: Rob Stradling To: "trans@ietf.org" Thread-Topic: [Trans] BCP 190 update Thread-Index: AQHVODfF9hwuIAGyIEm7onm2yhX+2qbLx70A Date: Mon, 15 Jul 2019 14:46:35 +0000 Message-ID: <216e2e5b-175d-2c0b-c99e-f93784139cec@sectigo.com> References: <90d308a9-2619-631c-4b78-67ce77918dff@gmail.com> In-Reply-To: <90d308a9-2619-631c-4b78-67ce77918dff@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0432.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:a0::36) To DM5PR17MB1211.namprd17.prod.outlook.com (2603:10b6:3:8b::20) 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: 8813b87d-775e-4d7e-39d9-08d709333bd7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR17MB1545; x-ms-traffictypediagnostic: DM5PR17MB1545: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(346002)(136003)(39860400002)(189003)(199004)(53754006)(2906002)(68736007)(6512007)(6306002)(5640700003)(4744005)(6436002)(6116002)(316002)(66476007)(66446008)(64756008)(66556008)(486006)(2616005)(31686004)(476003)(66946007)(25786009)(446003)(36756003)(102836004)(11346002)(52116002)(186003)(6916009)(386003)(76176011)(6506007)(53546011)(5660300002)(53936002)(966005)(2351001)(6246003)(8676002)(2501003)(14454004)(46003)(6486002)(15650500001)(7736002)(71190400001)(305945005)(99286004)(71200400001)(8936002)(86362001)(256004)(1730700003)(31696002)(81166006)(81156014)(478600001)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR17MB1545; H:DM5PR17MB1211.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-message-info: 1QdTAiFU4f30ecGIyKvWgMhdvyM4bqOXKt8TAXMX+UF1Rk4WClBjJ58QAkzENVPr/oZieK8v3kbpgIT31DlmA2t4c7IFogRbc5KtZfdV9EhDlSk4/EUD7Acwk1MquIVFmyPe9RGHu2W9PLRjm0cog78c55LyyCmbug76h/qkMbYETuhwJ5+3i8LwuvALtS+RgYZHuWu+6IK9HObcm9MJFDpXu9eolnKeJaOUmwb7SxQArJ5iVMH3kbvxNvZDd8SAP+LFxiS9jyM0HOAUM4OKxXgrCWezgzUF8wrtnSGlR4PbTkrb0Wh4pc68+HKPqtcfCwJGgpIp06v0kjNVKY3+4qOdI8MPOu7gkotxjTDYym2J+Oftu22qt65aFMPCRDvIbeRrn+8d5R1zrz/+g5FGBxeiB1P+2q7nHRUFlUMAyWo= Content-Type: text/plain; charset="utf-8" Content-ID: <9A7B7B04DCD18649BACA73DCDEDE8372@namprd17.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sectigo.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8813b87d-775e-4d7e-39d9-08d709333bd7 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2019 14:46:35.2080 (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: robs@comodoca.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR17MB1545 Archived-At: Subject: Re: [Trans] 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: Mon, 15 Jul 2019 14:46:39 -0000 SGkgYWxsLiAgSSBwb3N0ZWQgYSBtZXNzYWdlIHRvIHRoZSBBUlQgbGlzdDoNCg0KaHR0cHM6Ly9t YWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hcnQvckFQN3hyT2VrMWxwTzk2VVUteHVHNmJt S1JjDQooTWFueSB0aGFua3MgdG8gSmFjb2IgSG9mZm1hbi1BbmRyZXdzIGZvciBkcmFmdGluZyBt b3N0IG9mIHRoaXMgbWVzc2FnZSkuDQoNCk9uIDExLzA3LzIwMTkgMjM6MjYsIE1lbGluZGEgU2hv cmUgd3JvdGU6DQo+IEhpLCBhbGw6DQo+IA0KPiBXaGlsZSB3ZSd2ZSBnb3QgYWdyZWVtZW50IGFt b25nIHRoZSBjb2hvcnQgdGhhdCBCQ1AgMTkwDQo+IGNvbmZvcm1hbmNlIHdvdWxkIGJlIG9uZXJv dXMgYW5kIGl0IGRvZXMgbm90IGJyaW5nIGFueQ0KPiBhZHZhbnRhZ2VzIHRvIHVzLCB0aGVyZSBp cyBhIERJU0NVU1Mgb24gdGhhdCB0aGF0J3MgcHJldmVudGluZw0KPiB0aGUgZG9jdW1lbnQgZnJv bSBwcm9ncmVzc2luZy4gIEkgZXhjaGFuZ2VkIGVtYWlsIHdpdGggQWRhbQ0KPiBhbmQgZm9yIG5v dyB0aGUgd2F5IGZvcndhcmQgaXMgZm9yIHVzIHRvIHdvcmsgdG8gZ2V0IGNvbnNlbnN1cw0KPiBp biB0aGUgQVJUIGFyZWEgdGhhdCBCQ1AgMTkwIHJlcXVpcmVtZW50cyBzaG91bGQgYmUgcmVsYXhl ZC4NCj4gUm9iIGlzIGRyYWZ0aW5nIGVtYWlsIHRvIHRoZSBBUlQgbWFpbGluZyBsaXN0LCBhbmQg d2UndmUgZ290DQo+IDEwIG1pbnV0ZXMgb24gdGhlIEFSVCBhZ2VuZGEgaW4gTW9udHJlYWwgKE1v bmRheSBhdCAxODoxMA0KPiBpbiB0aGUgTGF1cmllciByb29tKSBmb3IgZGlzY3Vzc2lvbi4NCj4g DQo+IE1lbGluZGENCg0KLS0gDQpSb2IgU3RyYWRsaW5nDQpTZW5pb3IgUmVzZWFyY2ggJiBEZXZl bG9wbWVudCBTY2llbnRpc3QNClNlY3RpZ28gTGltaXRlZA0KDQo=