[Anima] Re: I-D Action: draft-ietf-anima-jws-voucher-11, WAS AW: AD review of draft-ietf-anima-jws-voucher-10

[Mahesh Jethanandani <[e-mail]>]

Hi Thomas,

Thanks for addressing most of the comments. Here are just a couple more.

Pledge Voucher Request (PVR) vs Pledge-Voucher-Request (PVR)?

Did you run idnits on the document, or look for the result of idnits during submission. You would have noticed that [I-D.draft-ietf-anima-constrained-voucher] does not resolve. It should be [I-D.ietf-anima-constrained-voucher] (no need to have the word draft).

Thanks.

> On Sep 10, 2024, at 8:52 AM, Werner, Thomas <[e-mail]> wrote:
> 
> Hello Mahesh, all,
>  
> FYI … just uploaded new version  [Anima] I-D Action: draft-ietf-anima-jws-voucher-11
> Including the feedback provided by AD review.
>  
> Thanks and regards
> Thomas
>  
> Von: [e-mail] <mailto:[e-mail]> [e-mail] <mailto:[e-mail]>
> Datum: Dienstag, 10. September 2024 um 17:37
> An: [e-mail] <mailto:[e-mail]> [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]> [e-mail] <mailto:[e-mail]>
> Betreff: [Anima] I-D Action: draft-ietf-anima-jws-voucher-11.txt
> 
> Internet-Draft draft-ietf-anima-jws-voucher-11.txt is now available. It is a
> work item of the Autonomic Networking Integrated Model and Approach (ANIMA) WG
> of the IETF.
> 
>    Title:   JWS signed Voucher Artifacts for Bootstrapping Protocols
>    Authors: Thomas Werner
>             Michael Richardson
>    Name:    draft-ietf-anima-jws-voucher-11.txt
>    Pages:   16
>    Dates:   2024-09-10
> 
> Abstract:
> 
>    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.
> 
>    In addition to explaining how the format is created, the
>    "application/voucher-jws+json" media type is registered and examples
>    are provided.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-anima-jws-voucher%2F&data=05%7C02%7Cthomas-werner%40siemens.com%7C2342b573a20b436d0f1a08dcd1ae8844%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638615794761412298%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=%2FpAL7JxZq3yD9YH6NDlDrDF7msBCsKURh9i635aA1j4%3D&reserved=0 <https://datatracker.ietf.org/doc/draft-ietf-anima-jws-voucher/>
> 
> There is also an HTML version available at:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-ietf-anima-jws-voucher-11.html&data=05%7C02%7Cthomas-werner%40siemens.com%7C2342b573a20b436d0f1a08dcd1ae8844%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638615794761421749%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=6Ho84ccv29TGVCzFa%2Foo3o7e4%2BhhXT95lrl9OpFJRN8%3D&reserved=0 <https://www.ietf.org/archive/id/draft-ietf-anima-jws-voucher-11.html>
> 
> A diff from the previous version is available at:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-ietf-anima-jws-voucher-11&data=05%7C02%7Cthomas-werner%40siemens.com%7C2342b573a20b436d0f1a08dcd1ae8844%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638615794761428407%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=c3ZNIWKrpycHQKrVTjSsyCsZS8HeeXkfL%2B13hCpUoL8%3D&reserved=0 <https://author-tools.ietf.org/iddiff?url2=draft-ietf-anima-jws-voucher-11>
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org <http://rsync.ietf.org/>::internet-drafts
> 
> 
> _______________________________________________
> Anima mailing list -- [e-mail] <mailto:[e-mail]>
> To unsubscribe send an email to [e-mail] <mailto:[e-mail]>
>  
>  
>  
>  
>  
> Von: Mahesh Jethanandani <[e-mail] <mailto:[e-mail]>>
> Datum: Mittwoch, 28. August 2024 um 00:46
> An: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Cc: [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>, [e-mail] <mailto:[e-mail]> <[e-mail] <mailto:[e-mail]>>
> Betreff: AD review of draft-ietf-anima-jws-voucher-10
> 
> 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 <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 <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] <mailto:[e-mail]>

Mahesh Jethanandani
[e-mail]