Re: [Anima] Last Call: (Voucher Profile for Bootstrapping Protocols) to Proposed Standard
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:anima-boun...@ietf.org] On Behalf Of Michael Richardson Sent: Tuesday, October 17, 2017 21:13 To: anima@ietf.org Subject: Re: [Anima] Last Call: (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. T
Re: [Anima] Last Call: (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. signature.asc Description: OpenPGP digital signature ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Last Call: (Voucher Profile for Bootstrapping Protocols) to Proposed Standard
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. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
Re: [Anima] Last Call: (Voucher Profile for Bootstrapping Protocols) to Proposed Standard
I have the following comments about draft-ietf-anima-voucher-05.txt. Section 6, para 2. I cannot parse this sentence. It has no verb. Para 3. Please give citations for DER and X.690. Section 6.2, para 1. The second sentence is not a sentence. It has no main clause. Section 8.1, para 3, last line. "should not" -> "SHOULD NOT" I have also sent several grammar/formatting corrections to the ANIMA list, as these are not substantive. Bill Atwood On 28/09/2017 9:24 AM, The IESG wrote: > > The IESG has received a request from the Autonomic Networking Integrated > Model and Approach WG (anima) to consider the following document: - 'Voucher > Profile for Bootstrapping Protocols' >as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits final > comments on this action. Please send substantive comments to the > i...@ietf.org mailing lists by 2017-10-12. Exceptionally, comments may be > sent to i...@ietf.org instead. In either case, please retain the beginning of > the Subject line to allow automated sorting. > > Abstract > > >This document defines a strategy to securely assign a pledge to an >owner, using an artifact signed, directly or indirectly, by the >pledge's manufacturer. This artifact is known as a "voucher". > >The voucher artifact is a YANG-defined JSON document that has (by >default) been signed using a PKCS#7 structure. The voucher artifact >is normally generated by the pledge's manufacturer or delegate (i.e. >the Manufacturer Authorized Signing Authority). > >This document only defines the voucher artifact, leaving it to other >documents to describe specialized protocols for accessing it. > > > > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ballot/ > > > No IPR declarations have been submitted directly on this I-D. > > > > > ___ > Anima mailing list > Anima@ietf.org > https://www.ietf.org/mailman/listinfo/anima > -- Dr. J.W. Atwood, Eng. tel: +1 (514) 848-2424 x3046 Distinguished Professor Emeritus fax: +1 (514) 848-2830 Department of Computer Science and Software Engineering Concordia University EV 3.185 email:william.atw...@concordia.ca 1455 de Maisonneuve Blvd. Westhttp://users.encs.concordia.ca/~bill Montreal, Quebec Canada H3G 1M8 ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
[Anima] Last Call: (Voucher Profile for Bootstrapping Protocols) to Proposed Standard
The IESG has received a request from the Autonomic Networking Integrated Model and Approach WG (anima) to consider the following document: - 'Voucher Profile for Bootstrapping Protocols' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2017-10-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". The voucher artifact is a YANG-defined JSON document that has (by default) been signed using a PKCS#7 structure. The voucher artifact is normally generated by the pledge's manufacturer or delegate (i.e. the Manufacturer Authorized Signing Authority). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/ballot/ No IPR declarations have been submitted directly on this I-D. ___ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
