Re: [Trans] Directory instead of .well-known for URL structure

Rob Stradling <rob@sectigo.com> Wed, 26 June 2019 10:19 UTC

Return-Path: <rob@sectigo.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D976E120279 for <trans@ietfa.amsl.com>; Wed, 26 Jun 2019 03:19:43 -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 H5Hz5x5Nu_vp for <trans@ietfa.amsl.com>; Wed, 26 Jun 2019 03:19:41 -0700 (PDT)
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (mail-eopbgr700049.outbound.protection.outlook.com [40.107.70.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505251200EB for <trans@ietf.org>; Wed, 26 Jun 2019 03:19:41 -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=fddYF4a6r+jWUUedyjOkFydHs7EU54/zuvBm2wb8ubo=; b=XGg+zRR/VVkZJBGlY5yKpW4DcQOb9N3XkHW0DURiDlBl1FeRsXgv8FV/KRehvmQdoIIATcyDNVPsjq8ilz4E38SlYOBD78Loqut/1R9bC5GvrQa4cK8CaTtPb+Zoy2HH/ehdVqVURYMHe0atDPlPXdm26HghZPy6zmG7YyokmDA=
Received: from DM5PR17MB1211.namprd17.prod.outlook.com (10.173.132.148) by DM5PR17MB1386.namprd17.prod.outlook.com (10.173.133.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Wed, 26 Jun 2019 10:19: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.2008.018; Wed, 26 Jun 2019 10:19:38 +0000
From: Rob Stradling <rob@sectigo.com>
To: "Manger, James" <James.H.Manger@team.telstra.com>, Eran Messeri <eranm=40google.com@dmarc.ietf.org>
CC: "trans@ietf.org" <trans@ietf.org>
Thread-Topic: [Trans] Directory instead of .well-known for URL structure
Thread-Index: AQHVJ7g3xV77fgqjj0ive+Voenofmqap50UAgAAKWICAAO2MAIAAr0IAgACfBACAARnhgIAAeouA
Date: Wed, 26 Jun 2019 10:19:38 +0000
Message-ID: <986ded03-f707-f8ed-5f75-3c62313ad8d7@sectigo.com>
References: <0d5e05fc-8f1e-54b5-536d-231153e7baf7@eff.org> <48a31dcd-71d9-42c8-9ec3-6104939a59ab@www.fastmail.com> <7161898d-a58d-1625-a041-2e93961e71a2@gmail.com> <f03a2bc2-9058-bafd-37a1-50a1fd5d02d2@sectigo.com> <SY2PR01MB27648842CD64DFBC3E9E3205E5E30@SY2PR01MB2764.ausprd01.prod.outlook.com> <CALzYgEf8GZY8UPr2K3iCYuxJKqVsx1EHJiPuZkKEJJyhRy8bug@mail.gmail.com> <SY2PR01MB27644A19071F56C0DBCC69ADE5E20@SY2PR01MB2764.ausprd01.prod.outlook.com>
In-Reply-To: <SY2PR01MB27644A19071F56C0DBCC69ADE5E20@SY2PR01MB2764.ausprd01.prod.outlook.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-clientproxiedby: LNXP265CA0009.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:5e::21) 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: 6dd88dc2-96c3-4e80-2867-08d6fa1fcb3e
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR17MB1386;
x-ms-traffictypediagnostic: DM5PR17MB1386:
x-ms-exchange-purlcount: 5
x-microsoft-antispam-prvs: <DM5PR17MB13862533D6111918EFF83673AAE20@DM5PR17MB1386.namprd17.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 00808B16F3
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(39850400004)(136003)(396003)(366004)(376002)(189003)(199004)(13464003)(6246003)(76176011)(52116002)(561944003)(305945005)(6306002)(53546011)(6506007)(7736002)(2616005)(386003)(71200400001)(99286004)(4326008)(46003)(71190400001)(486006)(6436002)(8936002)(229853002)(36756003)(25786009)(186003)(14454004)(6486002)(31686004)(53936002)(31696002)(966005)(6116002)(102836004)(476003)(446003)(316002)(256004)(478600001)(73956011)(66946007)(11346002)(110136005)(66476007)(5660300002)(66556008)(64756008)(66446008)(86362001)(14444005)(2906002)(81166006)(81156014)(68736007)(8676002)(6512007)(142923001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR17MB1386; 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: ZQ1hw/X/E4rF89ZtmhcwnMScDBOZObKYAgq0pdgxwEwnmynO5VPAvoxYmt+ZUYeO4OxvCZTwDeAb9Tqyd7ZKpZYpOKyM63NLbqXAY6RYFGn/6xyEGngMXLHrViVNbLoqnPaai+IAYw1NyqCjpmr+QtBnM3sXyf0SS9EYUG32/aCl1vJ5umzXx3ee1355ydHzYcywYJN2NY+zEQzqInE6qx16cy22cIZnxIvUEzG53h3MRifm9WVyjeIDuKRraEWzOqf6EsWyZ0CIKR31fntYzL0Pog6m3JP0ar3mHVcTSl2tuDTMhMYLURyasnVWaPYxIkDEYrys1QOEWOXSfr5/OaDOEAxekHfFAtR+BGeha6ALMwfMU6oTzjADNLnX9qNneAQrfVbGeKcDt3Ggld++0iHEiCosQMM0UtKHuNZRC7k=
Content-Type: text/plain; charset="utf-8"
Content-ID: <EC2A7B5FDD93844E954CE27D7F10A536@namprd17.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: sectigo.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 6dd88dc2-96c3-4e80-2867-08d6fa1fcb3e
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 10:19:38.2854 (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: DM5PR17MB1386
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/i6MN97fPmTLfCH8RuwWEonVjk-U>
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 <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Jun 2019 10:19:44 -0000

On 26/06/2019 04:00, Manger, James wrote:
<snip>
> A directory with a separate template for every action is a more pure 
> design: it gives a log total flexibility in URL design; and is easily 
> extendable if the log API gets far more complex in future.

I prefer the directory approach (vs URI templates), for these very reasons.

Some logs might want to support additional API endpoints (e.g., there 
was a "get-sths" proposal a while ago - 
https://github.com/google/certificate-transparency-rfcs/pull/200).

And some "logs" might want to support a subset of the standard log API 
(e.g., imagine a log submission proxy that only offers a "submit-entry" 
endpoint that, when called, forwards the submit-entry request to 
multiple real logs).

> At the cost of extra calls & code to read, parse, and process the directory.

Agreed, but I think it's worth this cost.

> --
> 
> James Manger
> 
> *From:*Trans <trans-bounces@ietf.org> *On Behalf Of *Eran Messeri
> *Sent:* Tuesday, 25 June 2019 8:12 PM
> *To:* Manger, James <James.H.Manger@team.telstra.com>
> *Cc:* Rob Stradling <rob@sectigo.com>; trans@ietf.org
> *Subject:* Re: [Trans] Directory instead of .well-known for URL structure
> 
> Can you clarify if you mean a single template to cover all possible 
> actions or separate one for each action?
> 
> The former would, I think, be tricky to define as different actions have 
> different parameters.
> 
> The latter is what we had, and is not in compliance with BCP190.
> 
> Either way, the issue here is compliance with BCP190, so if your 
> proposal is in compliance with BCP190 it's worth highlighting why (as 
> it's not clear to me personally).
> 
> Thanks,
> 
> Eran
> 
> On Tue, Jun 25, 2019 at 1:45 AM Manger, James 
> <James.H.Manger@team.telstra.com 
> <mailto:James.H.Manger@team.telstra.com>> wrote:
> 
>     Would it be sufficient to provide a URL template for each log,
>     instead of a directory URL?
>     Possible text:
> 
>        The address of a log is defined by a URL template [RFC6570] that
>     MUST include
>        the following variables: action, first, second, hash, start, end.
> 
>        'action' identifies the client message, such as 'submit-entry' or
>     'get-sth'.
>        'first' and 'second' are tree sizes. 'hash' is a base64-encoded
>     v2 leaf hash.
>        'start' and 'end' are 0-based entry indicies.
> 
>        Example:
>     https://log.example.net/ct/v2/red/{action}{?first}{?second}{?hash}{?start}{?end}
>     <https://log.example.net/ct/v2/red/%7Baction%7D%7B?first%7D%7B?second%7D%7B?hash%7D%7B?start%7D%7B?end%7D>
> 
>     --
>     James Manger
> 
>     -----Original Message-----
>     From: Trans <trans-bounces@ietf.org <mailto:trans-bounces@ietf.org>>
>     On Behalf Of Rob Stradling
>     Sent: Tuesday, 25 June 2019 12:16 AM
>     To: Melinda Shore <melinda.shore@gmail.com
>     <mailto:melinda.shore@gmail.com>>; trans@ietf.org
>     <mailto:trans@ietf.org>
>     Subject: Re: [Trans] Directory instead of .well-known for URL structure
> 
>     This sounds unanimous.  :-)
> 
>     I'll go ahead and make this change, and I'll cancel the registration
>     process for "ct" as a .well-known URI suffix.
> 
>     On 24/06/2019 01:05, Melinda Shore wrote:
>      > On 6/23/19 3:28 PM, Martin Thomson wrote:
>      >> I agree with Jacob here. As I have expressed in the past, I believe
>      >> that this is a better design than the well-known prefix.
>      >
>      >> On Fri, Jun 21, 2019, at 08:33, Jacob Hoffman-Andrews wrote:
>      >>> The latest draft adopts a /.well-known/ path for CT as a way to get
>      >>>   around BCP 190 (URI Design and Ownership:
>      >>> https://tools.ietf.org/html/bcp190#section-3).
>      >>>
>      >>> Personally I think BCP 190 makes it needlessly painful to specify
>      >>> HTTP-based APIs using techniques that are very common among
>      >>> practitioners. However, given that it is still considered best
>      >>> practice for IETF documents, I propose that CT should use a
>      >>> different workaround, one used very successfully by ACME:
>     Directory
>      >>> URLs.
>      >
>      > I have a fairly profound dislike for BCP 190, to be honest, and
>     am in
>      > agreement with the proposal.
>      >
>      > Melinda
>      >
> 
>     --
>     Rob Stradling
>     Senior Research & Development Scientist
>     Email: rob@sectigo.com <mailto: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 <mailto:Trans@ietf.org>
>     https://www.ietf.org/mailman/listinfo/trans
> 
>     _______________________________________________
>     Trans mailing list
>     Trans@ietf.org <mailto:Trans@ietf.org>
>     https://www.ietf.org/mailman/listinfo/trans
> 

-- 
Rob Stradling
Senior Research & Development Scientist
Email: rob@sectigo.com
Bradford, UK
Office: +441274024707
Sectigo Limited

This message and any files associated with it may contain legally 
privileged, confidential, or proprietary information. If you are not the 
intended recipient, you are not permitted to use, copy, or forward it, 
in whole or in part without the express consent of the sender. Please 
notify the sender by reply email, disregard the foregoing messages, and 
delete it immediately.