Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

Esko Dijk <esko.dijk@iotconsultancy.nl> Sat, 15 September 2018 14:30 UTC

Return-Path: <esko.dijk@iotconsultancy.nl>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E2BA130E58 for <ace@ietfa.amsl.com>; Sat, 15 Sep 2018 07:30:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=iotconsultancynl.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 8bq3yatofPU0 for <ace@ietfa.amsl.com>; Sat, 15 Sep 2018 07:30:14 -0700 (PDT)
Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70131.outbound.protection.outlook.com [40.107.7.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDEA2130E54 for <ace@ietf.org>; Sat, 15 Sep 2018 07:30:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iotconsultancynl.onmicrosoft.com; s=selector1-iotconsultancy-nl; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dUgj1RCII3Tk/vsctMyKUOf4MP5ddCZzfHvv5aj4tAE=; b=gszgGFXXMeLpDU2fwkqqIKgqr/7yA7wHyiKbHTWcqOshfKz+fUNLadoINz4TPUypWqxrR68SdHTvfvgEhamW1ebflMEBv3MNKiM3swvURx96jRjGce8yD/fANfhK00sgdPRWQMLcAfpFhsx5/hcdyBsiQgAy1n1LYO5JrEyDOy0=
Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM (10.172.229.12) by DB6P190MB0358.EURP190.PROD.OUTLOOK.COM (10.175.242.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1122.18; Sat, 15 Sep 2018 14:30:10 +0000
Received: from DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::74a4:5356:e25e:c0b1]) by DB6P190MB0054.EURP190.PROD.OUTLOOK.COM ([fe80::74a4:5356:e25e:c0b1%5]) with mapi id 15.20.1143.017; Sat, 15 Sep 2018 14:30:09 +0000
From: Esko Dijk <esko.dijk@iotconsultancy.nl>
To: "Panos Kampanakis (pkampana)" <pkampana@cisco.com>, "ace@ietf.org" <ace@ietf.org>
Thread-Topic: ace-coap-est: unclear definition of /.well-known/est URI
Thread-Index: AdRKqeFCUK1AzigFR5qvzUaQ2+R0GgAAdGzwAJTV7HA=
Date: Sat, 15 Sep 2018 14:30:09 +0000
Message-ID: <DB6P190MB00548845B38C0B0DF2380CD1FD180@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM>
References: <DB6P190MB005479015E3F02D4028541A9FD1B0@DB6P190MB0054.EURP190.PROD.OUTLOOK.COM> <39ff6ec1903c4c3a9d333c41a38a1ad9@XCH-ALN-010.cisco.com>
In-Reply-To: <39ff6ec1903c4c3a9d333c41a38a1ad9@XCH-ALN-010.cisco.com>
Accept-Language: en-US, nl-NL
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=esko.dijk@iotconsultancy.nl;
x-originating-ip: [85.147.165.150]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DB6P190MB0358; 6:xP9M1jC6tBtnVbw0espz0OsAKoY3pMhnblhQ5IhHFJgWduxEo+ngMahpGljE03cY+lXwr+N1xxao83z/7VNtJz0weFJvWNEdALqxmVfrX06ZtpRfDkDkC8eHkPETJuFdHFzEQk4rh7gQxJ4fOYd2j9O6/4XfgpvmSM0WHy396ZWiQX5dqF6ZoKVK77LJpzF0ErHqTWHAhgZx/F0DpXsXYnZGjr+hl9AqvAGSX8aW6Ce73d/Vfyel+8EcV2L3lVKh1UYYBfECzJvmWK6FCj3BPdbulT9dx7k+PWiL8gP4RQCAS1SS9Iq4wwguaU0sjIkphYdOR2RpKa6+OcSsLh7VU4eCg2+u98C3QKeXtqaUkeIL6UK4esvJS8768eFoclTzVjnkexG7lmEqKuapx2/wr8HY8RdxR8NNipmOoRn/GH/ZfYJzQv25lSvHSwen5B6mlD3Uwl2nu8AIPSdrWVWsPg==; 5:/fiJ+6ywV54Fum6GQVvo/biDzBltZQXMLPMA5Ppb/mFHaPANlIJccSjGcQ3IBkHzurl8Nmqa+EkH9BxlmhNVwNjFFNwhilosbtoUhsju1OQIZs9QJeAkNn9PdrdtpL71OUdOsQFouWk8E+sW+ZQyI4784Y3qi2yN2xanM/SCWL8=; 7:Bt1E6MLK8rlbhY9udoICQLzKiRrpooztNHzZxobzc/D9P8SvpRuAg3+g0fDDPYRCwzVSlXTszonl/pdyl3ZzkryKizPHnEgrAD1nvOdlzzhdEruvSJL8txjYPx4gUOldEWN9Z9P7GvgY/KYEmdsz1vKsZTlRvS+Atswcpqsm5xQk6eG6cZYMJD+5qNW5m99p6Xihp8qqG9scP9BUacBVW27kU3GUMt5V0Hr0r9eBdJu8ONceOZqrmP+1aG76vEhm
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-correlation-id: 1406fd6d-3261-4014-71b2-08d61b17bdab
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989137)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7023125)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:DB6P190MB0358;
x-ms-traffictypediagnostic: DB6P190MB0358:
x-microsoft-antispam-prvs: <DB6P190MB035837946462E5042333AAD7FD180@DB6P190MB0358.EURP190.PROD.OUTLOOK.COM>
x-exchange-antispam-report-test: UriScan:(158342451672863)(95692535739014)(79290750141951);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(3231355)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(149027)(150027)(6041310)(2016111802025)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(6043046)(201708071742011)(7699050); SRVR:DB6P190MB0358; BCL:0; PCL:0; RULEID:; SRVR:DB6P190MB0358;
x-forefront-prvs: 0796EBEDE1
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39830400003)(376002)(346002)(396003)(51914003)(189003)(199004)(11346002)(2900100001)(25786009)(106356001)(105586002)(7696005)(7736002)(74316002)(305945005)(53546011)(446003)(6506007)(186003)(76176011)(99286004)(486006)(44832011)(86362001)(476003)(256004)(26005)(14444005)(102836004)(8676002)(81166006)(508600001)(74482002)(68736007)(14454004)(33656002)(81156014)(110136005)(316002)(2501003)(5660300001)(3846002)(6116002)(2906002)(66066001)(6246003)(229853002)(8936002)(55016002)(53936002)(6436002)(9686003)(5250100002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6P190MB0358; H:DB6P190MB0054.EURP190.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: iotconsultancy.nl does not designate permitted sender hosts)
x-microsoft-antispam-message-info: R287CktfUIWmzw7PpPYggBhfQz5ROx4YGoNKQBleksMpsedZfdimsoyVk8FCmP5kzqOB9d7IYlh+p1AlllvMFeYhiodjySluKFZBCln1zuTLrX+HdHRnLq+dpsNIdTvG0C+y4zOPKeziDkCHilzpPfyEliaVgISPpeGX16ZmNH/2Tfg96fkmWYqstre22M5CNX5f5Yrvbdro81HuM0gZHwVLl9ZKlzWnhXUhQC1jNE5zCm3+x08wC6z5x2E2rzqiGNBNdp/s1ZbnMKQk+JUCYgEZfn9u8LTz74x3+fbpw1SvtDkt/FszKQp9eRiQWF1YiR7ktqVgaiHycPA02KrzXdhLXLAEKpiPjs8o2G3/JyU=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: iotconsultancy.nl
X-MS-Exchange-CrossTenant-Network-Message-Id: 1406fd6d-3261-4014-71b2-08d61b17bdab
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Sep 2018 14:30:09.8840 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 58bbf628-15d2-46bc-820b-863b6774d44b
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6P190MB0358
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/TgR6Q8KJFUNcYRcx9YnMWw_BNRM>
Subject: Re: [Ace] ace-coap-est: unclear definition of /.well-known/est URI
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 15 Sep 2018 14:30:17 -0000

