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

Chris Wendt <> Fri, 14 October 2016 02:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8E12A1295A9 for <>; Thu, 13 Oct 2016 19:29:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qzqymJwNnOsz for <>; Thu, 13 Oct 2016 19:29:40 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 601B81295AA for <>; Thu, 13 Oct 2016 19:29:40 -0700 (PDT)
Received: by with SMTP id m5so61965036qtb.3 for <>; Thu, 13 Oct 2016 19:29:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Un2+X5la8HnA/nUEM+DaZ3VYX887ENMu6+U1ygmbZUs=; b=v6HxpzgzS3xb2w5K3vaSQPq7y8Run2/KisBTjUZ5bK2kCdmLFC3IF9n5F3goFbIy3E 1oYZrkgm/jx+iSDBLBGJ7qfGVzKitVJW6vC7DCmLcOFrqf6isGkPdUIrHpcQhFRQl2DE 2vDe+nvy5FDtkKqugYfetZRquisuSFF1+Z4eIQeTEVqvKDRd1iCqiuxlzNWRs3wXUp0b 61UPehKIxBg6wIrAou8ivRHUhQZioOCwfYiCAiCcgvwoB27s+czd/kQhkeEbQE9l40xk y24qyqbsFQQoNBdP8kkzlF6aslwsf1H3zO1DpSF/OJSdixBv4EhDKSCPJCw9//fjM70G qB5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Un2+X5la8HnA/nUEM+DaZ3VYX887ENMu6+U1ygmbZUs=; b=RTlqusLq/dlHJbmCBzvvWzqCRkv0m1s8EaZWFSE95F/VnBCBgae631TM/IIcyyd69w ZMiLdJdPxadseoj+pA9TO2ngeaZh/piyE+4z8X7ba5+dmakKYu91Q1FJZXRCzxbL+vOG yPsnkq01E3630XzGhzz9EYrr15GliBLyb7PpUoCEWDvrW3J7WmYYzVOT8Jbv86uJ1tQB 9VcjVXdkBZV5uHcFP27JqubbmkiOb/p/rMMDKO/0vtW33QnGYgLin1lJ1p4r5QDAgaVp wGoyt0i2/tu7R6KbNVUO0rUrvh5TcZKNGL8I+3NESeQb6gwo+7+ycHvKZ20X3rXDlbH0 QALg==
X-Gm-Message-State: AA6/9RnarT21xF9y8WhXtJvP/D9XUCKE13WACUEkCarWzMrnXCakUxz8E/EpAPN5c8xIDQ==
X-Received: by with SMTP id r34mr10155353qtr.22.1476412179434; Thu, 13 Oct 2016 19:29:39 -0700 (PDT)
Received: from ?IPv6:2601:41:c101:9364:c85d:e32b:717d:d299? ([2601:41:c101:9364:c85d:e32b:717d:d299]) by with ESMTPSA id a26sm6438709qka.2.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Oct 2016 19:29:38 -0700 (PDT)
From: Chris Wendt <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E10BAE6E-A873-4A01-BCB0-41544921A6E6"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
Date: Thu, 13 Oct 2016 22:29:35 -0400
In-Reply-To: <0c3801d224f3$60030830$20091890$>
To: Jim Schaad <>
References: <065e01d2218f$fea323b0$fbe96b10$> <> <0c3801d224f3$60030830$20091890$>
X-Mailer: Apple Mail (2.3226)
Archived-At: <>
Subject: Re: [stir] draft-ietf-stir-passport-08
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 14 Oct 2016 02:29:43 -0000

Hi Jim,  Thanks for the clarifications.  Answers inline.

> On Oct 12, 2016, at 9:44 PM, Jim Schaad <> wrote:
>> -----Original Message-----
>> From: Chris Wendt []
>> Sent: Wednesday, October 12, 2016 12:31 PM
>> To: Jim Schaad <>
>> Cc:;
>> 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 <> 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
> As long as it is clear what is a key and what is a value for the purposes of JSON, I don't think it makes any difference.  My problem with the term was that it had both terms so yes "claim name" or "claim key" would seem to make sense.  However both the JSON document and JWT both seem to prefer "name" to "key".  I will note that JWT seems to prefer prefixing claim to both name and value. 

good, will also make sure this is consistent in the full document.

> .
>>> * 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.
> This is from the JSON document 7159 section 7 (Strings).  Thus it should be the default behavior for JSON serialization code.

Ok, so i will say "Any claim name or claim values outside the US-ASCII range should follow the default JSON serialization defined in [RFC7519] Section 7."

>>> * 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.
> I am more worried about the fact that when I read the document, I thought that 'orig' was associated with the entity making the claim - i.e. the service provider and not with the call originator than I am about the question of equivalence to the existing JWT claims.  

I will review the text and see if i can make that more clear, however i think we are stuck with a concept that is a bit unintuitive by default unfortunately.

>>> * 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
> I can understand some of your confusion and I got it partly wrong - I was looking at 4.2.2 not 4.2.1 when I wrote the text.
> 4.2.1 contains the text "The "orig" JSON object MUST only have one key value pair representing
>   the asserted identity of any type (currently either "tn" or "uri") of
>   the originator of the personal communications signaling." 
> The above is the only place that I can see that says that "orig" is a JSON object.  Separating this into two different sentences would make it clear that 1) it is and object and 2) the object can only have one name/value pair.

Got it thanks for the clarification

> In section 4.2.2 - I did not see any clear text before getting to the example about the array/object question for the "mky" name.   Looking at just the one example, I would not see that there is a distinction between having a single value and having multiple values as it is not clearly highlighted.  It might be good to break the first paragraph into multiple ones each dealing with different parts of the constructed item.  Simple language makes things easier to understand.

good, will clarify that

>>> * 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.
> I need to look; however, memory says that only the PASSporT compact form was allowed.  

No, we support both, but would be good to make that clear.

>>> * 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.
> That would be the base specification with the "iat" claim.  This is a NumericDate - that is an integer since.   Canonicalization is not a problem for JWT as the claim is transported so the form is fixed.

Right, for “iat” i think we are good.

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