Re: [stir] A few comments on the PASSporT Document

[Russ Housley <[e-mail]>]

Jon:

> Thanks for these notes Russ.
> 
>> I needed to chase a bunch of references to figure out what really goes in
>> the iat claim.  This leads me to two comments.
>> 
>> (1)  Let¹s help the reader and tell them that the iat claim contains a
>> JSON numeric value representing the number of seconds from 1970-01-01
>> 00:00:00 UTC.
> 
> Sounds good to me. That claim is defined in baseline JWS/JWT, but agreed
> it would be helpful to informationally reiterate its syntax in the
> PASSporT spec.

Thanks.

>> (2) The iat claim carries the time that the token was issued.  Section 7
>> tells that the token should be handled in a "reasonable for clock drift
>> and transmission time.²  This makes sense, but neither Section 3.2.1.1
>> nor Section 7 tells what ought to happen if it is determined to be stale.
> 
> This is where the hand-off between RFC4474bis and PASSporT can be murky.
> The behavior for SIP as a using protocol of PASSporT with regards to the
> freshness of Date/iat is given in RFC4474bis. Other using protocols might
> want to use other means to ascertain freshness; SIP behavior really comes
> down to comparing iat with the Date header, and we don't want that
> using-protocol-specific language to be in PASSporT.
> 
> I can also imagine PASSporT tokens being evaluated historically, rather
> than in real time, and the determination of "freshness" for those purposes
> might be different, or even just irrelevant.
> 
> What we can say about iat in PASSporT though is that using protocols are
> required to specify how they determine freshness (like, what they compare
> it to). Would that make sense as a way to approach this?

Yes, that makes sense to me.

>> The syntax of the mky claim seems to go against a JOSE design principle.
>> JOSE used very compact representations for everything.  However, the mky
>> claim uses a whole lot of colons.  This leads to a third comment.
>> 
>> (3) To align with the JOSE principle, should the mky claim syntax use a
>> hex string or a base64 string to carry the hash values.
> 
> Jonathan Lennox provided some compelling reasons for us to move mky to a
> JSON array format, similar to what WebRTC has done (so it's clear which
> keys can match to which m= lines in SDP, say). That at least was my
> take-away from the discussions around this in Buenos Aires. Would that be
> satisfactory for you?

I think so.

Russ