Re: [stir] draft-ietf-stir-passport-08

[Jim Schaad <[e-mail]>]

I went back to re-read the document and figure out where my confusion was on the issue of who the 'orig' and 'dest' referred to.  This is what I find.

 

Origination in the context of PASSporT and for a given application's use of PASSporT is the point in the network that has the authority to assert the caller identity.

 

The text then goes on to talk about certificates, which I made the assumption referred to the same certificate as appears in the JWT header under the ‘x5u’ name.

 

I think from this is it not unreasonable that I made the assumption that the ‘orig’ field referred not the caller originator but to the issuer of the PASSporT.

 

jim

 

> -----Original Message-----

> From: Chris Wendt [mailto:[e-mail]]

> Sent: Wednesday, October 12, 2016 12:31 PM

> To: Jim Schaad <[e-mail]>

> Cc: [e-mail]; [e-mail]

> Subject: Re: draft-ietf-stir-passport-08

> 

> HI Jim,

> 

> Thanks for the comprehensive review.  I am working through some of the fixes

> based on your comments.

> Meanwhile i have the following responses inline.

> 

> -Chris

> 

> 

> > On Oct 8, 2016, at 2:15 PM, Jim Schaad < <mailto:[e-mail]> [e-mail]> wrote:

> >

> > Here is a review of the document as a whole.

> >

> > * Section 4 - para 3 - The term "key values" is potentially ambiguous.

> > This could refer either to the value of the key or the value the key

> > is pointing to.  I would suggest making this clear.

> 

> I will use the term  “claim value” which is a RFC 7519 term.  One additional

> question is whether we say same thing for “claim name” as well?  I suppose we

> allow it.

> 

> >

> > * Section 4 - para 3 - The form you are using for encoding of claims

> > values has two problems.  The first is that this does not match what

> > the JSON document says to use "\uXXXX".  The second is that as

> > written, it is ambiguous.  If I have the US-ASCII string of "%ABCD"

> > then it does not need to be percent encoded as the string is not outside of the

> US-ASCII range.

> 

> Could you provide a pointer to the use of “\uXXX" specifically, we had a working

> group discussion on this text, but if there is something existing, i haven’t been

> able to find it.

> 

> >

> >  * Section 4.2.1 - General - I am having a hard time with this section

> > because it is not highlighting the last piece of information that I

> > think I need to understand for this.  From what I read, I think that

> > dest == aud in terms of JWT - that is the target of the statement.

> > Orig == iss in terms of JWT - that is the entity that issued the

> > statement.  I don't see anything that is telling me what the sub of the JWT is

> supposed to be.

> >

> > It would also be good to say why different items are being defined

> > that appear to be the same thing as already exist in JWT terms. (Yes,

> > at the core it is because the types are different.)

> 

> I don’t believe the mapping of aud and iss are appropriate here.  The “orig” and

> “dest” claim is specifically the asserted identity, telephone number of caller and

> callee, but may not correspond to the issuer/signer of the JWT, e.g. service

> provider.

> 

> I can explain this in the text if that is helpful.

> 

> >

> > * Section 4.2.X - you are not telling me that these are arrays of

> > "some type" rather than the "some type”.

> 

> sorry, i’m having trouble figuring out what you mean by this

> 

> >

> > * Section 4.2.2 - You are stating that things must occur in a specific

> > order.  This is not "normal" JSON behavior and not all JSON

> > serializers may be able to support this behavior.  I think you need

> > some justification someplace.

> 

> I plan to move this to the compact form section, since ordering is only really

> needed for compact form now.

> 

> >

> > * Section 5 - I am having a hard time finding the lexicographic order

> > and white space rules quickly.  A pointer might be reasonable.

> 

> same answer as above.

> 

> >

> > * Section 7 - One issue that I think you need to address in the

> > extension section is that signaling protocols need to identify what

> > these new items are so that they can be picked up and placed into the

> > PASSporT when it is reconstructed.  The destination does not have to

> > understand the extension, but it does need to understand that the extension

> exists.

> 

> This will be defined in the “using protocol” specification, however i can make

> that clearer

> 

> >

> > * Section 8 - You have a problem in that there are no rules in RFC

> > 7638 for dealing with serialization of integers.  Given that some of

> > the fields in the JWT are integers this needs to be addressed.  You

> > might want to move this justification to the top of the document so

> > that people are prepared for and look for this.

> 

> wondering if the best way to solve this is to note it and make sure that for any

> passport extensions that use compact form, they specify the handling integers.

> 

> >

> > * Section 8 - Wording problem with saying that "dest" and "mky" need

> > to follow their OWN rules.  Are these really defined elsewhere or do

> > you just use the standard rules recursively.

> 

> will try to clarify

> 

> >

> > * Section 9.2 - Consider using a list structure for the asterisk

> > leading list in this section.

> 

> Yep, this was just a missed formatting problem

> 

> >

> > * Section 10.1.1 - Encoding Considerations - This could be 7 bit as

> > the value is base64 encoded for normal values and would be UTF8 if you

> > used the full JOSE signature structure which you do not.

> 

> Ok, will look at changing this.

> 

> >

> > * General - I was really tired when I read through this and I kept

> > getting tripped up on prose.  I did not write down all of the items

> > which bothered me and now I have read it enough that it is harder for me to

> locate them.

> > However, I would request that the authors perform some method of

> > detailed reading to check for this.  I frequently read the text aloud

> > to myself for this purpose.  Alternatively, you can just wait for the copy

> editors.

> >

> > Jim

> >

> >

> >