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

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.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 Oct 2017 15:12:30 -0400

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.

---

From: Esko Dijk <[email-masked]>
Date: Wed, 18 Oct 2017 14:24:46 +0000

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-masked]] On Behalf Of Michael Richardson
Sent: Tuesday, October 17, 2017 21:13
To: [email-masked]
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

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:

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.
>
> 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

> 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.