search

anima-wg / constrained-voucher

This is a repo for the IETF Internet Draft about constrained vouchers in CBOR
2 stars 4 forks source link

should the registrar/masa communication allow CoAP? #58

Closed mcr closed 3 years ago

mcr commented 3 years ago

It seems convenient for some implementations to use CoAP from the Registrar to the MASA.

Some assumed that it could be either, but most prefer HTTPS.

mcr commented 3 years ago

The "ra" audit-request CoAP request is not necessary, and should not be shown in the example.

csosto-pk commented 3 years ago

It seems convenient for some implementations to use CoAP from the Registrar to the MASA.

Some organization standing a COAP MASA on the Internet seems a far fetched scenario. I would not expect MASA to be sitting in a constrained environment.

But again, I could be wrong and some may have appetite for a COAP MASA.

mcr commented 3 years ago

Consensus is that Registrar--> MASA will always be HTTPS. The format of the voucher-request will match the format of the pledge->registrar voucher request.

EskoDijk commented 3 years ago

See comment in #52 of today for a possible rationale why CoAPS could be attractive on a constrained (cellular/LPWAN) uplink to MASA. Then the reason why the MASA supports COAPS is not because it is itself constrained, but rather to offer support for constrained (e.g. cellular/IoT/LPWAN) uplinks of the Registrar towards the cloud. Still, the real difference in terms of latency (roundtrips) and payload size (total) is still unclear.

EskoDijk commented 3 years ago

Note: if HTTPS is used for Registrar -> MASA communication , then also this communication will use the full (HTTP) URI paths to the EST/BRSKI functions and not the abbreviated (CoAP) URI paths. So the resource "/ra" must be removed - as part of this ticket's work - from the text since the Registrar will use "/requestauditlog" to MASA. And the Pledge will not use this function towards Registrar if I'm correct.