Re: [Anima-bootstrap] CoAP mandatory?

Michael Richardson <> Wed, 01 March 2017 14:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A6741294FA for <>; Wed, 1 Mar 2017 06:11:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 yQyE4q9wuOei for <>; Wed, 1 Mar 2017 06:11:48 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 178361294E7 for <>; Wed, 1 Mar 2017 06:11:48 -0800 (PST)
Received: from ( [IPv6:2607:f0b0:f:2::247]) by (Postfix) with ESMTP id 76784E1E4; Wed, 1 Mar 2017 09:34:04 -0500 (EST)
Received: from (localhost [IPv6:::1]) by (Postfix) with ESMTP id B6EB36381A; Wed, 1 Mar 2017 09:11:46 -0500 (EST)
From: Michael Richardson <>
To: "" <>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 01 Mar 2017 09:11:46 -0500
Message-ID: <>
Archived-At: <>
Cc: Carsten Bormann <>, peter van der Stok <>, "Panos Kampanakis (pkampana)" <>, "Liubing (Leo)" <>, "Kumar, Sandeep" <>
Subject: Re: [Anima-bootstrap] CoAP mandatory?
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 01 Mar 2017 14:11:50 -0000

Carsten Bormann <> wrote:
    >> [Bing] I didn't quite followed the relative discussion. Is this
    >> because that CoAP is seldom supported by Non-IoT devices (e.g. telecom
    >> boxes)?

    > Well, ANIMA is rarely supported by Non-IoT devices either.

Agreed. I don't expect IETF-notion IoT devices to support an ACP.
(By this, I mean RFC7228 class 2 devices)

One reason I'd like to have rfc7228bis define class 3 and 4 devices is because
that's what the technical journalism think are IoT devices.  If baby monitors
(I'll call this class 3 for now) and home routers (I'll call this class 4)
are "IoT", then yes, I *DO* expect IoT to support some of ANIMA.

{I'd say that class 3 can speak client HTTP and TLS without simplification,
and class 4 devices support a (web?) UI, and could participate as a leaf in
an ACP. That would be *my* definitions without caring about ram/CPU/Mhz...}

Even within the IETF, it seems that we have many categories of class 2
device: the power and network constraints between electric meter sensors (AMI
has 802.15.4g PHYs and batteries that get charged regularly) and industrial
sensors and light bulbs is pretty wide.

The working environment that the ARM/TEEP people seem to be coming from seems
like it's pretty rich compared to class 2: I think we are rapidly moving
towards a place where code space and scratch ram are no longer significant
limits, while wakefulness and network bandwidth continue to be limits.

(I am recently involved in a project where a RPI/OrangePI 0 with mains
and/or weekly battery changes may need to uplink via LoRAN. Makes me think of
Marvin the Robot)

I think that we can have a number of things in common.
Frankly, I'm feeling a lot of pushback at this point, so please tell if you
support these goals.

    1) I'd like to have an ownership voucher format that is in common
       between IoT (class 2) devices and higher class devices.

    2) I'd like JRCs to be able to enroll IoT devices as well as class 3+
       devices.  I don't mind if the JRC has to have totally different
       interfaces (HTTPS/EST vs CoAP/DTLS vs CoAP/OSCOAP/CoMI) for these
       differing envionments.

    3) I think that the MASA/JRC interaction can be one protocol.

In order for the ownership voucher to be easily processed by class 2 devices,
there has to be a minimum of ASN.1 crud.  If some is necessary, it should be
easily faked with predefined const char crud[]={} constructs.

OSCOAP/EDHOC seems to moving towords Curve25519, and perhaps EdDSA.
I'm unclear if ACE will move from ECDSA to EdDSA. I'd like them to.
Meanwhile, I'm unclear if hardware accel of asymmetric operations will apply
to EdDSA as well as it does to ECDSA. I think that some devices, particularly
TPM ones, are locked to ECDSA, and often the single p256 curve.  This may
lock us down for some time.  This is an onwership voucher issue.

[ASN.1 is bad for code space issues, but also because the code will be used
once, and it's not gonna get a lot of attention]

Michael Richardson <>, Sandelman Software Works
 -= IPv6 IoT consulting =-