Skip to main content

PASSporT: Personal Assertion Token
draft-ietf-stir-passport-11

Revision differences

Document history

Date Rev. By Action
2017-09-01
11 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2017-07-31
11 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2017-07-17
11 (System) RFC Editor state changed to RFC-EDITOR from AUTH
2017-06-23
11 (System) RFC Editor state changed to AUTH from EDIT
2017-06-21
11 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2017-06-21
11 (System) IANA Action state changed to Waiting on RFC Editor from Waiting on Authors
2017-06-12
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2017-06-12
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2017-06-06
11 (System) IANA Action state changed to Waiting on Authors from In Progress
2017-06-06
11 (System) IANA Action state changed to In Progress from Waiting on Authors
2017-05-26
11 (System) RFC Editor state changed to EDIT
2017-05-26
11 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2017-05-26
11 (System) Announcement was received by RFC Editor
2017-05-26
11 (System) IANA Action state changed to Waiting on Authors
2017-05-26
11 Amy Vezza IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2017-05-26
11 Amy Vezza IESG has approved the document
2017-05-26
11 Amy Vezza Closed "Approve" ballot
2017-05-26
11 Amy Vezza Ballot approval text was generated
2017-05-26
11 Amy Vezza Ballot writeup was changed
2017-05-25
11 Adam Roach IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup
2017-05-25
11 Adam Roach RFC Editor Note was changed
2017-05-25
11 Adam Roach RFC Editor Note for ballot was generated
2017-05-25
11 Adam Roach RFC Editor Note for ballot was generated
2017-05-03
11 Alissa Cooper Shepherding AD changed to Adam Roach
2017-02-12
11 Stephen Farrell [Ballot comment]

