see inline On 10/06/17 09:11, Esko Dijk wrote: > 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.
Yes, but surely you are aware of two things: 1) constrained devices are not within ANIMA's charter. 2) we are trying to do exactly that in https://datatracker.ietf.org/doc/draft-ietf-6tisch-dtsecurity-zerotouch-join/ with ace-coap-est defining the translation from HTTP->CoAP. > 1. The choice for JSON only (MUST) in the voucher format seems rather > restrictive. Current work (CoRE WG, ACE WG, other SDOs) focuses on If voucher-05 says that JSON is the only format, then there is an error. PKCS7 signed JSON was chosen as the reference format for vouchers. There are MUST's in section 6, but supporting PKCS7 is not intended to be normative. We do say: Unless otherwise signaled (outside of the voucher artifact), the signing structure is by default a PKCS#7 SignedData structure, as specified by Section 9.1 of [RFC2315], encoded using ASN.1 distinguished encoding rules (DER), as specified in ITU-T X.690. Perhaps you can suggest some text that would make it clearer that we are establishing the semantics of what a voucher is, and then giving syntax in what we believe is a way to express the syntax in a concrete format. This is to prove that the YANG model is implementable. > 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, …). In March/April (you will see this in notes and list discussion) we considered going to JWS, and even straight to CWT. We got push back from implementers who objected to what they see is still a very immature technology. > 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 PKCS7 signed CBOR seems like a bad mix of new and old. CWT does everything that PKCS7/CMS provides us. > 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 Maybe. The document is the minimal semantics that we need. It's important to realize that vouchers are artifacts passed by a manufacturer to a device which they created. The only technical reason to have a standard at all is because it became clear that we wanted the Registrar to be able to audit the process. The political/communal reason is that a set of standard voucher formats will promote reuse; but that could have been done with a popular open source library. > 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 (*). Yes, it was omitted on purpose because we don't think that we can get consensus within the constraints of ANIMA's charter.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
