|
Below are my comments on draft-ietf-anima-voucher-05. Overall, the goal of these comments is to make BRSKI including voucher format as defined in the draft optimally suited to constrained, embedded devices that operate on low-bandwidth
IPv6 networks. See also draft-vanderstok-ace-coap-est for some more context on this work. 1. The choice for JSON only (MUST) in the voucher format seems rather restrictive. Current work (CoRE WG, ACE WG, other SDOs) focuses on embedded devices that will support CBOR but not JSON. Shouldn’t CBOR encoding be added already in the
present document, as it can be a quite straightforward mapping or straightforward derivation from the YANG format spec? A CBOR encoding will be a bit more compact as e.g. the three “binary” fields listed in Section 6.1 of the draft will be in CBOR directly
binary encoded, no base64 needed. So if the voucher draft would also specify the CBOR equivalent of the JSON structure it would be much better usable for the constrained-devices context; and leave still open more ways to perform the signing (PKCS#7 or others e.g. COSE,
JWS, …). 2. A voucher format that could even be preferable over “PKCS#7 signed CBOR data” is usage of COSE (RFC 8152) to sign the voucher data. When COSE signing is used the typical format for the signed data would be CBOR and that links back to
point 1. The current draft does leave open the option of other signing methods (non-PKCS#7); however … doesn’t the current emphasis on PKCS#7 kind of close the door to other formats since people will expect everyone to just use what’s in this document? Is
it intended that for a new voucher signing format a whole new RFC has to be created, extending the current anima-voucher draft? Including COSE signing option in the current draft would be best, but it seems to be on purpose omitted from the current draft
(*). Best regards Esko (*) possibly the outcome of the email thread “Re: [Anima] [Anima-bootstrap] Voucher signing method” earlier this year. The information contained in this email may be confidential and/or legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this email is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original email. |