[Anima] I-D Action: draft-ietf-anima-jws-voucher-10.txt, AW: [Anima] Review comments on draft-ietf-anima-jws-voucher-09

["Werner, Thomas" <[e-mail]>]

Please note this is the updated version, pushed to datatracker.

Best regards
Thomas


Internet-Draft draft-ietf-anima-jws-voucher-10.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-10.txt
   Pages:   15
   Dates:   2024-06-18

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://datatracker.ietf.org/doc/draft-ietf-anima-jws-voucher/10/


Von: Toerless Eckert <[e-mail]>
Datum: Donnerstag, 13. Juni 2024 um 17:06
An: Mahesh Jethanandani <[e-mail]>
Cc: [e-mail] <[e-mail]>, Robert Wilton <[e-mail]>, [e-mail] <[e-mail]>
Betreff: Re: [Anima] Review comments on draft-ietf-anima-jws-voucher-09
Thanks, Mahesh

We did discuss your input in our weekly BRSKI meeting. The authors did
submit an update to github, which i think resolves all your concerns below, see

https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fraw.githubusercontent.com%2Fanima-wg%2Fanima-jws-voucher%2Fmain%2Fanima-jws-voucher.txt&data=05%7C02%7Cthomas-werner%40siemens.com%7C0c2488ae7ab54710b0b308dc8bba5ab4%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C638538879728403557%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=FtZawatF1xKCCOpk675Jn%2Bz9TE9lx9rmhmvKQr1V5Gc%3D&reserved=0<https://raw.githubusercontent.com/anima-wg/anima-jws-voucher/main/anima-jws-voucher.txt>

Thst version should IMHO simply be pushed to datatracker as revision -10 and
then hopefvully be able to pass your official AD review (see other email) quickly.
Aka: as WG chair, i would like to see this pushed to datatracker.

For detail answers, see below.

Cheers
    Toerless

On Tue, Feb 13, 2024 at 03:43:12PM -0500, Mahesh Jethanandani wrote:
> Here are my comments on draft-ietf-anima-jws-voucher-09 draft.
>
> Overall the draft is short, and easy to understand. There are a few issues categorized under Overall, Major, Minor, and Nits, in order of importance.
>
> Overall:
>
> Please resolve all the TODOs in the document.

Done.

> Major:
>
> None.
>
> Minor:
>
> - The document makes the following statement, but it is not clear the purpose of the paragraph. Neither voucher data for CBOR or its signature format, COSE is referenced or discussed in the document. The paragraph should be removed.
>
> [I-D.ietf-anima-constrained-voucher] provides a serialization of the voucher data to CBOR [RFC8949] with the signature format of COSE [RFC8812] and the media type "application/voucher-cose+cbor”.

This explanatory text was improved and moved and hopefully meets your approval now.

This is all explanatory text and does not impact the functionality/interoperability described
basically the editorial challenge we have and solution we choose was how we should
define our voucher wrt. to RFC8366/RFC8366bis. a "JWS Voucher" uses a different
encoding than an RFC8366(bis) "CMS" Voucher and is hence incompatible with it in the sense
of interoperability on the wire. But given how it is carrying the same "payload" (voucher)
data, it is a voucher in the sense of the concept "voucher" introduced in RFC8366.

Alas, i am drawing a blank right now for a good example of a prior IETF digital artefact
technology that exists in different variations with these properties. So we did choose
to call JWS voucher an "extension" of RFC8366bis and marked it as an update RFC8366 so
that readers of RFC8366bis will be able to easily find JWS voucher - and pick it for their
deployments if it fits better than a CMS voucher. But whether or not the terms
"extension of RFC8366bis" and "update to RFC8366bis" are perfect matches with how others
interpret extension/update - i don't know. And i guess the authors neither. Which is why
we started putting "TODO" into the text for this type of editorial naming question. Which we
now removed on your request. Just to make it easier: We put a stake in the ground, choose
"extension" and "upgrade to" and let IESG/IETF review chime in if they don't like it.

> - The term “Voucher Artifact” is referenced multiple times in the document, sometimes with mixed capitalization. The terminology section has definition for other terms, but not for "Voucher Artifact”. draft-ietf-anima-rfc8366bis, which defines the term does not use any capitalization.

Fixed.

> - draft-kuehlewind-update-tag-04 has expired and archived. Do you want to continue referencing it?

Referring to that draft was just a ?feeble? attempt to find further evidence that
"extension" and "upgrade to" are the appropriate editorial word choices to describe
the situation. If i remember correctly, the draft also expired because Mirja could't
figure out how to get a sufficient agreement in the community about the vocabulary, so
thats why we're here - to make up the best wording as we go along ;-)

Aka: reference removed.

> Nit:
>
> Section 3.3
>
> - Am I missing a “\” in backslashes(“). Looks like the backslash got eaten by whatever was rendering the HTML. You might want to escape the backslash.
>
> - This sentence did not parse for me.
>
> "Note, a trust anchor SHOULD be provided differently to be trusted. This is consistent with Section 5.5.2 of [BRSKI].”
>
> Did you mean to say “SHOULD be provided separately, for it to be trusted”?

Fixed.

Thanks a lot for the review.
>
> Thanks
>
>
> Mahesh Jethanandani
> [e-mail]
>
>
>
>
>
>

--
---
[e-mail]