Hello Panos,

Thanks - it's clear now that the "ArbitraryLabel" needs to be supported for this use case. The unclarity in the current text comes from the fact that the default /.well-known/est/<short-est> is missing ; which should be supported also as in RFC 7030. Also the usage of the discoverable root URI is missing here.

So we could update the text in Section 5 as follows:

------
The individual EST-coaps well-known server URIs differ from the EST URI by
replacing the scheme https by coaps and by specifying shorter
resource path names:

   coaps://www.example.com/.well-known/est/<short-est>
   coaps://www.example.com/.well-known/est/ArbitraryLabel/<short-est>

The ArbitraryLabel Path-Segment, if used, SHOULD be of the shortest length
possible.

The optional additional EST-coaps server URIs, obtained through discovery of the EST
root resource(s), are of the form:

   coaps://www.example.com/<est-root-resource>/<short-est>
   coaps://www.example.com/<est-root-resource>/ArbitraryLabel/<short-est>

------

The suggestion by Peter to add references to the corresponding EST RFC 7030 sections is also good.

Regards
Esko

From: Panos Kampanakis (pkampana) <pkampana@cisco.com> 
Sent: Wednesday, September 12, 2018 17:31
To: Esko Dijk <esko.dijk@iotconsultancy.nl>; ace@ietf.org
Subject: RE: ace-coap-est: unclear definition of /.well-known/est URI

Hi Esko,

Thanks for the comment. 

Certificate authorities use the ArbitraryLabel in order to direct the CSR request and issue certificates based on a certain policy / cert profile. For example, if you are ClientX you get label ClientX198282 and when you hit the CA HTTP URI .well-known/est/ ClientX198282/sen the CA knows to use the policy for ClientX in order to issue a certificate. Of course, someone that has deployed an on-prem CA that has the same cert profile for all endpoints will not need an arbitrary label and the default EST namespace is enough.  

So, even though coaps://www.example..com/.well-known/est/<short-est> would work for many cases, we needed to keep the coaps://www.example..com/.well-known/est/ArbitraryLabel/<short-est> as well for cases where the client is getting a cert from a CA that serves more than on cert profiles. We may need to specify that the labl should be as short as possible, even though it is kind of self-explanatory. 

I hope it makes sense.

Panos


From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of Esko Dijk
Sent: Wednesday, September 12, 2018 11:10 AM
To: mailto:ace@ietf.org
Subject: [Ace] ace-coap-est: unclear definition of /.well-known/est URI

Dear all/authors of ace-coap-est,

Section 5 of ace-coap-est-05 indicates URI discovery is possible to find the EST functions entry point URI. Also a well-known URI is defined:

coaps://www.example..com/.well-known/est/ArbitraryLabel/<short-est>.

This URI seems more complicated than needed? What if we simply define an always-available well-known URI, usable without any discovery:

coaps://www.example..com/.well-known/est/<short-est>

This re-uses the well-known EST namespace which is exactly defined to do EST functions. So using the short-est names within this namespace should be fine.
It is important that a well-known URI is available that is usable without discovery, just like EST RFC 7030 defines it for https.
The "ArbitraryLabel" only makes the URI longer.

best regards
Esko Dijk