[art] Artart last call review of draft-ietf-stir-passport-rcd-21

[Harald Alvestrand via Datatracker <[e-mail]>]

Reviewer: Harald Alvestrand
Review result: Ready with Issues

This document is clearly a product of a fairly mature standards process, but as
always happens with fresh eyes, there are a number of points to call out.

I'll try to not revisit items unlikely to change, such as the excessive use of
3-letter tags (I suppose for shorter headers, despite the fact that compression
would make that irrelevant) and the use of the term "rich", which by this time
is as meaningless as that other IETF cozy-word "simple".

With that off my chest - commentary about details and nits follow. This
document is, to my mind, close to being "ready" - but fixing the issues would,
I think, make it better.

By section:
Section 4 mode 3-4 uses the term “forward control”, which is a confusing term.
The term seems to indicate that “the entity that signs the RCD object can
include within the JWT object a statement about what the signer of the PASSporT
object can claim to include”. This mechanism (and the need for it) is still
obscure to me after reading the spec. See also comments on section 7.

Section 5.1 talks about fields being “derived from” things like display-name
component of From header field value of SIP. This seems like an improper
constraint on how applications are built. More likely usage is that the
passport object is signed first, and the display-name is set from the same data
source; instead of saying “derived from”, a spec should say “the same as” -
what comes first and last is not a concern for the spec.

Section 6 - spec says MUST SHA512, MUST NOT SHA-1. Given that this is a
document format, is this the right place for that kind of statement? If specs
that use it already specify something about hash functions, they are unlikely
to change their usages just because this document says so. What will not be
obeyed should not be stated.

Section 6 says that it uses “JSON pointer with a minor additional rule”, is it
clear what the additional rule is? If it’s only the 6.1.4 “jump the indirect”,
that might be worth calling out.

Section 7, The JWT Claim Constraints section, talks about “constrain the
signer”. That’s an odd form if this is a document format description. RFC 8226
seems to say that it is part of the format for requesting a signature (the
unsigned or self-signed version of the cert), and is part of the cert only to
verify what the signer was asked to sign.

Section 9.1 talks about “the certificate used to sign the PASSporT”. This
terminology seems suspect. RFC 7515 section 5.1 is the “compute the signature”
step. It doesn’t talk about a certificate used as input. 12.1 also contains
this odd construct. Does it mean "the certificate containing the public key
associated with the private key used to sign the PASSporT"? If so, it should
say that this is what it means. (An alternative would be "the PKCS#11 object
that contains both the public and private keys" - but that would seem like a
*really* odd construct.)

Section 9.3 examples - it would be good to say which elements are protected by
what for each case - for instance, example 2 will have the protection for th
PASSPorT object of the icn URL, but has no protection for the content of the
image - it’s not verifiable - while examples 3 and 4 have protected the content
of the external references using “rcdi”.

The note in section 10.1 about reconstructing “nam” from the display-name
string means that use of this format with the SIP protocol requires them to be
identical, which seems to be a common assumption (see comment on 5.1).

Section 13 introduced “first” and “third” parties without defining them.
Presumably the "first" party is the signer of the PASSPorT, while the "third"
party is the signer of the RCD - making this explicit would be good.

14.2 says that one has to extract From and use it to check the rcd (which
constrains it to be the same, no?) - while the next para talks about pulling
the nam out and displaying it instead of the name in From. This is odd, given
that they are identical.

14.2 at first seems to constrain what a relying entity shold do, but the
section ends with a statement equivalent to “but do what you want” ("It's going
to be determined by policy"), so what’s the point of the section?

All that said - this specification seems to be clear for its purpose. It could
just be somewhat better.