draft-ietf-stir-certificates-18.txt   rfc8226.txt 
Network Working Group J. Peterson Internet Engineering Task Force (IETF) J. Peterson
Internet-Draft Neustar Request for Comments: 8226 Neustar
Intended status: Standards Track S. Turner Category: Standards Track S. Turner
Expires: June 21, 2018 sn3rd ISSN: 2070-1721 sn3rd
December 18, 2017 February 2018
Secure Telephone Identity Credentials: Certificates Secure Telephone Identity Credentials: Certificates
draft-ietf-stir-certificates-18
Abstract Abstract
In order to prevent the impersonation of telephone numbers on the In order to prevent the impersonation of telephone numbers on the
Internet, some kind of credential system needs to exist that Internet, some kind of credential system needs to exist that
cryptographically asserts authority over telephone numbers. This cryptographically asserts authority over telephone numbers. This
document describes the use of certificates in establishing authority document describes the use of certificates in establishing authority
over telephone numbers, as a component of a broader architecture for over telephone numbers, as a component of a broader architecture for
managing telephone numbers as identities in protocols like SIP. managing telephone numbers as identities in protocols like SIP.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on June 21, 2018. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8226.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction ....................................................2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology .....................................................3
3. Authority for Telephone Numbers in Certificates . . . . . . . 4 3. Authority for Telephone Numbers in Certificates .................4
4. Certificate Usage with STIR . . . . . . . . . . . . . . . . . 5 4. Certificate Usage with STIR .....................................5
5. Enrollment and Authorization Using the TN Authorization List 6 5. Enrollment and Authorization Using the TN Authorization List ....6
5.1. Constraints on Signing PASSporTs . . . . . . . . . . . . 8 5.1. Constraints on Signing PASSporTs ...........................8
5.2. Certificate Extension Scope and Structure . . . . . . . . 8 5.2. Certificate Extension Scope and Structure ..................8
6. Provisioning Private Keying Material . . . . . . . . . . . . 9 6. Provisioning Private Keying Material ............................9
7. Acquiring Credentials to Verify Signatures . . . . . . . . . 9 7. Acquiring Credentials to Verify Signatures ......................9
8. JWT Claim Constraints Syntax . . . . . . . . . . . . . . . . 10 8. JWT Claim Constraints Syntax ...................................10
9. TN Authorization List Syntax . . . . . . . . . . . . . . . . 11 9. TN Authorization List Syntax ...................................12
10. Certificate Freshness and Revocation . . . . . . . . . . . . 13 10. Certificate Freshness and Revocation ..........................14
10.1. Acquiring the TN List by Reference . . . . . . . . . . . 14 10.1. Acquiring the TN List by Reference .......................15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations ...........................................16
11.1. ASN.1 Registrations . . . . . . . . . . . . . . . . . . 15 11.1. ASN.1 Registrations ......................................16
11.2. Media Type Registrations . . . . . . . . . . . . . . . . 16 11.2. Media Type Registrations .................................16
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. Security Considerations .......................................17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 13. References ....................................................18
13.1. Normative References . . . . . . . . . . . . . . . . . . 17 13.1. Normative References .....................................18
13.2. Informative References . . . . . . . . . . . . . . . . . 19 13.2. Informative References ...................................20
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20 Appendix A. ASN.1 Module ..........................................21
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22 Acknowledgments ...................................................24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses ................................................24
1. Introduction 1. Introduction
The Secure Telephone Identity Revisited (STIR) problem statement The Secure Telephone Identity Revisited (STIR) problem statement
[RFC7340] identifies the primary enabler of robocalling, vishing [RFC7340] identifies the primary enabler of robocalling, vishing
(voicemail hacking), swatting, and related attacks as the capability (voicemail hacking), swatting, and related attacks as the capability
to impersonate a calling party number. The starkest examples of to impersonate a calling party number. The starkest examples of
these attacks are cases where automated callees on the Public these attacks are cases where automated callees on the Public
Switched Telephone Network (PSTN) rely on the calling number as a Switched Telephone Network (PSTN) rely on the calling number as a
security measure -- for example, to access a voicemail system. security measure -- for example, to access a voicemail system.
skipping to change at page 13, line 20 skipping to change at page 13, line 32
OCNs as specified in [ATIS-0300251], related SPIDs, or other OCNs as specified in [ATIS-0300251], related SPIDs, or other
similar identifiers for service providers. SPCs can be used to similar identifiers for service providers. SPCs can be used to
indirectly name all of the telephone numbers associated with that indirectly name all of the telephone numbers associated with that
identifier for a service provider. identifier for a service provider.
2. Telephone numbers can be listed in a range (in the 2. Telephone numbers can be listed in a range (in the
TelephoneNumberRange format), which consists of a starting TelephoneNumberRange format), which consists of a starting
telephone number and then an integer count of numbers within the telephone number and then an integer count of numbers within the
range, where the valid boundaries of ranges may vary according to range, where the valid boundaries of ranges may vary according to
national policies. The count field is only applicable to start national policies. The count field is only applicable to start
fields' whose values do not include "*" or "#" (i.e., a fields whose values do not include "*" or "#" (i.e., a
TelephoneNumber that does not include "*" or "#"). count MUST TelephoneNumber that does not include "*" or "#"). count
NOT make the number increase in length (i.e., a MUST NOT make the number increase in length (i.e., a
TelephoneNumberRange with TelephoneNumber=10 with a count=91 is TelephoneNumberRange with TelephoneNumber=10 and count=91 is
invalid); formally, given the inputs count and TelephoneNumber of invalid); formally, given the inputs count and TelephoneNumber of
length D TelephoneNumber + count MUST be less than 10^D. length D, TelephoneNumber + count MUST be less than 10^D.
3. A single telephone number can be listed (as a TelephoneNumber). 3. A single telephone number can be listed (as a TelephoneNumber).
Note that because large-scale service providers may want to associate Note that because large-scale service providers may want to associate
many numbers, possibly millions of numbers, with a particular many numbers, possibly millions of numbers, with a particular
certificate, optimizations are required for those cases to prevent certificate, optimizations are required for those cases to prevent
the certificate size from becoming unmanageable. In these cases, the the certificate size from becoming unmanageable. In these cases, the
TN Authorization List may be given by reference rather than by value, TN Authorization List may be given by reference rather than by value,
through the presence of a separate certificate extension that permits through the presence of a separate certificate extension that permits
verifiers to either (1) securely download the list of numbers verifiers to either (1) securely download the list of numbers
skipping to change at page 14, line 49 skipping to change at page 15, line 22
Acquiring a list of the telephone numbers associated with a Acquiring a list of the telephone numbers associated with a
certificate or its subject lends itself to an application-layer certificate or its subject lends itself to an application-layer
query/response interaction outside of certificate status, one that query/response interaction outside of certificate status, one that
could be initiated through a separate URI included in the could be initiated through a separate URI included in the
certificate. The AIA extension (see [RFC5280]) supports such a certificate. The AIA extension (see [RFC5280]) supports such a
mechanism: it designates an OID to identify the accessMethod and an mechanism: it designates an OID to identify the accessMethod and an
accessLocation, which would most likely be a URI. A verifier would accessLocation, which would most likely be a URI. A verifier would
then follow the URI to ascertain whether the TNs in the list are then follow the URI to ascertain whether the TNs in the list are
authorized for use by the caller. As with the certificate extension authorized for use by the caller. As with the certificate extension
defined in Section 9, a URI dereferenced from an end entity defined in Section 9, a URI dereferenced from an end-entity
certificate will indicate the TNs which the caller has been certificate will indicate the TNs that the caller has been
authorized. Verifiers MUST support the AIA extension and the authorized. Verifiers MUST support the AIA extension, and the
dereferenced URI from a CA certificate limits the the set of TNs for dereferenced URI from a CA certificate limits the set of TNs for
certification paths that include this certificate. certification paths that include this certificate.
HTTPS is the most obvious candidate for a protocol to be used for HTTPS is the most obvious candidate for a protocol to be used for
fetching the list of telephone numbers associated with a particular fetching the list of telephone numbers associated with a particular
certificate. This document defines a new AIA accessMethod, called certificate. This document defines a new AIA accessMethod, called
"id-ad-stirTNList", which uses the following AIA OID: "id-ad-stirTNList", which uses the following AIA OID:
id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 } id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 }
When the "id-ad-stirTNList" accessMethod is used, the accessLocation When the "id-ad-stirTNList" accessMethod is used, the accessLocation
MUST be an HTTPS URI. Dereferencing the URI will return the complete MUST be an HTTPS URI. Dereferencing the URI will return the complete
DER encoded TN Authorization List (see Section 9) for the certificate DER-encoded TN Authorization List (see Section 9) for the certificate
with a Content-Type of application/tnauthlist (see Section 11.2). with a Content-Type of application/tnauthlist (see Section 11.2).
Delivering the entire list of telephone numbers associated with a Delivering the entire list of telephone numbers associated with a
particular certificate will divulge to STIR verifiers information particular certificate will divulge to STIR verifiers information
about telephone numbers other than the one associated with the about telephone numbers other than the one associated with the
particular call that the verifier is checking. In some environments, particular call that the verifier is checking. In some environments,
where STIR verifiers handle a high volume of calls, maintaining an where STIR verifiers handle a high volume of calls, maintaining an
up-to-date and complete cache for the numbers associated with crucial up-to-date and complete cache for the numbers associated with crucial
certificate holders could give an important boost to performance. certificate holders could give an important boost to performance.
skipping to change at page 16, line 17 skipping to change at page 16, line 43
89 id-mod-tn-module 89 id-mod-tn-module
11.2. Media Type Registrations 11.2. Media Type Registrations
Type name: application Type name: application
Subtype name: tnauthlist Subtype name: tnauthlist
Required parameters: None Required parameters: None
Optional parameters: None Optional parameters: None
Encoding considerations: Binary Encoding considerations: Binary
Security considerations: See Section 12 of [RFCTBD] Security considerations: See Section 12 of RFC 8226
Interoperability considerations: Interoperability considerations:
The TN Authorization List inside this media type MUST be The TN Authorization List inside this media type MUST be
DER-encoded TNAuthorizationList. DER-encoded TNAuthorizationList.
Published specification: [RFCTBD] Published specification: RFC 8226
Applications that use this media type: Applications that use this media type:
Issuers and relying parties of secure telephone identity Issuers and relying parties of secure telephone identity
certificates, to limit the subject's authority to a certificates, to limit the subject's authority to a
particular telephone number or telephone number range. particular telephone number or telephone number range.
Fragment identifier considerations: None Fragment identifier considerations: None
Additional information: Additional information:
Deprecated alias names for this type: None Deprecated alias names for this type: None
Magic number(s): None Magic number(s): None
File extension(s): None File extension(s): None
Macintosh File Type Code(s): None Macintosh File Type Code(s): None
Person & email address to contact for further information: Person & email address to contact for further information:
Jon Peterson <jon.peterson@team.neustar> Jon Peterson <jon.peterson@team.neustar>
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
Author: Sean Turner <sean@sn3rd.com> Author: Sean Turner <sean@sn3rd.com>
Change controller: The IESG <iesg@ietf.org> Change controller: The IESG <iesg@ietf.org>
[RFC editor's instruction: Please replace RFCTBD with the
RFC number when this document is published.]
12. Security Considerations 12. Security Considerations
This document is entirely about security. For further information on This document is entirely about security. For further information on
certificate security and practices, see [RFC5280], in particular its certificate security and practices, see [RFC5280], in particular its
Security Considerations section. Security Considerations section.
If a certification authority issues a certificate attesting authority If a certification authority issues a certificate attesting authority
over many telephone numbers, the TNAuthList element can divulge to over many telephone numbers, the TNAuthList element can divulge to
relying parties extraneous telephone numbers associated with the relying parties extraneous telephone numbers associated with the
certificate which have no bearing on any given call in progress. The certificate that have no bearing on any given call in progress. The
potential privacy risk can be exacerbated by the use of AIA, as potential privacy risk can be exacerbated by the use of AIA, as
described in Section 10.1, to link many thousand of numbers to a described in Section 10.1, to link many thousands of numbers to a
single certificate. Even an SPC in a certificate can be used to link single certificate. Even an SPC in a certificate can be used to link
a certificate to a particular carrier and, with access to industry a certificate to a particular carrier and, with access to industry
databases, potentially the set of numbers associated with that SPC. databases, potentially the set of numbers associated with that SPC.
While these practices may not cause concern in some environments, in While these practices may not cause concern in some environments, in
other scenarios alternative approaches could minimize the data other scenarios alternative approaches could minimize the data
revealed to relying parties. For example, a service provider with revealed to relying parties. For example, a service provider with
authority over a large block of numbers could generate short-lived authority over a large block of numbers could generate short-lived
certificates for individual TNs that are not so easily linked to the certificates for individual TNs that are not so easily linked to the
service provider or any other numbers that the service provider service provider or any other numbers that the service provider
controls. Optimizations to facilitate acquiring short-lived controls. Optimizations to facilitate acquiring short-lived
skipping to change at page 17, line 39 skipping to change at page 18, line 21
Service Providers for Information Exchange", 2007. Service Providers for Information Exchange", 2007.
[DSS] National Institute of Standards and Technology, U.S. [DSS] National Institute of Standards and Technology, U.S.
Department of Commerce, "Digital Signature Standard Department of Commerce, "Digital Signature Standard
(DSS)", NIST FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4, (DSS)", NIST FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4,
July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/ July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/
NIST.FIPS.186-4.pdf>. NIST.FIPS.186-4.pdf>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997,
editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998, Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
<https://www.rfc-editor.org/info/rfc2392>. <https://www.rfc-editor.org/info/rfc2392>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
DOI 10.17487/RFC5912, June 2010, <https://www.rfc- DOI 10.17487/RFC5912, June 2010,
editor.org/info/rfc5912>. <https://www.rfc-editor.org/info/rfc5912>.
[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, [RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
DOI 10.17487/RFC5958, August 2010, <https://www.rfc- DOI 10.17487/RFC5958, August 2010,
editor.org/info/rfc5958>. <https://www.rfc-editor.org/info/rfc5958>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
Protocol (HTTP/1.1): Message Syntax and Routing", Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258,
2014, <https://www.rfc-editor.org/info/rfc7258>. May 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <https://www.rfc-editor.org/info/rfc7519>.
[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch, [RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
"PKCS #1: RSA Cryptography Specifications Version 2.2", "PKCS #1: RSA Cryptography Specifications Version 2.2",
RFC 8017, DOI 10.17487/RFC8017, November 2016, RFC 8017, DOI 10.17487/RFC8017, November 2016,
<https://www.rfc-editor.org/info/rfc8017>. <https://www.rfc-editor.org/info/rfc8017>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, RFC 2119 Key Words", BCP 14, RFC 8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224, Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, November 2017, <https://www.rfc- DOI 10.17487/RFC8224, February 2018,
editor.org/info/rfc8224>. <https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, November 2017, Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>. <https://www.rfc-editor.org/info/rfc8225>.
[X.509] International Telecommunication Union, "Information [X.509] International Telecommunication Union, "Information
technology - Open Systems Interconnection - The Directory: technology - Open Systems Interconnection - The Directory:
Public-key and attribute certificate frameworks", ITU-T Public-key and attribute certificate frameworks", ITU-T
Recommendation X.509, ISO/IEC 9594-8, October 2016, Recommendation X.509, ISO/IEC 9594-8, October 2016,
<https://www.itu.int/rec/T-REC-X.509>. <https://www.itu.int/rec/T-REC-X.509>.
[X.680] International Telecommunication Union, "Information [X.680] International Telecommunication Union, "Information
Technology - Abstract Syntax Notation One (ASN.1): Technology - Abstract Syntax Notation One (ASN.1):
skipping to change at page 19, line 39 skipping to change at page 20, line 21
[X.683] International Telecommunication Union, "Information [X.683] International Telecommunication Union, "Information
Technology - Abstract Syntax Notation One (ASN.1): Technology - Abstract Syntax Notation One (ASN.1):
Parameterization of ASN.1 specifications", ITU-T Parameterization of ASN.1 specifications", ITU-T
Recommendation X.683, ISO/IEC 8824-4, August 2015, Recommendation X.683, ISO/IEC 8824-4, August 2015,
<https://www.itu.int/rec/T-REC-X.683>. <https://www.itu.int/rec/T-REC-X.683>.
13.2. Informative References 13.2. Informative References
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, <https://www.rfc- DOI 10.17487/RFC2046, November 1996,
editor.org/info/rfc2046>. <https://www.rfc-editor.org/info/rfc2046>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003, <https://www.rfc- DOI 10.17487/RFC3647, November 2003,
editor.org/info/rfc3647>. <https://www.rfc-editor.org/info/rfc3647>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements", Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014, RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>. <https://www.rfc-editor.org/info/rfc7340>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model",
RFC 7375, DOI 10.17487/RFC7375, October 2014, RFC 7375, DOI 10.17487/RFC7375, October 2014,
<https://www.rfc-editor.org/info/rfc7375>. <https://www.rfc-editor.org/info/rfc7375>.
skipping to change at page 20, line 39 skipping to change at page 21, line 29
TN-Module-2016 TN-Module-2016
{ iso(1) identified-organization(3) dod(6) internet(1) security(5) { iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-tn-module(89) } mechanisms(5) pkix(7) id-mod(0) id-mod-tn-module(89) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS IMPORTS
id-ad, id-pe id-ad, id-pe
FROM PKIX1Explicit-2009 -- From [RFC5912] FROM PKIX1Explicit-2009 -- From RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1) security(5) { iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) }
EXTENSION EXTENSION
FROM PKIX-CommonTypes-2009 -- From [RFC5912] FROM PKIX-CommonTypes-2009 -- From RFC 5912
{ iso(1) identified-organization(3) dod(6) internet(1) security(5) { iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) }
; ;
-- --
-- JWT Claim Constraints Certificate Extension -- JWT Claim Constraints Certificate Extension
-- --
ext-jwtClaimConstraints EXTENSION ::= { ext-jwtClaimConstraints EXTENSION ::= {
SYNTAX JWTClaimConstraints IDENTIFIED BY id-pe-JWTClaimConstraints SYNTAX JWTClaimConstraints IDENTIFIED BY id-pe-JWTClaimConstraints
} }
id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 27 } id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 27 }
JWTClaimConstraints ::= SEQUENCE { JWTClaimConstraints ::= SEQUENCE {
mustInclude [0] JWTClaimNames OPTIONAL, mustInclude [0] JWTClaimNames OPTIONAL,
-- The listed claim names MUST appear in the PASSporT -- The listed claim names MUST appear in the PASSporT
-- in addition to iat, orig, and dest. If absent, iat, orig, -- in addition to iat, orig, and dest. If absent, iat, orig,
 End of changes. 31 change blocks. 
83 lines changed or deleted 77 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/