< draft-ietf-stir-certificates-15.txt		draft-ietf-stir-certificates-16.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 20, 2018 sn3rd		Expires: June 12, 2018 sn3rd
	November 16, 2017		December 9, 2017
	Secure Telephone Identity Credentials: Certificates		Secure Telephone Identity Credentials: Certificates
	draft-ietf-stir-certificates-15		draft-ietf-stir-certificates-16
	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 20, 2018.		This Internet-Draft will expire on June 12, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2017 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 6, line 12 ¶		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 16, line 17 ¶		skipping to change at page 16, line 17 ¶
	89 id-mod-tn-module		89 id-mod-tn-module
	11.2. Media Type Registrations		11.2. Media Type Registrations
	Type name: application		Type name: application
	Subtype name: tnauthlist		Subtype name: tnauthlist
	Required parameters: None.		Required parameters: None.
	Optional parameters: None.		Optional parameters: None.
	Encoding considerations: Binary.		Encoding considerations: Binary.
	Security considerations: See Section 12 of this specification.		Security considerations: See Section 12 of [RFCTBD].
	Interoperability considerations:		Interoperability considerations:
	The TN Authorization List inside this media type MUST be		The TN Authorization List inside this media type MUST be
	DER-encoded TNAuthorizationList.		DER-encoded TNAuthorizationList.
	Published specification: This specification.		Published specification: [RFCTBD].
	Applications that use this media type:		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.
	Additional information:		Additional information:
	Magic number(s): None		Magic number(s): None
	File extension(s): None		File extension(s): None
	Macintosh File Type Code(s): None		Macintosh File Type Code(s): None
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Jon Peterson <jon.peterson@team.neustar>		Jon Peterson <jon.peterson@team.neustar>
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: none		Restrictions on usage: none
	Author: Sean Turner <sean@sn3rd.com>		Author: Sean Turner <sean@sn3rd.com>
	Change controller: The IESG <iesg@ietf.org>		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		If a certification authority issues a certificate attesting authority
	over many telephone numbers, the TNAuthList element can divulge to		over many telephone numbers, the TNAuthList element can divulge to
	relying parties extraneous telephone numbers associated with the		relying parties extraneous telephone numbers associated with the
	certificate which have no bearing on any given call in progress. The		certificate which have no bearing on any given call in progress. The
	skipping to change at page 17, line 9 ¶		skipping to change at page 17, line 15 ¶
	databases, potentially the set of numbers associated with that SPC.		databases, potentially the set of numbers associated with that SPC.
	While these practices may not cause concern in some environments, in		While these practices may not cause concern in some environments, in
	other scenarios alternative approaches could minimize the data		other scenarios alternative approaches could minimize the data
	revealed to relying parties. For example, a service provider with		revealed to relying parties. For example, a service provider with
	authority over a large block of numbers could generate short-lived		authority over a large block of numbers could generate short-lived
	certificates for individual TNs that are not so easily linked to the		certificates for individual TNs that are not so easily linked to the
	service provider or any other numbers that the service provider		service provider or any other numbers that the service provider
	controls. Optimizations to facilitate acquiring short-lived		controls. Optimizations to facilitate acquiring short-lived
	certificates are a potential area of future work for STIR.		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
End of changes. 9 change blocks.
	10 lines changed or deleted		22 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/