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

Russ Housley <housley@vigilsec.com> Mon, 15 April 2019 19:44 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 3A8A61201B2 for <stir@ietfa.amsl.com>; Mon, 15 Apr 2019 12:44:42 -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 d8o1h3Kp7JRP for <stir@ietfa.amsl.com>; Mon, 15 Apr 2019 12:44:40 -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 C5B5C1201A6 for <stir@ietf.org>; Mon, 15 Apr 2019 12:44:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id BAAE0300ADD for <stir@ietf.org>; Mon, 15 Apr 2019 15:26:21 -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 9pOz2Ti2ylUD for <stir@ietf.org>; Mon, 15 Apr 2019 15:26:20 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (unknown [138.88.156.37]) by mail.smeinc.net (Postfix) with ESMTPSA id 2EA38300580; Mon, 15 Apr 2019 15:26:20 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <23FC946B-A5BC-4DAC-A281-9DB202C1DC93@team.neustar>
Date: Mon, 15 Apr 2019 15:44:37 -0400
Cc: IETF STIR Mail List <stir@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <060587D1-11D4-45D0-8605-0B11D38415ED@vigilsec.com>
References: <3162DDF4-CB71-41F8-983B-8572D33B460B@vigilsec.com> <23FC946B-A5BC-4DAC-A281-9DB202C1DC93@team.neustar>
To: Jon Peterson <jon.peterson@neustar.biz>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/4jNWfQQ3rVWhdOCkdS55KK7BTNM>
Subject: Re: [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 19:44:42 -0000

Jon:

Minor follow up...

>    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.
> 
> PASSporT Type ("ppt") is defined in RFC8224 Section 4. Its use is consistent with the terminology in the IANA Considerations of RFC8225 (Section 11.4) which formally names that registry the "PASSporT Extensions Registry." I'll clarify that we mean this registry in the IANA Considerations of the stir-passport-divert spec (and add the URL of the registry as you suggest below), but I think it's okay if we keep using the terminology "PASSporT Type".

Yes, I agree that "PASSporT Type" is fine as long as Section 10 has the right pointer.

>    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.
> 
> No problem, will add that.
> 
>    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.  
> 
> Well, the "header" and "claims" terminology is from the JWT RFC (7519), "payload" comes from the core JWS RFC (7515). They are kind of used interchangeably around the STIR specs; there are plenty of references to claims in RFC8225. I think I'm okay with continuing to use "payload" and "claims" to mean the same thing.

My reading of RFC 8225 is that the payload is composed of a collection of claims.  Some of the claims are defined in the JWT specifications, and other are defined specifically for PASSporT.  In the document, it is not clear to me whether a "claim object" is one of the claims in this collection or the whole collection.  If the term payload was used for the whole collection, I think it would be more consistent and clear.

>    Similarly, the last paragraph should say
>    that the PASSporT Payload of a "div" PASSporT MUST NOT contain an
>    "opt" claim.
> 
> Probably that's fine. I'm idly wondering if some other PASSporT extension might want to use "opt" in conjunction with "div" for some reason. Seems unlikely, and we could just leave it to any future extension to patch this later if needed.

The document already says otherwise:

   PASSporTs of type "div" MUST NOT contain an "opt" (see Section 6)
   element in their claims; PASSporTs of type "div-o" (see Section 5)
   MUST contain an "opt".

It does not say whether for future type "foo" can use it or not, which seems appropriate.

Russ