Subject: Re: [Anima] Last Call: <draft-ietf-anima-voucher-05.txt> (Voucher Profile for Bootstrapping Protocols) to Proposed Standard

From: William Atwood <[email-masked]>
Date: Wed, 4 Oct 2017 17:16:01 -0400

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'
>   <draft-ietf-anima-voucher-05.txt> 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
> [email-masked] mailing lists by 2017-10-12. Exceptionally, comments may be
> sent to [email-masked] 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
> [email-masked]
> 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:[email-masked]
1455 de Maisonneuve Blvd. West    http://users.encs.concordia.ca/~bill
Montreal, Quebec Canada H3G 1M8

---

From: Esko Dijk <[email-masked]>
Date: Fri, 6 Oct 2017 13:11:24 +0000

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.