Re: [Ace] I-D Action: draft-ietf-ace-cmpv2-coap-transport-02.txt

"Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com> Tue, 14 September 2021 06:19 UTC

Return-Path: <hendrik.brockhaus@siemens.com>
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 E08A13A0829 for <ace@ietfa.amsl.com>; Mon, 13 Sep 2021 23:19:19 -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_MSPIKE_H2=-0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=siemens.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 Z7Xnijn2ae5G for <ace@ietfa.amsl.com>; Mon, 13 Sep 2021 23:19:14 -0700 (PDT)
Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2082.outbound.protection.outlook.com [40.107.20.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484E03A0825 for <ace@ietf.org>; Mon, 13 Sep 2021 23:19:14 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kJVDq5dprPhKIijGxS66x9Qo6A4Z1Sh6xpWKmuLva1TdZYODyH3yJeCLRMZi2+T3T5ww3sttAbUwJtrPWYd3imKbHI0TkWCMjP2mwJ5EgCLzPNvDPbJPhw0PkcoRe9hyRMcdebPkgqnLT3qqpX0nRj+wZvO69qYa6fePdN6qL1rKsPVggsMlOsm7mJUbMnhv88x2BZKJL+GnYFhbX5yPca2DF9VM8wSNdcPjyy/eRjlmYrbp/uVhJmaN+xDdihvEJSP0nnJwXJdGQprhtXs/8/pNFKcS9tkbv33LVWh8qr3Pdc9YSMOuxPw+aUinO1INcSXiZ0HJEcCEBHq3iKyP1Q==
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; bh=6rieNTHfohhQNzmmSelDL6wCZVvsiJZnASP+PlGrymI=; b=ZNP1g4xFGi0FwC3G5HXABvq5Yk+Zk0ELWctDhQdWvE2KZbp3ycVZ3qG4Hjz5pKyfvw0PZpPJ/H9Vs3u+H3HWpzVSuW3X3OfTO5TxPSWAzvq6iWkZ23ElFPBmVgaKBdxA9p6UcQp/+uX1fIz6FvgpWgIFzx7Dz71Z9mucQo5P7WQVJ83G8oiA1F6j+p12IpxJ3XVq+oMa0vh7x/12j/Oep0tMF8sLUKZyk2CojjzDhXTkkFdbit7+ycxaFzEKcGmaIBsJ/OppDgyv/GEj/Co12l3FzkZPomLvOktYaj1n4pogaeC2WBIaD9KEXr8amYBz6nPeGsBtiB230VGYerVfZg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=siemens.com; dmarc=pass action=none header.from=siemens.com; dkim=pass header.d=siemens.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=siemens.onmicrosoft.com; s=selector1-siemens-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6rieNTHfohhQNzmmSelDL6wCZVvsiJZnASP+PlGrymI=; b=pIYI2qXedNTG3T5B5qGFKd6HpPkmMUvpGb5fHex8rktOYkumumRfYSBJ6j9ovHO2OFL47MusZKPF7UPDtA+4wCIiq/mYJCZznc0V6Nm/hd9ucPPEwp7WYvCX58sEGWGfuT7zWef1CXcvA4oEoCBFMOFUW4JU0nk7Oc0N4g5HEmY=
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:208:dd::17) by AM4PR1001MB1426.EURPRD10.PROD.OUTLOOK.COM (2603:10a6:200:96::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4500.17; Tue, 14 Sep 2021 06:19:05 +0000
Received: from AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::49c9:59f7:5238:b8f]) by AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM ([fe80::49c9:59f7:5238:b8f%7]) with mapi id 15.20.4500.018; Tue, 14 Sep 2021 06:19:05 +0000
From: "Brockhaus, Hendrik" <hendrik.brockhaus@siemens.com>
To: Mohit Sahni <mohit06jan@gmail.com>
CC: Daniel Migault <mglt.ietf@gmail.com>, Saurabh Tripathi <stripathi@paloaltonetworks.com>, "david.von.oheimb@siemens.com" <david.von.oheimb@siemens.com>, Ace Wg <ace@ietf.org>
Thread-Topic: [Ace] I-D Action: draft-ietf-ace-cmpv2-coap-transport-02.txt
Thread-Index: AQHXUWwho8tOpPWREEe0O73nBHk046r0NnqAgA/gygCAh8kmAIAAu62AgBWOpaCAAYzmAIAABEgw
Date: Tue, 14 Sep 2021 06:19:04 +0000
Message-ID: <AM0PR10MB24189353450D32F9280625D8FEDA9@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM>
References: <162195022206.30344.3798071050372276240@ietfa.amsl.com> <CAEpwuw20QKD3fEUdTUeFw9aMQ69WfjgZNF++j-6UFV_0YudhUg@mail.gmail.com> <CADZyTknWhA_TyJqUMgk57=f16dO5otAHzpJYJhWsAjE8fn445Q@mail.gmail.com> <CAEpwuw2jPrSGD4e+oacsR9_6F8uq8VKKFbZXCpvhDWKg6PcQEg@mail.gmail.com> <CADZyTkmN+tQhNpp-SzZ4PtwCrLfdZBDA4mz2XbBvSbE6azHJhw@mail.gmail.com> <AM0PR10MB2418D111C61B2AAE8A73C40BFED99@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM> <CAEpwuw1PcQ2eOns6HtNT5x3rPN27VoQ4B2_uixyttqCAWh1HMg@mail.gmail.com>
In-Reply-To: <CAEpwuw1PcQ2eOns6HtNT5x3rPN27VoQ4B2_uixyttqCAWh1HMg@mail.gmail.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-09-14T06:19:03Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=77ae72a4-6ce1-44c4-b388-3516b94fdd2d; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=siemens.com;
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ae331241-c355-46ee-fc9b-08d977478d8e
x-ms-traffictypediagnostic: AM4PR1001MB1426:
x-ld-processed: 38ae3bcd-9579-4fd4-adda-b42e1495d55a,ExtAddr
x-ms-exchange-transport-forked: True
x-microsoft-antispam-prvs: <AM4PR1001MB1426A2CBB034B246B45F6DF5FEDA9@AM4PR1001MB1426.EURPRD10.PROD.OUTLOOK.COM>
x-ms-oob-tlc-oobclassifiers: OLM:6790;
x-ms-exchange-senderadcheck: 1
x-ms-exchange-antispam-relay: 0
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: YBqIFqByjnpQluGY6bOwHleZW3fbqIZiIbz1lt4lqjON0IEBxQxQGJSHgmj/cEldLsTuoZ6wy+3nO6kRHvImzWpX5H9kJ1fAZmbNHTjCR8cP7mcNj6xokRJ/kyKL+HUXQHKEsphzUdsF7PZJPHxbhZw+F465PpZpuqZL39tv+XMqEh9MC0C6uvkW5/1oDeDkuyNLQaA/qS2Pmxr1W1XuFC0w+aU42JPzpH1TqJzKk4CsUWJ+jA0rUFuoCbSErVn1Ysig+Lk7sK0pp2hvsih17bknd0bY8cEitcFUQfU99Cide7IuFmMWv1ljo7l8P2b7xw3AK/S7rPY0va6lDuKYrkmXi80R0KNXk37ApC299NxV+05vppPrdmL/Ay5JjxwkDJnyGZGH6r1q9RzHqVOdvXwIn7R+2tiYqmxGCs0FoWi3qNL4SNEyQIJZEzDRWo+JbczXljb/qyAUjHD0VDANAxhWrIR+WAJ6utUcXamXccq1UOseQk58VqIYCz/cH/As4FYV2Eo8b/qx4B+COi8IbEgtuRcjUGdWjOUow1PjC4deMa6ldXSjBVMWhE2sT5PnYw5AydkiBSuiWvPuv+2DUaBSZG7SVoFV37CfRTY5QfhFfP1H1NsIirLXeaxizmX6h6rShdLLzmQWNYDTIEpUnF1V9svokbm53kZw1yqpZ/FdsT/snFi9NAcJ9qYnYsXcyIKXkzJgRFs2dhxvzFqLaIgihV168O60rgEC88h/JUYxnQGse7Zj6sNERQ9UiBTIUHL/xszphcCTV5ONE/FUmc9+fk/k7yClZ7EgEwEHqW+7/TjLur1LsYoUC2ukV//Q2f/7hNKEOXByu5EUBB9PtukJ7elGoZ7+SJ5D7xikjQM=
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(4636009)(136003)(39860400002)(376002)(366004)(346002)(396003)(26005)(8936002)(8676002)(53546011)(66946007)(66556008)(66446008)(66476007)(64756008)(71200400001)(7696005)(33656002)(186003)(4326008)(2906002)(9686003)(316002)(76116006)(52536014)(38070700005)(55016002)(86362001)(6916009)(38100700002)(30864003)(83380400001)(478600001)(45080400002)(5660300002)(66574015)(6506007)(122000001)(966005)(54906003)(376185003); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?yeWwqbPXXVtuj4XeU+YxrHUv/k7CTPvF+O5tkeDb3Yv2M7esD7X4jFzgn/jQ?= =?us-ascii?Q?cOf3GdtS9J4I4bmo0zpvp/qzwP/+BPKW0pexOo5meYeG4aE2DOc+096ZQ489?= =?us-ascii?Q?MiFFI7V0t67irLfv6ee33jnhZ3B2CKRzF4NZGD76kOUtns9lDP2sq0+kiEAQ?= =?us-ascii?Q?2n4/mEI1OtJA+FgKKKynKK8KtLQJHaFXluOVGkW+wkwnkwjScqflAv60/EsR?= =?us-ascii?Q?kGCZc1j3U8crHxwKFctl0dk9TT3jNz2XtpZlEuG9zMJDk5j5P20647tzGz2m?= =?us-ascii?Q?NPTMoSWZcNARpzf9ag6Syqd0pCR+eSrK8WDdGfXQTlczlUEwMlScL8Vjeqsq?= =?us-ascii?Q?NOIoyvJFVvCyWFIDCplORh/OWNAsJUtTe7S0hXcg5GLqCIBspBA2TH6uo0aE?= =?us-ascii?Q?4MmqTl13nBAmXf5XhBApavwxQ7fXRtFlizXH9hfKREauQloIOfq0H+JeSXYL?= =?us-ascii?Q?DHySQ8H2NEpBqr18ZZkxILVUIeyB9miVB1ji7hFla0jLG23thq4rJJo2gXaf?= =?us-ascii?Q?7xa7LT6XnN9UDBCzojFV/TjW1ZmO5yucAOoqPwieJ27LdEhldwxj/5LTmRPf?= =?us-ascii?Q?2vWhkpeLq9A5yNrfIGVz2WHmeIeLFhiid7LsAs8hHObdKL7qc4niHkK0Lblw?= =?us-ascii?Q?oiaM3bfuz8QAQl5cXeUBA/whGtqM8ONGT82SjrsOjjJZ3AriRl6yUGvZ/oaI?= =?us-ascii?Q?z1GgGD62uPms4/exUseCJZ6+oO3lDlkx3WJ5R59pTf6qRbRxkevgA06WeHOb?= =?us-ascii?Q?c+3i9QnwPeThpMtVdyXTL5/ZoMWaGnNmDJG5OLQ8Ytxhuh2r8TVDbZ8Fnd/v?= =?us-ascii?Q?gGVSdMdSMCEeICBHq5oZOAnU5+LyHGdzf9dckYfQJcvkxOwGDar9zLtxnCWF?= =?us-ascii?Q?GhcjZFPsG/5z8AYNLRNlcXQ+psWmyPO9a6UQwex2lntWCvAc+Z48deEMlopY?= =?us-ascii?Q?/wVD6WK6DlzsysHGQyB3PDED9oEnzx4AmKGGhm4qrVfwGkXhfOSaHdoaOXWK?= =?us-ascii?Q?NwApcr1JttIHrmHRwIHGVyhFLMzUBTB597rqgX8iUCLMbDSQH/QmBEy26evD?= =?us-ascii?Q?wjhIEnJjFGf8C293ILoj/8zUj8Z8I0HxCxFNkKsAKkm3mdOaIzEacfDMfaS2?= =?us-ascii?Q?NjJmcb+MufQy0ukK078yfI+hVS2eB4eQLB2wZITPdVrfd7YvpKCNXS+BJGzs?= =?us-ascii?Q?jp/6Iwh0zd0M8KjisQevoRsbqFXKgH5ZGGe639MZJNUgKl+hI7RG2KpGssJx?= =?us-ascii?Q?AkCaRc9wC6qMOcwyWIJSxb9awvhgfS/F9pfMmr8OHNmeJVyeLH5pU+wy31xB?= =?us-ascii?Q?GxiirvT6UH8NBWxuuJQn4LLB?=
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: siemens.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-Network-Message-Id: ae331241-c355-46ee-fc9b-08d977478d8e
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Sep 2021 06:19:05.0197 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 38ae3bcd-9579-4fd4-adda-b42e1495d55a
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 3lEL+pjTItt4tEeXY8UU/22d9ol9WH/oKW3G8xb1GIaUDgWfYuLSdXfPmtUyfPpdwkIc060UKnCCLmqBWZ4c+TLrmFKkPeN70D4KINdkjOM=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR1001MB1426
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/tKHLlPDZb02iUJTsNot6fvcRBFQ>
Subject: Re: [Ace] I-D Action: draft-ietf-ace-cmpv2-coap-transport-02.txt
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: Tue, 14 Sep 2021 06:19:20 -0000

