[Anima] Re: Review comments on draft-ietf-anima-jws-voucher-09

Toerless Eckert <tte@cs.fau.de> Thu, 13 June 2024 15:06 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DE52CC15199D; Thu, 13 Jun 2024 08:06:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.656
X-Spam-Status: No, score=-1.656 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id g4GgOW2RjlEQ; Thu, 13 Jun 2024 08:06:02 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 086DAC14F61E; Thu, 13 Jun 2024 08:05:56 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de []) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 4W0Qhb5vBCznkNb; Thu, 13 Jun 2024 17:05:51 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 4W0Qhb4z7Tzknx3; Thu, 13 Jun 2024 17:05:51 +0200 (CEST)
Date: Thu, 13 Jun 2024 17:05:51 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Mahesh Jethanandani <mjethanandani@gmail.com>
Message-ID: <ZmsKz214EgePVkl7@faui48e.informatik.uni-erlangen.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1206E48C-0A05-47E7-8832-F43DF9EF18CC@gmail.com>
X-MailFrom: eckert@i4.informatik.uni-erlangen.de
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-anima.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-anima-jws-voucher@ietf.org, Robert Wilton <rwilton@cisco.com>, anima@ietf.org
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Anima] Re: Review comments on draft-ietf-anima-jws-voucher-09
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/LqrX2iImZR_k_upzgQZaZltJXdQ>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Owner: <mailto:anima-owner@ietf.org>
List-Post: <mailto:anima@ietf.org>
List-Subscribe: <mailto:anima-join@ietf.org>
List-Unsubscribe: <mailto:anima-leave@ietf.org>

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


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.


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.


> 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. 


> - 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”?


Thanks a lot for the review.
> Thanks
> Mahesh Jethanandani
> mjethanandani@gmail.com