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 <[email protected]> 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: [email protected] <mailto:[email protected]> > [email protected] <mailto:[email protected]> > Datum: Dienstag, 10. September 2024 um 17:37 > An: [email protected] <mailto:[email protected]> > [email protected] <mailto:[email protected]> > Cc: [email protected] <mailto:[email protected]> [email protected] > <mailto:[email protected]> > 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 -- [email protected] <mailto:[email protected]> > To unsubscribe send an email to [email protected] > <mailto:[email protected]> > > > > > > Von: Mahesh Jethanandani <[email protected] > <mailto:[email protected]>> > Datum: Mittwoch, 28. August 2024 um 00:46 > An: [email protected] > <mailto:[email protected]> > <[email protected] > <mailto:[email protected]>> > Cc: [email protected] <mailto:[email protected]> > <[email protected] <mailto:[email protected]>>, [email protected] > <mailto:[email protected]> <[email protected] <mailto:[email protected]>> > 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 > [email protected] <mailto:[email protected]> Mahesh Jethanandani [email protected]
_______________________________________________ Anima mailing list -- [email protected] To unsubscribe send an email to [email protected]
