[stir] Protocol Action: 'Personal Assertion Token (PASSporT)' to Proposed Standard (draft-ietf-stir-passport-11.txt)
The IESG <firstname.lastname@example.org> Fri, 26 May 2017 14:18 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A06F7129C20; Fri, 26 May 2017 07:18:07 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: The IESG <email@example.com>
To: "IETF-Announce" <firstname.lastname@example.org>
Cc: The IESG <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org, Robert Sparks <email@example.com>, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org
Content-Type: text/plain; charset="utf-8"
Date: Fri, 26 May 2017 07:18:07 -0700
Subject: [stir] Protocol Action: 'Personal Assertion Token (PASSporT)' to Proposed Standard (draft-ietf-stir-passport-11.txt)
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Fri, 26 May 2017 14:18:08 -0000
The IESG has approved the following document: - 'Personal Assertion Token (PASSporT)' (draft-ietf-stir-passport-11.txt) as Proposed Standard This document is the product of the Secure Telephone Identity Revisited Working Group. The IESG contact persons are Adam Roach, Alexey Melnikov and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ Technical Summary This document defines a method for creating and validating a token that cryptographically verifies an originating identity, or more generally a URI or telephone number representing the originator of personal communications. The PASSporT token is cryptographically signed to protect the integrity of the identity the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. Working Group Summary This document has undergone heavy review. It was introduced into the suite of STIR documents as part of aligning with the SHAKEN effort. Recent versions of this document were implemented and tested at the SIP Forum SIPit test event in September. Feedback from that event informed significant improvements to both the protocol and the prose in the document. Those implementations are tracking the changes made in the latest versions. The document suite has been through three working group last calls, the third of which was abbreviated to one week. The first last call stimulated significant discussion, some of which was heated. Document Quality This document is a component of a toolset for combating robocalling. In the US, the FCC is applying significant pressure to the industry to deter robocalling (with deadlines in the last part of 2016). An industry-led strike force is moving towards deployment of a solution that uses that toolset. The ATIS/SIP Forum IPNNI Task Force's SHAKEN solution relies on the toolset defined by STIR and profiles it for deployment in the North American market. Personnel The document shepherd is Robert Sparks. The responsible AD is Adam Roach. RFC Editor Note Several trivial editorial issues were raised during IESG evaluation. Abstract; old text: the identity the originator New text: the identity of the originator Section 5.1.1; old text: As defined the "iat" should be set to the date and time of issuance of the JWT and MUST the origination of the personal communications. The time value should be of the format defined in [RFC7519] Section 2 NumericDate. New text: As defined the "iat" should be set to the date and time of issuance of the JWT and MUST indicate the date and time of the origination of the personal communications. The time value should be of the format defined in [RFC7519] Section 2 NumericDate. Section 5.2.2; old text: 2. Sort the lines based on the UTF8 encoding New text: 2. Sort the lines based on the UTF8 [RFC3629] encoding (and add RFC3629 as a normative reference)