Re: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01

Mohit Sahni <> Thu, 15 October 2020 00:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E9F93A119B for <>; Wed, 14 Oct 2020 17:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 682RZjruTSLa for <>; Wed, 14 Oct 2020 17:56:16 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A763E3A1120 for <>; Wed, 14 Oct 2020 17:56:16 -0700 (PDT)
Received: by with SMTP id l8so2129790ioh.11 for <>; Wed, 14 Oct 2020 17:56:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=I5vG79HqPJ+BfGQiBUfmGPeE/XDC0cipmUhJiNJ2m5I=; b=Q2rMYxdjAJYX2NTyTBZmATI41aHSJ4GObB2VrwyemBlwIv76Z7AM6G1uXeKrIloEJJ Ukxa8XQN0XxK7gvlEj7eYvnQPwwp0rBfhYbvfEPPjIgRbXS238s2HLCFMxBXVx6YEPuf AIIE0RAexlM9RJQmSCZQjYJT/Xg455aHGHTVSXpwpzdXNAvG0co0fEGUaf8QlvxHFz3S ltzeGkZZoXQzMLj+ZL8XTv8i3UzNpC7S17MIIE1n03bV08GtR6MnhsA5MLNyeJ3DfCwO K9UeXoZ/svmdqD6zvdKDltCXKU+CkpUKGchV2h/KE2gwE9xYzcS4pCEbsZd/KvEElAD8 TN1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=I5vG79HqPJ+BfGQiBUfmGPeE/XDC0cipmUhJiNJ2m5I=; b=MdOywf3c0oU5N/Td2Bsu/AYrtN1cryf4SJxftA/bbvhWK6hBSvIvmZ/kYD+as/k8et rnbaDuYHHFdQZkFEvmXMXh8TNdJqmm45se8QjbMFfE/YosrBBtJK9lP3QnWr0wMCpwuv jJ5WTKawAF7NLdGcGfJOrkrmwb2O0RWvhkPznCHn5hM/3GfqH/WCwfcJiyfQZ2GG+ZHO W6eXMH9I6SzwPv8RT6adQNArM0O+0iLNjZi0D2CE3LqshVZt4lYRSggO5o1CEr+ngXn6 WsfVAlIXL63ZrbP44SY6/JvlEO59U71HfVo7H9ZnssXjEGBDljkzH6Qbqi+oOMiwJY3M mANg==
X-Gm-Message-State: AOAM533nrJCmldx77IEwFJJBYkoiPqC4LCbv31ic118qRsTwfuOetmhT 6SXi+lbtw2KMMTde918drL7FmFdiFyt195UjfSA=
X-Google-Smtp-Source: ABdhPJzkAIV22nulHw0tpTC3vmwzUjbP1Sdml44xYlEPwHWmLTdpmy/PlzxkUVNoqU+1zRuDlBAf3I4TA83ZycH2vJw=
X-Received: by 2002:a05:6638:218b:: with SMTP id s11mr1718299jaj.16.1602723375980; Wed, 14 Oct 2020 17:56:15 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Mohit Sahni <>
Date: Wed, 14 Oct 2020 17:56:05 -0700
Message-ID: <>
Cc: Ace Wg <>,, "Brockhaus, Hendrik" <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
Subject: Re: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01
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, 15 Oct 2020 00:56:18 -0000

Resending it with correct formatting:
Hi Michael,
Thanks for going through the draft. Your feedback is very helpful. I
just want to reiterate that the scope of this draft is only how to use
CoAP as a transport protocol for CMP. The work on defining how CMP
protocol itself should work on constrained devices is being done in
the "Light Weight CMP Profile"
Some of your suggestions should be discussed in the context of the
LightWeight CMP profile draft.

Please see my comments inline:

> ---------- Forwarded message ----------
> From: Michael Richardson <>
> To: Ace Wg <>
> Cc: Kent Watsen <>
> Bcc:
> Date: Thu, 08 Oct 2020 13:42:40 -0400
> Subject: Re: [Ace] Call for adoption draft-msahni-ace-cmpv2-coap-transport-01
> Hi, I've read draft-msahni-ace-cmpv2-coap-transport-01.
> I think that the major reason to use CMP instead of EST is avoid the need for
> DTLS on the constrained client.  As such, use of coaps seems far less
> interesting.
> In particular, I think that section 4.2, on CoAPs to HTTPS proxy
> is just wrong.   I don't see why we need any kind of end to end trust
> assertions given that it is CMP.   MITM trust for anchors seems a rather
> unwanted thing.
> Why can't the EE just be configured to speak to a CoAPS enabled RA (using
> it's name), and then transported to the CA via HTTPS.  It is not like
> having the TLS MITM proxy is reducing crypto effort for any entity.

[M.S.] Section 3 covers the case where EE can talk to RA directly over
CoAPs, the CoAPs to HTTPs proxy in section 4.2 is for the use case
where changes to the existing RA deployment are not desired due to
operational overheads of upgrading the RA to something that supports
CoAP/CoAPs. CoAPs to HTTPs proxy is not something that is required for
the functionality but rather an option to help with easy adoption of
the "Lightweight CMP profile" and CMPv2 protocol for constrained
devices. I will work on making it more clear what are the pros and
cons of using a proxy vs direct communication.

> I have no fundamental objection to this work, and I think that it should be
> adopted.
> But, I think that it is worth doing more than just s/http/coap/.

[M.S.]  I agree with that.

> I think that end points should be specified, as well as resource discovery.
> I was writing some text (not yet pushed) for BRSKI-ASYNC-ENROLL
> about how to do CMP for the "Delay Tolerant Networks" that AE envisions.

[M.S.]  I will add the endpoint definitions and make resource
discovery more clear in the draft.

> On constrained networks, there are some significant tussles between allowing
> certificate renewal to be driven by a state machine on the client device vs
> by the network itself.
> Client devices know when they are awake and can receive renewals, but they
> don't know if the network has capacity at that time.
> On the other hand, the network knows when it has bandwidth, and it can manage
> things.
> My approach to CMP would be define a set of resources and then use CORECONF
> to access/update them.   I think that:
> The later offers a CSR leaf that a RA could *retrieve*, and then when a
> certificate is available, could push into the keystore.
> This also deals with what the trust anchors are.
> It could be that some additional leafs are needed to implement some of the
> additional CMP specific functionality.

[M.S.] This is something that I believe is not in the scope of this
draft, This draft only defines how to use the CoAP transport for
carrying the CMP messages. When and what CMP messages are sent should
come under the CMP protocol implementation itself.

> --
> Michael Richardson <>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> _______________________________________________
> Ace mailing list