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

From: Jim Schaad <[email-masked]>
Date: Sun, 23 Oct 2016 15:29:24 -0700

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.

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.

Jim

---

From: Chris Wendt <[email-masked]>
Date: Mon, 31 Oct 2016 08:21:59 -0400

Hi Jim,

Inline.

> On Oct 23, 2016, at 6:29 PM, Jim Schaad <[email-masked]> wrote:
> 

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.

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.

---

From: Jim Schaad <[email-masked]>
Date: Mon, 31 Oct 2016 09:22:27 -0700

Looks good to me

> -----Original Message-----
> From: Chris Wendt [mailto:[email-masked]]
> Sent: Monday, October 31, 2016 5:22 AM
> To: Jim Schaad <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-ietf-stir-passport
> 
> Hi Jim,
> 
> Inline.
> 
> > 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.
> >
> > 2. Sort the lines based on the UTF8 encoding of the strings 3. Encode
> > the array in the order of the sorted lines.
> > 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.
> > [UNICODE] code points of the member names.  If two member names are
> > equal, then the JSON serialization fails.
> > 4. JSON numbers are to be encoded as integers unless the field is
> > defined to be encoded otherwise.
> > 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.
> 4. JSON numbers are to be encoded as integers unless the field is defined
to be
> encoded otherwise.
> 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
> >
> >
> >