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 <[email protected]>
Datum: Donnerstag, 13. Juni 2024 um 17:06
An: Mahesh Jethanandani <[email protected]>
Cc: [email protected]
<[email protected]>, Robert Wilton <[email protected]>,
[email protected] <[email protected]>
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
> [email protected]
>
>
>
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
