Re: [stir] Genart last call review of draft-ietf-stir-passport-rcd-22

[[e-mail]]

Chris Wendt <[e-mail]> writes:
> Thank you very much for the very comprehensive review, comments inline:

Omitting most of the items, as I have nothing to add.  Prioritizing the
technical issue:

>> Section 6 tells that the "rcdi" datum is used to record hashes of the
>> components and subcomponents of the "rcd" datum.  Some questions arise
>> when a referenced datum is a string which has the format of a URI.
>> Section 6 requires that if the datum is a URI, then the hash is taken
>> of the resource retrieved using the URI, but if the datum is a string,
>> then the hash is taken of the Json representation of the string.
[omitting part]
>> Section 6 seems to assume that the hashing algorithm knows whether
>> such a datum is a URI or not, but Json does not mark URIs specially.
>> Is the hashing algorithm required to know a priori which keys have
>> values that are URIs?  Does this cause problems with extensibility of
>> the Passport?
>
> As far as I can see, at least for jcard specifically which is
> currently the only use-case defined that this is relevant, the use of
> URI is always prescriptively defined, so the a priori knowledge
> follows the specifications.  I don't believe the extensibility defined
> is inteded to be as flexible as you are interpreting it where strings
> vs URIs are interchangeable for different jcard fields.

My concern is if jcard is extended in the future.  As the specification
now reads, if I am correct, for every field of the jcard that might be
referenced by an rcdi item, the verifier has to have knowledge of
whether the field is to be treated as a string or a URI.  If we can be
assured that jcard won't be extended, that's not an issue, but in my
experience, things are always extended and protocols should be designed
to be robust against extensions that an endpoint is not aware of.

In the case of Passport, it seems the only thing the verifier has to
know about any field is one bit, whether it needs to be dereferenced
before the hash is taken.  And it seems that the syntax could be
modified slightly so that the "rcdi" items signal that explicitly.

>> And given that the "jcd" datum is a Jcard, any extension elements of a
>> Jcard must be similarly understood by the hashing algorithm.  Looking
>> at the example "Rendezvous for Little Nellie" in section 9.3, I see
>> that /jcd/1/3/2 is the string "uri", which I suspect is what flags
>> that /jcd/1/3/3 should be interpreted as a URI.  To what degree are
>> behaviors like this embedded in Jcard, and therefore must be
>> understood by the hashing algorithm?
>
> I'm having trouble finding an example with 1/3/2, but in general one
> URI reference should not influence how another JSON pointer hash
> should be interpreted.  By definition each JSON pointer in "rcdi"
> should have a hash build on only URI references.  

I was referring to part of one of the "rendezvous for Little Nellie"
examples:

 {
   "crn": "Rendezvous for Little Nellie",
   "orig": { "tn": "12025551000"},
   "dest": { "tn": ["12155551001"]},
   "iat": 1443208345,
   "rcd": {
     "jcd": ["vcard",
     [ ["version",{},"text","4.0"],
       ["fn",{},"text","Q Branch"],
       ["org",{},"text","MI6;Q Branch Spy Gadgets"],
       ["photo",{},"uri","https://example.com/photos/q-256x256.png"],
       ["logo",{},"uri","https://example.com/logos/mi6-256x256.jpg"],
       ["logo",{},"uri","https://example.com/logos/mi6-64x64.jpg"]
     ] ],
     "nam": "Q Branch Spy Gadgets"
   },
   "rcdi": {
     "/jcd/1/3/3": "sha256-RojgWwU6xUtI4q82+kHPyHm1JKbm7+663bMvzymhkl4",
     "/jcd/1/4/3": "sha256-jL4f47fF82LuwcrOrSyckA4SWrlElfARHkW6kYo1JdI",
     "/jcd/1/5/3": "sha256-GKNxxqlLRarbyBNh7hc/4lbZAdK6B0kMRf1AMRWPkSo"
   }
 }

