[Anima] Re: Mail regarding draft-ietf-anima-rfc8366bis - Questions regarding Voucher Request

Michael Richardson <mcr+ietf@sandelman.ca> Sat, 01 June 2024 18:13 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B87C14F615 for <anima@ietfa.amsl.com>; Sat, 1 Jun 2024 11:13:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sandelman.ca
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQE-puFHQ_9G for <anima@ietfa.amsl.com>; Sat, 1 Jun 2024 11:13:17 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 371C8C14F5E9 for <anima@ietf.org>; Sat, 1 Jun 2024 11:13:16 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 84ABF3898F; Sat, 1 Jun 2024 14:13:15 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id a3aFNQsg8stQ; Sat, 1 Jun 2024 14:13:14 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id C72F93898C; Sat, 1 Jun 2024 14:13:14 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sandelman.ca; s=mail; t=1717265594; bh=u9Uhya5PRbIo5qM3U5KnSlZw3oeWhgLOEcE+J/Y6DYw=; h=From:To:Subject:In-Reply-To:References:Date:From; b=Xt935OyHG/il93rY/gC1kkZZka3cB4xWRG5PhSSrHK0PJLOALb7eX3xp7wdQ5QmL3 neU0mIUI2awCtbkNg6YJz2SI58AxMVsdW7oQTRvL3yUPTd6LrlWmGvMEx83H+QIMCe I0WTVKXvgjqCWWUVqHAkk+DtKVo9MGkJt0GioVySOh/IjLW2+grZsMvcC6WtTlk/u7 PDcSFUSe1h0pk6p6ITI8C8id8GvKarT2yYbkQGZLOhpCQgjqcGHBHg9bCFC6P6qXFE jskNDkBPtbbS1wm+mvlU2mFRCib0ClkLV5sLte2fXh0AJ8eFWSUfnsKsqqY6qk/9pC YKEyMN6DWgzog==
Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id A5EAD236; Sat, 1 Jun 2024 14:13:14 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Julian Krieger <julian.krieger@me.com>, anima@ietf.org
In-Reply-To: <7F98270B-5CE7-47AD-8B0A-D6E90C505873@me.com>
References: <7F98270B-5CE7-47AD-8B0A-D6E90C505873@me.com>
X-Mailer: MH-E 8.6+git; nmh 1.8+dev; GNU Emacs 28.2
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0;<'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Date: Sat, 01 Jun 2024 14:13:14 -0400
Message-ID: <10654.1717265594@obiwan.sandelman.ca>
Message-ID-Hash: SRLYFPFZK6MWURLRWL7LUKBFBWLBVXAT
X-Message-ID-Hash: SRLYFPFZK6MWURLRWL7LUKBFBWLBVXAT
X-MailFrom: mcr+ietf@sandelman.ca
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
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Anima] Re: Mail regarding draft-ietf-anima-rfc8366bis - Questions regarding Voucher Request
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/DK1I3vK-BSfJc6FVLcFsgju1ask>
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>

Thank you for the comments/questions!

Julian Krieger <julian.krieger@me.com> wrote:
    > I have read the most recent version of the specification document and
    > I’ve come up with two questions based on the current documentation.

okay.

    > The Voucher Request Artifact extends and augments the Voucher
    > Request. Does it also extend the verification that stakeholders - for
    > example, the pledge - need to consider? Here, if the expires-on field
    > is set, the verification of said field should fall upon the receiving
    > party (this of course only makes sense to think about if there is a
    > reason within the protocol to set said field in a Voucher Request
    > Artifact).

The Voucher Request artifact is created by the pledge, so the pledge does not
verify the request.   Would it make sense for a pledge's voucher request to
include an expired-on header?  I don't know offhand.  I'd say no.

    > Is the “expires-on” field necessary at all in a VRA? All usages of a
    > Voucher Request I could find in related documents seem to use a nonce.

It's used in vouchers that should expire.  Most vouchers should expire, with
the registrar getting new vouchers if it needs to.  This is less typically
used in a BRSKI flow, but SZTP needs it.

    > If there exists a valid scenario for “expires-on” to be set in a PVR or
    > RVR, maybe there could be a short sentence on verification of that
    > field in the document?

    > Next, I’ve been wondering whether it would make sense for the MASA to
    > consider verifying the idevid-issuer field if used in the Voucher
    > Request Artifact, as in making sure that the idevid-issuer field
    > matches its own KID.

if idevid-issuer was present in the voucher request, then the MASA could
check it, yes.  But, it would not be terribly useful to include it.

Julian Krieger <julian.krieger@me.com> wrote:
    > There’s one more question - In draft-ietf-anima-rfc8366bis-11, Section
    > 11.3 the Media type “voucher-cms+json” is registered with
    > IANA. However, Section 2 mentions other signature types like JWS in the
    > “Voucher” description. Should the draft then not also mention the
    > “application/voucher-jws+json” media type registered in
    > draft-ietf-anima-jws-voucher-09?

No, because ietf-anima-jws-voucher is responsible for that media type.

--
Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide