[stir] WG Last Call Comments: draft-ietf-stir-passport-divert-05

Russ Housley <housley@vigilsec.com> Mon, 15 April 2019 15:04 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 444DB1203C5 for <stir@ietfa.amsl.com>; Mon, 15 Apr 2019 08:04:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvetT0465kv4 for <stir@ietfa.amsl.com>; Mon, 15 Apr 2019 08:04:28 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 081241203B4 for <stir@ietf.org>; Mon, 15 Apr 2019 08:04:28 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9E8F2300AAA for <stir@ietf.org>; Mon, 15 Apr 2019 10:46:09 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wpwcqPSpqlPy for <stir@ietf.org>; Mon, 15 Apr 2019 10:46:07 -0400 (EDT)
Received: from [172.20.10.2] (mobile-166-170-29-191.mycingular.net [166.170.29.191]) by mail.smeinc.net (Postfix) with ESMTPSA id 1051C300AF4 for <stir@ietf.org>; Mon, 15 Apr 2019 10:46:06 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Message-Id: <3162DDF4-CB71-41F8-983B-8572D33B460B@vigilsec.com>
Date: Mon, 15 Apr 2019 11:03:21 -0400
To: IETF STIR Mail List <stir@ietf.org>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/KEtyjQAG5RXnTN2aRgdb9cJ6e0o>
Subject: [stir] WG Last Call Comments: draft-ietf-stir-passport-divert-05
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 15 Apr 2019 15:04:30 -0000

Document: draft-ietf-stir-passport-divert-05
Reviewer: Russ Housley
Review Date: 2019-04-15

Major:

Section 1: The last paragraph introduces the "div" PASSporT type.  In
another document, IANA got confused when the "type" was not aligned with
the names used for the registries.  Looking at the structure of RFC 8225,
I think that "div" is a PASSporT Header Parameter value.  Please reword
to provide clarity.  Also, later in the document, "div" PASSporT is used
as shorthand.  This seems very useful.  I suggest this be defined in
Section 1 and used consistently in the document.

Section 1: Please provide similar clarity for the separate "div-o"
PASSporT type and "opt" PASSporT element.  Defining a "div-o" PASSporT
in Section 1 would also help the reader.

Section 3: The first paragraph points out that a new PASSporT is only
necessary when the canonical form of the "dest" identifier (per the
canonicalization procedures in [RFC8224] Section 8).  This seems like
a place for a MUST NOT statement.  If the canonical form of the "dest"
identifier is unchanged, then a new PASSporT with a "div" claim MUST
NOT be produced.

Section 3: The text talks about the PASSporT claims object.  I think
this is the PASSporT Payload as described in Section 5 of RFC 8225.
Please use the same terms.  Similarly, the last paragraph should say
that the PASSporT Payload of a "div" PASSporT MUST NOT contain an
"opt" claim.

Section 5: This section also text talks about the PASSporT claims object.
As above, I think this is the PASSporT Payload as described in Section 5
of RFC 8225.

Section 10: As I said above, in another document, IANA got confused when
the "type" was not aligned with the names used for the registries.  This
can be avoided by providing the URL for the intended registry in each
subsection.


Minor:

Section 1: The second paragraph says: "... it also provides a signature
over the called number as the authentication service sees it."  I think
the point is to authenticate the intended recipient, not just provide
visibility.

Section 2: Please update the first paragraph to reference RFC 8174
in addition to RFC 2119, as follows: 

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.
   
Of course, also add a normative reference to RFC 8174.

Examples of "x5u" claims use the .pkx file extension.  Please use .cer
to align with the conventions in RFC 2585.


Nits:

The document uses 'div' and "div".  It also used 'dest' and "dest".
Please pick one convention, and then use it throughout the document.

Suggestion for the start of the Abstract: "This document extends
PASSporT, which is specified in RFC 8224 to convey cryptographically-
signed ..."

The 'Updates' line in the title page header should list only the numbers
of the to-be-updated RFCs (if approved).

Outdated reference: draft-ietf-stir-rph has been published as RFC 8443.
Please update the reference.