< draft-ietf-stir-certificates-04.txt		draft-ietf-stir-certificates-05.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: November 27, 2016 Sn3rd		Expires: December 27, 2016 sn3rd
	May 26, 2016		June 25, 2016
	Secure Telephone Identity Credentials: Certificates		Secure Telephone Identity Credentials: Certificates
	draft-ietf-stir-certificates-04.txt		draft-ietf-stir-certificates-05.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 proves authority over telephone numbers. This		cryptographically proves authority over telephone numbers. This
	document describes the use of certificates in establishing authority		document describes the use of certificates in establishing authority
	over telephone numbers, as a component of a broader architecture for		over telephone numbers, as a component of a broader architecture for
	managing telephone numbers as identities in protocols like SIP.		managing telephone numbers as identities in protocols like SIP.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on November 27, 2016.		This Internet-Draft will expire on December 27, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 26 ¶		skipping to change at page 2, line 26 ¶
	7. Acquiring Credentials to Verify Signatures . . . . . . . . . 8		7. Acquiring Credentials to Verify Signatures . . . . . . . . . 8
	8. Verifying Certificate Scope with TN Authorization List . . . 9		8. Verifying Certificate Scope with TN Authorization List . . . 9
	9. Certificate Freshness and Revocation . . . . . . . . . . . . 11		9. Certificate Freshness and Revocation . . . . . . . . . . . . 11
	9.1. Choosing a Verification Method . . . . . . . . . . . . . 11		9.1. Choosing a Verification Method . . . . . . . . . . . . . 11
	9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 12		9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 12
	9.2.1. OCSP Extension Specification . . . . . . . . . . . . 13		9.2.1. OCSP Extension Specification . . . . . . . . . . . . 13
	9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 14		9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 14
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 16		12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	13. Informative References . . . . . . . . . . . . . . . . . . . 16		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 19		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
	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,
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 4 ¶
	curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447]		curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447]
	Section 8.2) for certificate signatures. Implementers are		Section 8.2) for certificate signatures. Implementers are
	advised that RS256 is mandated only as a transitional mechanism,		advised that RS256 is mandated only as a transitional mechanism,
	due to its widespread use in existing PKI, but we anticipate that		due to its widespread use in existing PKI, but we anticipate that
	this mechanism will eventually be deprecated.		this mechanism will eventually be deprecated.
	5. Finally, note that all certificates compliant with this		5. Finally, note that all certificates compliant with this
	specification MUST provide cryptographic keying material		specification MUST provide cryptographic keying material
	sufficient to generate the ECDSA P-256 signatures necessary to		sufficient to generate the ECDSA P-256 signatures necessary to
	support the ES256 hashed signatures required by PASSporT		support the ES256 hashed signatures required by PASSporT
	[I-D.ietf-stir-passport], which in turn follows JWT [RFC7519].
			[I-D.ietf-stir-passport], which in turn follows JSON Web Token
			(JWT) [RFC7519].
	5. Enrollment and Authorization using the TN Authorization List		5. Enrollment and Authorization using the TN Authorization List
	This document assumes a threefold model for certificate enrollment		This document assumes a threefold model for certificate enrollment
	when using the TN Authorization List extension.		when using the TN Authorization List extension.
	The first enrollment model is one where the certification authority		The first enrollment model is one where the certification authority
	acts in concert with national numbering authorities to issue		acts in concert with national numbering authorities to issue
	credentials to those parties to whom numbers are assigned. In the		credentials to those parties to whom numbers are assigned. In the
	United States, for example, telephone number blocks are assigned to		United States, for example, telephone number blocks are assigned to
	skipping to change at page 9, line 37 ¶		skipping to change at page 9, line 37 ¶
	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 particular is to allow a verifier to		TN Authorization List extension particular is to allow a verifier to
	ascertain when the certification authority has designed that the		ascertain when the certification authority has designed that the
	subject has authority over a particular telephone number or number		subject has authority over a particular telephone number or number
	range.		range.
	The Telephony Number (TN) Authorization List certificate extension is		The Telephony Number (TN) Authorization List certificate extension is
	identified by the following object identifier:		identified by the following object identifier:
	id-ce-TNAuthList OBJECT IDENTIFIER ::= { TBD }		id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD }
	The TN Authorization List certificate extension has the following		The TN Authorization List certificate extension has the following
	syntax:		syntax:
	TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNAuthorization		TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNAuthorization
	TNAuthorization ::= SEQUENCE SIZE (1..MAX) OF TNEntry
	TNEntry ::= CHOICE {
	spid ServiceProviderIdentifierList,
	range TelephoneNumberRange,
	one E164Number }
	ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF
	OCTET STRING
	-- When all three are present: SPID, Alt SPID, and Last Alt SPID		TNAuthorization ::= SEQUENCE SIZE (1..MAX) OF TNEntry
	TelephoneNumberRange ::= SEQUENCE {		TNEntry ::= CHOICE {
			spid [0] ServiceProviderIdentifierList,
			range [1] TelephoneNumberRange,
			one E164Number }
	start E164Number,		ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF
			OCTET STRING
	count INTEGER }		-- When all three are present: SPID, Alt SPID, and Last Alt SPID
	E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789"))		TelephoneNumberRange ::= SEQUENCE {
			start E164Number,
			count INTEGER }
	[TBD- do we really need to do IA5String? The alternative would be		E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789"))
	UTF8String, e.g.: UTF8String (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: 1) a Service Provider Identifier (SPID) can be used to		the block:
	indirectly name all of the telephone numbers associated with that
	service provider, 2) telephone numbers can be listed in a range, and		1. A Service Provider Identifier (SPID) can be used to indirectly
	3) a single telephone number can be listed.		name all of the telephone numbers associated with that service
			provider,
			2. Telephone numbers can be listed in a range, and
			3. A single telephone number can be listed.
	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. This optimization will be detailed in		authority of this certificate. This optimization will be detailed in
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 24 ¶
	Dynamic changes to number assignments can occur due to number		Dynamic changes to number assignments can occur due to number
	portability, for example. So even if a verifier has a valid cached		portability, for example. So even if a verifier has a valid cached
	certificate for a telephone number (or a range containing the		certificate for a telephone number (or a range containing the
	number), the verifier must determine that the entity that signed is		number), the verifier must determine that the entity that signed is
	still a proper authority for that number.		still a proper authority for that number.
	To verify the status of the certificate, the verifier needs to		To verify the status of the certificate, the verifier needs to
	acquire the certificate if necessary (via the methods described in		acquire the certificate if necessary (via the methods described in
	Section 7), and then would need to either:		Section 7), and then would need to either:
	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
	Rely on status information from the authority		(b) Rely on status information from the authority
	The tradeoff between short lived certificates and using status		The tradeoff between short lived certificates and using status
	information is the former's burden is on the front end (i.e.,		information is the former's burden is on the front end (i.e.,
	enrollment) and the latter's burden is on the back end (i.e.,		enrollment) and the latter's burden is on the back end (i.e.,
	verification). Both impact call setup time, but it is assumed that		verification). Both impact call setup time, but it is assumed that
	performing enrollment for each call is more of an impact that using		performing enrollment for each call is more of an impact that using
	status information. This document therefore recommends relying on		status information. This document therefore recommends relying on
	status information.		status information.
	9.1. Choosing a Verification Method		9.1. Choosing a Verification Method
	There are three common certificate verification mechanisms employed		There are three common certificate verification mechanisms employed
	by CAs:		by CAs:
	Certificate Revocation Lists (CRLs) [RFC5280]		1. Certificate Revocation Lists (CRLs) [RFC5280]
	Online Certificate Status Protocol (OCSP) [RFC6960], and		2. Online Certificate Status Protocol (OCSP) [RFC6960], and
	Server-based Certificate Validation Protocol (SCVP) [RFC5055].
			3. Server-based Certificate Validation Protocol (SCVP) [RFC5055].
	When relying on status information, the verifier needs to obtain the		When relying on status information, the verifier needs to obtain the
	status information - but before that can happen, the verifier needs		status information - but before that can happen, the verifier needs
	to know where to locate it. Placing the location of the status		to know where to locate it. Placing the location of the status
	information in the certificate makes the certificate larger, but it		information in the certificate makes the certificate larger, but it
	eases the client workload. The CRL Distribution Point certificate		eases the client workload. The CRL Distribution Point certificate
	extension includes the location of the CRL and the Authority		extension includes the location of the CRL and the Authority
	Information Access certificate extension includes the location of		Information Access certificate extension includes the location of
	OCSP and/or SCVP servers; both of these extensions are defined in		OCSP and/or SCVP servers; both of these extensions are defined in
	[RFC5280]. In all cases, the status information location is provided		[RFC5280]. In all cases, the status information location is provided
	skipping to change at page 14, line 7 ¶		skipping to change at page 14, line 5 ¶
	The OCSP TNQuery extension is included as one of the		The OCSP TNQuery extension is included as one of the
	requestExtensions in requests. It may also appear in the		requestExtensions in requests. It may also appear in the
	responseExtensions. When an OCSP server includes a number in the		responseExtensions. When an OCSP server includes a number in the
	responseExtensions, this informs the client that the certificate is		responseExtensions, this informs the client that the certificate is
	still valid for the number that appears in the TNQuery extension		still valid for the number that appears in the TNQuery extension
	field. If the TNQuery is absent from a response to a query		field. If the TNQuery is absent from a response to a query
	containing a TNQuery in its requestExtensions, then the server is not		containing a TNQuery in its requestExtensions, then the server is not
	able to validate that the number is still in the scope of authority		able to validate that the number is still in the scope of authority
	of the certificate.		of the certificate.
	id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD }		id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD }
	TNQuery ::= E164Number		TNQuery ::= E164Number
	Note that HVE OCSP profile [RFC5019] prohibits the use of per-request		Note that HVE OCSP profile [RFC5019] prohibits the use of per-request
	extensions. As it is anticipated that STIR will use OCSP in a high-		extensions. As it is anticipated that STIR will use OCSP in a high-
	volume environment, many of the optimizations recommended by HVE are		volume environment, many of the optimizations recommended by HVE are
	desirable for the STIR environment. This document therefore uses		desirable for the STIR environment. This document therefore uses
	these extensions in a baseline OCSP environment with some HVE		these extensions in a baseline OCSP environment with some HVE
	optimizations. [More TBD]		optimizations. [More TBD]
	Ideally, once a certificate has been acquired by a verifier, some		Ideally, once a certificate has been acquired by a verifier, some
	sort of asynchronous mechanism could notify and update the verifier		sort of asynchronous mechanism could notify and update the verifier
	skipping to change at page 15, line 12 ¶		skipping to change at page 15, line 7 ¶
	designates an OID to identify the accessMethod and an accessLocation,		designates an OID to identify the accessMethod and an accessLocation,
	which would most likely be a URI. A verifier would then follow the		which would most likely be a URI. A verifier would then follow the
	URI to ascertain whether the list of TNs authorized for use by the		URI to ascertain whether the list of TNs authorized for use by the
	caller.		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 number associated with a particular		fetching the list of telephone number associated with a particular
	certificate. This document defines a new AIA accessMethod, called		certificate. This document defines a new AIA accessMethod, called
	"id-ad-stir-tn", which uses the following AIA OID:		"id-ad-stir-tn", which uses the following AIA OID:
	id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD }		id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD }
	When the "id-ad-stir-tn" accessMethod is used, the accessLocation		When the "id-ad-stir-tn" accessMethod is used, the accessLocation
	MUST be an HTTPS URI. The document returned by dereferencing that		MUST be an HTTPS URI. The document returned by dereferencing that
	URI will contain the complete TN Authorization List (see Section 8)		URI will contain the complete TN Authorization List (see Section 8)
	for the certificate.		for the certificate.
	Delivering the entire list of telephone numbers associated with a		Delivering the entire list of telephone numbers associated with a
	particular certificate will divulge to STIR verifiers information		particular certificate will divulge to STIR verifiers information
	about telephone numbers other than the one associated with the		about telephone numbers other than the one associated with the
	particular call that the verifier is checking. In some environments,		particular call that the verifier is checking. In some environments,
	skipping to change at page 15, line 36 ¶		skipping to change at page 15, line 31 ¶
	10. Acknowledgments		10. Acknowledgments
	Russ Housley, Brian Rosen, Cullen Jennings and Eric Rescorla provided		Russ Housley, Brian Rosen, Cullen Jennings and Eric Rescorla provided
	key input to the discussions leading to this document.		key input to the discussions leading to this document.
	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 8, TN-HVE OCSP extension in		Extension defined in Section 8, TN-HVE OCSP extension in
	Section 9.2.1, and the TN by reference AIA access descriptor defined		Section 9.2.1, the TN by reference AIA access descriptor defined in
	in Section 9.3. It therefore requests that the IANA make the		Section 9.3, and the ASN.1 module identifier defined in Appendix A.
	following assignments:		It therefore requests that the IANA make the following assignments:
	- TN Certificate Extension in the SMI Security for PKIX		o TN Certificate Extension in the SMI Security for PKIX Certificate
	Certificate Extension registry: http://www.iana.org/assignments/		Extension registry: http://www.iana.org/assignments/smi-numbers/
	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
	- TN-HVE OCSP extension in the SMI Security for PKIX Online		o TN-HVE OCSP extension in the SMI Security for PKIX Online
	Certificate Status Protocol (OCSP) registry:		Certificate Status Protocol (OCSP) registry:
	http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-		http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-
	numbers-1.3.6.1.5.5.7.48.1		numbers-1.3.6.1.5.5.7.48.1
	- 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
			registry: http://www.iana.org/assignments/smi-numbers/smi-
			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 [RFC3280], in particular its		certificate security and practices, see [RFC5280], in particular its
	Security Considerations.		Security Considerations.
	13. Informative References		13. References
	[I-D.ietf-stir-passport]		[I-D.ietf-stir-passport]
	Wendt, C. and J. Peterson, "Persona Assertion Token",		Wendt, C. and J. Peterson, "Persona Assertion Token",
	draft-ietf-stir-passport-02 (work in progress), May 2016.		draft-ietf-stir-passport-03 (work in progress), June 2016.
	[I-D.ietf-stir-rfc4474bis]		[I-D.ietf-stir-rfc4474bis]
	Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,		Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
	"Authenticated Identity Management in the Session		"Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-09		Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-09
	(work in progress), May 2016.		(work in progress), May 2016.
	[I-D.peterson-sipping-retarget]
	Peterson, J., "Retargeting and Security in SIP: A
	Framework and Requirements", draft-peterson-sipping-
	retarget-00 (work in progress), February 2005.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	DOI 10.17487/RFC2046, November 1996,		DOI 10.17487/RFC2046, November 1996,
	<http://www.rfc-editor.org/info/rfc2046>.		<http://www.rfc-editor.org/info/rfc2046>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[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>.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
	DOI 10.17487/RFC2818, May 2000,
	<http://www.rfc-editor.org/info/rfc2818>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,
	<http://www.rfc-editor.org/info/rfc3261>.
	[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
	Protocol (SIP): Locating SIP Servers", RFC 3263,
	DOI 10.17487/RFC3263, June 2002,
	<http://www.rfc-editor.org/info/rfc3263>.
	[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
	X.509 Public Key Infrastructure Certificate and
	Certificate Revocation List (CRL) Profile", RFC 3280,
	DOI 10.17487/RFC3280, April 2002,
	<http://www.rfc-editor.org/info/rfc3280>.
	[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>.
	[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using		[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
	the Elliptic Curve Digital Signature Algorithm (ECDSA)",		the Elliptic Curve Digital Signature Algorithm (ECDSA)",
	RFC 4754, DOI 10.17487/RFC4754, January 2007,		RFC 4754, DOI 10.17487/RFC4754, January 2007,
	<http://www.rfc-editor.org/info/rfc4754>.		<http://www.rfc-editor.org/info/rfc4754>.
	skipping to change at page 17, line 48 ¶		skipping to change at page 17, line 16 ¶
	Polk, "Server-Based Certificate Validation Protocol		Polk, "Server-Based Certificate Validation Protocol
	(SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007,		(SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007,
	<http://www.rfc-editor.org/info/rfc5055>.		<http://www.rfc-editor.org/info/rfc5055>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<http://www.rfc-editor.org/info/rfc5280>.		<http://www.rfc-editor.org/info/rfc5280>.
			[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
			Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
			DOI 10.17487/RFC5912, June 2010,
			<http://www.rfc-editor.org/info/rfc5912>.
	[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,		[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
	DOI 10.17487/RFC5958, August 2010,		DOI 10.17487/RFC5958, August 2010,
	<http://www.rfc-editor.org/info/rfc5958>.		<http://www.rfc-editor.org/info/rfc5958>.
	[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words		[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words
	for Use in RFCs to Indicate Requirement Levels", RFC 6919,		for Use in RFCs to Indicate Requirement Levels", RFC 6919,
	DOI 10.17487/RFC6919, April 2013,		DOI 10.17487/RFC6919, April 2013,
	<http://www.rfc-editor.org/info/rfc6919>.		<http://www.rfc-editor.org/info/rfc6919>.
	[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,		[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
	skipping to change at page 18, line 26 ¶		skipping to change at page 17, line 46 ¶
	[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)		[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
	Multiple Certificate Status Request Extension", RFC 6961,		Multiple Certificate Status Request Extension", RFC 6961,
	DOI 10.17487/RFC6961, June 2013,		DOI 10.17487/RFC6961, June 2013,
	<http://www.rfc-editor.org/info/rfc6961>.		<http://www.rfc-editor.org/info/rfc6961>.
	[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,		[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
	"Enrollment over Secure Transport", RFC 7030,		"Enrollment over Secure Transport", RFC 7030,
	DOI 10.17487/RFC7030, October 2013,		DOI 10.17487/RFC7030, October 2013,
	<http://www.rfc-editor.org/info/rfc7030>.		<http://www.rfc-editor.org/info/rfc7030>.
	[RFC7299] Housley, R., "Object Identifier Registry for the PKIX
	Working Group", RFC 7299, DOI 10.17487/RFC7299, July 2014,
	<http://www.rfc-editor.org/info/rfc7299>.
	[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>.
	[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token		[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
	skipping to change at page 19, line 20 ¶		skipping to change at page 18, line 37 ¶
	Technology - Abstract Syntax Notation One:		Technology - Abstract Syntax Notation One:
	Parameterization of ASN.1 Specifications", ITU-T X.683,		Parameterization of ASN.1 Specifications", ITU-T X.683,
	ISO/IEC 8824-4:2002, 2002.		ISO/IEC 8824-4:2002, 2002.
	Appendix A. ASN.1 Module		Appendix A. ASN.1 Module
	This appendix provides the normative ASN.1 [X.680] definitions for		This appendix provides the normative ASN.1 [X.680] definitions for
	the structures described in this specification using ASN.1, as		the structures described in this specification using ASN.1, as
	defined in [X.680] through [X.683].		defined in [X.680] through [X.683].
	TBD		This ASN.1 module imports ASN.1 from [RFC5912].
			TN-Module {
			iso(1) identified-organization(3) dod(6) internet(1)
			security(5) mechanisms(5) pkix(7) id-mod(0)
			id-mod-tn-module(TBD) }
			DEFINITIONS EXPLICIT TAGS ::= BEGIN
			IMPORTS
			id-ad, id-ad-ocsp -- From [RFC5912]
			FROM PKIX1Explicit-2009 {
			iso(1) identified-organization(3) dod(6) internet(1) security(5)
			mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) }
			id-ce -- From [RFC5912]
			FROM PKIX1Implicit-2009 {
			iso(1) identified-organization(3) dod(6) internet(1) security(5)
			mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) }
			EXTENSION -- From [RFC5912]
			FROM PKIX-CommonTypes-2009 {
			iso(1) identified-organization(3) dod(6) internet(1)
			security(5) mechanisms(5) pkix(7) id-mod(0)
			id-mod-pkixCommon-02(57) }
			;
			-- TN Entry Certificate Extension
			ext-tnAuthList EXTENSION ::= {
			SYNTAX TNAuthorizationList IDENTIFIED BY id-ce-TNAuthList }
			TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNAuthorization
			TNAuthorization ::= SEQUENCE SIZE (1..MAX) OF TNEntry
			TNEntry ::= CHOICE {
			spid [0] ServiceProviderIdentifierList,
			range [1] TelephoneNumberRange,
			one E164Number }
			ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF
			OCTET STRING
			-- When all three are present: SPID, Alt SPID, and Last Alt SPID
			TelephoneNumberRange ::= SEQUENCE {
			start E164Number,
			count INTEGER }
			E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789"))
			-- TN OCSP Extension
			re-ocsp-tn-query EXTENSION ::= {
			SYNTAX TNQuery IDENTIFIED BY id-pkix-ocsp-stir-tn }
			TNQuery ::= E164Number
			-- TN Access Descriptor
			id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD }
			--
			-- Object Identifiers
			--
			id-pkix-ocsp OBJECT IDENTIFIER ::= id-ad-ocsp
			id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD }
			id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD }
			END
	Authors' Addresses		Authors' Addresses
	Jon Peterson		Jon Peterson
	Neustar, Inc.		Neustar, Inc.
	Email: jon.peterson@neustar.biz		Email: jon.peterson@neustar.biz
	Sean Turner		Sean Turner
	Sn3rd		sn3rd
	Email: sean@sn3rd.com		Email: sean@sn3rd.com
End of changes. 35 change blocks.
	87 lines changed or deleted		137 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/