[stir] JWT/JSON (was - Re: Review of: draft-ietf-stir-passport-05)

[Dave Crocker <[e-mail]>]

On 7/29/2016 2:11 PM, Dave Crocker wrote:
> On 7/29/2016 10:46 AM, Peterson, Jon wrote:
>> I wouldn't say it's a correction to the STIR charter - the charter was
>> always clear that it was not limited to SIP (see the bits about "one or
>> more non-SIP hops" and "out-of-band mechanism" in the charter). But given
>> that our original signing mechanism was, as I said, a concatenation of
>> SIP
>> header field values, the intervention was that other protocols would need
>> something less bound to SIP. JWT turned out to be the solution that the
>> group had consensus to adopt.
>
> JWT has nothing to do with SIP.  So when applied to a SIP context, it's
> entirely artificial.  And yes, I noted the views that thought it simpler
> or equivalent to the computed string, but could not see the explicit
> logic that made JWT a better choice, no does it seem obvious to me.
> Quite the contrary.
>
> Note that during the wg session in Berlin there was /still/ question
> about where to put the JWT information.


Folks,

I'm citing the above text, for discussing the concern I rasied about 
JWT/JSON use in Passport, because that was the first time I criticized 
it, which was several rounds of postings after I sent my review.  That 
is, it was /not/ part of my review.  I made a conscious choice to leave 
that concern out, although I already saw it as likely problematic.

On its face, yes it looks like a reasonable choice.  It's pre-existing 
technology and it looks clean.  The concerns develop in its application, 
not its concept.

Look for JSON and JWT in SIP.  You won't find it.  That means that it is 
an added layer of specification.  Or, in this case, specifications.  And 
since JSON and JWT are their own environments, that means there is a 
learning curve and other baggage to carry, before it is useful to SIP 
and STIR.

Even better is that even the STIR specification for SIP does not require 
using JWT or JSON.  Note that ppt is optional.  This adds to the view 
that, at best, JWT/JSON is really just an abstraction for STIR.

But in fact the fact that ppt is optional really means that the SIP STIR 
specification has added complexity, with very unclear benefit.

As for the underlying justification for the Passport model, references 
to broader applicability are always appealing, but lacking concrete 
specifications and clear, documented intentions of use -- including a 
clear explanation of the benefit to be gained by the abstraction -- they 
turn out mostly to be a distraction from the immediate concern, namely 
added complexity to the mainstream use.

Again: JSON/JWT adds a layer (or two) of mechanism that almost certainly 
is not needed and almost certainly adds problematic complexity to the 
specification, probably to the point of impeding reader comprehension.

As I've noted, the underlying task here is pretty straightforward:

    *  Define a mechanism for finding and validating a public key.

    *  Decide on scope and canonicalization of data to be signed. Define
       a signing mechanism.

    *  Define a validation mechanism.

    *  Decide how to deal with partial adoption

    *  Decide how to deal with broken signatures.


Maybe a little more than this, but not much.


d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net