Mohit

I do not see any reason not using cmp as URI suffix for CoAP as well.
If the suffixes used for CoAP are defined in the same registry (https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml#well-known-uris-1) like the one used for http, the definition in CMP Updates Section 3.3 should be sufficient.

Does anyone else sees issues with reusing the suffix?

Hendrik

> Von: Mohit Sahni <mohit06jan@gmail.com>
> Gesendet: Dienstag, 14. September 2021 07:56
> 
> Hendrik,
> Do you see any practical issue in using the same /.well-known/ URL suffix? Given
> that these URIs will have different Protocol part i.e.
> http:// or https:// for HTTP transport and coap:// or coaps:// for CoAP
> Transport, I think it makes sense to have just cmp for both instead of  have
> different .well-known/ suffix for different transports.
> 
> -Mohit
> 
> 
> 
> On Sun, Sep 12, 2021 at 11:32 PM Brockhaus, Hendrik
> <hendrik.brockhaus@siemens.com> wrote:
> >
> > Mohit, Daniel
> >
> >
> >
> > My preference is to define the URI suffix in cmp-over-coap.
> >
> > As the URI suffix is coap specific, it looks more logical to me to define it there.
> In CMP Updates we define the http URI suffix as update to RFC 6712 and not to
> RFC 4210. Finally CMP Updates only provides updates to RFC 4210 and RFC
> 6712. Therefore I see no good place to put the URI definition in CMP Updates.
> >
> >
> >
> > Hendrik
> >
> >
> >
> >
> >
> > Von: Ace <ace-bounces@ietf.org> Im Auftrag von Daniel Migault
> > Gesendet: Montag, 30. August 2021 15:04
> >
> > It seems fine to me. For the IANA section I would add a note to notify the RFC
> editor that either we ar waiting for cmp-update to be published or that the
> document publishes instead the URI suffix - of course we will have to coordinate
> with the cmp-update co-authors.  The real situation we want to avoid is that we
> describe something that is not registered.
> >
> >
> >
> > Yours,
> > Daniel
> >
> >
> >
> > On Sun, Aug 29, 2021 at 9:52 PM Mohit Sahni <mohit06jan@gmail.com>
> wrote:
> >
> > Hi Daniel
> > Thanks for the comments and sorry for taking a long time to reply.
> > Please find my resolutions to your comments below:
> > mglt1: I made the change with suggested text
> >
> > mglt2:  You are correct that the motivation behind the HTTP-to-CoAP
> > proxy section is to make new entities using CoAP transport work with
> > the existing PKI entities using HTTP transport for CMP for quick
> > adoption. I will change the text to the suggested one.
> >
> > mglt3: Originally writing the draft I was thinking to only capture the
> > use case of communication between EEs and RAs or EEs and CAs. The RAs
> > and CAs are most likely not the constraints devices so a use case of
> > RAs and CAs to talk among themselves over CoAP transport does not
> > exist and HTTP may be a better option for that purpose. I guess I can
> > remove that constraint from the draft.
> >
> > mglt 4:
> > in Cmp Over HTTP transport, given that CMP has its own integrity and
> > privacy mechanisms, HTTP  is the default transport instead of HTTPs. I
> > am following the same convention.
> > I will remove cmp from the Iana section, looks like another draft that
> > was in progress with this one has added it to IANA.
> > operationalLabel and profileLabel are just examples, The idea is to
> > host multiple cmp services on these paths based on the functionality
> > (operational label) of the EEs (e.g. either networking devices, or
> > cameras or cell phones) or based on the CMP profile (set of supported
> > message and functionalities of the CMP protocol). I will add more
> > clarifications in this section.
> >
> > mglt6:
> > I will update the section with ct attribute.
> >
> > mglt7:
> > I will update the section with mention of the Observe option and why
> > we don't prefer to use it.
> >
> > mglt8:
> > I will update that.
> >
> > mglt9:
> > I will add additional information in the IANA section for requesting
> > new content type "application/pkixcmp".
> >
> > For now I will skip requesting the IANA registration for cmp as its
> > already approved temporarily for ID [draft-ietf-lamps-cmp-updates-10]
> >
> > Please let me know if this resolves your comments, I will shortly
> > update the next version of the draft with these resolutions. I
> > apologize for the delay in response.
> >
> > Thanks
> > Mohit
> >
> > On Fri, Jun 4, 2021 at 9:17 AM Daniel Migault <mglt.ietf@gmail.com> wrote:
> > >
> > > Hi,
> > >
> > > I have read the document and please find some comments below. I do not
> see any major issues, and the most crucial point seems to proceed to the
> appropriate procedure to register the IANA code points.
> > >
> > > Yours,
> > > Daniel
> > >
> > > mglt 1
> > >
> > > Since the text specifies that the document applies to specifically CMPv2 and
> CMPv3. I am wondering if we should not mention that both of these versions are
> designated as CMP in this document. The change I am proposing is something
> around the lines below. I will let the co-author choose whether this is more
> appropriate.
> > >
> > > OLD:
> > > This document specifies the use of CoAP over UDP as a transport medium for
> the CMP version 2 [RFC4210], CMP version 3 [Certificate-Management-
> Protocol-Updates] and Lightweight CMP Profile [Lightweight-CMP-Profile].
> > >
> > > NEW:
> > > This document specifies the use of CoAP over UDP as a transport medium for
> the CMP version 2 [RFC4210], CMP version 3 [Certificate-Management-
> Protocol-Updates] - designated as CMP in this document - and Lightweight CMP
> Profile [Lightweight-CMP-Profile].
> > >
> > > mglt 2
> > >
> > > """
> > > This document also provides guidance on how to use a "CoAP-to-HTTP"
> proxy for a better adaptation of CoAP transport without significant changes to
> the existing PKI entities.
> > > """
> > >
> > > It is not clear to me what better adaptation means nor the potential changes
> associated to the existing PKI. Note that I am not native English speaker so the
> comment might only concern myself and you are free to ignore it. My
> understanding of the motivations to describe "CoAP-to-HTTP"  is to interconnect
> CMP over CoAP with existing CMP over HTTP infrastructure which would reduce
> the overhead of providing CMP over CoAP and as such favor its adoption.
> > >
> > > If that is correct, I am wondering if something around the lines could be
> clearer - of course, feel free to change it:
> > >
> > > This document also provides guidance on how to use a "CoAP-to-HTTP"
> proxy to ease adoption of CoAP transport by enabling the interconnection with
> existing PKI entities already providing CMP over HTTP.
> > >
> > > mglt 3
> > >
> > >
> > > """
> > > Although CoAP transport can be used for communication between
> Registration Authority (RA) and Certification Authority (CA) or between CAs, the
> scope of this document is for communication between End Entity (EE) and RA or
> EE and CA.  This document is applicable only when the CoAP transport is used for
> the CMP transactions.
> > > """
> > >
> > > For my knowledge, I am curious why we are making a distinction between
> CMP being used by an EE versus another entity. It seems to me that if the
> document specifies how CMP can be used over CoAP this could be used by any
> entity willing to use CoAP. Whether these entities are willing to use CoAP or not
> seems to me orthogonal to the document. The last sentence sounds strange to
> me. Overall I am wondering if we should not remove these lines, unless I am
> missing something.
> > >
> > > mglt 4
> > >
> > > """
> > >
> coap://https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.example.com%2F.well-
> known%2Fcmp&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7
> C2cf94d39bd214e1d443908d97744672f%7C38ae3bcd95794fd4addab42e1495d
> 55a%7C1%7C0%7C637671957943242652%7CUnknown%7CTWFpbGZsb3d8eyJ
> WIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C
> 1000&amp;sdata=YEns3whCzpzlJ%2BHUVuaeBtfTT1eNAoY%2FAvZ08oDG6bI%3
> D&amp;reserved=0
> > >
> coap://https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.example.com%2F.well-
> known%2Fcmp%2FoperationalLabel&amp;data=04%7C01%7Chendrik.brockhau
> s%40siemens.com%7C2cf94d39bd214e1d443908d97744672f%7C38ae3bcd9579
> 4fd4addab42e1495d55a%7C1%7C0%7C637671957943242652%7CUnknown%7C
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX
> VCI6Mn0%3D%7C1000&amp;sdata=3xSR%2BlVgI7Sg3pDwvQ90Z9ArkHqwOh9I5
> UNJ2f6PHM8%3D&amp;reserved=0
> > >
> coap://https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fw
> ww.example.com%2F.well-
> known%2Fcmp%2FprofileLabel&amp;data=04%7C01%7Chendrik.brockhaus%40
> siemens.com%7C2cf94d39bd214e1d443908d97744672f%7C38ae3bcd95794fd4
> addab42e1495d55a%7C1%7C0%7C637671957943242652%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C1000&amp;sdata=cby1oAiwP1nE1HrN0I64MFNYqKd5TD4ho1XxU5
> %2FXeOY%3D&amp;reserved=0
> > >
> > > coap://https://eur01.safelinks.protection.outlook.com/?url=http%3A%2
> > > F%2Fwww.example.com%2F.well-
> known%2Fcmp%2FprofileLabel%2Foperational
> > >
> Label&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2cf94d3
> 9b
> > >
> d214e1d443908d97744672f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7
> C0%7
> > >
> C637671957943242652%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM
> DAiLCJQ
> > >
> IjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=Jbc8OAN
> p
> > > pYPwOtULaCJx5v%2BmhGDW%2Fx7I4FNMBRuq6mE%3D&amp;reserved=0
> > > """
> > >
> > > I am wondering if coaps would not be more appropriated for the
> > > example. In addition, I see the registered name 'cmp' in the IANA section, but
> I would like t o understand if the document intends to specify operationalLabel
> profileLabel or if these are just provided as examples. If that is the case, I would
> like for my own knowledge to understand why we do not specify these
> additional URL schemes. ?
> > >
> > > mglt 6
> > >
> > >   """
> > > 2.2.  Discovery of CMP RA/CA
> > > """
> > >
> > > I am wondering if any should be mentioned regarding the 'ct' attribute
> "application/pkixcmp". My understanding is that from 7252, is that not including
> the 'ct' attribute means that no specific format is expected which is not the
> situation we are in. As a result, I am expecting the 'ct' attribute to be mentioned.
> I am wondering if that is worth clarifying ?
> > >
> > > mglt 7
> > >
> > > """
> > > 2.5.  Announcement PKIMessage
> > > """
> > >
> > > I understand this section as not recommending the use of Observe Option. If
> that is the case, It might clearer to mention the option at least as an example.
> > >
> > > mglt 8
> > >
> > > """
> > > 3.  Using CoAP over DTLS
> > > """
> > > I think that the reference to DTLS should be updated with draft-ietf-tls-
> dtls13.
> > >
> > > mglt 9
> > >
> > > """
> > > IANA section
> > > """
> > > The registration of the content type "application/pkixcmp" is
> > > described in 7252 section 12.3
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> > > tatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7252%23section-
> 12.3&amp;data=04
> > >
> %7C01%7Chendrik.brockhaus%40siemens.com%7C2cf94d39bd214e1d443908d9
> 77
> > >
> 44672f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C63767195794
> 32426
> > >
> 52%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL
> CJBT
> > >
> iI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=a7I%2BTBiUAeeSI77jHQgD
> bbO
> > > N2UFzlvrOYdnwHHgS%2FT8%3D&amp;reserved=0
> > > And it seems to me the IANA section needs to provide additional information
> to select the appropriate number.
> > >
> > >
> > > The registration of the 'cmp' needs to follow a specific process define din
> RFC8615 section 3.1.
> > > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fda
> > > tatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8615%23section-
> 3.1&amp;data=04%
> > >
> 7C01%7Chendrik.brockhaus%40siemens.com%7C2cf94d39bd214e1d443908d97
> 74
> > >
> 4672f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637671957943
> 24265
> > >
> 2%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJ
> BTi
> > >
> I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=u5kvGU3WXjXKdH7%2F777
> S8neD
> > > eFoFwmaRiQJh8CBHAls%3D&amp;reserved=0
> > > I am not aware this process has been initiated yet. If that is correct, please
> initiate it asap. It mostly consists in sending the appropriate email and tracking
> the response. I would recommend CCing the WG, though I am not sure that is
> required.
> > >
> > > On Tue, May 25, 2021 at 9:48 AM Mohit Sahni <mohit06jan@gmail.com>
> wrote:
> > >>
> > >> Hello Ace WG, I have submitted the new version of the draft based
> > >> on the feedback that I received during the WGLC. Please let me know
> > >> if any of the comments are not resolved.
> > >>
> > >> Thanks
> > >> Mohit
> > >>
> > >> On Tue, May 25, 2021 at 6:44 AM <internet-drafts@ietf.org> wrote:
> > >> >
> > >> >
> > >> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > >> > This draft is a work item of the Authentication and Authorization for
> Constrained Environments WG of the IETF.
> > >> >
> > >> >         Title           : CoAP Transport for Certificate Management Protocol
> > >> >         Authors         : Mohit Sahni
> > >> >                           Saurabh Tripathi
> > >> >         Filename        : draft-ietf-ace-cmpv2-coap-transport-02.txt
> > >> >         Pages           : 8
> > >> >         Date            : 2021-05-25
> > >> >
> > >> > Abstract:
> > >> >    This document specifies the use of Constrained Application Protocol
> > >> >    (CoAP) as a transport medium for the Certificate Management Protocol
> > >> >    (CMP) as mentioned in the Lightweight CMP Profile
> > >> >    [Lightweight-CMP-Profile].  CMP defines the interaction between
> > >> >    various PKI entities for the purpose of certificate creation and
> > >> >    management.  CoAP is an HTTP like client-server protocol used by
> > >> >    various constrained devices in the IoT space.
> > >> >
> > >> >
> > >> > The IETF datatracker status page for this draft is:
> > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > >> > Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-ace-cmpv2-coap-transport
> > >> >
> %2F&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2cf94d39
> > >> >
> bd214e1d443908d97744672f%7C38ae3bcd95794fd4addab42e1495d55a%7C1%
> 7
> > >> >
> C0%7C637671957943252642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwM
> > >> >
> DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdat
> > >> >
> a=IqADSVpeFt59aksyC%2FbOx3mWMlBUT15l7zndeWphLyw%3D&amp;reserved
> =0
> > >> >
> > >> > There is also an htmlized version available at:
> > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > >> > Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-ace-cmpv2-coap-tr
> > >> > ansport-
> 02&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2
> > >> >
> cf94d39bd214e1d443908d97744672f%7C38ae3bcd95794fd4addab42e1495d55
> > >> >
> a%7C1%7C0%7C637671957943252642%7CUnknown%7CTWFpbGZsb3d8eyJWIj
> oiMC
> > >> >
> 4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&a
> > >> >
> mp;sdata=9X9GFDJBEJ1g6bve3Cl19%2BFoOrukXdQlm8GK2yW3LRI%3D&amp;re
> s
> > >> > erved=0
> > >> >
> > >> > A diff from the previous version is available at:
> > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > >> > Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-ietf-ace-cmpv2-coap-transp
> > >> > ort-
> 02&amp;data=04%7C01%7Chendrik.brockhaus%40siemens.com%7C2cf94
> > >> >
> d39bd214e1d443908d97744672f%7C38ae3bcd95794fd4addab42e1495d55a%7C
> > >> >
> 1%7C0%7C637671957943252642%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4
> wLj
> > >> >
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;s
> > >> >
> data=GF2okO%2BRIIAZ0oue3axcJbrQjlP%2BmxH4yTocZGvyQPo%3D&amp;reser
> > >> > ved=0
> > >> >
> > >> >
> > >> > Internet-Drafts are also available by anonymous FTP at:
> > >> > https://eur01.safelinks.protection.outlook.com/?url=ftp%3A%2F%2Ff
> > >> > tp.ietf.org%2Finternet-drafts%2F&amp;data=04%7C01%7Chendrik.brock
> > >> >
> haus%40siemens.com%7C2cf94d39bd214e1d443908d97744672f%7C38ae3bcd9
> > >> >
> 5794fd4addab42e1495d55a%7C1%7C0%7C637671957943252642%7CUnknown
> %7C
> > >> >
> TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiL
> > >> >
> CJXVCI6Mn0%3D%7C1000&amp;sdata=J9evUYBRyIdwYV5Rql4%2Bd9PmiZEJ8Fj
> V
> > >> > tVvGNk4r4c0%3D&amp;reserved=0
> > >> >
> > >> >
> > >> > _______________________________________________
> > >> > Ace mailing list
> > >> > Ace@ietf.org
> > >> > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > >> >
> Fwww.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=04%7C01%7Chendr
> > >> >
> ik.brockhaus%40siemens.com%7C2cf94d39bd214e1d443908d97744672f%7C3
> > >> >
> 8ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637671957943252642%7C
> Un
> > >> >
> known%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6I
> > >> >
> k1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=5QAWIvg%2FwNoMO4ZAeFk
> US%2B
> > >> > EOB3j9%2FTxgjIuDFbgOX6k%3D&amp;reserved=0
> > >
> > >
> > >
> > > --
> > > Daniel Migault
> > > Ericsson
> >
> >
> >
> >
> > --
> >
> > Daniel Migault
> >
> > Ericsson