A Voucher Artifact for Bootstrapping Protocols
draft-ietf-anima-voucher-07

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.

The document is generally fine, but first references to CN-ID and DNS-ID need a reference to RFC 6125, as these terms are not defined anywhere in the document. X.690 also needs a reference.

Nit In 7.1, first sentence:

has no understand ==> has no understanding

Just some editorial comments:

- Abstract: I suspect readers will not understand the meaning of "pledge". The abstract should be understandable without referencing the terminology section.

-4, definition of Assertion Basis" : is "secure root of trust of measurement" a term of art, or a typo?

-7.1, first paragraph: s/understand/understanding

Some nits, coming from Joe Clarke as OPS DIR reviewer.

Section 2:

Old Text:

The MAS concept is explained in more detail in...

New Text:

The MASA concept is explained in more detail in...

(Note: MAS => MASA)

Old Text:

Registrar  See Join Registrar

New Text:

Registrar:  See Join Registrar

(Note: colon added)

We are discussing some comments in email, but they seem to be about writing, not technology.

Thank you for addressing Russ' Gen Art comments.  With that, I'm wondering if a recommended signature algorithm should be specified.  This change had the work go from just supporting RSA to including other (and better) choices.  

Thanks,
Kathleen