< draft-ietf-stir-certificates-14.txt		draft-ietf-stir-certificates-15.txt >
	STIR J. Peterson		Network Working Group J. Peterson
	Internet-Draft Neustar		Internet-Draft Neustar
	Intended status: Standards Track S. Turner		Intended status: Standards Track S. Turner
	Expires: November 10, 2017 sn3rd		Expires: May 20, 2018 sn3rd
	May 9, 2017		November 16, 2017
	Secure Telephone Identity Credentials: Certificates		Secure Telephone Identity Credentials: Certificates
	draft-ietf-stir-certificates-14		draft-ietf-stir-certificates-15
	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.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 10, 2017.		This Internet-Draft will expire on May 20, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 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		(http://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 . . . . . . . 3		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 . . . . . . . . . . . . 7		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 . . . . . . . . . . . . 8		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 . . . . . . . . . . . . . . . . 11
	10. Certificate Freshness and Revocation . . . . . . . . . . . . 13		10. Certificate Freshness and Revocation . . . . . . . . . . . . 13
	10.1. Acquiring TN Lists By Reference . . . . . . . . . . . . 14		10.1. Acquiring the TN List by Reference . . . . . . . . . . . 14
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 15		11.1. ASN.1 Registrations . . . . . . . . . . . . . . . . . . 15
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		11.2. Media Type Registrations . . . . . . . . . . . . . . . . 16
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15		12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	14.1. Normative References . . . . . . . . . . . . . . . . . . 16		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	14.2. Informative References . . . . . . . . . . . . . . . . . 17		13.1. Normative References . . . . . . . . . . . . . . . . . . 17
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18		13.2. Informative References . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20
			Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 22
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	The STIR problem statement [RFC7340] identifies the primary enabler		The Secure Telephone Identity Revisited (STIR) problem statement
	of robocalling, vishing, swatting and related attacks as the		[RFC7340] identifies the primary enabler of robocalling, vishing
	capability to impersonate a calling party number. The starkest		(voicemail hacking), swatting, and related attacks as the capability
	examples of these attacks are cases where automated callees on the		to impersonate a calling party number. The starkest examples of
	PSTN rely on the calling number as a security measure, for example to		these attacks are cases where automated callees on the Public
	access a voicemail system. Robocallers use impersonation as a means		Switched Telephone Network (PSTN) rely on the calling number as a
	of obscuring identity; while robocallers can, in the ordinary PSTN,		security measure -- for example, to access a voicemail system.
	block (that is, withhold) their caller identity, callees are less		Robocallers use impersonation as a means of obscuring identity.
	likely to pick up calls from blocked identities, and therefore		While robocallers can, in the ordinary PSTN, block (that is,
	appearing to call from some number, any number, is preferable.		withhold) their caller identity, callees are less likely to pick up
	Robocallers however prefer not to call from a number that can trace		calls from blocked identities; therefore, appearing to call from some
	back to the robocaller, and therefore they impersonate numbers that		number, any number, is preferable. Robocallers, however, prefer not
	are not assigned to them.		to call from a number that can trace back to the robocaller, and
			therefore they impersonate numbers that are not assigned to them.
	One of the most important components of a system to prevent		One of the most important components of a system to prevent
	impersonation is the implementation of credentials which identify the		impersonation is the implementation of credentials that identify the
	parties who control telephone numbers. With these credentials,		parties who control telephone numbers. With these credentials,
	parties can assert that they are in fact authorized to use telephony		parties can assert that they are in fact authorized to use telephony
	numbers, and thus distinguish themselves from impersonators unable to		numbers (TNs), and thus they distinguish themselves from
	present such credentials. For that reason the STIR threat model		impersonators unable to present such credentials. For that reason,
	[RFC7375] stipulates, "The design of the credential system envisioned		the STIR threat model [RFC7375] stipulates that "The design of the
	as a solution to these threats must, for example, limit the scope of		credential system envisioned as a solution to these threats must, for
	the credentials issued to carriers or national authorities to those		example, limit the scope of the credentials issued to carriers or
	numbers that fall under their purview." This document describes		national authorities to those numbers that fall under their purview."
	credential systems for telephone numbers based on [X.509] version 3		This document describes credential systems for telephone numbers
	certificates in accordance with [RFC5280]. While telephone numbers		based on [X.509] version 3 certificates in accordance with [RFC5280].
	have long been part of the X.509 standard (X.509 supports arbitrary		While telephone numbers have long been part of the X.509 standard
	naming attributes to be included in a certificate; the		(X.509 supports arbitrary naming attributes to be included in a
	telephoneNumber attribute was defined in the 1988 [X.520]		certificate; the telephoneNumber attribute was defined in the 1988
	specification) this document provides ways to determine authority		[X.520] specification), this document provides ways to determine
	more aligned with telephone network requirements, including extending		authority more aligned with telephone network requirements, including
	X.509 with a Telephone Number Authorization List certificate		extending X.509 with a Telephony Number Authorization List
	extension which binds certificates to asserted authority for		certificate extension, which binds certificates to asserted authority
	particular telephone numbers, or potentially telephone number blocks		for particular telephone numbers or, potentially, telephone number
	or ranges.		blocks or ranges.
	In the STIR in-band architecture specified in		In the STIR in-band architecture specified in [RFC8224], two basic
	[I-D.ietf-stir-rfc4474bis], two basic types of entities need access		types of entities need access to these credentials: authentication
	to these credentials: authentication services, and verification		services and verification services (or verifiers). An authentication
	services (or verifiers). An authentication service must be operated		service must be operated by an entity enrolled with the certification
	by an entity enrolled with the certification authority (CA, see		authority (CA) (see Section 5), whereas a verifier need only trust
	Section 5), whereas a verifier need only trust the trust anchor of		the trust anchor of the authority and also have a means to access and
	the authority, and have a means to access and validate the public		validate the public keys associated with these certificates.
	keys associated with these certificates. Although the guidance in		Although the guidance in this document is written with the STIR
	this document is written with the STIR in-band architecture in mind,		in-band architecture in mind, the credential system described in this
	the credential system described in this document could be useful for		document could be useful for other protocols that want to make use of
	other protocols that want to make use of certificates to assert		certificates to assert authority over telephone numbers on the
	authority over telephone numbers on the Internet.		Internet.
	This document specifies only the credential syntax and semantics		This document specifies only the credential syntax and semantics
	necessary to support this architecture. It does not assume any		necessary to support this architecture. It does not assume any
	particular CA or deployment environment. We anticipate that some		particular CA or deployment environment. We anticipate that some
	deployment experience will be necessary to determine optimal		deployment experience will be necessary to determine optimal
	operational models.		operational models.
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in RFC		"OPTIONAL" in this document are to be interpreted as described in
	2119 [RFC2119].		BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
			capitals, as shown here.
	3. Authority for Telephone Numbers in Certificates		3. Authority for Telephone Numbers in Certificates
	At a high level, this specification details two non-exclusive		At a high level, this specification details two non-exclusive
	approaches that can be employed to determine authority over telephone		approaches that can be employed to determine authority over telephone
	numbers with certificates.		numbers with certificates.
	The first approach is to leverage the existing subject of the		The first approach is to leverage the existing subject of the
	certificate to ascertain that the holder of the certificate is		certificate to ascertain that the holder of the certificate is
	authorized to claim authority over a telephone number. The subject		authorized to claim authority over a telephone number. The subject
	might be represented as a domain name in the subjectAltName, such as		might be represented as a domain name in the subjectAltName, such as
	an "example.net" where that domain is known to relying parties as a		an "example.net" where that domain is known to relying parties as a
	carrier, or represented with other identifiers related to the		carrier, or represented with other identifiers related to the
	operation of the telephone network including Service Provider codes		operation of the telephone network, including Service Provider Codes
	(SPCs) such as OCNs or SPIDs via the TN Authorization List specified		(SPCs) such as Operating Company Numbers (OCNs) or Service Provider
	in this document. A relying party could then employ an external data		Identifiers (SPIDs) via the TN Authorization List specified in this
	set or service that determines whether or not a specific telephone		document. A relying party could then employ an external data set or
	number is under the authority of the carrier identified as the		service that determines whether or not a specific telephone number is
	subject of the certificate, and use that to ascertain whether or not		under the authority of the carrier identified as the subject of the
	the carrier should have authority over a telephone number.		certificate and use that to ascertain whether or not the carrier
	Potentially, a certificate extension to convey the URI of such an		should have authority over a telephone number. Potentially, a
	information service trusted by the issuer of the certificate could be		certificate extension to convey the URI of such an information
	developed (though this specification does not propose one).		service trusted by the issuer of the certificate could be developed
	Alternatively, some relying parties could form bilateral or		(though this specification does not propose one). Alternatively,
	multilateral trust relationships with peer carriers, trusting one		some relying parties could form bilateral or multilateral trust
	another's assertions just as telephone carriers in the SS7 network		relationships with peer carriers, trusting one another's assertions
			just as telephone carriers in the Signaling System 7 (SS7) network
	today rely on transitive trust when displaying the calling party		today rely on transitive trust when displaying the calling party
	telephone number received through SS7 signaling.		telephone number received through SS7 signaling.
	The second approach is to extend the syntax of certificates to		The second approach is to extend the syntax of certificates to
	include a new attribute, defined here as TN Authorization List, which		include a new attribute, defined here as the TN Authorization List,
	contains a list of telephone numbers defining the scope of authority		which contains a list of telephone numbers defining the scope of
	of the certificate. Relying parties, if they trust the issuer of the		authority of the certificate. Relying parties, if they trust the
	certificate as a source of authoritative information on telephone		issuer of the certificate as a source of authoritative information on
	numbers, could therefore use the TN Authorization List instead of the		telephone numbers, could therefore use the TN Authorization List
	subject of the certificate to make a decision about whether or not		instead of the subject of the certificate to make a decision about
	the signer has authority over a particular telephone number. The TN		whether or not the signer has authority over a particular telephone
	Authorization List could be provided in one of two ways: as a literal		number. The TN Authorization List could be provided in one of two
	value in the certificate, or as a network service that allows relying		ways: as a literal value in the certificate or as a network service
	parties to query in real time to determine that a telephone number is		that allows relying parties to query in real time to determine that a
	in the scope of a certificate. Using the TN Authorization list		telephone number is in the scope of a certificate. Using the TN
	rather than the certificate subject makes sense when, for example,		Authorization List rather than the certificate subject makes sense
	for privacy reasons, the certificate owner would prefer not to be		when, for example, for privacy reasons the certificate owner would
	identified, or in cases where the holder of the certificate does not		prefer not to be identified, or in cases where the holder of the
	participate in the sort of traditional carrier infrastructure that		certificate does not participate in the sort of traditional carrier
	the first approach assumes.		infrastructure that the first approach assumes.
	The first approach requires little change to existing Public Key		The first approach requires little change to existing Public Key
	Infrastructure (PKI) certificates; for the second approach, we must		Infrastructure (PKI) certificates; for the second approach, we must
	define an appropriate enrollment and authorization process. For the		define an appropriate enrollment and authorization process. For the
	purposes of STIR, the over-the-wire format specified in		purposes of STIR, the over-the-wire format specified in [RFC8224]
	[I-D.ietf-stir-rfc4474bis] accommodates either of these approaches:		accommodates either of these approaches: the methods for
	the methods for canonicalizing, signing, for identifying and		canonicalizing, for signing, for identifying and accessing the
	accessing the certificate and so on remain the same; it is only the		certificate, and so on remain the same; it is only the verifier
	verifier behavior and authorization decision that will change		behavior and authorization decision that will change, depending on
	depending on the approach to telephone number authority taken by the		the approach to telephone number authority taken by the certificate.
	certificate. For that reason, the two approaches are not mutually		For that reason, the two approaches are not mutually exclusive, and
	exclusive, and in fact a certificate issued to a traditional		in fact a certificate issued to a traditional telephone network
	telephone network service provider could contain a TN Authorization		service provider could contain a TN Authorization List or not, were
	List or not, were it supported by the CA issuing the credential.		it supported by the CA issuing the credential. Regardless of which
	Regardless of which approach is used, certificates that assert		approach is used, certificates that assert authority over telephone
	authority over telephone numbers are subject to the ordinary		numbers are subject to the ordinary operational procedures that
	operational procedures that govern certificate use per [RFC5280].		govern certificate use per [RFC5280]. This means that verification
	This means that verification services must be mindful of the need to		services must be mindful of the need to ensure that they trust the
	ensure that they trust the trust anchor that issued the certificate,		trust anchor that issued the certificate and that they have some
	and that they have some means to determine the freshness of the		means to determine the freshness of the certificate (see Section 10).
	certificate (see Section 10).
	4. Certificate Usage with STIR		4. Certificate Usage with STIR
	[I-D.ietf-stir-rfc4474bis] Section 7.4 requires that all credential		[RFC8224], Section 7.4 requires that all credential systems used by
	systems used by STIR explain how they address the requirements		STIR explain how they address the requirements enumerated below.
	enumerated below. Certificates as described in this document address		Certificates as described in this document address the STIR
	the STIR requirements as follows:		requirements as follows:
	1. The URI [RFC3986] schemes permitted in the SIP Identity header		1. The URI [RFC3986] schemes permitted in the SIP Identity header
	"info" parameter, as well as any special procedures required to		"info" parameter, as well as any special procedures required to
	dereference the URIs: while normative text is given below in		dereference the URIs: while normative text is given below in
	Section 7, this mechanism permits the HTTP [RFC7230], CID and SIP		Section 7, this mechanism permits the HTTP [RFC7230], CID
	URI schemes to appear in the "info" parameter.		(Content-ID) [RFC2392], and SIP URI schemes to appear in the
			"info" parameter.
	2. Procedures required to extract keying material from the resources		2. Procedures required to extract keying material from the resources
	designated by the URI: implementations perform no special		designated by the URI: implementations perform no special
	procedures beyond dereferencing the "info" URI. See Section 7.		procedures beyond dereferencing the "info" URI. See Section 7.
	3. Procedures used by the verification service to determine the		3. Procedures used by the verification service to determine the
	scope of the credential: this specification effectively proposes		scope of the credential: this specification effectively proposes
	two methods, as outlined in Section 3: one where the subject (or		two methods, as outlined in Section 3: one where the subject (or,
	more properly subjectAltName) of the certificate indicates the		more properly, subjectAltName) of the certificate indicates the
	scope of authority through a domain name, and relying parties		scope of authority through a domain name, and relying parties
	either trust the subject entirely or have some direct means of		either trust the subject entirely or have some direct means of
	determining whether or not a number falls under a subject's		determining whether or not a number falls under a subject's
	authority; and another where an extension to the certificate as		authority; and another where an extension to the certificate as
	described in Section 9 identifies the scope of authority of the		described in Section 9 identifies the scope of authority of the
	certificate.		certificate.
	4. The cryptographic algorithms required to validate the		4. The cryptographic algorithms required to validate the
	credentials: for this specification, that means the signature		credentials: for this specification, that means the signature
	algorithms used to sign certificates. This specification		algorithms used to sign certificates. This specification
	REQUIRES that implementations support both ECDSA with the P-256		REQUIRES that implementations support both the Elliptic Curve
	curve (see [DSS]) and RSA PKCS#1 v1.5 (see [RFC3447] Section 8.2)		Digital Signature Algorithm (ECDSA) with the P-256 curve (see
	for certificate signatures. Implementers are advised that RS256		[DSS]) and RSA PKCS #1 v1.5 ("PKCS" stands for "Public-Key
	is mandated only as a transitional mechanism, due to its		Cryptography Standards") (see [RFC8017], Section 8.2) for
	widespread use in existing PKI, but we anticipate that this		certificate signatures. Implementers are advised that RS256 is
	mechanism will eventually be deprecated.		mandated only as a transitional mechanism, due to its widespread
			use in existing PKIs, but we anticipate that this mechanism will
			eventually be deprecated.
	5. Finally, note that all certificates compliant with this		5. Finally, note that all certificates compliant with this
	specification:		specification:
	* MUST provide cryptographic keying material sufficient to		* MUST provide cryptographic keying material sufficient to
	generate the ECDSA using P-256 and SHA-256 signatures		generate the ECDSA using P-256 and SHA-256 signatures
	necessary to support the ES256 hashed signatures required by		necessary to support the ES256 hashed signatures required by
	PASSporT [I-D.ietf-stir-passport], which in turn follows JSON		PASSporT [RFC8225], which in turn follows the JSON Web Token
	Web Token (JWT) [RFC7519].		(JWT) [RFC7519].
	* MUST support both ECDSA with P-256 and RSA PKCS#1 v1.5 for		* MUST support both ECDSA with P-256 and RSA PKCS #1 v1.5 for
	certificate signature verification.		certificate signature verification.
	This document also includes additional certificate-related		This document also includes additional certificate-related
	requirements:		requirements:
	o See Section 5.1 for requirements related to the certificate		o See Section 5.1 for requirements related to the JWT Claim
	policies extension.		Constraints certificate extension.
	o See Section 7 for requirements related to relying parties		o See Section 7 for requirements related to relying parties
	acquiring credentials.		acquiring credentials.
	o See Section 10 and Section 10.1 for requirements related to		o See Sections 10 and 10.1 for requirements related to certificate
	certificate freshness and the Authority Information Access (AIA)		freshness and the Authority Information Access (AIA) certificate
	certificate extension.		extension.
	5. Enrollment and Authorization using the TN Authorization List		5. Enrollment and Authorization Using the TN Authorization List
	This document covers three models for enrollment when using the TN		This document covers three models for enrollment when using the TN
	Authorization List extension.		Authorization List extension.
	The first enrollment model is one where the CA acts in concert with		The first enrollment model is one where the CA acts in concert with
	national numbering authorities to issue credentials to those parties		national numbering authorities to issue credentials to those parties
	to whom numbers are assigned. In the United States, for example,		to whom numbers are assigned. In the United States, for example,
	telephone number blocks are assigned to Local Exchange Carriers		telephone number blocks are assigned to Local Exchange Carriers
	(LECs) by the North American Numbering Plan Administrator (NANPA),		(LECs) by the North American Numbering Plan Administration (NANPA),
	who is in turn directed by the national regulator. LECs may also		who is in turn directed by the national regulator. LECs may also
	receive numbers in smaller allocations, through number pooling, or		receive numbers in smaller allocations, through number pooling, or
	via an individual assignment through number portability. LECs assign		via an individual assignment through number portability. LECs assign
	numbers to customers, who may be private individuals or organizations		numbers to customers, who may be private individuals or organizations
	- and organizations take responsibility for assigning numbers within		-- and organizations take responsibility for assigning numbers within
	their own enterprise. This model requires top-down adoption of the		their own enterprise. This model requires top-down adoption of the
	model from regulators through to carriers. Assignees of E.164		model from regulators through to carriers. Assignees of E.164
	numbering resources participating in this enrollment model should		numbering resources participating in this enrollment model should
	take appropriate steps to establish trust anchors.		take appropriate steps to establish trust anchors.
	The second enrollment model is a bottom-up approach where a CA		The second enrollment model is a bottom-up approach where a CA
	requires that an entity prove control by means of some sort of test,		requires that an entity prove control by means of some sort of test
	which, as with certification authorities for web PKI, might either be		that, as with certification authorities for web PKI, might either be
	automated or a manual administrative process. As an example of an		(1) automated or (2) a manual administrative process. As an example
	automated process, an authority might send a text message to a		of an automated process, an authority might send a text message to a
	telephone number containing a URL (which might be dereferenced by the		telephone number containing a URL (which might be dereferenced by the
	recipient) as a means of verifying that a user has control of		recipient) as a means of verifying that a user has control of a
	terminal corresponding to that number. Checks of this form are		terminal corresponding to that number. Checks of this form are
	frequently used in commercial systems today to validate telephone		frequently used in commercial systems today to validate telephone
	numbers provided by users. This is comparable to existing enrollment		numbers provided by users. This is comparable to existing enrollment
	systems used by some certificate authorities for issuing S/MIME		systems used by some certificate authorities for issuing S/MIME
	credentials for email by verifying that the party applying for a		credentials for email by verifying that the party applying for a
	credential receives mail at the email address in question.		credential receives mail at the email address in question.
	The third enrollment model is delegation: that is, the holder of a		The third enrollment model is delegation: that is, the holder of a
	certificate (assigned by either of the two methods above) might		certificate (assigned by either of the two methods above) might
	delegate some or all of their authority to another party. In some		delegate some or all of their authority to another party. In some
	skipping to change at page 7, line 37 ¶		skipping to change at page 7, line 45 ¶
	traditional hierarchical PKIs who use the name constraints extension		traditional hierarchical PKIs who use the name constraints extension
	[RFC5280]; the root CA delegates names in sales to the sales		[RFC5280]; the root CA delegates names in sales to the sales
	department CA, names in development to the development CA, etc. As		department CA, names in development to the development CA, etc. As
	lengthy certificate delegation chains are brittle, however, and can		lengthy certificate delegation chains are brittle, however, and can
	cause delays in the verification process, this document considers		cause delays in the verification process, this document considers
	optimizations to reduce the complexity of verification.		optimizations to reduce the complexity of verification.
	Future work might explore methods of partial delegation, where		Future work might explore methods of partial delegation, where
	certificate holders delegate only part of their authority. For		certificate holders delegate only part of their authority. For
	example, individual assignees may want to delegate to a service		example, individual assignees may want to delegate to a service
	authority for text messages associated with their telephone number,		authority for text messages associated with their telephone number
	but not for other functions.		but not for other functions.
	5.1. Constraints on Signing PASSporTs		5.1. Constraints on Signing PASSporTs
	The public key in the certificate is used to validate the signature		The public key in the certificate is used to validate the signature
	on a JSON Web Token (JWT) [RFC7519] that conforms to the conventions		on a JWT [RFC7519] that conforms to the conventions specified in
	specified in PASSporT [I-D.ietf-stir-passport]. This specification		PASSporT [RFC8225]. This specification supports constraints on the
	supports constraints on the JWT claims, which allows the CA to grant		JWT claims, thereby allowing the CA to grant different permissions to
	different permissions to certificate holders, for example those		certificate holders -- for example, those enrolled from
	enrolled from proof-of-possession versus delegation. A Certification		proof-of-possession versus delegation. A Certificate Policy (CP) and
	Policy and a Certification Practice Statement [RFC3647] are produced		a Certification Practice Statement (CPS) [RFC3647] are produced as
	as part of the normal PKI bootstrapping process, (i.e., the CP is		part of the normal PKI bootstrapping process (i.e., the CP is written
	written first and then the CA says how it conforms to the CP in the		first, and then the CA says how it conforms to the CP in the CPS). A
	CPS). A CA that wishes to place constraints on the JWT claims MUST		CA that wishes to place constraints on the JWT claims MUST include
	include the JWT Claim Constraints certificate extension in issued		the JWT Claim Constraints certificate extension in issued
	certificates. See Section 8 for information about the certificate		certificates. See Section 8 for information about the certificate
	extension.		extension.
	5.2. Certificate Extension Scope and Structure		5.2. Certificate Extension Scope and Structure
	This specification places no limits on the number of telephone		This specification places no limits on the number of telephone
	numbers that can be associated with any given certificate. Some		numbers that can be associated with any given certificate. Some
	service providers may be assigned millions of numbers, and may wish		service providers may be assigned millions of numbers and may wish to
	to have a single certificate that can be applied to signing for any		have a single certificate that can be applied to signing for any one
	one of those numbers. Others may wish to compartmentalize authority		of those numbers. Others may wish to compartmentalize authority over
	over subsets of the numbers they control.		subsets of the numbers they control.
	Moreover, service providers may wish to have multiple certificates		Moreover, service providers may wish to have multiple certificates
	with the same scope of authority. For example, a service provider		with the same scope of authority. For example, a service provider
	with several regional gateway systems may want each system to be		with several regional gateway systems may want each system to be
	capable of signing for each of their numbers, but not want to have		capable of signing for each of their numbers but not want to have
	each system share the same private key.		each system share the same private key.
	The set of telephone numbers for which a particular certificate is		The set of telephone numbers for which a particular certificate is
	valid is expressed in the certificate through a certificate		valid is expressed in the certificate through a certificate
	extension; the certificate's extensibility mechanism is defined in		extension; the certificate's extensibility mechanism is defined in
	[RFC5280] but the TN Authorization List extension is specified in		[RFC5280], but the TN Authorization List extension is specified in
	this document.		this document.
	The subjects of certificates containing the TN Authorization List		The subjects of certificates containing the TN Authorization List
	extension are typically the administrative entities to whom numbers		extension are typically the administrative entities to whom numbers
	are assigned or delegated. For example, a LEC might hold a		are assigned or delegated. For example, a LEC might hold a
	certificate for a range of telephone numbers. In some cases, the		certificate for a range of telephone numbers. In some cases, the
	organization or individual issued such a certificate may not want to		organization or individual issued such a certificate may not want to
	associate themselves with a certificate; for example, a private		associate themselves with a certificate; for example, a private
	individual with a certificate for a single telephone number might not		individual with a certificate for a single telephone number might not
	want to distribute that certificate publicly if every verifier		want to distribute that certificate publicly if every verifier
	immediately knew their name. The certification authorities issuing		immediately knew their name. The certification authorities issuing
	certificates with the TN Authorization List extensions may, in		certificates with the TN Authorization List extensions may, in
	accordance with their policies, obscure the identity of the subject,		accordance with their policies, obscure the identity of the subject,
	though mechanisms for doing so are outside the scope of this		though mechanisms for doing so are outside the scope of this
	document.		document.
	6. Provisioning Private Keying Material		6. Provisioning Private Keying Material
	In order for authentication services to sign calls via the procedures		In order for authentication services to sign calls via the procedures
	described in [I-D.ietf-stir-rfc4474bis], they must hold a private key		described in [RFC8224], they must hold a private key corresponding to
	corresponding to a certificate with authority over the calling		a certificate with authority over the calling number. [RFC8224]
	number. [I-D.ietf-stir-rfc4474bis] does not require that any		does not require that any particular entity in a SIP deployment
	particular entity in a SIP deployment architecture sign requests,		architecture sign requests, only that it be an entity with an
	only that it be an entity with an appropriate private key; the		appropriate private key; the authentication service role may be
	authentication service role may be instantiated by any entity in a		instantiated by any entity in a SIP network. For a certificate
	SIP network. For a certificate granting authority only over a		granting authority only over a particular number that has been issued
	particular number which has been issued to an end user, for example,		to an end user, for example, an end-user device might hold the
	an end user device might hold the private key and generate the		private key and generate the signature. In the case of a service
	signature. In the case of a service provider with authority over		provider with authority over large blocks of numbers, an intermediary
	large blocks of numbers, an intermediary might hold the private key		might hold the private key and sign calls.
	and sign calls.
	The specification RECOMMENDS distribution of private keys through		The specification RECOMMENDS distribution of private keys through
	PKCS#8 objects signed by a trusted entity, for example through the		PKCS #8 objects signed by a trusted entity -- for example, through
	CMS package specified in [RFC5958].		the Cryptographic Message Syntax (CMS) package specified in
			[RFC5958].
	7. Acquiring Credentials to Verify Signatures		7. Acquiring Credentials to Verify Signatures
	This specification documents multiple ways that a verifier can gain		This specification documents multiple ways that a verifier can gain
	access to the credentials needed to verify a request. As the		access to the credentials needed to verify a request. As the
	validity of certificates does not depend on the method of their		validity of certificates does not depend on the method of their
	acquisition, there is no need to standardize any single mechanism for		acquisition, there is no need to standardize any single mechanism for
	this purpose. All entities that comply with		this purpose. All entities that comply with [RFC8224] necessarily
	[I-D.ietf-stir-rfc4474bis] necessarily support SIP, and consequently		support SIP, and consequently SIP itself can serve as a way to
	SIP itself can serve as a way to deliver certificates.		deliver certificates. [RFC8224] provides an "info" parameter of the
	[I-D.ietf-stir-rfc4474bis] provides an "info" parameter of the		Identity header; this parameter contains a URI for the credential
	Identity header which contains a URI for the credential used to		used to generate the Identity header. [RFC8224] also requires that
	generate the Identity header; [I-D.ietf-stir-rfc4474bis] also		documents that define credential systems list the URI schemes that
	requires documents which define credential systems list the URI		may be present in the "info" parameter. For implementations
	schemes that may be present in the "info" parameter. For		compliant with this specification, three URI schemes are REQUIRED:
	implementations compliant with this specification, three URI schemes		the CID URI, the SIP URI, and the HTTP URI.
	are REQUIRED: the CID URI, the SIP URI, and the HTTP URI.
	The simplest way for a verifier to acquire the certificate needed to		The simplest way for a verifier to acquire the certificate needed to
	verify a signature is for the certificate be conveyed in a SIP		verify a signature is for the certificate to be conveyed in a
	request along with the signature itself. In SIP, for example, a		SIP request along with the signature itself. In SIP, for example, a
	certificate could be carried in a multipart MIME body [RFC2046], and		certificate could be carried in a multipart MIME body [RFC2046], and
	the URI in the Identity header "info" parameter could specify that		the URI in the Identity header "info" parameter could specify that
	body with a CID URI [RFC2392]. However, in many environments this is		body with a CID URI [RFC2392]. However, in many environments this
	not feasible due to message size restrictions or lack of necessary		is not feasible due to message size restrictions or lack of necessary
	support for multipart MIME.		support for multipart MIME.
	The Identity header "info" parameter in a SIP request may contain a		The Identity header "info" parameter in a SIP request may contain a
	URI that the verifier dereferences. Implementations of this		URI that the verifier dereferences. Implementations of this
	specification are REQUIRED to support the use of SIP for this		specification are REQUIRED to support the use of SIP for this
	function (via the SUBSCRIBE/NOTIFY mechanism) as well as HTTP and		function (via the SUBSCRIBE/NOTIFY mechanism) as well as HTTP and
	HTTPS.		HTTPS.
	Note well that as an optimization, a verifier may have access to a		Note well that as an optimization, a verifier may have access to a
	service, a cache or other local store that grants access to		service, a cache, or other local store that grants access to
	certificates for a particular telephone number. However, there may		certificates for a particular telephone number. However, there may
	be multiple valid certificates that can sign a call setup request for		be multiple valid certificates that can sign a call setup request for
	a telephone number, and as a consequence, there needs to be some		a telephone number, and as a consequence, there needs to be some
	discriminator that the signer uses to identify their credentials.		discriminator that the signer uses to identify their credentials.
	The Identity header "info" parameter itself can serve as such a		The Identity header "info" parameter itself can serve as such a
	discriminator, provided implementations use that parameter as a key		discriminator, provided implementations use that parameter as a key
	when accessing certificates from caches or other sources.		when accessing certificates from caches or other sources.
	8. JWT Claim Constraints Syntax		8. JWT Claim Constraints Syntax
	Certificate subjects are limited to specific values for PASSporT		Certificate subjects are limited to specific values for PASSporT
	claims with the JWT Claim Constraints certificate extension; issuers		claims with the JWT Claim Constraints certificate extension; issuers
	permit all claims by omitting the JWT Claim Constraints certificate		permit all claims by omitting the JWT Claim Constraints certificate
	extension from the certificate's extension field [RFC5280]. The		extension from the certificate's extension field [RFC5280]. The
	extension is non-critical, applicable only to end-entity		extension is non-critical, applicable only to end-entity
	certificates, and defined with ASN.1 [X.680][X.681][X.682][X.683]		certificates, and defined with ASN.1 [X.680] [X.681] [X.682] [X.683]
	later in this section. The syntax of the claims is given in		later in this section. The syntax of the claims is given in
	PASSporT; specifying new claims follows the procedures in		PASSporT; specifying new claims follows the procedures in [RFC8225],
	[I-D.ietf-stir-passport] (Section 8.3).		Section 8.3.
	This certificate extension is optional, but if present, it constrains		This certificate extension is optional, but if present, it constrains
	the claims that authentication services may include in the PASSporT		the claims that authentication services may include in the PASSporT
	objects they sign. Constraints are applied by issuers and enforced		objects they sign. Constraints are applied by issuers and enforced
	by verifiers when validating PASSporT claims as follows:		by verifiers when validating PASSporT claims as follows:
	1. mustInclude indicates claims that MUST appear in the PASSporT in		1. mustInclude indicates claims that MUST appear in the PASSporT in
	addition to iat, orig, and dest. The baseline claims of PASSporT		addition to iat, orig, and dest. The baseline claims of PASSporT
	("iat", "orig", and "dest") are considered to be permitted by		("iat", "orig", and "dest") are considered to be permitted by
	default and SHOULD NOT be included. If mustInclude is absent,		default and SHOULD NOT be included. If mustInclude is absent,
	skipping to change at page 10, line 42 ¶		skipping to change at page 11, line 5 ¶
	2. permittedValues indicates that if the claim name is present, the		2. permittedValues indicates that if the claim name is present, the
	claim MUST contain one of the listed values.		claim MUST contain one of the listed values.
	Consider two examples with a PASSporT claim called "confidence" with		Consider two examples with a PASSporT claim called "confidence" with
	values "low", "medium", and "high":		values "low", "medium", and "high":
	o If a CA issues to an authentication service a certificate that		o If a CA issues to an authentication service a certificate that
	contains the mustInclude JWTClaimName "confidence", then an		contains the mustInclude JWTClaimName "confidence", then an
	authentication service MUST include the "confidence" claim in all		authentication service MUST include the "confidence" claim in all
	PASSporTs it generates; a verification service will treat as		PASSporTs it generates; a verification service will treat as
	invalid any PASSporT it receives with a PASSporT claim that does		invalid any PASSporT it receives with a PASSporT claim that
	not include the "confidence" claim.		does not include the "confidence" claim.
	o If a CA issues to an authentication service a certificate that		o If a CA issues to an authentication service a certificate that
	contains the permittedValues JWTClaimName "confidence" and a		contains the permittedValues JWTClaimName "confidence" and a
	permitted "high" value, then an authentication service will treat		permitted "high" value, then an authentication service will treat
	as invalid any PASSporT it receives with a PASSporT claim that		as invalid any PASSporT it receives with a PASSporT claim that
	does not include the "confidence" claim with a "high" value.		does not include the "confidence" claim with a "high" value.
	The JWT Claim Constraints certificate extension is identified by the		The JWT Claim Constraints certificate extension is identified by the
	following object identifier (OID), which is defined under the id-pe		following object identifier (OID), which is defined under the id-pe
	OID arc defined in [RFC5280] and managed by IANA (see Section 11):		OID arc defined in [RFC5280] and managed by IANA (see Section 11):
	id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 25 }		id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 27 }
	The JWT Claim Constraints certificate extension has the following		The JWT Claim Constraints certificate extension has the following
	syntax:		syntax:
	JWTClaimConstraints ::= SEQUENCE {		JWTClaimConstraints ::= SEQUENCE {
	mustInclude [0] JWTClaimNames OPTIONAL,		mustInclude [0] JWTClaimNames OPTIONAL,
	-- The listed claim names MUST appear in the PASSporT in addition		-- The listed claim names MUST appear in the PASSporT
	-- to iat, orig, and dest. If absent, iat, orig, and dest MUST		-- in addition to iat, orig, and dest. If absent, iat, orig,
	-- appear in the PASSporT.		-- and dest MUST appear in the PASSporT.
	permittedValues [1] JWTClaimPermittedValuesList OPTIONAL }		permittedValues [1] JWTClaimPermittedValuesList OPTIONAL }
	-- If the claim name is present, the claim MUST contain one of		-- If the claim name is present, the claim MUST contain one of
	-- the listed values.		-- the listed values.
	( WITH COMPONENTS { ..., mustInclude PRESENT } |		( WITH COMPONENTS { ..., mustInclude PRESENT } |
	WITH COMPONENTS { ..., permittedValues PRESENT } )		WITH COMPONENTS { ..., permittedValues PRESENT } )
	JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) OF		JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) OF
	JWTClaimPermittedValues		JWTClaimPermittedValues
	JWTClaimPermittedValues ::= SEQUENCE {		JWTClaimPermittedValues ::= SEQUENCE {
	claim JWTClaimName,		claim JWTClaimName,
	permitted SEQUENCE SIZE (1..MAX) OF UTF8String }		permitted SEQUENCE SIZE (1..MAX) OF UTF8String }
	JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName		JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName
	JWTClaimName ::= IA5String		JWTClaimName ::= IA5String
	9. TN Authorization List Syntax		9. TN Authorization List Syntax
	The subjects of certificates containing the TN Authorization List		The subjects of certificates containing the TN Authorization List
	extension are the administrative entities to whom numbers are		extension are the administrative entities to whom numbers are
	assigned or delegated. When a verifier is validating a caller's		assigned or delegated. When a verifier is validating a caller's
	identity, local policy always determines the circumstances under		identity, local policy always determines the circumstances under
	which any particular subject may be trusted, but the purpose of the		which any particular subject may be trusted, but the purpose of the
	TN Authorization List extension in particular is to allow a verifier		TN Authorization List extension in particular is to allow a verifier
	to ascertain when the CA has designated that the subject has		to ascertain when the CA has designated that the subject has
	authority over a particular telephone number or number range. The		authority over a particular telephone number or number range. The
	non critical Telephony Number (TN) Authorization List certificate		non-critical TN Authorization List certificate extension is included
	extension is included in the Certificate's extension field [RFC5280].		in the certificate's extension field [RFC5280]. The extension is
	The extension is defined with ASN.1 [X.680][X.681][X.682] [X.683].		defined with ASN.1 [X.680] [X.681] [X.682] [X.683]. The syntax and
	What follows is the syntax and semantics of the extension.		semantics of the extension are as follows.
	The subjects of certificates containing the TN Authorization List		The subjects of certificates containing the TN Authorization List
	extension are the administrative entities to whom numbers are		extension are the administrative entities to whom numbers are
	assigned or delegated. In an end entity certificate, TN		assigned or delegated. In an end-entity certificate, the TN
	Authorization List indicates the TNs which the certificate has been		Authorization List indicates the TNs that it has authorized. In a CA
	authorized. In a CA certificate, the TN Authorization List limits		certificate, the TN Authorization List limits the set of TNs for
	the set of TNs for certification paths that include this certificate.		certification paths that include this certificate.
	The Telephony Number (TN) Authorization List certificate extension is		The TN Authorization List certificate extension is identified by the
	identified by the following object identifier (OID), which is defined		following object identifier (OID), which is defined under the id-pe
	under the id-pe OID arc defined in [RFC5280] and managed by IANA (see		OID arc defined in [RFC5280] and managed by IANA (see Section 11):
	Section 11):
	id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 }		id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 }
	The TN Authorization List certificate extension has the following		The TN Authorization List certificate extension has the following
	syntax:		syntax:
	TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry		TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
	TNEntry ::= CHOICE {		TNEntry ::= CHOICE {
	spc [0] ServiceProviderCode,		spc [0] ServiceProviderCode,
	range [1] TelephoneNumberRange,		range [1] TelephoneNumberRange,
	one [2] TelephoneNumber		one [2] TelephoneNumber
	}		}
	ServiceProviderCode ::= IA5String		ServiceProviderCode ::= IA5String
	-- Service Provider Codes may be OCNs, various SPIDs, or other		-- SPCs may be OCNs, various SPIDs, or other SP identifiers
	-- SP identifiers from the telephone network		-- from the telephone network.
	TelephoneNumberRange ::= SEQUENCE {		TelephoneNumberRange ::= SEQUENCE {
	start TelephoneNumber,		start TelephoneNumber,
	count INTEGER (2..MAX)		count INTEGER (2..MAX),
			...
	}		}
	TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789#*"))		TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789#*"))
	The TN Authorization List certificate extension indicates the		The TN Authorization List certificate extension indicates the
	authorized phone numbers for the call setup signer. It indicates one		authorized phone numbers for the call setup signer. It indicates one
	or more blocks of telephone number entries that have been authorized		or more blocks of telephone number entries that have been authorized
	for use by the call setup signer. There are three ways to identify		for use by the call setup signer. There are three ways to identify
	the block:		the block:
	1. Service Provider Codes as described in this document are a		1. SPCs as described in this document are a generic term for the
	generic term for the identifiers used to designate service		identifiers used to designate service providers in telephone
	providers in the telepohone networks today. In North American		networks today. In North American context, these would include
	context, these would include Operating Company Numbers (OCNs) as		OCNs as specified in [ATIS-0300251], related SPIDs, or other
	specified in [ATIS-0300251], related Service Provide Identifiers		similar identifiers for service providers. SPCs can be used to
	(SPIDs), or other similar identifiers for service providers.		indirectly name all of the telephone numbers associated with that
			identifier for a service provider.
	SPCs can be used to indirectly name all of the telephone numbers
	associated with that 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, or		national policies. The count field is only applicable to start
			fields' whose values do not include "*" or "#" (i.e., a
			TelephoneNumber that does not include "*" or "#"). count never
			overflows a TelephoneNumber digit boundary (i.e., a
			TelephoneNumberRange with TelephoneNumber=10 with a count=91 will
			address numbers 10-99).
	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
	certificate size from becoming unmanageable. In these cases, the TN		the certificate size from becoming unmanageable. In these cases, the
	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 securely download the list of numbers associated		verifiers to either (1) securely download the list of numbers
	with a certificate, or to verify that a single number is under the		associated with a certificate or (2) verify that a single number is
	authority of this certificate. For more on this optimization, see		under the authority of this certificate. For more on this
	Section 10.1.		optimization, see Section 10.1.
	10. Certificate Freshness and Revocation		10. Certificate Freshness and Revocation
	Regardless of which of the approaches in Section 3 is followed for		Regardless of which of the approaches in Section 3 is followed for
	using certificates, a certificate verification mechanism is required.		using certificates, a certificate verification mechanism is required.
	However, the traditional problem of certificate freshness gains a new		However, the traditional problem of certificate freshness gains a new
	wrinkle when using the TN Authorization List extension with telephone		wrinkle when using the TN Authorization List extension with telephone
	numbers or number ranges (as opposed to SPCs), because verifiers must		numbers or number ranges (as opposed to SPCs), because verifiers must
	establish not only that a certificate remains valid, but also that		establish not only that a certificate remains valid but also that the
	the certificate's scope contains the telephone number that the		certificate's scope contains the telephone number that the verifier
	verifier is validating. Dynamic changes to number assignments can		is validating. Dynamic changes to number assignments can occur due
	occur due to number portability, for example. So even if a verifier		to number portability, for example. So, even if a verifier has a
	has a valid cached certificate for a telephone number (or a range		valid cached certificate for a telephone number (or a range
	containing the number), the verifier must determine that the entity		containing the number), the verifier must determine that the entity
	that signed is still a proper authority for that number.		that created the PASSporT, which includes a digital signature, is
			still a proper authority for that number.
	To verify the status of such a certificate, the verifier needs to		To verify the status of such a certificate, the verifier needs to
	acquire the certificate if necessary (via the methods described in		acquire the certificate if necessary (via the methods described in
	Section 7), and then would need to either:		Section 7) and then would need to either:
	a. Rely on short-lived certificates and not check the certificate's		a. Rely on short-lived certificates and not check the certificate's
	status, or		status, or
	b. Rely on status information from the authority (e.g., OCSP)		b. Rely on status information from the authority (e.g., the Online
			Certificate Status Protocol (OCSP)).
	The tradeoff between short lived certificates and using status		The trade-off between short-lived certificates and using status
	information is that the former's burden is on the front end (i.e.,		information is that the former's burden is on the front end (i.e.,
	enrollment) and the latter's burden is on the back end (i.e.,		enrollment) and the latter's burden is on the back end (i.e.,
	verification). Both impact call setup time, but some approaches to		verification). Both impact call setup time, but some approaches to
	generating a short-lived certificate, like requiring one for each		generating a short-lived certificate, like requiring one for each
	call, would incur a greater operational cost than acquiring status		call, would incur a greater operational cost than acquiring status
	information. This document makes no particular recommndation for a		information. This document makes no particular recommendation for a
	means of determinate certificate freshness for STIR, as this requires		means of determining certificate freshness for STIR, as this requires
	further study and implementation experience. Acquiring online status		further study and implementation experience. Acquiring online status
	information for certificates has the potential to disclose private		information for certificates has the potential to disclose private
	information [RFC7258] if proper precautions are not taken. Future		information [RFC7258] if proper precautions are not taken. Future
	specifications that define certificate freshness mechanisms for STIR		specifications that define certificate freshness mechanisms for STIR
	MUST note any such risks and provide countermeasures where possible.		MUST note any such risks and provide countermeasures where possible.
	10.1. Acquiring TN Lists By Reference		10.1. Acquiring the TN List by Reference
	One alternative to checking certificate status for a particular		One alternative to checking certificate status for a particular
	telephone number is simply acquiring the TN Authorization List by		telephone number is simply acquiring the TN Authorization List by
	reference, that is, through dereferencing a URL in the certificate,		reference, that is, through dereferencing a URL in the certificate,
	rather than including the value of the TN Authorization List in the		rather than including the value of the TN Authorization List in the
	certificate itself.		certificate itself.
	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 which		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 list of TNs are		then follow the URI to ascertain whether the TNs in the list are
	authorized for use by the caller.		authorized for use by the caller. As with the certificate extension
			defined in Section 9, a URI dereferenced from an end entity
			certificate will indicate the TNs which the caller has been
			authorized. Verifiers MUST support the AIA extension and the
			dereferenced URI from a CA certificate limits the the set of TNs for
			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. The document returned by dereferencing that		MUST be an HTTPS URI. Dereferencing the URI will return the complete
	URI will contain the complete TN Authorization List (see Section 9)		DER encoded TN Authorization List (see Section 9) for the certificate
	for the certificate.		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.
	11. IANA Considerations		11. IANA Considerations
	This document makes use of object identifiers for the TN Certificate		11.1. ASN.1 Registrations
	Extension defined in Section 9, the TN by reference AIA access
			This document makes use of object identifiers for the TN certificate
			extension defined in Section 9, the "TN List by reference" AIA access
	descriptor defined in Section 10.1, and the ASN.1 module identifier		descriptor defined in Section 10.1, and the ASN.1 module identifier
	defined in Appendix A. It therefore requests that the IANA make the		defined in Appendix A. Therefore, per this document, IANA has made
	following assignments:		the following assignments, as shown on
			<https://www.iana.org/assignments/smi-numbers>:
	o JWT Claim Constraints Certificate Extension in the SMI Security		o TN Authorization List certificate extension in the "SMI Security
	for PKIX Certificate Extension registry:		for PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry:
	http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-		26 id-pe-TNAuthList
	numbers-1.3.6.1.5.5.7.1
	o TN Certificate Extension in the SMI Security for PKIX Certificate		o JWT Claim Constraints certificate extension in the "SMI Security
	Extension registry: http://www.iana.org/assignments/smi-numbers/		for PKIX Certificate Extension" (1.3.6.1.5.5.7.1) registry:
	smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1
	o TNS by reference access descriptor in the SMI Security for PKIX		27 id-pe-JWTClaimConstraints
	Access Descriptor registry: http://www.iana.org/assignments/smi-
	numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48
	o The TN ASN.1 module in SMI Security for PKIX Module Identifier		o TN List by reference access descriptor in the "SMI Security for
	registry: http://www.iana.org/assignments/smi-numbers/smi-		PKIX Access Descriptor" (1.3.6.1.5.5.7.48) registry:
	numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0
			14 id-ad-stirTNList
			o The TN ASN.1 module in the "SMI Security for PKIX Module
			Identifier" (1.3.6.1.5.5.7.0) registry:
			89 id-mod-tn-module
			11.2. Media Type Registrations
			Type name: application
			Subtype name: tnauthlist
			Required parameters: None.
			Optional parameters: None.
			Encoding considerations: Binary.
			Security considerations: See Section 12 of this specification.
			Interoperability considerations:
			The TN Authorization List inside this media type MUST be
			DER-encoded TNAuthorizationList.
			Published specification: This specification.
			Applications that use this media type:
			Additional information:
			Magic number(s): None
			File extension(s): None
			Macintosh File Type Code(s): None
			Person & email address to contact for further information:
			Jon Peterson <jon.peterson@team.neustar>
			Intended usage: COMMON
			Restrictions on usage: none
			Author: Sean Turner <sean@sn3rd.com>
			Change controller: The IESG <iesg@ietf.org>
	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.		Security Considerations section.
	13. Acknowledgments		If a certification authority issues a certificate attesting authority
			over many telephone numbers, the TNAuthList element can divulge to
			relying parties extraneous telephone numbers associated with the
			certificate which have no bearing on any given call in progress. The
			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
			single certificate. Even an SPC in a certificate can be used to link
			a certificate to a particular carrier and, with access to industry
			databases, potentially the set of numbers associated with that SPC.
			While these practices may not cause concern in some environments, in
			other scenarios alternative approaches could minimize the data
			revealed to relying parties. For example, a service provider with
			authority over a large block of numbers could generate short-lived
			certificates for individual TNs that are not so easily linked to the
			service provider or any other numbers that the service provider
			controls. Optimizations to facilitate acquiring short-lived
			certificates are a potential area of future work for STIR.
	Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave		13. References
	Crocker, Tony Rutkowski, John Braunberger, and Eric Rescorla provided
	key input to the discussions leading to this document. Russ Housley
	provided some direct assistance and text surrounding the ASN.1
	module.
	14. References		13.1. Normative References
	14.1. Normative References
	[ATIS-0300251]		[ATIS-0300251]
	ATIS Recommendation 0300251, "Codes for Identification of		ATIS Recommendation 0300251, "Codes for Identification of
	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
	version 4", NIST FIPS PUB 186-4, 2013.		(DSS)", NIST FIPS PUB 186-4, DOI 10.6028/NIST.FIPS.186-4,
			July 2013, <http://nvlpubs.nist.gov/nistpubs/FIPS/
	[I-D.ietf-stir-passport]		NIST.FIPS.186-4.pdf>.
	Wendt, C. and J. Peterson, "Personal Assertion Token
	(PASSporT)", draft-ietf-stir-passport-11 (work in
	progress), February 2017.
	[I-D.ietf-stir-rfc4474bis]
	Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
	"Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
	(work in progress), February 2017.
	[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,		DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2119>.		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,
	<http://www.rfc-editor.org/info/rfc2392>.		<https://www.rfc-editor.org/info/rfc2392>.
	[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
	2003, <http://www.rfc-editor.org/info/rfc3447>.
	[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,
	<http://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,
	<http://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,		DOI 10.17487/RFC5912, June 2010, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc5912>.		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,		DOI 10.17487/RFC5958, August 2010, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc5958>.		editor.org/info/rfc5958>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<http://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, May
	2014, <http://www.rfc-editor.org/info/rfc7258>.		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,
	<http://www.rfc-editor.org/info/rfc7519>.		<https://www.rfc-editor.org/info/rfc7519>.
	[X.509] ITU-T Recommendation X.509 | ISO/IEC 9594-8, "Information		[RFC8017] Moriarty, K., Ed., Kaliski, B., Jonsson, J., and A. Rusch,
			"PKCS #1: RSA Cryptography Specifications Version 2.2",
			RFC 8017, DOI 10.17487/RFC8017, November 2016,
			<https://www.rfc-editor.org/info/rfc8017>.
			[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
			2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
			May 2017, <https://www.rfc-editor.org/info/rfc8174>.
			[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
			"Authenticated Identity Management in the Session
			Initiation Protocol (SIP)", RFC 8224,
			DOI 10.17487/RFC8224, November 2017, <https://www.rfc-
			editor.org/info/rfc8224>.
			[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
			Token", RFC 8225, DOI 10.17487/RFC8225, November 2017,
			<https://www.rfc-editor.org/info/rfc8225>.
			[X.509] International Telecommunication Union, "Information
	technology - Open Systems Interconnection - The Directory:		technology - Open Systems Interconnection - The Directory:
	Public-key and attribute certificate frameworks", 2012.		Public-key and attribute certificate frameworks", ITU-T
			Recommendation X.509, ISO/IEC 9594-8, October 2016,
			<https://www.itu.int/rec/T-REC-X.509>.
	[X.680] ITU-T Recommendation X.680 | ISO/IEC 8824-1, "Information		[X.680] International Telecommunication Union, "Information
	Technology - Abstract Syntax Notation One: Specification		Technology - Abstract Syntax Notation One (ASN.1):
	of basic notation", 2015.		Specification of basic notation", ITU-T Recommendation
			X.680, ISO/IEC 8824-1, August 2015,
			<https://www.itu.int/rec/T-REC-X.680>.
	[X.681] ITU-T Recommendation X.681 | ISO/IEC 8824-2, "Information		[X.681] International Telecommunication Union, "Information
	Technology - Abstract Syntax Notation One: Information		Technology - Abstract Syntax Notation One (ASN.1):
	Object Specification", 2015.		Information object specification", ITU-T Recommendation
			X.681, ISO/IEC 8824-2, August 2015,
			<https://www.itu.int/rec/T-REC-X.681>.
	[X.682] ITU-T Recommendation X.682 | ISO/IEC 8824-2, "Information		[X.682] International Telecommunication Union, "Information
	Technology - Abstract Syntax Notation One: Constraint		Technology - Abstract Syntax Notation One (ASN.1):
	Specification", 2015.		Constraint specification", ITU-T Recommendation
			X.682, ISO/IEC 8824-3, August 2015,
			<https://www.itu.int/rec/T-REC-X.682>.
	[X.683] ITU-T Recommendation X.683 | ISO/IEC 8824-3, "Information		[X.683] International Telecommunication Union, "Information
	Technology - Abstract Syntax Notation One:		Technology - Abstract Syntax Notation One (ASN.1):
	Parameterization of ASN.1 Specifications", 2015.		Parameterization of ASN.1 specifications", ITU-T
			Recommendation X.683, ISO/IEC 8824-4, August 2015,
			<https://www.itu.int/rec/T-REC-X.683>.
	14.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,		DOI 10.17487/RFC2046, November 1996, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc2046>.		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,		DOI 10.17487/RFC3647, November 2003, <https://www.rfc-
	<http://www.rfc-editor.org/info/rfc3647>.		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,
	<http://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,
	<http://www.rfc-editor.org/info/rfc7375>.		<https://www.rfc-editor.org/info/rfc7375>.
	[X.520] ITU-T Recommendation X.520 | ISO/IEC 9594-6, "Information		[X.520] International Telecommunication Union, "Information
	technology - Open Systems Interconnection - The Directory:		technology - Open Systems Interconnection - The Directory:
	Selected Attribute Types", 2012.		Selected attribute types", ITU-T Recommendation
			X.520, ISO/IEC 9594-6, October 2016,
			<https://www.itu.int/rec/T-REC-X.520>.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	This appendix provides the normative ASN.1 [X.680] definitions for		This appendix provides the normative ASN.1 [X.680] definitions for
	the structures described in this specification using ASN.1, as		the structures described in this specification using ASN.1, as
	defined in [X.680] through [X.683].		defined in [X.680], [X.681], [X.682], and [X.683].
	The modules defined in this document are compatible with the most		The modules defined in this document are compatible with the most
	current ASN.1 specification published in 2015 (see [X.680], [X.681],		current ASN.1 specifications published in 2015 (see [X.680], [X.681],
	[X.682], [X.683]). None of the newly defined tokens in the 2008		[X.682], and [X.683]). None of the newly defined tokens in the 2008
	ASN.1 (DATE, DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, RELATIVE-		ASN.1 (DATE, DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI,
	OID-IRI, TIME, TIME-OF-DAY)) are currently used in any of the ASN.1		RELATIVE-OID-IRI, TIME, TIME-OF-DAY) are currently used in any of the
	specifications referred to here.		ASN.1 specifications referred to here.
	This ASN.1 module imports ASN.1 from [RFC5912].		This ASN.1 module imports ASN.1 from [RFC5912].
	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(88) }		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 [RFC5912]
	{ 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 [RFC5912]
	{ 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 25 }		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 in addition		-- The listed claim names MUST appear in the PASSporT
	-- to iat, orig, and dest. If absent, iat, orig, and dest MUST		-- in addition to iat, orig, and dest. If absent, iat, orig,
	-- appear in the PASSporT.		-- and dest MUST appear in the PASSporT.
	permittedValues [1] JWTClaimPermittedValuesList OPTIONAL }		permittedValues [1] JWTClaimPermittedValuesList OPTIONAL }
	-- If the claim name is present, the claim MUST contain one of		-- If the claim name is present, the claim MUST contain one of
	-- the listed values.		-- the listed values.
	( WITH COMPONENTS { ..., mustInclude PRESENT } |		( WITH COMPONENTS { ..., mustInclude PRESENT } |
	WITH COMPONENTS { ..., permittedValues PRESENT } )		WITH COMPONENTS { ..., permittedValues PRESENT } )
	JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) Of		JWTClaimPermittedValuesList ::= SEQUENCE SIZE (1..MAX) Of
	JWTClaimPermittedValues		JWTClaimPermittedValues
	JWTClaimPermittedValues ::= SEQUENCE {		JWTClaimPermittedValues ::= SEQUENCE {
	claim JWTClaimName,		claim JWTClaimName,
	permitted SEQUENCE SIZE (1..MAX) OF UTF8String }		permitted SEQUENCE SIZE (1..MAX) OF UTF8String }
	JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName		JWTClaimNames ::= SEQUENCE SIZE (1..MAX) OF JWTClaimName
	JWTClaimName ::= IA5String		JWTClaimName ::= IA5String
	--		--
	-- Telephone Number Authorization List Certificate Extension		-- Telephony Number Authorization List Certificate Extension
	--		--
	ext-tnAuthList EXTENSION ::= {		ext-tnAuthList EXTENSION ::= {
	SYNTAX TNAuthorizationList IDENTIFIED BY id-pe-TNAuthList		SYNTAX TNAuthorizationList IDENTIFIED BY id-pe-TNAuthList
	}		}
	id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 }		id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 }
	TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
	TNEntry ::= CHOICE {		TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
	spc [0] ServiceProviderCode,
	range [1] TelephoneNumberRange,
	one [2] TelephoneNumber
	}
	ServiceProviderCode ::= IA5String		TNEntry ::= CHOICE {
			spc [0] ServiceProviderCode,
			range [1] TelephoneNumberRange,
			one [2] TelephoneNumber
			}
	-- Service Provider Codes may be OCNs, various SPIDs, or other		ServiceProviderCode ::= IA5String
	-- SP identifiers from the telephone network
	TelephoneNumberRange ::= SEQUENCE {		-- SPCs may be OCNs, various SPIDs, or other SP identifiers
	start TelephoneNumber,		-- from the telephone network.
	count INTEGER (2..MAX)
	}
	TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789"))		TelephoneNumberRange ::= SEQUENCE {
			start TelephoneNumber,
			count INTEGER (2..MAX),
			...
			}
	-- TN Access Descriptor		TelephoneNumber ::= IA5String (SIZE (1..15)) (FROM ("0123456789#*"))
	id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 }		-- TN Access Descriptor
	END		id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 }
			END
			Acknowledgments
			Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave
			Crocker, Tony Rutkowski, John Braunberger, Eric Rescorla, and Martin
			Thomson provided key input to the discussions leading to this
			document. Russ Housley provided some direct assistance and text
			surrounding the ASN.1 module.
	Authors' Addresses		Authors' Addresses
	Jon Peterson		Jon Peterson
	Neustar, Inc.		Neustar, Inc.
	Email: jon.peterson@neustar.biz		Email: jon.peterson@neustar.biz
	Sean Turner		Sean Turner
	sn3rd		sn3rd
End of changes. 132 change blocks.
	405 lines changed or deleted		487 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/