Re: [Ace] draft-ietf-ace-cmpv2-coap-transport-00.txt - do not mention V" of CMP in the document

David von Oheimb <> Thu, 11 March 2021 17:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 471283A1503 for <>; Thu, 11 Mar 2021 09:11:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lna2ioVutAD7 for <>; Thu, 11 Mar 2021 09:10:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AA133A1541 for <>; Thu, 11 Mar 2021 09:10:56 -0800 (PST)
Received: from ( []) by (8.15.2/8.15.2) with ESMTPS id 12BHArpK020462 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 11 Mar 2021 18:10:53 +0100
Received: from [] ([]) by (8.15.2/8.15.2) with ESMTP id 12BHAqe0017128; Thu, 11 Mar 2021 18:10:52 +0100
To: Mohit Sahni <>
Cc: "Brockhaus, Hendrik" <>, "" <>, Andreas Kretschmer <>
References: <AM0PR10MB24186B276EBD30EE32A7A87BFE969@AM0PR10MB2418.EURPRD10.PROD.OUTLOOK.COM> <>
From: David von Oheimb <>
Message-ID: <>
Date: Thu, 11 Mar 2021 18:10:52 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------88DD0E99C0EA41BDF3B1B8A1"
Content-Language: en-US
Archived-At: <>
Subject: Re: [Ace] draft-ietf-ace-cmpv2-coap-transport-00.txt - do not mention V" of CMP in the document
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 11 Mar 2021 17:11:06 -0000

Hi Mohit,

thanks a lot for providing that draft. It looks very good already.

Good point by Hendrik to replace "CMPv2" by "CMP" since the version
really does not matter here.

I'd suggest dropping the hyperlinked reference from the abstract and
a couple of further adaptations to the abstract, such that it becomes

   This document specifies use of the Constrained Application Protocol
   (CoAP) for transferring Certificate Management Protocol (CMP) messages.
   It details the respective option mentioned in the Lightweight CMP Profile.
   CMP defines the interaction between various PKI entities for certificate
   enrollment and management.  CoAP is an HTTP-like client-server protocol
   for use in constrained devices in IoT space.

Further mostly very minor improvement suggestions are given below.


Section 1:

transport -> transfer (several times)
encryption of messages -> protection of messages
between CAs -> between RAs

Section 2:

PKIMesssage -> PKIMesssages

I do not understand what you want so say here:
> An EE MUST verify the configured Root CA
> certificate against the Root CA certificate of the discovered entity
Likely you meant:

An EE MUST verify the certificate of the discovered entity
against a configured trust anchor (Root CA certificate)

The URI's for CoAP resources should start ->
The only difference is that the URIs for CoAP resources MUST start

should return a "2.05 Content" ->
MUST return a "2.05 Content"
(or are there other options in case of success?)

application/pkixcmp -> "application/pkixcmp"

for the possible changes -> for potential changes

Block Wise -> Block-Wise (in title of 2.6)
Block Wise -> block-wise (in body of 2.6)

header body and optional fields ->
header, body, protection, and extraCerts including many optional and
potentially bulky fields

outgoing interface -> interface
(because this may also happen for responses)

maybe leave out?   that are exchanged between EEs and RAs or CAs

maybe weaken?:   mode MUST be used -> mode SHOULD be used

then, it -> then it

Proxy opens -> the proxy opens

maybe leave out?   from EEs to RAs or from EEs to CAs

Section 3:

the encryption and authentication of the messages but in cases when ->
protecting message contents, in case

7.1 and 7.2 -> 7.2 and 7.3
(for draft 03 at least)

overhead of using DTLS connection -> overhead of setting up DTLS connections

Sections 4 and 5:

CoAP to HTTP -> CoAP-to-HTTP
(several times)

significant changes -> changes

Announcements Messages -> announcement messages

MUST be positioned -> SHOULD be positioned
(else the recommendation given next makes no sense)

between CAs and RAs -> between RAs and CAs

UDP based -> UDP-based
(two times)


HTTPS protocol, -> HTTPS.

however client SHOULD be configured to trust the CA certificate used by
proxy to sign the Man in the Middle (MITM) certificate for certificate
chain validation ->
The client SHOULD be configured with a trust anchor suitable for
validating the DTLS server certificate used by the proxy

I doubt if the paragraph
>    However, the CoAP protocol which
>    uses UDP as layer 4 transport is vulnerable to many issues due to the
>    connectionless characteristics of UDP itself.  The Security
>    considerations for CoAP protocol are mentioned in the [RFC7252 <>].
>    Using a CoAP to HTTP proxy mitigates some of the risks as the
>    requests from the EE's can terminate inside the trusted network and
>    will not require the server to listen on a UDP port making it safe
>    from UDP based address spoofing, Denial of Service, and amplification
>    attacks due to the characteristics of UDP.
makes sense because, as you wrote before, CMP is already self-contained
in terms of security.
Therefore I think it should be sufficient to say for instance:

Therefore security issues of CoAP due to using UDP do not carry over to the CMP layer 
except for the vulnerability to Denial-of-Service attacks.

Section 6:

content-type application/pkixcmp -> content type "application/pkixcmp".

On 10.03.21 19:44, Mohit Sahni wrote:
> Hi Hendrik
> Thanks for the update, I will make changes to remove the CMP version
> references from the document. I think we can exclude CMPv1 from the
> scope as it will obsolete soon.
> Thanks
> Mohit
> On Fri, Mar 5, 2021 at 9:36 AM Brockhaus, Hendrik
> <> wrote:
>> Mohit
>> We introduced V3 of CMP in draft-ietf-lamps-cmp-updates-08 Section 2.15. The version of CMP is not relevant to the CoAP transport, I guess. Therefore, I suggest to  remove references to the CMP version from your draft, especially from the title. If you want to exclude CMP V1 as specified in RFC 2510 from the scope of your draft, this is fine with me as well.
>> Hendrik