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

Jim Schaad <ietf@augustcellars.com> Sat, 08 October 2016 18:16 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id DE3CD12954F; Sat, 8 Oct 2016 11:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.897
X-Spam-Status: No, score=-4.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BTTrOKJoNP5A; Sat, 8 Oct 2016 11:16:00 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1039129508; Sat, 8 Oct 2016 11:15:59 -0700 (PDT)
Received: from hebrews ( by mail2.augustcellars.com ( with Microsoft SMTP Server (TLS) id 15.0.1210.3; Sat, 8 Oct 2016 11:29:10 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: draft-ietf-stir-passport@ietf.org
Date: Sat, 08 Oct 2016 11:15:45 -0700
Message-ID: <065e01d2218f$fea323b0$fbe96b10$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdIg4gF4XR18IpbFR76cpVd45Z1JXQ==
Content-Language: en-us
X-Originating-IP: []
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/OjlWrBHxGX4IFMEJKXVPbBAGZlA>
Cc: stir@ietf.org
Subject: [stir] draft-ietf-stir-passport-08
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Oct 2016 18:16:02 -0000

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.

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

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

* Section 4.2.X - you are not telling me that these are arrays of "some
type" rather than the "some type".

 * 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

* Section 5 - I am having a hard time finding the lexicographic order and
white space rules quickly.  A pointer might be reasonable.

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

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

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

* Section 9.2 - Consider using a list structure for the asterisk leading
list in this section.

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

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