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

[Jim Schaad <[e-mail]>]

Looks good to me

> -----Original Message-----
> From: Chris Wendt [mailto:[e-mail]]
> Sent: Monday, October 31, 2016 5:22 AM
> To: Jim Schaad <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: draft-ietf-stir-passport
> 
> Hi Jim,
> 
> Inline.
> 
> > On Oct 23, 2016, at 6:29 PM, Jim Schaad <[e-mail]> wrote:
> >
> > I have started looking at implementation of this and I have two
> > suggestions for changes to the document which I think will make the
> > code easier to implement.  I think that, with one exception, this will
> > generate exactly the same output for all of the current cases.
> >
> > Change #1 in section 5.2.2
> >
> > I suggest that the text be modified to say that the algorithm is:
> >
> > 1. Take the a=fingerprint lines from the SIP header.
> > 2. Sort the lines based on the UTF8 encoding of the strings 3. Encode
> > the array in the order of the sorted lines.
> > 	- Each element in the array is a map
> > 	- Each map contains two elements constructed as follows ....
> >
> > I think that this will be the same as the current sorting order.
> 
> Agree could be a little clearer.
> 
> I did variation on a theme:
> 
> >>
>    The "mky" claim is a JSON object with a claim name of "mky" and a
>    claim value of a JSON array denoted by brackets.  The "mky" claim
>    value JSON array MUST be constructed as follows:
> 
>    1.  Take each "a=fingerprint" lines carried in the SDP.
> 
>    2.  Sort the lines based on the UTF8 encoding of the concatenation of
>        the "alg" and "dig" claim value strings.
> 
>    3.  Encode the array in the order of the sorted lines, where each
>        "mky" array element is a JSON object with two elements
>        corresponding to the "alg" and "dig" objects, with "alg" first
>        and "dig" second.
> >>
> 
> >
> >
> > Change #2 in section 9
> >
> > The current text in JWK-Thumbprint does not cover the cases that you
need.
> >
> > The JSON object MUST following the following rules.  These rules are
> > based on the thumbprint of a JSON Web Key (JWK) as defined in Section
> > 3 of [RFC7638].  They cover some additional cases that [RFC7638] did
> > not need to document.
> >
> > 1. The JSON object contains no whitespace or line breaks before or
> > after any syntactic elements.
> > 2. Map objects have the keys ordered lexicographically by the Unicode
> > [UNICODE] code points of the member names.  If two member names are
> > equal, then the JSON serialization fails.
> > 3. JSON value literals are lowercase
> > 4. JSON numbers are to be encoded as integers unless the field is
> > defined to be encoded otherwise.
> > 5. Encoding rules are applied recursively to member values and array
values.
> >
> > The rule on two key names is new, but is implicit as JWKs are not
> > supposed to have two keys of the same name.  Having a generic rule on
> > maps means that one will not have a miss someplace if a new element is
> defined.
> 
> New Text:
> >>
> The JSON object MUST follow the following rules.  These rules are based on
the
> thumbprint of a JSON Web Key (JWK) as defined in Section 3 Step 1 of
> {{RFC7638}}.
> 
> 1. The JSON object MUST contain no whitespace or line breaks before or
after
> any syntactic elements.
> 2. JSON objects MUST have the keys ordered lexicographically by the
Unicode
> {{UNICODE}} code points of the member names.
> 3. JSON value literals MUST be lowercase.
> 4. JSON numbers are to be encoded as integers unless the field is defined
to be
> encoded otherwise.
> 5. Encoding rules MUST be applied recursively to member values and array
> values.
> 
> Note: For any PASSporT extension claims, member names within the scope of
a
> JSON object MUST NOT be equal to other member names, otherwise
> serialization will not be deterministic.
> >>
> 
> >
> > Jim
> >
> >
> >