The rcdi item "/jcd/1/3/3" refers to the datum
"https://example.com/photos/q-256x256.png" in the "photo" contentline.
Tracing back to the jcard definition (RFC 7095 section 3.5.2), the 3rd
item on that line, "uri", specifies that the 4th item on that line is a
URI.  That is, the 4th item on that line *need not be a URI*, that the
verifier can only tell that "/jcd/1/3/3" should be processed as a URI,
that is, dereferenced before hashing, by looking at "/jcd/1/3/2".  This
is a coupling between the verifier and the details of the jcard data
structure that it seems should be avoid ed.

Taking these together, it seems to me that a lot of trouble will be
avoided by marking rcdi items explicitly whether dereferencing should be
done.

>> From my point of view, it would be helpful to provide an example
>> showing all the moving parts, e.g. how a SIP INVITE message is
>> assembled using this mechanism [...]

> [...]  I think the second part of your
> comment is really covered fully by RFC8224 specific to SIP call flow
> and how PASSporTs are inserted into identity header fields, etc., so
> we didn't want to repeat all of that in this document. [...]

I probably overstated what I'm looking for.  Clearly, if one reads RFCs
8224, 8225, and 8226, then the reader will have the framework for
understanding this document.  But it seems to me that providing a clear
example of a SIP INVITE that contains this mechanism, with an
enumeration of its features (and which RFCs define them) would allow a
reader to digest the essentials of this mechanism without first having
to read RFCs 8224, 8225, and 8226.  Indeed, I've discovered that even
when I already know the prerequisites for an RFC, a clearly presented
example makes it a lot easier to absorb the details as I read them.  It
seems to me that an example and a brief description of its points should
only take 1/2 to 1 page and would be very valuable for non-expert
readers.

>> - Use only one term for each concept.  A particularly confusing
>>  example are these, which seem to me to be intended to have the same
>>  meaning, but are all different, and only one has a non-trivial word
>>  to describe the relationship between "ppt" and "rcd":
>> 
>>    a "ppt" value of "rcd"
>>    a "ppt" for "rcd"
>>    a "ppt" of "rcd"
>>    "ppt" does contain an "rcd"
>> 
>>  A "Terminology" section helps ensure that there is a set term for
>>  each concept.
>
> Yes, agree i was using that shortcut a lot, i cleaned up avoiding
> using "ppt" as the equivalent of "PASSporT extension"

I don't expect you to make further changes for this, but I do want to
clarify my point:  I didn't find e.g. 'a "ppt" value of "rcd"' to be
unclear.  Indeed, as a naive reader, that would be clearer than referring
to "Passport extension" as it is referring to a concrete thing in the
protocol.

What I was complaining about was that the same condition was described
with several different sets of words in different places.  That requires
the reader to digest well the meaning of each passage before realizing
that they all mean the same thing.  Much better is to use exactly the
same words to describe the condition in every situation so that the
reader knows that they all mean the same thing, even if the reader
hasn't fully grasped what the meaning *is*.  Indeed, the reader can
often learn a considerable amount about an item by cross-correlating
several mentions it.

>> Datatracker says it expired on 2022-09-08:
>> 
>>   [I-D.ietf-sipcore-callinfo-rcd]
>>              Wendt, C. and J. Peterson, "SIP Call-Info Parameters for
>>              Rich Call Data", Work in Progress, Internet-Draft, draft-
>>              ietf-sipcore-callinfo-rcd-04, 7 March 2022,
>>              <https://www.ietf.org/archive/id/draft-ietf-sipcore-
>>              callinfo-rcd-04.txt>.
>
> Yes, we were trying to update and work on both documents in parallel,
> but it became clear that until this document settled it wasn't
> useful/efficient to keep modifying both.  I will be updating the
> sipcore document very shortly to correspond with the state of
> passport-rcd document, so we can finish the work on that document in
> sipcore.

You don't have to *change* the document to refresh its validity date,
just update the version number and update exactly the same text.  If
you're detail-oriented add a sentence at the beginning stating it is
identical to the previous version.  Refreshing the document records that
it is still being actively considered.

Dale