Thanks for handling my DISCUSS about deterministic signing.
2017-02-12
11 Stephen Farrell [Ballot Position Update] Position for Stephen Farrell has been changed to No Objection from Discuss
2017-02-09
11 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2017-02-09
11 Chris Wendt New version available: draft-ietf-stir-passport-11.txt
2017-02-09
11 (System) New version approved
2017-02-09
11 (System) Request for posting confirmation emailed to previous authors: "Jon Peterson" , "Chris Wendt"
2017-02-09
11 Chris Wendt Uploaded new revision
2016-12-27
10 Sabrina Tanamal IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2016-11-10
10 Tero Kivinen Closed request for Last Call review by SECDIR with state 'No Response'
2016-11-07
10 Robert Sparks Added to session: IETF-97: stir  Wed-0930
2016-11-03
10 Cindy Morgan IESG state changed to IESG Evaluation::AD Followup from IESG Evaluation
2016-11-03
10 Gunter Van de Velde Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Bert Wijnen.
2016-11-02
10 Joel Jaeggli [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli
2016-11-02
10 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2016-11-02
10 Stephen Farrell
[Ballot discuss]

Deterministic ECDSA (RFC6979) gets rid of a significant weakness
with ECDSA. IIRC when JOSE was done there was a feeling that …
[Ballot discuss]

Deterministic ECDSA (RFC6979) gets rid of a significant weakness
with ECDSA. IIRC when JOSE was done there was a feeling that adding a
MUST or SHOULD for that was tricky due to lack of support in
libraries. When we recently re-checked for COSE, the answer was
that today, it's ok to have that as a MUST or SHOULD. (If some
kind of FIPS-140 stuff precludes a MUST, then a "SHOULD unless
you're sad enough to be stuck having to pay lip lipservice to
FIPS-140" clause might be right. So the DISCUSS point here is:
given the real-world demonstrated weakness inherent in the need
for an RNG in ECDSA why didn't the WG choose to at least RECOMMEND
deterministic ECDSA? (Or better, make it a MUST.)

If the answer is: "we thought about it [ref] and decided to not require
deterministic" then I'll clear. But even if the WG did consider it
a couple of years ago, the situation may have changed so a quick
re-think might be worthwhile.
2016-11-02
10 Stephen Farrell [Ballot Position Update] New position, Discuss, has been recorded for Stephen Farrell
2016-11-02
10 Alia Atlas
[Ballot comment]
Nit:

In Sec 5.1.1:
"As defined the "iat" should be set to the date and
  time of issuance of the JWT and …
[Ballot comment]
Nit:

In Sec 5.1.1:
"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."
I assume that should be "MUST be" ?
2016-11-02
10 Alia Atlas [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas
2016-11-02
10 Kathleen Moriarty
[Ballot comment]
Thanks for a very well written example of how to use some of the JOSE work.

In section 9.1 there's another nit that …
[Ballot comment]
Thanks for a very well written example of how to use some of the JOSE work.

In section 9.1 there's another nit that was not identified (that I can see) by other reviewers.

This section demonstrate the deterministic JSON
s/demonstrate/demonstrates/
2016-11-02
10 Kathleen Moriarty [Ballot Position Update] New position, Yes, has been recorded for Kathleen Moriarty
2016-11-02
10 Ben Campbell [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell
2016-11-02
10 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2016-11-02
10 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2016-11-02
10 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko
2016-11-01
10 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2016-11-01
10 Benoît Claise
[Ballot comment]
Editorial feedback from Bert Wijnen, our OPS-DIR reviewer:
While I was at it, I found someNits and/or typos:

The abstract states:


    …
[Ballot comment]
Editorial feedback from Bert Wijnen, our OPS-DIR reviewer:
While I was at it, I found someNits and/or typos:

The abstract states:


                            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.

s/the identity the originator/the identity of the originator/
Or so I think.

section 5.1.1 states:


                  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.

Is that a correct sentence? or is the a verb missing around
  "the JWT and MUST the origination" ???

Section 5.2.2

5.2.2. "mky" - Media Key claim Why such a cryptic "mky". Why not "mkey" ?? I can live with it. I just wonder why we make it more cryptic than needed. Section 10.2 2nd bullet        In many applications, the end user represented by the asserted
      identity represents and signer may not be one in the same
I do/did not know the term "one in the same". I do know "one and the same". I guess other people may have the same knowledge as I do (as non native English speaker) Bert
2016-11-01
10 Benoît Claise [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise
2016-11-01
10 Mirja Kühlewind
[Ballot comment]
"The claim value for the "tn" claim is the telephone number and MUST
  be canonicalized according to the procedures specified in
  …
[Ballot comment]
"The claim value for the "tn" claim is the telephone number and MUST
  be canonicalized according to the procedures specified in
  [I-D.ietf-stir-rfc4474bis] Section 8.3."
This indicated that's section 8.3 of ietf-stir-rfc4474bis belongs in this doc. Is there are reason why it is in ietf-stir-rfc4474bis instead?
2016-11-01
10 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2016-11-01
10 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2016-11-01
10 Alexey Melnikov
[Ballot comment]
This is generally a well written and detailed document. Thank you.

I have some minor comments:

5.1.1.  "iat" - Issued At claim

  …
[Ballot comment]
This is generally a well written and detailed document. Thank you.

I have some minor comments:

5.1.1.  "iat" - Issued At claim

  The JSON claim MUST include the "iat" [RFC7519] Section 4.1.6 defined
  claim Issued At.  As defined the "iat" should be set to the date and
  time of issuance of the JWT and MUST the origination

I think a verb is missing between "MUST" and "the origination"

  of the personal
  communications.

5.2.2.  "mky" - Media Key claim

  2.  Sort the lines based on the UTF8 encoding

UTF-8 needs a normative reference (RFC 3629).

      of the concatenation of
      the "alg" and "dig" claim value strings.

7.1.  Example Compact form PASSporT Token

  eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9

I decoded this and it looks reasonable:
{"alg":"ES256","typ":"passport","x5u":"https://cert.example.org/passport.cer"}

  .
  eyJkZXN0Ijp7InVyaSI6WyJzaXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI
  6IjE0NDMyMDgzNDUiLCJvcmlnIjp7InRuIjoiMTIxNTU1NTEyMTIifX0

OpenSSL produced the following:

{"dest":{"uri":["sip:alice@example.com"]},"iat":

this looks like a truncated value. Is something wrong with the value or is this an OpenSSL bug?
2016-11-01
10 Alexey Melnikov [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov
2016-11-01
10 Robert Sparks
1. Summary

draft-ietf-stir-passport defines protocol and is intended for publication as
Proposed Standard. From the abstract:

  This document defines a method for creating and …
1. Summary

draft-ietf-stir-passport defines protocol and is intended for publication as
Proposed Standard. From the abstract:

  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.

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.

2. Review and Consensus

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.

This document requires review on the jwt-reg-review and jose-reg-review lists.
Review requests were sent to those lists 18Oct. Feedback from those reviews
has been incorporated in the draft. Jim Schaad, in particular, provided a careful
review and many improvements.

The document registers a media type, requiring media-type review. That review
was requested 18Oct. Feedback from the review has been incorporated into the
document.

3. Intellectual Property

The authors have each confirmed that any IPR they are aware of has been
disclosed. There are currently no disclosures registered for this document.

4. Other Points

There are no normative downreferences from this document.

The document uses no formal languages, but does contain several examples. These
have been carefully reviewed by implementors.

The document requires several actions from IANA. They are concretely described
in the document text.

2016-11-01
10 Alissa Cooper IESG state changed to IESG Evaluation from Waiting for Writeup
2016-11-01
10 Alissa Cooper Ballot has been issued
2016-11-01
10 Alissa Cooper [Ballot Position Update] New position, Yes, has been recorded for Alissa Cooper
2016-11-01
10 Alissa Cooper Created "Approve" ballot
2016-11-01
10 Alissa Cooper Ballot writeup was changed
2016-11-01
10 (System) IESG state changed to Waiting for Writeup from In Last Call
2016-10-31
10 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2016-10-31
10 Sabrina Tanamal
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-stir-passport-09.txt. If any part of this review is inaccurate, please let …
(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-stir-passport-09.txt. If any part of this review is inaccurate, please let us know.

Upon approval of this document, we understand that there are three registry actions to complete.

First, in the application subregistry of the Media Types registry located at:

https://www.iana.org/assignments/media-types/

a single, new media type will be added as follows:

Name: passport
Template: [ TBD-at-registration ]
Reference: [ RFC-to-be ]

Second, in the JSON Web Token Claims subregistry in the JSON Web Token (JWT) registry located at:

https://www.iana.org/assignments/jwt/

three, new Web Token Claims are to be registered as follows:

Claim Name: orig
Clain Description: Originating Identity String
Change Controller: IESG
Reference: [ RFC-to-be ]

Claim Name: dest
Clain Description: Destination Identity String
Change Controller: IESG
Reference: [ RFC-to-be ]

Claim Name: mky
Clain Description: Media Key Fingerprint String
Change Controller: IESG
Reference: [ RFC-to-be ]

As this is an Expert Review (see RFC 5226) registry, we will initiate the required review via a separate request. Approval by the expert is required for registration. 

Third, in the JSON Web Signature and Encryption Header Parameters subregistry of the JSON Object Signing and Encryption (JOSE) regsitry located at:

https://www.iana.org/assignments/jose/

a single new parameter is to be registered as follows:

Header Parameter Name: ppt
Header Parameter Description: PASSporT extension identifier
Header Parameter Usage Location: JWS
Change Controller: IESG
Reference: [ RFC-to-be ]

Once again, as this is an Expert Review (see RFC 5226) registry, we will initiate the required review via a separate request. Approval by the expert is required for registration. 

We understand that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

Thank you,

Sabrina Tanamal
IANA Services Specialist
PTI
2016-10-31
10 Chris Wendt New version available: draft-ietf-stir-passport-10.txt
2016-10-31
10 (System) New version approved
2016-10-31
10 (System) Request for posting confirmation emailed to previous authors: "Jon Peterson" , "Chris Wendt"
2016-10-31
10 Chris Wendt Uploaded new revision
2016-10-27
09 Roni Even Request for Last Call review by GENART Completed: Ready. Reviewer: Roni Even.
2016-10-22
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Bert Wijnen
2016-10-22
09 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Bert Wijnen
2016-10-20
09 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2016-10-20
09 Jean Mahoney Request for Last Call review by GENART is assigned to Roni Even
2016-10-20
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2016-10-20
09 Tero Kivinen Request for Last Call review by SECDIR is assigned to Paul Wouters
2016-10-18
09 Cindy Morgan IANA Review state changed to IANA - Review Needed
2016-10-18
09 Cindy Morgan
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alissa@cooperw.in, draft-ietf-stir-passport@ietf.org, stir@ietf.org, "Robert Sparks" , stir-chairs@ietf.org, …
The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: alissa@cooperw.in, draft-ietf-stir-passport@ietf.org, stir@ietf.org, "Robert Sparks" , stir-chairs@ietf.org, rjsparks@nostrum.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Personal Assertion Token (PASSporT)) to Proposed Standard


The IESG has received a request from the Secure Telephone Identity
Revisited WG (stir) to consider the following document:
- 'Personal Assertion Token (PASSporT)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-11-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  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.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-stir-passport/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-stir-passport/ballot/


No IPR declarations have been submitted directly on this I-D.




2016-10-18
09 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2016-10-18
09 Alissa Cooper Last call was requested
2016-10-18
09 Alissa Cooper Ballot approval text was generated
2016-10-18
09 Alissa Cooper Ballot writeup was generated
2016-10-18
09 Alissa Cooper IESG state changed to Last Call Requested from Publication Requested
2016-10-18
09 Alissa Cooper Last call announcement was generated
2016-10-18
09 Robert Sparks
1. Summary

draft-ietf-stir-passport defines protocol and is intended for publication as
Proposed Standard. From the abstract:

  This document defines a method for creating and …
1. Summary

draft-ietf-stir-passport defines protocol and is intended for publication as
Proposed Standard. From the abstract:

  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.

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.

2. Review and Consensus

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.

This document requires review on the jwt-reg-review and jose-reg-review lists.
Early feedback from Jim Schaad is already reflected in the document. Review
requests were sent to those lists 18Oct.

The document registers a media type, requiring media-type review. That review
was requested 18Oct.

3. Intellectual Property

The authors have each confirmed that any IPR they are aware of has been
disclosed. There are currently no disclosures registered for this document.

4. Other Points

There are no normative downreferences from this document.

The document uses no formal languages, but does contain several examples. These
have been carefully reviewed by implementors.

The document requires several actions from IANA. They are concretely described
in the document text.

2016-10-18
09 Robert Sparks Responsible AD changed to Alissa Cooper
2016-10-18
09 Robert Sparks IETF WG state changed to Submitted to IESG for Publication from In WG Last Call
2016-10-18
09 Robert Sparks IESG state changed to Publication Requested
2016-10-18
09 Robert Sparks IESG process started in state Publication Requested
2016-10-18
09 Robert Sparks Intended Status changed to Proposed Standard from None
2016-10-18
09 Robert Sparks Changed document writeup
2016-10-18
09 Robert Sparks Notification list changed to "Robert Sparks" <rjsparks@nostrum.com>
2016-10-18
09 Robert Sparks Document shepherd changed to Robert Sparks
2016-10-18
09 Chris Wendt New version available: draft-ietf-stir-passport-09.txt
2016-10-18
09 (System) New version approved
2016-10-18
09 (System) Request for posting confirmation emailed to previous authors: "Jon Peterson" , "Chris Wendt"
2016-10-18
09 Chris Wendt Uploaded new revision
2016-10-18
08 Alissa Cooper Changed consensus to Yes from Unknown
2016-10-18
08 Alissa Cooper Placed on agenda for telechat - 2016-11-03
2016-09-29
08 Chris Wendt New version available: draft-ietf-stir-passport-08.txt
2016-09-29
08 Chris Wendt New version approved
2016-09-29
08 Chris Wendt Request for posting confirmation emailed to previous authors: "Jon Peterson" , "Chris Wendt"
2016-09-29
08 (System) Uploaded new revision
2016-09-09
07 Chris Wendt New version available: draft-ietf-stir-passport-07.txt
2016-08-22
06 Chris Wendt New version available: draft-ietf-stir-passport-06.txt
2016-07-22
05 Chris Wendt New version available: draft-ietf-stir-passport-05.txt
2016-07-22
04 Russ Housley
A two week WG Last Call for the PASSporT document started on 13 July 2016, and it will end on 27 July 2016.  Ideally major …
A two week WG Last Call for the PASSporT document started on 13 July 2016, and it will end on 27 July 2016.  Ideally major concerns will be raised quickly so that they can be tackled during IETF 96.
2016-07-22
04 Russ Housley IETF WG state changed to In WG Last Call from WG Document
2016-07-08
04 Chris Wendt New version available: draft-ietf-stir-passport-04.txt
2016-07-07
03 Robert Sparks Added to session: IETF-96: stir  Tue-1400
2016-06-13
03 Chris Wendt New version available: draft-ietf-stir-passport-03.txt
2016-05-27
02 Russ Housley Added to session: interim-2016-stir-1
2016-05-24
02 Chris Wendt New version available: draft-ietf-stir-passport-02.txt
2016-03-23
01 Naveen Khan New version available: draft-ietf-stir-passport-01.txt
2016-03-21
00 Robert Sparks Added to session: IETF-95: stir  Tue-1740
2016-02-22
00 Chris Wendt New version available: draft-ietf-stir-passport-00.txt