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

Daniel Migault <mglt.ietf@gmail.com> Mon, 30 August 2021 13:04 UTC

Return-Path: <mglt.ietf@gmail.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 B3E913A09F0 for <ace@ietfa.amsl.com>; Mon, 30 Aug 2021 06:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IU3VfIxAeAGH for <ace@ietfa.amsl.com>; Mon, 30 Aug 2021 06:04:01 -0700 (PDT)
Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (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 1257C3A1076 for <ace@ietf.org>; Mon, 30 Aug 2021 06:04:01 -0700 (PDT)
Received: by mail-qv1-xf33.google.com with SMTP id g11so8216362qvd.2 for <ace@ietf.org>; Mon, 30 Aug 2021 06:04:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=dn2Eb0MxqPTxwYsd4nQSlDF2cCkTltPwl3E9LwohRaI=; b=AzBYGc/4xJVH/Eg0CgLBGce7Tut/knkcEg6+j/Q+A6eFIx5W+DfZHjRCLFfhYrS8my aUbB8Gn5zNwqmx+VmopMNp3w6v6F1+ezWjXShLjXibdGuGhJrq6FZue7fOZkYC3+4DUv fRCPjDUAGM0/DrJCtuHewKsR+yMj5H4YaD/5uBeE8+Af3KpGDGrOZGaEzr5Hpmimd77i ekc3R4GkgbO1nWlnTo/3h3iSZSiqLnlrggEZPm6dH07yAdBMXcjr32uvdDa4yVT2SHUP XEXMFqRTV7HCxMxecQ9Ruv4Qhx88aXQCE73h9bcELadkqjJtZKHBwjfCMcl9z/vJbFIy 2EJQ==
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=dn2Eb0MxqPTxwYsd4nQSlDF2cCkTltPwl3E9LwohRaI=; b=YMtyPQcF91a9hq28vwTosINoL3m/8xGEy9b3pZnFtziDu+lyOoWE8JFd1KNZV8UHLh YaInOoncdvqWAq3uZNPpNnmxsbM+LkpBbyYXWuDNfZGcXCfTU/SQrcjqn9PrsZLIalp+ afr+kqsKejD9cDEWVMendNF6PyLhibOz6HP6akXwX9iPqTPtQTZBVokKrJtIXIK2kQij d/7EDJ9xnnrJ/ryxrK2GvoIU4sCB7KLPkAId4Bkz5VNt7/ihu6LG3yiUPq6B2HqUxw7A 39CsJo/RQSc3Y3k7QWxelWbBcOgTnGT2h8kpnKp5MqjlD8P4vWQdLMEOXSwr3ZDl6laj A4KA==
X-Gm-Message-State: AOAM53198kGdp3BKPfGEWyYcldHHbjfbysEN6R9KXlbr4EnkI44GtUVK hLoIWTi4hbyia0SeISrJYspIYr/3W5cKRvOZpcg=
X-Google-Smtp-Source: ABdhPJyOq/3GEgi5ZAJFENm/NM/sjYKWJ4NjDo9M0FVQumSVCFTTlzmLGqgUxfP56O7hHszYJ2rmdKBbdM/dJommrLU=
X-Received: by 2002:ad4:5247:: with SMTP id s7mr22946478qvq.58.1630328638830; Mon, 30 Aug 2021 06:03:58 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <CAEpwuw2jPrSGD4e+oacsR9_6F8uq8VKKFbZXCpvhDWKg6PcQEg@mail.gmail.com>
From: Daniel Migault <mglt.ietf@gmail.com>
Date: Mon, 30 Aug 2021 09:03:47 -0400
Message-ID: <CADZyTkmN+tQhNpp-SzZ4PtwCrLfdZBDA4mz2XbBvSbE6azHJhw@mail.gmail.com>
To: Mohit Sahni <mohit06jan@gmail.com>
Cc: Ace Wg <ace@ietf.org>, David von Oheimb <david.von.oheimb@siemens.com>, Saurabh Tripathi <stripathi@paloaltonetworks.com>
Content-Type: multipart/alternative; boundary="000000000000627d3005cac6773a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/-E1irp9cH99Ywvc6FBNn8KjFC8U>
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: Mon, 30 Aug 2021 13:04:06 -0000

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://www.example.com/.well-known/cmp
> >    coap://www.example.com/.well-known/cmp/operationalLabel
> >    coap://www.example.com/.well-known/cmp/profileLabel
> >    coap://www.example.com/.well-known/cmp/profileLabel/operationalLabel
> > """
> >
> > 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://datatracker.ietf.org/doc/html/rfc7252#section-12.3
> > 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://datatracker.ietf.org/doc/html/rfc8615#section-3.1
> > 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://datatracker.ietf.org/doc/draft-ietf-ace-cmpv2-coap-transport/
> >> >
> >> > There is also an htmlized version available at:
> >> >
> https://datatracker.ietf.org/doc/html/draft-ietf-ace-cmpv2-coap-transport-02
> >> >
> >> > A diff from the previous version is available at:
> >> >
> https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-cmpv2-coap-transport-02
> >> >
> >> >
> >> > Internet-Drafts are also available by anonymous FTP at:
> >> > ftp://ftp.ietf.org/internet-drafts/
> >> >
> >> >
> >> > _______________________________________________
> >> > Ace mailing list
> >> > Ace@ietf.org
> >> > https://www.ietf.org/mailman/listinfo/ace
> >
> >
> >
> > --
> > Daniel Migault
> > Ericsson
>


-- 
Daniel Migault
Ericsson