Subject: [Anima] Adam Roach's No Objection on draft-ietf-anima-voucher-06: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Wed, 13 Dec 2017 22:28:39 -0800

Adam Roach has entered the following ballot position for
draft-ietf-anima-voucher-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to the authors and working group participants for their work on this
document. I have a somewhat major and handful of minor suggestions for
improvement.

The larger comment is: section 5 talks about a variety of potential alternate
formats and mentions a couple of techniques that might be used to differentiate
among them. I'll note that these techniques relate to MIME types and related
data (filename extensions). The fact that *this* document doesn't define a MIME
type for the CMS-signed-JSON variant will make it difficult and/or awkward for
these future formats to employ these techniques. For example, if I were to
define a COSE-signed-CBOR format and say "use HTTP Content-Type header fields
to tell this apart from CMS-signed-JSON", I would be in the somewhat odd
position of having to define the MIME-type for CMS-signed-JSON in *that*
document, or of coming up with a very short update to the anima-voucher
document that does nothing other than define its MIME type.

It seems that adding a single sentence to section 5 ("To facilitate these
techniques, this document registers a MIME type for CMS-signed JSON in section
8.4") plus a registration of a new MIME type along with its filename extension
(e.g., "application/voucher-cms+json" and ".vcj") in that new section 8.4 would
make life much easier for anyone who wants to define the alternate formats
envisioned by section 5.

Section 2:
      Securely imprinting is a primary focus of this document [imprinting].

This is a pretty awkward citation. Suggest maybe changing it to:
      Securely imprinting is a primary focus of [imprinting].

(It's also not entirely clear that the cited article covers *securely*
imprinting, so you may consider rephrasing the sentence entirely)

Section 2:
   Authentication of Join Registrar:  Indicates how the Pledge can
      authenticate the Join Registrar.  This might include an indication
      of the private PKIX (Public Key Infrastructure using X.509) trust
      anchor used by the Registrar, or an indication of a public PKIX
      trust anchor and additional CN-ID or DNS-ID information to
      complete authentication.

I think a citation here to RFC6125 would be helpful to the user in
understanding the meaning of CN-ID and DNS-ID.

Section 7.1: I think it would be useful to explicitly point out that a device
that might have a MITM registrar could also have an MITM attack against any
attempts to use an unauthenticated network protocol (such as NTP) to retrieve a
time; and that such network-retreived times cannot be trusted for voucher
verification purposes.

---

From: Michael Richardson <[email-masked]>
Date: Fri, 15 Dec 2017 09:24:34 -0500

Adam Roach <[email-masked]> wrote:
    > these future formats to employ these techniques. For example, if I were

In the first use of this format over HTTPS, which is "BRSKI",

We register parameters for the application/smime-type.
Since that we written we changed the "primary" signing type from PKCS7 to
CMS, so I think that these will become application/cms registrations instead.

https://tools.ietf.org/html/draft-ietf-anima-bootstrapping-keyinfra-09#section-7
> This document requests the following Parameter Values for the "smime-
>   type" Parameters:
>
>   o  voucher-request
>
>   o  voucher

As for .vcj extension, that's a good idea.
I think that NETCONF could register something.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 20 Dec 2017 00:05:50 -0500

> CMS, so I think that these will become application/cms registrations instead.

After some discussion, Max and I (Kent is on PTO) decided that your way
is best, and provided that Kent has no problem with your suggestion of
application/voucher-cms+json, we will go with that.

https://github.com/anima-wg/voucher/pull/14/commits/683d3c49037dcfe3e65717856eaabb1e213fe4ca

are the changes... does the MIME registration look right?