< draft-ietf-stir-certificates-08.txt		draft-ietf-stir-certificates-09.txt >
	Network Working Group 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: March 13, 2017 sn3rd		Expires: April 9, 2017 sn3rd
	September 9, 2016		October 6, 2016
	Secure Telephone Identity Credentials: Certificates		Secure Telephone Identity Credentials: Certificates
	draft-ietf-stir-certificates-08.txt		draft-ietf-stir-certificates-09.txt
	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 March 13, 2017.		This Internet-Draft will expire on April 9, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 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. Levels Of Assurance . . . . . . . . . . . . . . . . . . . 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. TN Authorization List Syntax . . . . . . . . . . . . . . . . 10		8. JWT Claim Constraints Syntax . . . . . . . . . . . . . . . . 10
	9. Certificate Freshness and Revocation . . . . . . . . . . . . 12		9. TN Authorization List Syntax . . . . . . . . . . . . . . . . 11
	9.1. Choosing a Verification Method . . . . . . . . . . . . . 12		10. Certificate Freshness and Revocation . . . . . . . . . . . . 12
	9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 13		10.1. Choosing a Verification Method . . . . . . . . . . . . . 13
	9.2.1. OCSP Extension Specification . . . . . . . . . . . . 14		10.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 14
	9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 16		10.2.1. OCSP Extension Specification . . . . . . . . . . . . 15
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		10.3. Acquiring TN Lists By Reference . . . . . . . . . . . . 17
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 18		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
	12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		12. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
			14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 21		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 21
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	The STIR problem statement [RFC7340] identifies the primary enabler		The STIR problem statement [RFC7340] identifies the primary enabler
	of robocalling, vishing, swatting and related attacks as the		of robocalling, vishing, swatting and related attacks as the
	capability to impersonate a calling party number. The starkest		capability to impersonate a calling party number. The starkest
	examples of these attacks are cases where automated callees on the		examples of these attacks are cases where automated callees on the
	PSTN rely on the calling number as a security measure, for example to		PSTN rely on the calling number as a security measure, for example to
	skipping to change at page 3, line 9 ¶		skipping to change at page 3, line 10 ¶
	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 which 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, and thus distinguish themselves from impersonators unable to
	present such credentials. For that reason the STIR threat model		present such credentials. For that reason the STIR threat model
	[RFC7375] stipulates, "The design of the credential system envisioned		[RFC7375] stipulates, "The design of the credential system envisioned
	as a solution to these threats must, for example, limit the scope of		as a solution to these threats must, for example, limit the scope of
	the credentials issued to carriers or national authorities to those		the credentials issued to carriers or national authorities to those
	numbers that fall under their purview." This document describes		numbers that fall under their purview." This document describes
	credential systems for telephone numbers based on X.509 version 3		credential systems for telephone numbers based on [X.509] version 3
	certificates in accordance with [RFC5280]. While telephone numbers		certificates in accordance with [RFC5280]. While telephone numbers
	have long been part of the X.509 standard (X.509 supports arbitrary		have long been part of the X.509 standard (X.509 supports arbitrary
	naming attributes to be included in a certificate; the		naming attributes to be included in a certificate; the
	telephoneNumber attribute was defined in the 1988 [X.520]		telephoneNumber attribute was defined in the 1988 [X.520]
	specification) this document provides ways to determine authority		specification) this document provides ways to determine authority
	more aligned with telephone network requirements, including extending		more aligned with telephone network requirements, including extending
	X.509 with a Telephone Number Authorization List certificate		X.509 with a Telephone Number Authorization List certificate
	extension which binds certificates to asserted authority for		extension which binds certificates to asserted authority for
	particular telephone numbers, or potentially telephone number blocks		particular telephone numbers, or potentially telephone number blocks
	or ranges.		or ranges.
	skipping to change at page 4, line 8 ¶		skipping to change at page 4, line 14 ¶
	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		operation of the telephone network including Service Provider
	Identifiers (SPIDs) could serve as a subject as well. A relying		Identifiers (SPIDs) via the TN Authorization List specified in this
	party could then employ an external data set or service that		document. A relying party could then employ an external data set or
	determines whether or not a specific telephone number is under the		service that determines whether or not a specific telephone number is
	authority of the carrier identified as the subject of the		under the authority of the carrier identified as the subject of the
	certificate, and use that to ascertain whether or not the carrier		certificate, and use that to ascertain whether or not the carrier
	should have authority over a telephone number. Potentially, a		should have authority over a telephone number. Potentially, a
	certificate extension to convey the URI of such an information		certificate extension to convey the URI of such an information
	service trusted by the issuer of the certificate could be developed		service trusted by the issuer of the certificate could be developed
	(though this specification does not propose one). Alternatively,		(though this specification does not propose one). Alternatively,
	some relying parties could form bilateral or multilateral trust		some relying parties could form bilateral or multilateral trust
	relationships with peer carriers, trusting one another's assertions		relationships with peer carriers, trusting one another's assertions
	just as telephone carriers in the SS7 network today rely on		just as telephone carriers in the SS7 network today rely on
	transitive trust when displaying the calling party telephone number		transitive trust when displaying the calling party telephone number
	received through SS7 signaling.		received through SS7 signaling.
	skipping to change at page 5, line 15 ¶		skipping to change at page 5, line 21 ¶
	certificate. For that reason, the two approaches are not mutually		certificate. For that reason, the two approaches are not mutually
	exclusive, and in fact a certificate issued to a traditional		exclusive, and in fact a certificate issued to a traditional
	telephone network service provider could contain a TN Authorization		telephone network service provider could contain a TN Authorization
	List or not, were it supported by the CA issuing the credential.		List or not, were it supported by the CA issuing the credential.
	Regardless of which approach is used, certificates that assert		Regardless of which approach is used, certificates that assert
	authority over telephone numbers are subject to the ordinary		authority over telephone numbers are subject to the ordinary
	operational procedures that govern certificate use per [RFC5280].		operational procedures that govern certificate use per [RFC5280].
	This means that verification services must be mindful of the need to		This means that verification services must be mindful of the need to
	ensure that they trust the trust anchor that issued the certificate,		ensure that they trust the trust anchor that issued the certificate,
	and that they have some means to determine the freshness of the		and that they have some means to determine the freshness of the
	certificate (see Section 9).		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		[I-D.ietf-stir-rfc4474bis] Section 7.4 requires that all credential
	systems used by STIR explain how they address the requirements		systems used by STIR explain how they address the requirements
	enumerated below. Certificates as described in this document address		enumerated below. Certificates as described in this document address
	the STIR requirements as follows:		the STIR requirements as follows:
	1. The URI schemes permitted in the SIP Identity header "info"		1. The URI schemes permitted in the SIP Identity header "info"
	parameter, as well as any special procedures required to		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, CID and SIP URI		Section 7, this mechanism permits the HTTP, CID and SIP URI
	schemes to appear in the "info" parameter.		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 8 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 ECDSA with the P-256
	curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447]		curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447]
	Section 8.2) for certificate signatures. Implementers are		Section 8.2) for certificate signatures. Implementers are
	advised that RS256 is mandated only as a transitional mechanism,		advised that RS256 is mandated only as a transitional mechanism,
	due to its widespread use in existing PKI, but we anticipate that		due to its widespread use in existing PKI, but we anticipate that
	this mechanism will eventually be deprecated.		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:
	skipping to change at page 6, line 25 ¶		skipping to change at page 6, line 33 ¶
	* 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 certificate
	policies extension.		policies extension.
	o See Section 7 for requirements related to the TN Query certificate		o See Section 7 for requirements related to relying parties
	extension.		acquiring credentials.
	o See Section 9.2 and Section 9.3 for requirements related to the		o See Section 10.2 and Section 10.3 for requirements related to the
	Authority Information Access (AIA) certificate extension.		Authority Information Access (AIA) certificate extension.
	o See Section 9.2.1 for requirements related to the authority key		o See Section 10.2.1 for requirements related to the authority key
	identifier and subject key identifier certificate extensions.		identifier and subject key identifier certificate extensions.
	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,
	skipping to change at page 7, line 42 ¶		skipping to change at page 8, line 5 ¶
	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. Levels Of Assurance		5.1. Constraints on Signing PASSporTs
	This specification supports different level of assurance (LOA). The		The public key in the certificate is used to validate the signature
	LOA indications, which are Object Identifiers (OIDs) included in the		on a JSON Web Token (JWT) [RFC7519] that conforms to the conventions
	certificate's certificate policies extension [RFC5280], allow CAs to		specified in PASSporT [I-D.ietf-stir-passport]. This specification
			supports constraints on the JWT claims, which allows the CA to
	differentiate those enrolled from proof-of-possession versus		differentiate those enrolled from proof-of-possession versus
	delegation. A Certification Policy and a Certification Practice		delegation. A Certification Policy and a Certification Practice
	Statement [RFC3647] are produced as part of the normal PKI		Statement [RFC3647] are produced as part of the normal PKI
	bootstrapping process (i.e., the CP is written first and then the CAs		bootstrapping process, (i.e., the CP is written first and then the CA
	say how they conform to the CP in the CPS). OIDs are used to		says how it conforms to the CP in the CPS). A CAs that wishes to
	reference the CP and if the CA wishes it can also include a reference		place constraints on the JWT claims MUST include the JWT Claim
	to the CPS with the certificate policies extension. CAs that wish to		Constraints certificate extension in issued certificates. See
	express different LOAs MUST include the certificate policies		Section 8 for information about the certificate extension.
	extension in issued certificates. See Section 11 for additional
	information about the LOA registry.
	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 have a single certificate that can be applied to signing for any		to have a single certificate that can be applied to signing for any
	one of those numbers. Others may wish to compartmentalize authority		one of those numbers. Others may wish to compartmentalize authority
	over subsets of the numbers they control.		over subsets of the numbers they control.
	skipping to change at page 9, line 13 ¶		skipping to change at page 9, line 23 ¶
	particular entity in a SIP deployment architecture sign requests,		particular entity in a SIP deployment architecture sign requests,
	only that it be an entity with an appropriate private key; the		only that it be an entity with an appropriate private key; the
	authentication service role may be instantiated by any entity in a		authentication service role may be instantiated by any entity in a
	SIP network. For a certificate granting authority only over a		SIP network. For a certificate granting authority only over a
	particular number which has been issued to an end user, for example,		particular number which has been issued to an end user, for example,
	an end user device might hold the private key and generate the		an end user device might hold the private key and generate the
	signature. In the case of a service provider with authority over		signature. In the case of a service provider with authority over
	large blocks of numbers, an intermediary might hold the private key		large blocks of numbers, an intermediary 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 the
	CMS package specified in [RFC5958].		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
	skipping to change at page 10, line 12 ¶		skipping to change at page 10, line 22 ¶
	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. TN Authorization List Syntax		8. JWT Claim Constraints Syntax
			The subjects of certificates containing the JWT Claim Constraints
			certificate extension are specifies values for claims that are
			permitted, values for claims that are excluded, or both. When a
			verifier is validating PASSporT claims, the JWT claim MUST contain
			permitted values, and MUST NOT contain excluded values. The JWT
			Claim Constraints certificate extension is included in the extension
			field of the certificate [RFC5280]. The extension is defined with
			ASN.1 [X.680][X.681][X.682] [X.683].
			The JWT Claim Constraints certificate extension is identified by the
			following object identifier (OID), which is defined under the id-ce
			OID arc defined in [RFC5280] and managed by IANA (see Section 11):
			id-ce-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-ce TBD1 }
			The JWT Claim Constraints certificate extension has the following
			syntax:
			JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint
			JWTClaimConstraint ::= SEQUENCE {
			claim IA5String,
			permitted [1] SEQUENCE OF IA5String OPTIONAL,
			excluded [2] SEQUENCE OF IA5String OPTIONAL }
			( WITH COMPONENTS { ..., permitted PRESENT } |
			WITH COMPONENTS { ..., excluded PRESENT } )
			The JWT Claim Constraints certificate extension places constraints on
			the values that are allowed in particular JWT claims. The extension
			provides claim values that the call setup signer is permitted to
			include, excluded from including, or both.
			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
	Telephony Number (TN) Authorization List certificate extension is		Telephony Number (TN) Authorization List certificate extension is
	included in the Certificate's extension field [RFC5280]. The		included in the Certificate's extension field [RFC5280]. The
	extension is defined with ASN.1, defined in [X.680] through [X.683].		extension is defined with ASN.1 [X.680][X.681][X.682] [X.683]. What
	What follows is the syntax and semantics of the extension.		follows is the syntax and semantics of the extension.
	The Telephony Number (TN) Authorization List certificate extension is		The Telephony Number (TN) Authorization List certificate extension is
	identified by the following object identifier (OID), which is defined		identified by the following object identifier (OID), which is defined
	under the id-ce OID arc defined in [RFC5280] and managed by IANA (see		under the id-ce OID arc defined in [RFC5280] and managed by IANA (see
	Section 10):		Section 11).
	id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD }		id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD2 }
	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 TNAuthorization		TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
	TNAuthorization ::= SEQUENCE SIZE (1..MAX) OF TNEntry
	TNEntry ::= CHOICE {		TNEntry ::= CHOICE {
	spid [0] ServiceProviderIdentifierList,		spid [0] ServiceProviderIdentifierList,
	range [1] TelephoneNumberRange,		range [1] TelephoneNumberRange,
	one E164Number }		one E164Number }
	ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF		ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF
	OCTET STRING		OCTET STRING
	-- When all three are present: SPID, Alt SPID, and Last Alt SPID		-- Allows SPID, Alt SPID, and Last Alt SPID to be present
	TelephoneNumberRange ::= SEQUENCE {		TelephoneNumberRange ::= SEQUENCE {
	start E164Number,		start E164Number,
	count INTEGER }		count INTEGER }
	E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789"))		E164Number ::= 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. A Service Provider Identifier (SPID, also known as an Operating		1. A Service Provider Identifier (SPID, also known as an Operating
	skipping to change at page 12, line 5 ¶		skipping to change at page 12, line 29 ¶
	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		certificate size from becoming unmanageable. In these cases, the TN
	Authorization List may be given by reference rather than by value,		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 securely download the list of numbers associated
	with a certificate, or to verify that a single number is under the		with a certificate, or to verify that a single number is under the
	authority of this certificate. This optimization is left for future		authority of this certificate. This optimization is left for future
	work.		work.
	9. 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, because		wrinkle when using the TN Authorization List extension with telephone
	verifiers must establish not only that a certificate remains valid,		numbers or number ranges (as opposed to SPIDs), because verifiers
	but also that the certificate's scope contains the telephone number		must establish not only that a certificate remains valid, but also
	that the verifier is validating. Dynamic changes to number		that the certificate's scope contains the telephone number that the
	assignments can occur due to number portability, for example. So		verifier is validating. Dynamic changes to number assignments can
	even if a verifier has a valid cached certificate for a telephone		occur due to number portability, for example. So even if a verifier
	number (or a range containing the number), the verifier must		has a valid cached certificate for a telephone number (or a range
	determine that the entity that signed is still a proper authority for		containing the number), the verifier must determine that the entity
	that number.		that signed is still a proper authority for that number.
	To verify the status of the certificate, the verifier needs to		To verify the status of the 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, see		(b) Rely on status information from the authority (e.g. OCSP, see
	Section 9.2)		Section 10.2)
	The tradeoff between short lived certificates and using status		The tradeoff 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 it is assumed that		verification). Both impact call setup time, but it is assumed that
	generating a short-lived certificate for each all, and consequently		generating a short-lived certificate for each call, and consequently
	performing enrollment for each call, is more of an impact than		performing enrollment for each call, is more of an impact than
	acquiring status information. This document therefore recommends		acquiring status information. This document therefore details an
	relying on status information.		approach for relying on status information.
	9.1. Choosing a Verification Method		10.1. Choosing a Verification Method
	There are three common certificate verification mechanisms employed		There are three common certificate verification mechanisms employed
	by CAs:		by CAs:
	1. Certificate Revocation Lists (CRLs) [RFC5280]		1. Certificate Revocation Lists (CRLs) [RFC5280]
	2. Online Certificate Status Protocol (OCSP) [RFC6960], and		2. Online Certificate Status Protocol (OCSP) [RFC6960], and
	3. Server-based Certificate Validation Protocol (SCVP) [RFC5055].		3. Server-based Certificate Validation Protocol (SCVP) [RFC5055].
	skipping to change at page 13, line 26 ¶		skipping to change at page 14, line 4 ¶
	mechanisms to scope the size of the CRLs based on revocation reasons		mechanisms to scope the size of the CRLs based on revocation reasons
	(e.g., key compromise vs CA compromise), user certificates only, and		(e.g., key compromise vs CA compromise), user certificates only, and
	CA certificates only as well as just operationally deciding to keep		CA certificates only as well as just operationally deciding to keep
	the CRLs small. However, scoping the CRL introduces other issues		the CRLs small. However, scoping the CRL introduces other issues
	(i.e., does the RP have all of the CRL partitions).		(i.e., does the RP have all of the CRL partitions).
	CAs in the STIR architecture will likely all create CRLs for audit		CAs in the STIR architecture will likely all create CRLs for audit
	purposes, but it NOT RECOMMENDED that they be relied upon for status		purposes, but it NOT RECOMMENDED that they be relied upon for status
	information. Instead, one of the two "online" options is preferred.		information. Instead, one of the two "online" options is preferred.
	Between the two, OCSP is much more widely deployed and this document		Between the two, OCSP is much more widely deployed and this document
	therefore recommends the use of OCSP in high-volume environments		therefore RECOMMENDS the use of OCSP in high-volume environments
	(HVE) for validating the freshness of certificates, based on		(HVE) for validating the freshness of certificates, based on
	[RFC6960], incorporating some (but not all) of the optimizations of		[RFC6960], incorporating some (but not all) of the optimizations of
	[RFC5019]. CRLs MUST be signed with the same algorithm as the		[RFC5019]. CRLs MUST be signed with the same algorithm as the
	certificate.		certificate.
	9.2. Using OCSP with TN Auth List		10.2. Using OCSP with TN Auth List
	Certificates compliant with this specification therefore SHOULD		Certificates compliant with this specification therefore SHOULD
	include a URL pointing to an OCSP service in the Authority		include a URL pointing to an OCSP service in the Authority
	Information Access (AIA) certificate extension, via the "id-ad-ocsp"		Information Access (AIA) certificate extension, via the "id-ad-ocsp"
	accessMethod specified in [RFC5280]. It is RECOMMENDED that entities		accessMethod specified in [RFC5280]. It is RECOMMENDED that entities
	that issue certificates with the Telephone Number Authorization List		that issue certificates with the Telephone Number Authorization List
	certificate extension run an OCSP server for this purpose. Baseline		certificate extension run an OCSP server for this purpose. Baseline
	OCSP however supports only three possible response values: good,		OCSP however supports only three possible response values: good,
	revoked, or unknown. Without some extension, OCSP would not indicate		revoked, or unknown. Without some extension, OCSP would not indicate
	whether the certificate is authorized for a particular telephone		whether the certificate is authorized for a particular telephone
	skipping to change at page 14, line 4 ¶		skipping to change at page 14, line 28 ¶
	OCSP however supports only three possible response values: good,		OCSP however supports only three possible response values: good,
	revoked, or unknown. Without some extension, OCSP would not indicate		revoked, or unknown. Without some extension, OCSP would not indicate
	whether the certificate is authorized for a particular telephone		whether the certificate is authorized for a particular telephone
	number that the verifier is validating.		number that the verifier is validating.
	At a high level, there are two ways that a client might pose this		At a high level, there are two ways that a client might pose this
	authorization question:		authorization question:
	For this certificate, is the following number currently in its		For this certificate, is the following number currently in its
	scope of validity?		scope of validity?
	What are all the telephone numbers associated with this		What are all the telephone numbers associated with this
	certificate, or this certificate subject?		certificate, or this certificate subject?
	Only the former lends itself to piggybacking on the OCSP status		Only the former lends itself to piggybacking on the OCSP status
	mechanism; since the verifier is already asking an authority about		mechanism; since the verifier is already asking an authority about
	the certificate's status, why not reuse that mechanism, instead of		the certificate's status, that mechanism can be reused instead of
	creating a new service that requires additional round trips? Like		creating a new service that requires additional round trips? Like
	most PKIX-developed protocols, OCSP is extensible; OCSP supports		most PKIX-developed protocols, OCSP is extensible; OCSP supports
	request extensions (including sending multiple requests at once) and		request extensions (including sending multiple requests at once) and
	per-request extensions. It seems unlikely that the verifier will be		per-request extensions. It seems unlikely that the verifier will be
	requesting authorization checks on multiple telephone numbers in one		requesting authorization checks on multiple telephone numbers in one
	request, so a per-request extension is what is needed.		request, so a per-request extension is what is needed.
	The requirement to consult OCSP in real time results in a network		The requirement to consult OCSP in real time results in a network
	round-trip time of day, which is something to consider because it		round-trip time of day, which is something to consider because it
	will add to the call setup time. OCSP server implementations		will add to the call setup time. OCSP server implementations
	commonly pre-generate responses, and to speed up HTTPS connections,		commonly pre-generate responses, and to speed up HTTPS connections,
	servers often provide OCSP responses for each certificate in their		servers often provide OCSP responses for each certificate in their
	hierarchy. If possible, both of these OCSP concepts should be		hierarchy. If possible, both of these OCSP concepts should be
	adopted for use with STIR.		adopted for use with STIR.
	9.2.1. OCSP Extension Specification		10.2.1. OCSP Extension Specification
	The extension mechanism for OCSP follows X.509 v3 certificate		The extension mechanism for OCSP follows X.509 v3 certificate
	extensions, and thus requires an OID, a criticality flag, and ASN.1		extensions, and thus requires an OID, a criticality flag, and ASN.1
	syntax as defined by the OID. The criticality specified here is		syntax as defined by the OID. The criticality specified here is
	optional: per [RFC6960] Section 4.4, support for all OCSP extensions		optional: per [RFC6960] Section 4.4, support for all OCSP extensions
	is optional. If the OCSP server does not understand the requested		is optional. If the OCSP server does not understand the requested
	extension, it will still provide the baseline validation of the		extension, it will still provide the baseline validation of the
	certificate itself. Moreover, in practical STIR deployments, the		certificate itself. Moreover, in practical STIR deployments, the
	issuer of the certificate will set the accessLocation for the OCSP		issuer of the certificate will set the accessLocation for the OCSP
	AIA extension to point to an OCSP service that supports this		AIA extension to point to an OCSP service that supports this
	skipping to change at page 16, line 22 ¶		skipping to change at page 17, line 5 ¶
	PKI environments as an optimization which allows web servers to send		PKI environments as an optimization which allows web servers to send
	up-to-date certificate status information acquired from OCSP to		up-to-date certificate status information acquired from OCSP to
	clients as TLS is negotiated. A similar mechanism could be		clients as TLS is negotiated. A similar mechanism could be
	implemented for SIP requests, in which the authentication service		implemented for SIP requests, in which the authentication service
	adds status information for its certificate to the SIP request, which		adds status information for its certificate to the SIP request, which
	would save the verifier the trouble of performing the OCSP dip		would save the verifier the trouble of performing the OCSP dip
	itself. Especially for high-volume authentication and verification		itself. Especially for high-volume authentication and verification
	services, this could result in significant performance improvements.		services, this could result in significant performance improvements.
	This is left as an optimization for future work.		This is left as an optimization for future work.
	9.3. Acquiring TN Lists By Reference		10.3. Acquiring TN Lists By Reference
	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 OCSP, one which could be		query/response interaction outside of OCSP, one which could be
	initiated through a separate URI included in the certificate. The		initiated through a separate URI included in the certificate. The
	AIA extension (see [RFC5280]) supports such a mechanism: it		AIA extension (see [RFC5280]) supports such a mechanism: it
	designates an OID to identify the accessMethod and an accessLocation,		designates an OID to identify the accessMethod and an accessLocation,
	which would most likely be a URI. A verifier would then follow the		which would most likely be a URI. A verifier would then follow the
	URI to ascertain whether the list of TNs are authorized for use by		URI to ascertain whether the list of TNs are authorized for use by
	the caller.		the caller.
	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-stir-tn", which uses the following AIA OID:		"id-ad-stir-tn", which uses the following AIA OID:
	id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD }		id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD }
	When the "id-ad-stir-tn" accessMethod is used, the accessLocation		When the "id-ad-stir-tn" accessMethod is used, the accessLocation
	MUST be an HTTPS URI. The document returned by dereferencing that		MUST be an HTTPS URI. The document returned by dereferencing that
	URI will contain the complete TN Authorization List (see Section 8)		URI will contain the complete TN Authorization List (see Section 9)
	for the certificate.		for the certificate.
	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.
	10. IANA Considerations		11. IANA Considerations
	This document makes use of object identifiers for the TN Certificate		This document makes use of object identifiers for the TN Certificate
	Extension defined in Section 8, TN-HVE OCSP extension in		Extension defined in Section 9, TN-HVE OCSP extension in
	Section 9.2.1, the TN by reference AIA access descriptor defined in		Section 10.2.1, the TN by reference AIA access descriptor defined in
	Section 9.3, and the ASN.1 module identifier defined in Appendix A.		Section 10.3, and the ASN.1 module identifier defined in Appendix A.
	It therefore requests that the IANA make the following assignments:		It therefore requests that the IANA make the following assignments:
			o JWT Claim Constraints Certificate Extension in the SMI Security
			for PKIX Certificate Extension registry:
			http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-
			numbers-1.3.6.1.5.5.7.1
	o TN Certificate Extension in the SMI Security for PKIX Certificate		o TN Certificate Extension in the SMI Security for PKIX Certificate
	Extension registry: http://www.iana.org/assignments/smi-numbers/		Extension registry: http://www.iana.org/assignments/smi-numbers/
	smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1		smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1
	o TN-HVE OCSP extension in the SMI Security for PKIX Online		o TN-HVE OCSP extension in the SMI Security for PKIX Online
	Certificate Status Protocol (OCSP) registry:		Certificate Status Protocol (OCSP) registry:
	http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-		http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-
	numbers-1.3.6.1.5.5.7.48.1		numbers-1.3.6.1.5.5.7.48.1
	o TNS by reference access descriptor in the SMI Security for PKIX		o TNS by reference access descriptor in the SMI Security for PKIX
	Access Descriptor registry: http://www.iana.org/assignments/smi-		Access Descriptor registry: http://www.iana.org/assignments/smi-
	numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48		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 The TN ASN.1 module in SMI Security for PKIX Module Identifier
	registry: http://www.iana.org/assignments/smi-numbers/smi-		registry: http://www.iana.org/assignments/smi-numbers/smi-
	numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0		numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0
	This document also makes use of the Level of Assurance (LoA) Profiles		12. Security Considerations
	registry defined in [RFC6711] because as is stated in RFC 6711: "Use
	of the registry by protocols other than SAML is encouraged." IANA is
	requested to creae the STIR Levels of Assurance (LOA) sub-registry in
	the Level of Assurance (LoA) Profile registry. Instead of
	registering a SAML Context Class, the Certificate Policy's Object
	Identifier representing the LOA is included in the registry. An
	example registration is as follows:
	To: loa-profiles-experts@icann.org
	From: jrandom@example.com
	1. Name of requester: J. Random User
	2. Email address of requester: jrandom@example.com
	3. Organization of requester: Example Trust Frameworks LLP
	4. Requested registration:
	URI http://foo.example.com/assurance/loa-1
	Name foo-loa-1
	Informational URL https://foo.example.com/assurance/
	Certificate Policy Object Identifier: 0.0.0.0
	NOTE: Do not register this example. The OID is purposely invalid.
	Experts are expected to ensure the reference CP includes the OID
	being registered.
	11. 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. For OCSP-related security considerations		Security Considerations. For OCSP-related security considerations
	see [RFC6960] and [RFC5019]		see [RFC6960] and [RFC5019]
	12. Acknowledgments		13. Acknowledgments
	Russ Housley, Brian Rosen, Cullen Jennings, Dave Crocker, Tony		Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave
	Rutkowski, John Braunberger, and Eric Rescorla provided key input to		Crocker, Tony Rutkowski, John Braunberger, and Eric Rescorla provided
	the discussions leading to this document.		key input to the discussions leading to this document. Russ Housley
			provided some direct assistance and text surrounding the ASN.1
			module.
	13. References		14. References
	[ATIS-0300050]		[ATIS-0300050]
	ATIS Recommendation 0300050, "Carrier Identification Code		ATIS Recommendation 0300050, "Carrier Identification Code
	(CIC) Assignment Guidelines", 2012.		(CIC) Assignment Guidelines", 2012.
	[I-D.ietf-stir-passport]		[I-D.ietf-stir-passport]
	Wendt, C. and J. Peterson, "Persona Assertion Token",		Wendt, C. and J. Peterson, "Personal Assertion Token
	draft-ietf-stir-passport-07 (work in progress), September		(PASSporT)", draft-ietf-stir-passport-08 (work in
	2016.		progress), September 2016.
	[I-D.ietf-stir-rfc4474bis]		[I-D.ietf-stir-rfc4474bis]
	Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,		Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
	"Authenticated Identity Management in the Session		"Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-11		Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-13
	(work in progress), August 2016.		(work in progress), September 2016.
	[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,
	<http://www.rfc-editor.org/info/rfc2046>.		<http://www.rfc-editor.org/info/rfc2046>.
	[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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	skipping to change at page 20, line 14 ¶		skipping to change at page 20, line 20 ¶
	[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,
	<http://www.rfc-editor.org/info/rfc5912>.		<http://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,		DOI 10.17487/RFC5958, August 2010,
	<http://www.rfc-editor.org/info/rfc5958>.		<http://www.rfc-editor.org/info/rfc5958>.
	[RFC6711] Johansson, L., "An IANA Registry for Level of Assurance
	(LoA) Profiles", RFC 6711, DOI 10.17487/RFC6711, August
	2012, <http://www.rfc-editor.org/info/rfc6711>.
	[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,		[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
	Galperin, S., and C. Adams, "X.509 Internet Public Key		Galperin, S., and C. Adams, "X.509 Internet Public Key
	Infrastructure Online Certificate Status Protocol - OCSP",		Infrastructure Online Certificate Status Protocol - OCSP",
	RFC 6960, DOI 10.17487/RFC6960, June 2013,		RFC 6960, DOI 10.17487/RFC6960, June 2013,
	<http://www.rfc-editor.org/info/rfc6960>.		<http://www.rfc-editor.org/info/rfc6960>.
	[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)		[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
	Multiple Certificate Status Request Extension", RFC 6961,		Multiple Certificate Status Request Extension", RFC 6961,
	DOI 10.17487/RFC6961, June 2013,		DOI 10.17487/RFC6961, June 2013,
	<http://www.rfc-editor.org/info/rfc6961>.		<http://www.rfc-editor.org/info/rfc6961>.
	skipping to change at page 21, line 45 ¶		skipping to change at page 21, line 45 ¶
	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 specification published in 2015 (see [X.680], [X.681],
	[X.682], [X.683]). None of the newly defined tokens in the 2008		[X.682], [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, RELATIVE-
	OID-IRI, TIME, TIME-OF-DAY)) are currently used in any of the ASN.1		OID-IRI, TIME, TIME-OF-DAY)) are currently used in any of the ASN.1
	specifications referred to here.		specifications referred to here.
	This ASN.1 module imports ASN.1 from [RFC5912].		This ASN.1 module imports ASN.1 from [RFC5912].
	TN-Module {		TN-Module-2016 {
	iso(1) identified-organization(3) dod(6) internet(1)		iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-tn-module(TBD) }		id-mod-tn-module(TBD) }
	DEFINITIONS EXPLICIT TAGS ::= BEGIN		DEFINITIONS EXPLICIT TAGS ::= BEGIN
	IMPORTS		IMPORTS
	id-ad, id-ad-ocsp -- From [RFC5912]		id-ad, id-ad-ocsp -- From [RFC5912]
	FROM PKIX1Explicit-2009 {		FROM PKIX1Explicit-2009 {
	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) }
	id-ce -- From [RFC5912]		id-ce -- From [RFC5912]
	FROM PKIX1Implicit-2009 {		FROM PKIX1Implicit-2009 {
	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-implicit-02(59) }		mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) }
	EXTENSION -- From [RFC5912]		EXTENSION -- From [RFC5912]
	FROM PKIX-CommonTypes-2009 {		FROM PKIX-CommonTypes-2009 {
	iso(1) identified-organization(3) dod(6) internet(1)		iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-pkixCommon-02(57) }		id-mod-pkixCommon-02(57) }
	;		;
	-- TN Entry Certificate Extension		--
			-- JWT Claim Constraints Certificate Extension
			--
	ext-tnAuthList EXTENSION ::= {		ext-jwtClaimConstraints EXTENSION ::= {
	SYNTAX TNAuthorizationList IDENTIFIED BY id-ce-TNAuthList }		SYNTAX JWTClaimConstraints IDENTIFIED BY id-ce-JWTClaimConstraints }
	TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNAuthorization		id-ce-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-ce TBD1 }
	TNAuthorization ::= SEQUENCE SIZE (1..MAX) OF TNEntry		JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint
	TNEntry ::= CHOICE {		JWTClaimConstraint ::= SEQUENCE {
	spid [0] ServiceProviderIdentifierList,		claim IA5String,
	range [1] TelephoneNumberRange,		permitted [1] SEQUENCE OF IA5String OPTIONAL,
	one E164Number }		excluded [2] SEQUENCE OF IA5String OPTIONAL }
			( WITH COMPONENTS { ..., permitted PRESENT } |
			WITH COMPONENTS { ..., excluded PRESENT } )
	ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF		--
	OCTET STRING		-- Telephone Number Authorization List Certificate Extension
			--
	-- When all three are present: SPID, Alt SPID, and Last Alt SPID		ext-tnAuthList EXTENSION ::= {
			SYNTAX TNAuthorizationList IDENTIFIED BY id-ce-TNAuthList }
	TelephoneNumberRange ::= SEQUENCE {		id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD2 }
	start E164Number,
	count INTEGER }
	E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789"))		TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
			TNEntry ::= CHOICE {
			spid [0] ServiceProviderIdentifierList,
			range [1] TelephoneNumberRange,
			one E164Number }
	-- TN OCSP Extension		ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF
			OCTET STRING
	re-ocsp-tn-query EXTENSION ::= {		-- Allows SPID, Alt SPID, and Last Alt SPID to be present
	SYNTAX TNQuery IDENTIFIED BY id-pkix-ocsp-stir-tn }
	TNQuery ::= E164Number		TelephoneNumberRange ::= SEQUENCE {
			start E164Number,
			count INTEGER }
	-- TN Access Descriptor		E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789"))
	id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD }		--
			-- Telephone Number Query OCSP Extension
			--
	--		re-ocsp-tn-query EXTENSION ::= {
	-- Object Identifiers		SYNTAX TNQuery IDENTIFIED BY id-ad-stir-tn }
	--
	id-pkix-ocsp OBJECT IDENTIFIER ::= id-ad-ocsp		TNQuery ::= E164Number
	id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD }
	id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD }
	END		id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD3 }
			END
	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. 77 change blocks.
	183 lines changed or deleted		196 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/