Michael, Thanks for your feedback. Indeed I understood constrained devices are not in ANIMA's scope, but at least I feel the usage of vouchers for this domain should not be a-priori 'blocked'. Hence my CBOR comment.
> If voucher-05 says that JSON is the only format, then there is an error. I indeed read Section 6 as stating that JSON is the only format: (possibly a verb is missing in this sentence) The voucher signing structure that MUST contain JSON-encoded content conforming to the voucher-artifact YANG data schema of the YANG module specified in Section 6.3. Section 1 I understood in the same way, JSON=MUST and signing can differ: The voucher artifact is a JSON [RFC7159] document, conforming to a data model described by YANG [RFC7950], encoded using the rules defined in [RFC7159], and signed using (by default) a PKCS#7 structure [RFC2315]. It does not say "a (by default) JSON document" but "a JSON document". The abstract also states JSON. I could suggest some text, such that CBOR encoding is also allowed - this will imply a few word changes in Abstract, Section 1 and Section 6 I think. regards Esko -----Original Message----- From: Anima [mailto:[email protected]] On Behalf Of Michael Richardson Sent: Tuesday, October 17, 2017 21:13 To: [email protected] Subject: Re: [Anima] Last Call: <draft-ietf-anima-voucher-05.txt> (Voucher Profile for Bootstrapping Protocols) to Proposed Standard 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. ________________________________ 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. _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
