Re: [Anima-bootstrap] CoAP mandatory?

[Michael Richardson <[e-mail]>]

Carsten Bormann <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-