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