Thank you for the comments/questions!

Julian Krieger <[email protected]> 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 <[email protected]> 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 <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

Attachment: signature.asc
Description: PGP signature

_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to