Subject: Re: [Anima] Call for adoption: draft-richardson-anima-jose-voucher

From: Michael Richardson <[email-masked]>
Date: Fri, 16 Jul 2021 18:20:28 -0400

This email addresses the Adoption Call comments from Toerless Eckert <[email-masked]> on the
JOSE-voucher document that were made 2021-07-01.
EXEC SUM: I will rename it draft-ietf-anima-jws-voucher-00 when I post it in ten days.

in the meantime, the diff from draft-richardson-anima-jose-voucher-01 to
draft-richardson-anima-jose-voucher-02 is at:
  https://www.ietf.org/rfcdiff?url1=3Ddraft-richardson-anima-jose-voucher-01&url2=3Dhttps://raw.githubusercontent.com/anima-wg/anima-jws-voucher/main/anima-jose-voucher-02.txt

 }  13	   This document describes a serialiation of the RFC8366 voucher format
 }  14	   to a JSON format is then signed using the JSON Object Signing and
 }  15	   Encryption mechanism described in RFC7515.

    tte> Welcome to the club of people too lazy to use spell checkers.

Yeah. How many times do I need to tell it that "TCP" is a word?
Spell-checking the XML is impossible, but the markdown ought to be easier.
I also found in spell checking that I was not consistent in the MIME type allocation.

    tte> (2) Up to the point where an AD or other higher power might have objections,
    tte> i really would like to see this document marked as an Update to RFC8366 so
    tte> that we have a breadcrump trail from RFC8366 to this document (personally
    tte> i am never quite sure what the strict requirements are for such a marking).

I have added text;
   This document should be considered an Update to [RFC8366] in the
   category of "See Also" as per [I-D.kuehlewind-update-tag].

    tte> (3) I like to avoid playing "can you remember that RFC number", by prefacing newly
    tte> introduced RFC numbers with their title or otherwise better known abbreviations.

I have taken your advice, and expanded the document names in the intro,
and I've changed the citation to [BRSKI] and [SZTP] rather than [RFC8995] and [RFC8572].
(I kinda wish we could do both, because that would help people recognize important RFC numbers...)

    tte> Likewise full titles would be better for following instances, like CBOR, but i'l
    tte> not comment on all places, you get the idea.

Since the CBOR and COSE references are rather informative, I could leave them that way.

 }  88	   This document provides an equivalent mapping of JSON format with the
 }  89	   signature format in JOSE format [RFC7515].

    tte> (5) Here a quick reason why this document exist should be. Something like:

    tte> The encoding specified in this document is required for [I-D.ietf-anima-brski-async-enroll]
    tte> and may be required and/or preferred in other use-cases, for example when
    tte> JOSE is already used in other parts of the use-case, but CMS is not.

I've taken your text as:

   This document provides an equivalent mapping of JSON format with the
   signature format in JOSE format [RFC7515].  The encoding specified in
   this document is required for [I-D.ietf-anima-brski-async-enroll] and
   may be required and/or preferred in other use-cases, for example when
   JOSE is already used in other parts of the use-case, but CMS is not.

    tte> I think this document might be the first one that warrants this warning given
    tte> how this seems like the first new voucher format defined by itself without
    tte> being tied to a use-case - like constrained-voucher is really constrained-brski,
    tte> although the same note would make sense there too. Or we also split that
    tte> up...

well, brski-async-enroll is the use case, and it can say that.

 }  109	   [RFC7515] defines two serializations: the JWS Compact Serialization
 }  110	   and the JWS JSON Serialization.  This document restricts itself to
 }  111	   the JWS Compact Serialization (JWT) format.

    tte> (8) ...because ... ?!

explained.

    tte> (10) It is actually called the JWS payload if i read rfc7515 correctly, and i
    tte> wonder if this whole draft would also not more correctly be called draft-richardson-anima-jws-voucher

That's fair enough, and I'll rename it when I upload it.

 }  151	   If PKIX [RFC5280] format certificates are used then the [RFC7515]
 }  152	   section 4.1.6 "x5c" certificate chain SHOULD be used to contain the
 }  153	   certificate and chain.  Vouchers will often need all certificates in
 }  154	   the chain, including what would be considered the trust anchor
 }  155	   certificate because intermediate devices (such as the Registrar) may
 }  156	   need to audit the artifact, or end systems may need to pin a trust
 }  157	   anchor for future operations.  This is consistent with [RFC8995]
 }  158	   section 5.5.2.

    tte> I'll have to hink about this more once its WG draft ;-)

CMS provides a bag to put certificates.
Because it's ASN.1, they just seem to disappear into the CMS object in a way rather like Hermione's Bag of Holding.
The JWS way is "x5c", and it feels a lot less like magic.

    tte> (13) There should be a section "Updates to rfc8366" which just two sentences:

    tte> This document adds the new JOSE (JWS ?) signature option to vouchers.
    tte> This document adds privacy considerations for transporting vouchers.

Maybe the note in the Introduction is enough?

 }  170	5.  Security Considerations
 }  172	   The issues of how [RFC8366] vouchers are used in a [RFC8995] system
 }  173	   is addressed in

    tte> EOUTOFCOFFEE ?

yes. Oops.

 }  388	A.2.  Example Parboiled Voucher Request (from Registrar to MASA)

    tte> (15) If you want to keep "parboiled", please add a reference to where an
    tte> explanation is what it means.

I've added an explanation in the example.
Maybe it belongs in section 2.

Not everyone liked my term, but I didn't get a better one.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide