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

"Peterson, Jon" <> Mon, 15 April 2019 19:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CB471200D8 for <>; Mon, 15 Apr 2019 12:14:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.638
X-Spam-Status: No, score=-0.638 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cs8t5Ep4eTVA for <>; Mon, 15 Apr 2019 12:14:58 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 49C76120026 for <>; Mon, 15 Apr 2019 12:14:58 -0700 (PDT)
Received: from pps.filterd ( []) by ( with SMTP id x3FJDLvs028148; Mon, 15 Apr 2019 15:14:57 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=selector1; bh=qbBZydx63VMiruD2cMk/KD2aFzB0EiRzdNsk5tJ+MvA=; b=OO46Z9yMfLd5F1tLWBzZblpROdIIcoYpCK1BpSaF1+NUFAxf5baKd6AcOcVriVs4B1cR hKgw+5hFT5VnT0WbWN0bAY1TQTU/q9mfBd2NOC2X/IPSRL87YklfJai2TTzRGW4OlpEk eSxh1/VYBm11BOUcMi+csGaaszA5ZYpXLKGcvV+0HVKhvFcYyU2HIP9Bz8c0vNuqtU5B 0jzvuQb6oSV3PwVR/JyjEIGU+f0tCfTZy18mPmJxQh/EC9KfFY9ntRYRMbjFBDnjy/0/ YgUB0jSuff9J26AJ45TMhW6FQVR8RzO0QE2WaMKn6kj40UF80siHutez/YSgzPy6PcH1 vA==
Received: from ([]) by with ESMTP id 2ruadw4h1x-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 15 Apr 2019 15:14:57 -0400
Received: from ([fe80::a831:d3b4:fb4e:e45b]) by ([::1]) with mapi id 14.03.0439.000; Mon, 15 Apr 2019 15:14:55 -0400
From: "Peterson, Jon" <>
To: Russ Housley <>, IETF STIR Mail List <>
Thread-Topic: [stir] WG Last Call Comments: draft-ietf-stir-passport-divert-05
Thread-Index: AQHU85yNh0+cmX1LOUqH/lTch1TgtaY9ZYCA
Date: Mon, 15 Apr 2019 19:14:55 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-15_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904150133
Archived-At: <>
Subject: Re: [stir] WG Last Call Comments: draft-ietf-stir-passport-divert-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Secure Telephone Identity Revisited <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Apr 2019 19:14:59 -0000

Thanks for the notes Russ. Some responses inline.
    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".
    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.

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

"as the authentication service sees it" there is not about visibility, it's referring to the fact that the intended recipient may change in flight - the authentication service sees it before those changes.
    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",
       "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.
Will do.

    Examples of "x5u" claims use the .pkx file extension.  Please use .cer
    to align with the conventions in RFC 2585.
Will do. And will do those nits below, with my one note there...
    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 ..."

I thought we weren't supposed to put references in the abstract (apart from notes about RFC obsoleted etc. by this spec).
    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.
Jon Peterson
Neustar, Inc.