[Anima] AD review of draft-ietf-anima-jws-voucher-10

[Mahesh Jethanandani <[e-mail]>]

Back in February I had provided comments as an individual contributor. Thanks for addressing them.

This is my AD comments that are divided between COMMENTs and NITs. I hope to see responses to the COMMENTs. while NITs are there FYI. 


-------------------------------------------------------------------------------
COMMENT
———————————————————————————————————————

This document updates RFC8366, but does not seem to include explanatory text
about this in the abstract.

"Abstract", paragraph 0
>    [I-D.draft-ietf-anima-rfc8366bis] defines a digital artifact called
>    voucher as a YANG-defined JSON document that is signed using a
>    Cryptographic Message Syntax (CMS) structure.  This document
>    introduces a variant of the voucher artifact in which CMS is replaced
>    by the JSON Object Signing and Encryption (JOSE) mechanism described
>    in RFC7515 to support deployments in which JOSE is preferred over
>    CMS.

An Abstract cannot have a reference. Please change the reference to I-D.draft-ietf-anima-rfc8366bis to plain text.

Section 2, paragraph 5
>    Voucher:  A short form for voucher artifact and refers to the signed
>       statement from the MASA service that indicates to a pledge the
>       cryptographic identity of the domain it should trust, per
>       [I-D.draft-ietf-anima-rfc8366bis].

Please add definition and expansion on first use of terms such as MASA. Also you need to define Pledge (with a capital P), or point to a definition in another document. Avoid mixing capitalization between Pledge and pledge.

Section 3, paragraph 6
>    A "JWS JSON Serialization Overview" is given in Section 3.2 of
>    [RFC7515] and more details on the JWS serializations in Section 7 of
>    [RFC7515].  This document makes use of the "General JWS JSON
>    Serialization Syntax" of [RFC7515] to support multiple signatures, as
>    already supported by [RFC8366] for CMS-signed vouchers.

Since the document mentions two forms of serialization, it would help to understand the choice. Was the choice of "General JWS JSON Serialization Syntax" to support multiple signatures? Why was the "JWS Compact Serialization" not chosen?

Section 4, paragraph 2
>    This request occurs via HTTP-over-TLS, however, for the Pledge-to-
>    Registrar TLS connection, the Pledge is provisionally accepting the
>    Registrar server certificate.  Hence it is subject to disclosure by a
>    Dolev-Yao attacker (a "malicious messenger") [ON-PATH], as explained
>    in Section 10.2 of [BRSKI].

The first sentence does not parse for me. Can it be reworded?

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "he"; alternatives might be "they", "them", "their"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool) so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 1, paragraph 2
>    This document provides cryptographic signing of the JSON voucher data
>    in form of JSON Web Signature (JWS) [RFC7515] and the media type
>    "application/voucher-jws+json".  The encoding specified in this
>    document is used by [I-D.ietf-anima-brski-prm] and may be more handy
>    for use cases already using Javascript Object Signing and Encryption
>    (JOSE).  This document should be considered as enhancement of
>    [I-D.draft-ietf-anima-rfc8366bis],
>    as it provides a new voucher form with media type "application/
>    voucher-jws+json" and the related serialization.  It does not extend
>    the YANG definition of [I-D.draft-ietf-anima-rfc8366bis].

I continue to see inconsistent use of capitalization for terms defined or used in this document. E.g. JSON voucher data, and JSON Voucher Data.

Section 3.2, paragraph 0
>    The JSON Voucher Data is an unsigned JSON document [RFC8259] that
>    conforms with the data model described by the ietf-voucher YANG
>    module [RFC7950] defined in Section 5.3 of
>    [I-D.draft-ietf-anima-rfc8366bis] and is encoded using the rules
>    defined in [RFC7951].  The following figure provides an example of
>    JSON Voucher Data:

Please correct the reference to the Section number in I-D.draft-ietf-anima-rfc8366bis. It should be 7.3.

Section 3.3, paragraph 3
>    To validate voucher signatures all certificates of the certificate
>    chain are required up to the trust anchor, Note, to establish trust
>    the trust anchor SHOULD be provided out-of-band upfront.  This is
>    consistent with Section 5.5.2 of [BRSKI].

s/to the trust anchor, Note,/to the trust anchor. Note,/

Document references draft-ietf-anima-rfc8366bis-11, but -12 is the latest
available revision.

Document references draft-ietf-anima-brski-prm-12, but -15 is the latest
available revision.

Document references draft-ietf-anima-constrained-voucher-24, but -25 is the
latest available revision.

Paragraph 4
>  type is registered and examples are provided. Status of This Memo This Inte
>                                  ^^^^^^^^^^^^
You have used the passive voice repeatedly in nearby sentences. To make your
writing clearer and easier to read, consider using active voice.

Section 2, paragraph 3
> on first use of terms such as MASA. Also you need to define Pledge (with a c
>                                     ^^^^
A comma may be missing after the conjunctive/linking adverb "Also".

Section 3.1, paragraph 6
>  JSON [RFC8259] optionally allows to escape these with backslashes ('\'). Hen
>                                   ^^^^^^^^^
Did you mean "escaping"? Or maybe you should add a pronoun? In active voice,
"allow" + "to" takes an object, usually a pronoun.

Section 3.3, paragraph 3
>  the Registrar server certificate. Hence it is subject to disclosure by a Do
>                                    ^^^^^
A comma may be missing after the conjunctive/linking adverb "Hence".

Mahesh Jethanandani
[e-mail]