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

Mohit Sahni <> Wed, 14 October 2020 23:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7E2EB3A112E for <>; Wed, 14 Oct 2020 16:19:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2Kux5GSxsU_B for <>; Wed, 14 Oct 2020 16:19:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5AB5D3A112D for <>; Wed, 14 Oct 2020 16:19:29 -0700 (PDT)
Received: by with SMTP id u19so1834237ion.3 for <>; Wed, 14 Oct 2020 16:19:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=1T3k2x2nP2tBh2Ekf4IMymseg5Xy+O12O2LhnIYLRcM=; b=kUYjf7JyrOqGNQR+QlqRivo3BnzeoDELprY+yQW/Bl1vDJHUPD9ZWovcEdQMFNsW+S AHodfxO3DLpYH5iLEKIJGsM8in6YJ0okmq+5Iyr1IooUibtBe69s58/pJIkS1jjz2tZH 5y8gAKWm6o2mJZNkd9GbKQ3aWefYH6QdROAuoUSUsKCkz9nqYvakLXy9gf3UKy2tNnJW tNM8ZlhD5l3fsFP9AB6T3S0ZCxDrVpLh5FjRYjULR12lcLn9jvcjZuKSwC7xovMr5y7t 4xkwrFJkjsYA8yHq++09tuPbhyqpxHQRHXwC3Rxt3RELY1sWuB50iXKWf5XNot4ySKW2 2w1Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=1T3k2x2nP2tBh2Ekf4IMymseg5Xy+O12O2LhnIYLRcM=; b=s7Z2xT0WVE7srrbN5RoSoD2EEfYSPt5+Ogja0wc83DfPz1q8r41LOfhJXR0Ff86KRP MzEP/GC4CnwQLiBrO5L7aD7u4zZXfis5/T16ccsTXUxKcNfrWuWh6rChC18kpbwFcEuL DUjv3AHDuLlZtPBbhvuw4TBkZo8j2CYTXs31d9uXwRLFGA79bV2dxZJXOeKCQvx/H6P+ Y6xNI3dFyqbxo9U/iQbVtYXNhMfqtCq/p7/1OKFh2vOgOzhginnAC7s8+kYBSRdr/KQz X6Y8qyQ/FdehOqMEsOyuOZn79Y+PSQQLlXHJSFB1IC7OrN9XP6O7oEM5X4sOKIyAVXW7 y5YA==
X-Gm-Message-State: AOAM531a0FDOq78dk85wtu0DmQ0og6HBw2ZgVAKBw7TAhXxetTdw8y0E x5QpmKUhS2sXR/toKJLMT76zcJ3djisLYJHl+Apw7KREggo=
X-Google-Smtp-Source: ABdhPJyF78Jcoj7soe4WV3EzryD/tmywXbb60GvKwxNcouJOIajIe15ePSuKRHepw6N6lyGJsHMVWT4jW6YUgd8ADw4=
X-Received: by 2002:a02:a384:: with SMTP id y4mr1437433jak.63.1602717567237; Wed, 14 Oct 2020 16:19:27 -0700 (PDT)
MIME-Version: 1.0
From: Mohit Sahni <>
Date: Wed, 14 Oct 2020 16:19:16 -0700
Message-ID: <>
To: Ace Wg <>
Content-Type: multipart/alternative; boundary="0000000000004546a905b1a9c300"
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: Wed, 14 Oct 2020 23:19:31 -0000

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
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.
> <MS> 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

> 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/.

<MS> 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

<MS> 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.
<MS> 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