< draft-ietf-stir-certificates-11.txt		draft-ietf-stir-certificates-12.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: May 4, 2017 sn3rd		Expires: September 14, 2017 sn3rd
	October 31, 2016		March 13, 2017
	Secure Telephone Identity Credentials: Certificates		Secure Telephone Identity Credentials: Certificates
	draft-ietf-stir-certificates-11.txt		draft-ietf-stir-certificates-12.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 May 4, 2017.		This Internet-Draft will expire on September 14, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 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 . . . . . . . 4		3. Authority for Telephone Numbers in Certificates . . . . . . . 3
	4. Certificate Usage with STIR . . . . . . . . . . . . . . . . . 5		4. Certificate Usage with STIR . . . . . . . . . . . . . . . . . 5
	5. Enrollment and Authorization using the TN Authorization List 6		5. Enrollment and Authorization using the TN Authorization List 6
	5.1. Constraints on Signing PASSporTs . . . . . . . . . . . . 8		5.1. Constraints on Signing PASSporTs . . . . . . . . . . . . 7
	5.2. Certificate Extension Scope and Structure . . . . . . . . 8		5.2. Certificate Extension Scope and Structure . . . . . . . . 8
	6. Provisioning Private Keying Material . . . . . . . . . . . . 9		6. Provisioning Private Keying Material . . . . . . . . . . . . 8
	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 . . . . . . . . . . . . 12		10. Certificate Freshness and Revocation . . . . . . . . . . . . 13
	10.1. Choosing a Verification Method . . . . . . . . . . . . . 13		10.1. Acquiring TN Lists By Reference . . . . . . . . . . . . 13
	10.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 14		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	10.2.1. OCSP Extension Specification . . . . . . . . . . . . 15		12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	10.3. Acquiring TN Lists By Reference . . . . . . . . . . . . 17		13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 18		14.1. Normative References . . . . . . . . . . . . . . . . . . 15
	13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		14.2. Informative References . . . . . . . . . . . . . . . . . 17
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18
	14.1. Normative References . . . . . . . . . . . . . . . . . . 18		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	14.2. Informative References . . . . . . . . . . . . . . . . . 20
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 21
	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
	access a voicemail system. Robocallers use impersonation as a means		access a voicemail system. Robocallers use impersonation as a means
	of obscuring identity; while robocallers can, in the ordinary PSTN,		of obscuring identity; while robocallers can, in the ordinary PSTN,
	block (that is, withhold) their caller identity, callees are less		block (that is, withhold) their caller identity, callees are less
	likely to pick up calls from blocked identities, and therefore		likely to pick up calls from blocked identities, and therefore
	appearing to calling from some number, any number, is preferable.		appearing to call from some number, any number, is preferable.
	Robocallers however prefer not to call from a number that can trace		Robocallers however prefer not to call from a number that can trace
	back to the robocaller, and therefore they impersonate numbers that		back to the robocaller, and therefore they impersonate numbers that
	are not assigned to them.		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 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
	skipping to change at page 4, line 17 ¶		skipping to change at page 4, line 11 ¶
	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 codes
	Identifiers (SPIDs) via the TN Authorization List specified in this		(SPCs) such as OCNs or SPIDs via the TN Authorization List specified
	document. A relying party could then employ an external data set or		in this document. A relying party could then employ an external data
	service that determines whether or not a specific telephone number is		set or service that determines whether or not a specific telephone
	under the authority of the carrier identified as the subject of the		number is under the authority of the carrier identified as the
	certificate, and use that to ascertain whether or not the carrier		subject of the certificate, and use that to ascertain whether or not
	should have authority over a telephone number. Potentially, a		the carrier should have authority over a telephone number.
	certificate extension to convey the URI of such an information		Potentially, a certificate extension to convey the URI of such an
	service trusted by the issuer of the certificate could be developed		information service trusted by the issuer of the certificate could be
	(though this specification does not propose one). Alternatively,		developed (though this specification does not propose one).
	some relying parties could form bilateral or multilateral trust		Alternatively, some relying parties could form bilateral or
	relationships with peer carriers, trusting one another's assertions		multilateral trust relationships with peer carriers, trusting one
	just as telephone carriers in the SS7 network today rely on		another's assertions just as telephone carriers in the SS7 network
	transitive trust when displaying the calling party telephone number		today rely on transitive trust when displaying the calling party
	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 TN Authorization List, which
	contains a list of telephone numbers defining the scope of authority		contains a list of telephone numbers defining the scope of authority
	of the certificate. Relying parties, if they trust the issuer of the		of the certificate. Relying parties, if they trust the issuer of the
	certificate as a source of authoritative information on telephone		certificate as a source of authoritative information on telephone
	numbers, could therefore use the TN Authorization List instead of the		numbers, could therefore use the TN Authorization List instead of the
	subject of the certificate to make a decision about whether or not		subject of the certificate to make a decision about whether or not
	the signer has authority over a particular telephone number. The TN		the signer has authority over a particular telephone number. The TN
	Authorization List could be provided in one of two ways: as a literal		Authorization List could be provided in one of two ways: as a literal
	skipping to change at page 5, line 30 ¶		skipping to change at page 5, line 24 ¶
	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 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		[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 [RFC3986] schemes permitted in the SIP Identity header
	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, CID and SIP URI		Section 7, this mechanism permits the HTTP [RFC7230], CID and SIP
	schemes to appear in the "info" parameter.		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
	skipping to change at page 6, line 36 ¶		skipping to change at page 6, line 28 ¶
	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 relying parties		o See Section 7 for requirements related to relying parties
	acquiring credentials.		acquiring credentials.
	o See Section 10.2 and Section 10.3 for requirements related to the		o See Section 10 and Section 10.1 for requirements related to
	Authority Information Access (AIA) certificate extension.		certificate freshness and the Authority Information Access (AIA)
			certificate extension.
	o See Section 10.2.1 for requirements related to the authority key
	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,
	telephone number blocks are assigned to Local Exchange Carriers		telephone number blocks are assigned to Local Exchange Carriers
	skipping to change at page 8, line 10 ¶		skipping to change at page 7, line 45 ¶
	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 JSON Web Token (JWT) [RFC7519] that conforms to the conventions
	specified in PASSporT [I-D.ietf-stir-passport]. This specification		specified in PASSporT [I-D.ietf-stir-passport]. This specification
	supports constraints on the JWT claims, which allows the CA to		supports constraints on the JWT claims, which allows the CA to grant
	differentiate those enrolled from proof-of-possession versus		different permissions to certificate holders, for example those
	delegation. A Certification Policy and a Certification Practice		enrolled from proof-of-possession versus delegation. A Certification
	Statement [RFC3647] are produced as part of the normal PKI		Policy and a Certification Practice Statement [RFC3647] are produced
	bootstrapping process, (i.e., the CP is written first and then the CA		as part of the normal PKI bootstrapping process, (i.e., the CP is
	says how it conforms to the CP in the CPS). A CA that wishes to		written first and then the CA says how it conforms to the CP in the
	place constraints on the JWT claims MUST include the JWT Claim		CPS). A CA that wishes to place constraints on the JWT claims MUST
	Constraints certificate extension in issued certificates. See		include the JWT Claim Constraints certificate extension in issued
	Section 8 for information about the certificate extension.		certificates. See Section 8 for information about the certificate
			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 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 10, line 8 ¶		skipping to change at page 9, line 43 ¶
	request along with the signature itself. In SIP, for example, a		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 is
	not feasible due to message size restrictions or lack of necessary		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, via		function (via the SUBSCRIBE/NOTIFY mechanism) as well as HTTP and
	the Enrollment over Secure Transport mechanisms described in RFC 7030		HTTPS.
	[RFC7030].
	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
	The subjects of certificates containing the JWT Claim Constraints		The subjects of certificates containing the JWT Claim Constraints
	certificate extension are specifies values for claims that are		certificate extension are specifies values for PASSporT claims that
	permitted, values for claims that are excluded, or both. When a		are permitted, values for PASSporT claims that are excluded, or both.
	verifier is validating PASSporT claims, the JWT claim MUST contain		The syntax of these claims is given in PASSporT; specifying new
	permitted values, and MUST NOT contain excluded values. The JWT		claims follows the procedures in [I-D.ietf-stir-passport]
	Claim Constraints certificate extension is included in the extension		(Section 8.3). When a verifier is validating PASSporT claims, the
	field of the certificate [RFC5280]. The extension is defined with		JWT claim MUST contain permitted values, and MUST NOT contain
	ASN.1 [X.680][X.681][X.682] [X.683].		excluded values. The non-critical JWT Claim Constraints certificate
			extension is included in the extension field of end entity
			certificates [RFC5280]. The extension is defined with ASN.1
			[X.680][X.681][X.682] [X.683].
			The JWT Claim Constraints certificate extension places constraints on
			the values that are allowed in particular JWT claims. This
			certificate extension is optional, but if present, it constraints the
			claims that authentication services may include in the PASSporT
			objects they sign. For example, imagine a PASSporT extension claim
			called "confidence". If a CA issue to an authentication service a
			certificate that contains the value "confidence" in the "permitted"
			field of the JWT Claim Constraints, then an authentication service
			MAY add a "confidence" claim to any PASSporTs it generates. A
			verification service MUST treat as invalid any PASSporT it receives
			with a PASSporT extension claim that is not included in JWT Claim
			Constraints The baseline claims of PASSporT ("orig", "dest", "iat"
			and "mky") are considered to be permitted by default and SHOULD NOT
			be included in a "permitted" field of the certificate." The issuer
			of a certificate may similarly explicitly allow the use of a
			particular claim by the holder of the certificate. If a certificate
			contains no JWT Claim Constraints, the issuer of the certificate
			permits all claims.
	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 25 }
	The JWT Claim Constraints certificate extension has the following		The JWT Claim Constraints certificate extension has the following
	syntax:		syntax:
	JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint		JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint
	JWTClaimConstraint ::= SEQUENCE {		JWTClaimConstraint ::= SEQUENCE {
	claim IA5String,		claim IA5String,
	permitted [1] SEQUENCE OF IA5String OPTIONAL,		permitted SEQUENCE OF IA5String
	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		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		non critical Telephony Number (TN) Authorization List certificate
	included in the Certificate's extension field [RFC5280]. The		extension is included in the Certificate's extension field [RFC5280].
	extension is defined with ASN.1 [X.680][X.681][X.682] [X.683]. What		The extension is defined with ASN.1 [X.680][X.681][X.682] [X.683].
	follows is the syntax and semantics of the extension.		What follows is the syntax and semantics of the extension.
			The subjects of certificates containing the TN Authorization List
			extension are the administrative entities to whom numbers are
			assigned or delegated. In an end entity certificate, TN
			Authorization List indicates the TNs which the certificate has been
			authorized. In a CA certificate, the TN Authorization List limits
			the set of TNs for certification paths that include this certificate.
	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-pe OID arc defined in [RFC5280] and managed by IANA (see		under the id-pe 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 {
	spid [0] ServiceProviderIdentifierList,		spc [0] ServiceProviderCodeList,
	range [1] TelephoneNumberRange,		range [1] TelephoneNumberRange,
	one E164Number }		one E164Number }
	ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF		ServiceProviderCodeList ::= SEQUENCE SIZE (1..3) OF
	OCTET STRING		IA%String
	-- Allows SPID, Alt SPID, and Last Alt SPID to be present		-- Service Provider Codes may be OCNs, various SPIDs, or other SP identifiers from the telephone network
	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. Service Provider Codes as described in this document are a
	Company Number (OCN) as specified in [ATIS-0300251]) can be used		generic term for the identifiers used to designate service
	to indirectly name all of the telephone numbers associated with		providers in the telepohone networks today. In North American
	that identifier for a service provider,		context, these would include Operating Company Numbers (OCNs) as
			specified in [ATIS-0300251], related Service Provide Identifiers
			(SPIDs), or other similar identifiers for service providers.
			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, or
	3. A single telephone number can be listed (as an E164Number).		3. A single telephone number can be listed (as an E164Number).
	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		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. For more on this optimization, see		authority of this certificate. For more on this optimization, see
	Section 10.3.		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 SPIDs), because verifiers		numbers or number ranges (as opposed to SPCs), because verifiers must
	must establish not only that a certificate remains valid, but also		establish not only that a certificate remains valid, but also that
	that the certificate's scope contains the telephone number that the		the certificate's scope contains the telephone number that the
	verifier is validating. Dynamic changes to number assignments can		verifier is validating. Dynamic changes to number assignments can
	occur due to number portability, for example. So even if a verifier		occur due to number portability, for example. So even if a verifier
	has a valid cached certificate for a telephone number (or a range		has a 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 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 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, see		(b) Rely on status information from the authority (e.g., OCSP)
	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 some approaches to
	generating a short-lived certificate for each call, and consequently		generating a short-lived certificate, like requiring one for each
	performing enrollment for each call, is more of an impact than		call, would incur a greater operational cost than acquiring status
	acquiring status information. This document therefore details an		information. This document makes no particular recommndation for a
	approach for relying on status information.		means of determinate certificate freshness for STIR, as this requires
			further study and implementation experience. Acquiring online status
	10.1. Choosing a Verification Method		information for certificates has the potential to disclose private
			information [RFC7258] if proper precautions are not taken. Future
	There are three common certificate verification mechanisms employed		specifications that define certificate freshness mechanisms for STIR
	by CAs:		MUST note any such risks and provide countermeasures where possible.
	1. Certificate Revocation Lists (CRLs) [RFC5280]
	2. Online Certificate Status Protocol (OCSP) [RFC6960], and
	3. Server-based Certificate Validation Protocol (SCVP) [RFC5055].
	When relying on status information, the verifier needs to obtain the
	status information - but before that can happen, the verifier needs
	to know where to locate it. Placing the location of the status
	information in the certificate makes the certificate larger, but it
	eases the client workload. The CRL Distribution Point certificate
	extension includes the location of the CRL and the Authority
	Information Access certificate extension includes the location of
	OCSP and/or SCVP servers; both of these extensions are defined in
	[RFC5280]. In all cases, the status information location is provided
	in the form of an URI.
	CRLs are an obviously attractive solution because they are supported
	by every CA. CRLs have a reputation of being quite large (10s of
	MBytes), because CAs maintain and issue one monolithic CRL with all
	of their revoked certificates, but CRLs do support a variety of
	mechanisms to scope the size of the CRLs based on revocation reasons
	(e.g., key compromise vs CA compromise), user certificates only, and
	CA certificates only as well as just operationally deciding to keep
	the CRLs small. However, scoping the CRL introduces other issues
	(i.e., does the RP have all of the CRL partitions).
	CAs in the STIR architecture will likely all create CRLs for audit
	purposes, but it NOT RECOMMENDED that they be relied upon for status
	information. Instead, one of the two "online" options is preferred.
	Between the two, OCSP is much more widely deployed and this document
	therefore RECOMMENDS the use of OCSP in high-volume environments
	(HVE) for validating the freshness of certificates, based on
	[RFC6960], incorporating some (but not all) of the optimizations of
	[RFC5019]. CRLs MUST be signed with the same algorithm as the
	certificate.
	10.2. Using OCSP with TN Auth List
	Certificates compliant with this specification therefore SHOULD
	include a URL pointing to an OCSP service in the Authority
	Information Access (AIA) certificate extension, via the "id-ad-ocsp"
	accessMethod specified in [RFC5280]. It is RECOMMENDED that entities
	that issue certificates with the Telephone Number Authorization List
	certificate extension run an OCSP server for this purpose. Baseline
	OCSP however supports only three possible response values: good,
	revoked, or unknown. Without some extension, OCSP would not indicate
	whether the certificate is authorized for a particular telephone
	number that the verifier is validating.
	At a high level, there are two ways that a client might pose this
	authorization question:
	For this certificate, is the following number currently in its
	scope of validity?
	What are all the telephone numbers associated with this
	certificate, or this certificate subject?
	Only the former lends itself to piggybacking on the OCSP status
	mechanism; since the verifier is already asking an authority about
	the certificate's status, that mechanism can be reused instead of
	creating a new service that requires additional round trips? Like
	most PKIX-developed protocols, OCSP is extensible; OCSP supports
	request extensions (including sending multiple requests at once) and
	per-request extensions. It seems unlikely that the verifier will be
	requesting authorization checks on multiple telephone numbers in one
	request, so a per-request extension is what is needed.
	The requirement to consult OCSP in real time results in a network
	round-trip delay, which is something to consider because it will add
	to the call setup time. OCSP server implementations commonly pre-
	generate responses, and to speed up HTTPS connections, servers often
	provide OCSP responses for each certificate in their hierarchy. If
	possible, both of these OCSP concepts should be adopted for use with
	STIR.
	10.2.1. OCSP Extension Specification
	The extension mechanism for OCSP follows X.509 v3 certificate
	extensions, and thus requires an OID, a criticality flag, and ASN.1
	syntax as defined by the OID. The criticality specified here is
	optional: per [RFC6960] Section 4.4, support for all OCSP extensions
	is optional. If the OCSP server does not understand the requested
	extension, it will still provide the baseline validation of the
	certificate itself. Moreover, in practical STIR deployments, the
	issuer of the certificate will set the accessLocation for the OCSP
	AIA extension to point to an OCSP service that supports this
	extension, so the risk of interoperability failure due to lack of
	support for this extension is minimal.
	The OCSP TNQuery extension is included as one of the request's
	singleRequestExtensions. It may also appear in the response's
	singleExtensions. When an OCSP server includes a number in the
	response's singleExtensions, this informs the client that the
	certificate is still valid for the number that appears in the TNQuery
	extension field. If the TNQuery is absent from a response to a query
	containing a TNQuery in its singleRequestExtension, then the server
	is not able to validate that the number is still in the scope of
	authority of the certificate.
	id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp 10 }
	TNQuery ::= E164Number
	The HVE OCSP profile [RFC5019] prohibits the use of per-request
	extensions. As it is anticipated that STIR will use OCSP in a high-
	volume environment, many of the optimizations recommended by HVE are
	desirable for the STIR environment. This document therefore uses the
	HVE optimizations augmented as follows:
	o Implementations MUST use SHA-256 as the hashing algorithm for the
	CertID.issuerNameHash and the CertID.issuerKeyHash values. That
	is CertID.hashAlgorithm is id-sha256 [RFC4055] and the values are
	truncated to 160-bits as specified Option 1 in Section 2 of
	[RFC7093].
	o Clients MUST include the OCSP TNQuery extension in requests'
	singleRequestExtensions.
	o Servers MUST include the OCSP TNQuery extension in responses'
	singleExtensions.
	o Servers SHOULD return responses that would otherwise have been
	"unknown" as "not good" (i.e., return only "good" and "not good"
	responses).
	o Clients MUST treat returned "unknown" responses as "not good".
	o If the server uses ResponderID, it MUST generate the KeyHash using
	SHA-256 and truncate the value to 160-bits as specified in Option
	1 in Section 2 of [RFC7093].
	o Implementations MUST support ECDSA using P-256 and SHA-256. Note
	that [RFC6960] requires RSA with SHA-256 be supported.
	o There is no requirement to support SHA-1, RSA with SHA-1, or DSA
	with SHA-1.
	OCSP responses MUST be signed using the same algorithm as the
	certificate being checked.
	To facilitate matching the authority key identifier values found in
	CA certificates with the KeyHash used in the OCSP response,
	certificates compliant with this specification MUST generate
	authority key identifiers and subject key identifiers using the
	SHA-256 and truncate the value to 160-bits as specified in Option 1
	in Section 2 of [RFC7093].
	Ideally, once a certificate has been acquired by a verifier, some
	sort of asynchronous mechanism could notify and update the verifier
	if the scope of the certificate changes so that verifiers could
	implement a cache. While not all possible categories of verifiers
	could implement such behavior, some sort of event-driven notification
	of certificate status is another potential subject of future work.
	One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based
	accessMethod for AIA might be defined (which would also be applicable
	to the method described in the following section) by some future
	specification.
	Strategies for stapling OCSP [RFC6961] have become common in some web		10.1. Acquiring TN Lists By Reference
	PKI environments as an optimization which allows web servers to send
	up-to-date certificate status information acquired from OCSP to
	clients as TLS is negotiated. A similar mechanism could be
	implemented for SIP requests, in which the authentication service
	adds status information for its certificate to the SIP request, which
	would save the verifier the trouble of performing the OCSP dip
	itself. Especially for high-volume authentication and verification
	services, this could result in significant performance improvements.
	This is left as an optimization for future work.
	10.3. Acquiring TN Lists By Reference		One alternative to checking certificate status for a particular
			telephone number is simply acquiring the TN Authorization List by
			reference, that is, through dereferencing a URL in the certificate,
			rather than including the value of the TN Authorization List in the
			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 OCSP, one which could be		query/response interaction outside of certificate status, one which
	initiated through a separate URI included in the certificate. The		could be initiated through a separate URI included in the
	AIA extension (see [RFC5280]) supports such a mechanism: it		certificate. The AIA extension (see [RFC5280]) supports such a
	designates an OID to identify the accessMethod and an accessLocation,		mechanism: it designates an OID to identify the accessMethod and an
	which would most likely be a URI. A verifier would then follow the		accessLocation, which would most likely be a URI. A verifier would
	URI to ascertain whether the list of TNs are authorized for use by		then follow the URI to ascertain whether the list of TNs are
	the caller.		authorized for use by 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-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. The document returned by dereferencing that
	skipping to change at page 17, line 40 ¶		skipping to change at page 14, line 40 ¶
	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		This document makes use of object identifiers for the TN Certificate
	Extension defined in Section 9, TN-HVE OCSP extension in		Extension defined in Section 9, the TN by reference AIA access
	Section 10.2.1, the TN by reference AIA access descriptor defined in		descriptor defined in Section 10.1, and the ASN.1 module identifier
	Section 10.3, and the ASN.1 module identifier defined in Appendix A.		defined in Appendix A. It therefore requests that the IANA make the
	It therefore requests that the IANA make the following assignments:		following assignments:
	o JWT Claim Constraints Certificate Extension in the SMI Security		o JWT Claim Constraints Certificate Extension in the SMI Security
	for PKIX Certificate Extension registry:		for PKIX Certificate Extension 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.1		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
	Certificate Status Protocol (OCSP) registry:
	http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-
	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
	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. For OCSP-related security considerations		Security Considerations.
	see [RFC6960] and [RFC5019]
	13. Acknowledgments		13. Acknowledgments
	Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave		Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave
	Crocker, Tony Rutkowski, John Braunberger, and Eric Rescorla provided		Crocker, Tony Rutkowski, John Braunberger, and Eric Rescorla provided
	key input to the discussions leading to this document. Russ Housley		key input to the discussions leading to this document. Russ Housley
	provided some direct assistance and text surrounding the ASN.1		provided some direct assistance and text surrounding the ASN.1
	module.		module.
	14. References		14. References
	skipping to change at page 18, line 47 ¶		skipping to change at page 15, line 45 ¶
	[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 | NIST FIPS PUB 186-4, "Digital		Department of Commerce | NIST FIPS PUB 186-4, "Digital
	Signature Standard, version 4", 2013.		Signature Standard, version 4", 2013.
	[I-D.ietf-stir-passport]		[I-D.ietf-stir-passport]
	Wendt, C. and J. Peterson, "Personal Assertion Token		Wendt, C. and J. Peterson, "Personal Assertion Token
	(PASSporT)", draft-ietf-stir-passport-10 (work in		(PASSporT)", draft-ietf-stir-passport-11 (work in
	progress), October 2016.		progress), February 2017.
	[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-14		Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
	(work in progress), October 2016.		(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,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource		[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
	Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,		Locators", RFC 2392, DOI 10.17487/RFC2392, August 1998,
	<http://www.rfc-editor.org/info/rfc2392>.		<http://www.rfc-editor.org/info/rfc2392>.
	[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography		[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
	Standards (PKCS) #1: RSA Cryptography Specifications		Standards (PKCS) #1: RSA Cryptography Specifications
	Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February		Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
	2003, <http://www.rfc-editor.org/info/rfc3447>.		2003, <http://www.rfc-editor.org/info/rfc3447>.
	[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Algorithms and Identifiers for RSA Cryptography for use in		Resource Identifier (URI): Generic Syntax", STD 66,
	the Internet X.509 Public Key Infrastructure Certificate		RFC 3986, DOI 10.17487/RFC3986, January 2005,
	and Certificate Revocation List (CRL) Profile", RFC 4055,		<http://www.rfc-editor.org/info/rfc3986>.
	DOI 10.17487/RFC4055, June 2005,
	<http://www.rfc-editor.org/info/rfc4055>.
	[RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online		[RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online
	Certificate Status Protocol (OCSP) Profile for High-Volume		Certificate Status Protocol (OCSP) Profile for High-Volume
	Environments", RFC 5019, DOI 10.17487/RFC5019, September		Environments", RFC 5019, DOI 10.17487/RFC5019, September
	2007, <http://www.rfc-editor.org/info/rfc5019>.		2007, <http://www.rfc-editor.org/info/rfc5019>.
	[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,
	skipping to change at page 20, line 11 ¶		skipping to change at page 17, line 5 ¶
	[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>.
	[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>.
	[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	"Enrollment over Secure Transport", RFC 7030,		Protocol (HTTP/1.1): Message Syntax and Routing",
	DOI 10.17487/RFC7030, October 2013,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<http://www.rfc-editor.org/info/rfc7030>.		<http://www.rfc-editor.org/info/rfc7230>.
	[RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods		[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
	for Generating Key Identifiers Values", RFC 7093,		Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
	DOI 10.17487/RFC7093, December 2013,		2014, <http://www.rfc-editor.org/info/rfc7258>.
	<http://www.rfc-editor.org/info/rfc7093>.
	[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>.		<http://www.rfc-editor.org/info/rfc7519>.
	[X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8,		[X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8,
	"Information technology - Open Systems Interconnection -		"Information technology - Open Systems Interconnection -
	The Directory: Public-key and attribute certificate		The Directory: Public-key and attribute certificate
	frameworks", 2012.		frameworks", 2012.
	skipping to change at page 21, line 11 ¶		skipping to change at page 18, line 5 ¶
	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>.
	[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,
	<http://www.rfc-editor.org/info/rfc3647>.		<http://www.rfc-editor.org/info/rfc3647>.
	[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W.
	Polk, "Server-Based Certificate Validation Protocol
	(SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007,
	<http://www.rfc-editor.org/info/rfc5055>.
	[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
	Multiple Certificate Status Request Extension", RFC 6961,
	DOI 10.17487/RFC6961, June 2013,
	<http://www.rfc-editor.org/info/rfc6961>.
	[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>.		<http://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>.		<http://www.rfc-editor.org/info/rfc7375>.
	[X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6,		[X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6,
	skipping to change at page 22, line 19 ¶		skipping to change at page 19, line 4 ¶
	id-ad, id-ad-ocsp, id-pe -- From [RFC5912]		id-ad, id-ad-ocsp, id-pe -- 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) }
	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) }
	;		;
	id-pkix-ocsp OBECT IDENTIFIER ::= id-ad-ocsp
	--		--
	-- 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 25 }
	JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint		JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint
	skipping to change at page 23, line 4 ¶		skipping to change at page 19, line 34 ¶
	--		--
	-- Telephone Number Authorization List Certificate Extension		-- Telephone 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		TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
	TNEntry ::= CHOICE {		TNEntry ::= CHOICE {
	spid [0] ServiceProviderIdentifierList,		spc [0] ServiceProviderCodeList,
	range [1] TelephoneNumberRange,		range [1] TelephoneNumberRange,
	one E164Number }		one E164Number }
	ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF		ServiceProviderCodeList ::= SEQUENCE SIZE (1..3) OF
	OCTET STRING		IA5STRING
	-- Allows SPID, Alt SPID, and Last Alt SPID to be present		-- Service Provider Codes may be OCNs, various SPIDs, or other SP identifiers from the telephone network
	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"))
	--
	-- Telephone Number Query OCSP Extension
	--
	re-ocsp-tn-query EXTENSION ::= {
	SYNTAX TNQuery IDENTIFIED BY id-pkix-ocsp-stir-tn }
	TNQuery ::= E164Number
	id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp 10 }
	-- TN Access Descriptor		-- TN Access Descriptor
	id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 }		id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 }
	END		END
	Authors' Addresses		Authors' Addresses
	Jon Peterson		Jon Peterson
	Neustar, Inc.		Neustar, Inc.
End of changes. 50 change blocks.
	347 lines changed or deleted		170 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/