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

[Chris Wendt <[e-mail]>]

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
> 
> 
>