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

[Christer Holmberg <[e-mail]>]

Hi,

>>I agree with Ekr, and being able to use something pre-existing is the
>> reason I asked the passport authors to consider JWT. If you think there
>> is something better pre-existing, please say so, but if you want to do
>> something from scratch I think we¹d need some really good justification
>> for that. I don¹t agree with your earlier statements that JWT is
>> complex, and there are tons of tools to test and verify JWTs.
>
>
>Christer,
>
>Just to be thorough, I'll repeat that I agree with the goal of using
>existing solutions, where they represent a high-enough point of
>departure (if they aren't a perfect match), preferably with enough track
>record to establish efficacy.
>
>And I'll repeat that my view of the passport draft did not criticize the
>use of JWT.  (By the way, is it only JWT or is it actually JOSE, and if
>it isn't why not?)

It¹s actually JWS (JOSE is the name of the generic framework). It¹s
probably
something we should fix too.


>It's not that I didn't question the use, it's that I didn't indulge in
>that questioning at that point.  This came later, as I watched the
>documentation efforts to integrate use of JWT.
>
>
> > In Berlin I did raise an issue on how STIR uses JWT in SIP (the encoded
> > object is ³split up², and different pieces are placed in different SIP
> > elements), but Jon promised to make sure it¹s clarified and well
> > explained in the next version of the bis draft, so I think we should
> > give him a chance to do that.
>
>There are at least two major problems here.
>
>The technical one is that the current approach requires doing encoding
>and packaging twice, from what I can tell.  Once in a JSON context and
>the second in a SIP header context.  By itself, that should be worrying.
>That the latter hasn't been fully documented and agreed to, yet, raises
>a question about how anyone thought the documents were ready for last
>call.

The latter is the exact issue I raised, and it must be well documented
(together with examples) how it¹s done.

However, once you done the JSON encoding, I don¹t think you need to do
further ³encoding² (no need to escape characters etc). The idea (afaik) is
to split the encoded string into different pieces, and place those in
different SIP header field/parameters. But, HOW that split is done, and
how the string is re-generated on the receiving side, must be clarified.

 
>The other major problem is that the introduction of JSON/JWT has
>produced levels of indirection in the documentation that made it
>essentially impossible for me to understand and analyze the
>specification details.  And I tried pretty hard.  So this does not bode
>well for other new readers of the specifications.  (More generally, the
>documents make cross-references and indulge in cross-dependencies that
>defeat the benefits of modularity and create really serious reading
>complexity.)

Assuming PASSPorT is supposed to be something generic, I think we should
avoid normative references to the draft-bis from PASSPorT.

(draft-bis draft obviously have to normatively reference PASSPorT.)

As I have zero knowledge of DKIM, I¹ll let others discuss its¹
applicability to STIR, and whether it¹s better/worse than what we
currently have. But, in general, I don¹t think WGLC is too late for a
beauty contest. 

Regards,

Christer




>And now, yes, I'll indulge in the dreaded "DKIM" reference...
>
>DKIM is another existing mechanism that provides exactly the needed
>functionality, with more than 10 years of field experience (counting the
>predecessor Yahoo's Domainkeys) and a relatively simple design.
>
>As I've noted before, the list of 'topics' for the STIR work is not
>long.  I'll do an abbreviated listing here:
>
>    1. Calling value acquisition -- getting the string to validate
>
>    2. Key management --getting the key and validating that it is
>       authorized for use with the calling value.
>
>    3. A bunch of crypto-related computation -- including
>       canonicalization of the data of course
>
>    4. Packaging the result -- for use by the validation mechanism.
>
>Step 1 is not part of the crypto work, but it is of course fundamental,
>as well as being specific to STIR.  The crypto subsystem just uses it as
>input. The choice of JSON/JWT, DKIM, or whatever is irrelevant to this
>step.
>
>Step 2:
>
>   a)  For non-telephone URIs, DKIM's DNS model can be used directly.
>
>   b)  I'm unclear about the role of the domain name in the URIs that
>have a phone number in the left-hand side.  In any event, as I've noted
>repeatedly, number-based key management is an open issue, with
>demonstrated high risk, given that the previous effort failed.
>
>Step 3 can use DKIM almost directly.
>
>Step 4 can use DKIM almost directly.
>
>
>So the DKIM approach is dramatically simpler and offers by far the
>highest point of departure for STIR.
>
>In particular, the hard parts of doing STIR aren't solved by this choice
>-- JSON/JWT don't help either.
>
>d/
>-- 
>
>   Dave Crocker
>   Brandenburg InternetWorking
>   bbiw.net