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

Chris Wendt <> Wed, 12 October 2016 19:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8FDA712965D for <>; Wed, 12 Oct 2016 12:31:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 3BtDPxpVJFPi for <>; Wed, 12 Oct 2016 12:31:30 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6B311129657 for <>; Wed, 12 Oct 2016 12:31:30 -0700 (PDT)
Received: by with SMTP id f6so27103581qtd.2 for <>; Wed, 12 Oct 2016 12:31:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mEZq4jVR8BzT56Aw6eY/OjzKRTyvBWtkAMwjj5hX4T4=; b=uJwjIgzGHxv2okUegoJt4wZKXdJ6bk0i9iNIRplYt1hZvKdyhSxziNVfF5fwOdnx5q UDUfDmYxNBeGyQ/TmlOtG/zUeur48PvrS2JuuJrQOKBP6c2Y5vzASN7gTqTgjH1o6NA2 OdPA+MKxrmuXdmsSCa2jW9kWOJRrle3ZuFxrSG4zRe/UKvzIOfAWAYKzXc98egVfqlZd nKPReGqRq3T+GaS2kO3JyjvWwxLilnVi4ZUtG56DGt6BPVdHI4lTYoW9GBQ2UGCeU/9Q 9H3oOpzPIY392W/ppQDFhQ3wMXLRXAd+SH3o2qbNKliSZKkKOXG3m8OxpShKl3fY+Dy5 0S+Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mEZq4jVR8BzT56Aw6eY/OjzKRTyvBWtkAMwjj5hX4T4=; b=A6FNwnbOxMwRLczc0aMNWRpMCRPqfLHKzIvSIZg7rzDdxbpP+Y8D41IUzGe3tjqmWE 8yTTmwOYc8veLosY1WjIE/QQ5rDoVfMINBvIDEDZUngMRbAC5Ny73kop7MvT3BJgtgnc dJGvoDpfPpmpCHVQQ81clU663Kr7EznkO5akPchMI4JQ9tUNCS8phL1ZcCaJ9LIszc8W xRnnD9MzU9B3jPDdYN6wG+kRgysv3AWsNNHSI1Ll89963zzySJhJNuIi6GfCWhC3uWo0 /Y4ASDKQ2UGoy1DFBffHAI+fTRh71fihCPsKZe6VWvbG58wX1v1JrNqGo8F/2HQRcv1C E7Hg==
X-Gm-Message-State: AA6/9Rk9nS/WKDZpuRHSaY8fHKrzu36m9JyDWgWo8d5tdaZmZzm9xYeq6JjfPq7aWnq+Ng==
X-Received: by with SMTP id a23mr3010651qtb.79.1476300689531; Wed, 12 Oct 2016 12:31:29 -0700 (PDT)
Received: from ?IPv6:2601:a40:100:d3:34fe:c9ba:a1aa:6ddf? ([2601:a40:100:d3:34fe:c9ba:a1aa:6ddf]) by with ESMTPSA id 65sm2179795qth.0.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 12 Oct 2016 12:31:29 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.0 \(3226\))
From: Chris Wendt <>
In-Reply-To: <065e01d2218f$fea323b0$fbe96b10$>
Date: Wed, 12 Oct 2016 15:31:29 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <065e01d2218f$fea323b0$fbe96b10$>
To: Jim Schaad <>
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: Wed, 12 Oct 2016 19:31:32 -0000

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.


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

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