< draft-ietf-stir-certificates-05.txt		draft-ietf-stir-certificates-06.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: December 27, 2016 sn3rd		Expires: January 8, 2017 sn3rd
	June 25, 2016		July 7, 2016
	Secure Telephone Identity Credentials: Certificates		Secure Telephone Identity Credentials: Certificates
	draft-ietf-stir-certificates-05.txt		draft-ietf-stir-certificates-06.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 December 27, 2016.		This Internet-Draft will expire on January 8, 2017.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	4. Certificate Usage . . . . . . . . . . . . . . . . . . . . . . 5		4. Certificate Usage . . . . . . . . . . . . . . . . . . . . . . 5
	5. Enrollment and Authorization using the TN Authorization List 6		5. Enrollment and Authorization using the TN Authorization List 6
	5.1. Certificate Extension Scope and Structure . . . . . . . . 7		5.1. Certificate Extension Scope and Structure . . . . . . . . 7
	6. Provisioning Private Keying Material . . . . . . . . . . . . 8		6. Provisioning Private Keying Material . . . . . . . . . . . . 8
	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 . . . . . . . . . . . . . 15
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 16		12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
	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 3, line 22 ¶		skipping to change at page 3, line 22 ¶
	ways to determine authority more aligned with telephone network		ways to determine authority more aligned with telephone network
	requirements, including extending X.509 with a Telephone Number		requirements, including extending X.509 with a Telephone Number
	Authorization List which binds certificates to authority for		Authorization List which binds certificates to authority for
	particular telephone numbers, or potentially telephone number blocks		particular telephone numbers, or potentially telephone number blocks
	or ranges.		or ranges.
	In the STIR in-band architecture specified in		In the STIR in-band architecture specified in
	[I-D.ietf-stir-rfc4474bis], two basic types of entities need access		[I-D.ietf-stir-rfc4474bis], two basic types of entities need access
	to these credentials: authentication services, and verification		to these credentials: authentication services, and verification
	services (or verifiers). An authentication service must be operated		services (or verifiers). An authentication service must be operated
	by an entity enrolled with the certification authority (see		by an entity enrolled with the certification authority (CA, see
	Section 5), whereas a verifier need only trust the root certificate		Section 5), whereas a verifier need only trust the root certificate
	of the authority, and have a means to access and validate the public		of the authority, and have a means to access and validate the public
	keys associated with these certificates. Although the guidance in		keys associated with these certificates. Although the guidance in
	this document is written with the STIR in-band architecture in mind,		this document is written with the STIR in-band architecture in mind,
	the credential system described in this document could be useful for		the credential system described in this document could be useful for
	other protocols that want to make use of certificates to prove		other protocols that want to make use of certificates to prove
	authority over telephone numbers on the Internet.		authority over telephone numbers on the Internet.
	This document specifies only the credential syntax and semantics		This document specifies only the credential syntax and semantics
	necessary to support this architecture. It does not assume any		necessary to support this architecture. It does not assume any
	particular certification authority or deployment environment. We		particular CA or deployment environment. We anticipate that some
	anticipate that some deployment experience will be necessary to		deployment experience will be necessary to determine optimal
	determine optimal operational models.		operational models.
	2. Terminology		2. Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as		"OPTIONAL" in this document are to be interpreted as described in RFC
	described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919].		2119 [RFC2119].
	3. Authority for Telephone Numbers in Certificates		3. Authority for Telephone Numbers in Certificates
	At a high level, this specification details two non-exclusive		At a high level, this specification details two non-exclusive
	approaches that can be employed to determine authority over telephone		approaches that can be employed to determine authority over telephone
	numbers with certificates.		numbers with certificates.
	The first approach is to leverage the subject of the certificate to		The first approach is to leverage the subject of the certificate to
	ascertain that the holder of the certificate is authorized to claim		ascertain that the holder of the certificate is authorized to claim
	authority over a telephone number. The subject might be represented		authority over a telephone number. The subject might be represented
	skipping to change at page 4, line 40 ¶		skipping to change at page 4, line 40 ¶
	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
	value in the certificate, or as a network service that allows relying		value in the certificate, or as a network service that allows relying
	parties to query in real time to determine that a telephone number is		parties to query in real time to determine that a telephone number is
	in the scope of a certificate. Using the TN Authorization list		in the scope of a certificate. Using the TN Authorization list
	rather than the certificate subject makes sense when, for example,		rather than the certificate subject makes sense when, for example,
	for privacy reasons, the certificate owner would prefer not to be		for privacy reasons, the certificate owner would prefer not to be
	identified, or in cases where the holder of the certificate does not		identified, or in cases where the holder of the certificate does not
	participate in the sort of traditional carrier infrastructure taht		participate in the sort of traditional carrier infrastructure taht
	the first approach assumes.		the first approach assumes.
	The first approach requires little change to existing PKI		The first approach requires little change to existing Public Key
	certificates; for the second approach, we must define an appropriate		Infrastructure (PKI) certificates; for the second approach, we must
	enrollment and authorization process. For the purposes of STIR, the		define an appropriate enrollment and authorization process. For the
	over-the-wire format specified in [I-D.ietf-stir-rfc4474bis]		purposes of STIR, the over-the-wire format specified in
	accommodates either of these approaches: the methods for		[I-D.ietf-stir-rfc4474bis] accommodates either of these approaches:
	canonicalizing, signing, for identifying and accessing the		the methods for canonicalizing, signing, for identifying and
	certificate and so on remain the same; it is only the verifier		accessing the certificate and so on remain the same; it is only the
	behavior and authorization decision that will change depending on the		verifier behavior and authorization decision that will change
	approach to telephone number authority taken by the certificate. For		depending on the approach to telephone number authority taken by the
	that reason, the two approaches are not mutually exclusive, and in		certificate. For that reason, the two approaches are not mutually
	fact a certificate issued to a traditional telephone network service		exclusive, and in fact a certificate issued to a traditional
	provider could contain a TN Authorization List or not, depending on		telephone network service provider could contain a TN Authorization
	the certification authority issuing the credential. Regardless of		List or not, depending on the CA issuing the credential. Regardless
	which approach is used, certificates that assert authority over		of which approach is used, certificates that assert authority over
	telephone numbers are subject to the ordinary operational procedures		telephone numbers are subject to the ordinary operational procedures
	that govern certificate use per [RFC5280]. This means that		that govern certificate use per [RFC5280]. This means that
	verification services must be mindful of the need to ensure that they		verification services must be mindful of the need to ensure that they
	trust the root certificate authority that issued the certificate, and		trust the root certificate authority that issued the certificate, and
	that they have some means to determine the freshness of the		that they have some means to determine the freshness of the
	certificate (see Section 9).		certificate (see Section 9).
	4. Certificate Usage		4. Certificate Usage
	[I-D.ietf-stir-rfc4474bis] requires that all credential systems used		[I-D.ietf-stir-rfc4474bis] requires that all credential systems used
	skipping to change at page 5, line 50 ¶		skipping to change at page 5, line 50 ¶
	algorithms used to sign certificates. This specification		algorithms used to sign certificates. This specification
	REQUIRES that implementations support both ECDSA with the P-256		REQUIRES that implementations support both ECDSA with the P-256
	curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447]		curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447]
	Section 8.2) for certificate signatures. Implementers are		Section 8.2) for certificate signatures. Implementers are
	advised that RS256 is mandated only as a transitional mechanism,		advised that RS256 is mandated only as a transitional mechanism,
	due to its widespread use in existing PKI, but we anticipate that		due to its widespread use in existing PKI, but we anticipate that
	this mechanism will eventually be deprecated.		this mechanism will eventually be deprecated.
	5. Finally, note that all certificates compliant with this		5. Finally, note that all certificates compliant with this
	specification 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 using P-256 and SHA-256
	support the ES256 hashed signatures required by PASSporT		signatures necessary to support the ES256 hashed signatures
			required by PASSporT [I-D.ietf-stir-passport], which in turn
	[I-D.ietf-stir-passport], which in turn follows JSON Web Token		follows JSON Web Token (JWT) [RFC7519].
	(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 CA acts in concert with
	acts in concert with national numbering authorities to issue		national numbering authorities to issue credentials to those parties
	credentials to those parties to whom numbers are assigned. In the		to whom numbers are assigned. In the United States, for example,
	United States, for example, telephone number blocks are assigned to		telephone number blocks are assigned to Local Exchange Carriers
	Local Exchange Carriers (LECs) by the North American Numbering Plan		(LECs) by the North American Numbering Plan Administrator (NANPA),
	Administrator (NANPA), who is in turn directed by the national		who is in turn directed by the national regulator. LECs may also
	regulator. LECs may also receive numbers in smaller allocations,		receive numbers in smaller allocations, through number pooling, or
	through number pooling, or via an individual assignment through		via an individual assignment through number portability. LECs assign
	number portability. LECs assign numbers to customers, who may be		numbers to customers, who may be private individuals or organizations
	private individuals or organizations - and organizations take		- and organizations take responsibility for assigning numbers within
	responsibility for assigning numbers within their own enterprise.		their own enterprise. This model requires top-down adoption of the
	This model requires top-down adoption of the model from regulators		model from regulators through to carriers.
	through to carriers.
	The second enrollment model is a bottom-up approach where a		The second enrollment model is a bottom-up approach where a CA
	certification authority requires that an entity prove control by		requires that an entity prove control by means of some sort of test,
	means of some sort of test, which, as with certification authorities		which, as with certification authorities for web PKI, might either be
	for web PKI, might either be automated or a manual administrative		automated or a manual administrative process. As an example of an
	process. As an example of an automated process, an authority might		automated process, an authority might send a text message to a
	send a text message to a telephone number containing a URL (which		telephone number containing a URL (which might be dereferenced by the
	might be dereferenced by the recipient) as a means of verifying that		recipient) as a means of verifying that a user has control of
	a user has control of terminal corresponding to that number. Checks		terminal corresponding to that number. Checks of this form are
	of this form are frequently used in commercial systems today to		frequently used in commercial systems today to validate telephone
	validate telephone numbers provided by users. This is comparable to		numbers provided by users. This is comparable to existing enrollment
	existing enrollment systems used by some certificate authorities for		systems used by some certificate authorities for issuing S/MIME
	issuing S/MIME credentials for email by verifying that the party		credentials for email by verifying that the party applying for a
	applying for a credential receives mail at the email address in		credential receives mail at the email address in question.
	question.
	The third enrollment model is delegation: that is, the holder of a		The third enrollment model is delegation: that is, the holder of a
	certificate (assigned by either of the two methods above) might		certificate (assigned by either of the two methods above) might
	delegate some or all of their authority to another party. In some		delegate some or all of their authority to another party. In some
	cases, multiple levels of delegation could occur: a LEC, for example,		cases, multiple levels of delegation could occur: a LEC, for example,
	might delegate authority to a customer organization for a block of		might delegate authority to a customer organization for a block of
	100 numbers used by an IP PBX, and the organization might in turn		100 numbers used by an IP PBX, and the organization might in turn
	delegate authority for a particular number to an individual employee.		delegate authority for a particular number to an individual employee.
	This is analogous to delegation of organizational identities in		This is analogous to delegation of organizational identities in
	traditional hierarchical Public Key Infrastructures (PKIs) who use		traditional hierarchical PKIs who use the name constraints extension
	the name constraints extension [RFC5280]; the root CA delegates names		[RFC5280]; the root CA delegates names in sales to the sales
	in sales to the sales department CA, names in development to the		department CA, names in development to the development CA, etc. As
	development CA, etc. As lengthy certificate delegation chains are		lengthy certificate delegation chains are brittle, however, and can
	brittle, however, and can cause delays in the verification process,		cause delays in the verification process, this document considers
	this document considers optimizations to reduce the complexity of		optimizations to reduce the complexity of verification.
	verification.
	[TBD] Future versions of this specification may address adding a		This specification supports different level of assurance (LOA). The
	level of assurance indication to certificates to differentiate those		LOA indications, which are Object Identifiers (OIDs) included in the
	enrolled from proof-of-possession versus delegation.		certificate's certificate policies extension [RFC5280], allow CAs to
			differentiate those enrolled from proof-of-possession versus
			delegation. A Certification Policy and a Certification Practice
			Statement [RFC3647] are produced as part of the normal PKI
			bootstrapping process (i.e., the CP is written first and then the CAs
			say how they conform to the CP in the CPS). OIDs are used to
			reference the CP and if the CA wishes it can also include a reference
			to the CPS with the certificate policies extension. CAs that wish to
			express different LOAs MUST include the certificate policies
			extension in issued certificates. See Section 11 for additional
			information about the LOA registry.
	[TBD] Future versions of this specification may also discuss methods		Future versions of this specification may also discuss methods of
	of partial delegation, where certificate holders delegate only part		partial delegation, where certificate holders delegate only part of
	of their authority. For example, individual assignees may want to		their authority. For example, individual assignees may want to
	delegate to a service authority for text messages associated with		delegate to a service authority for text messages associated with
	their telephone number, but not for other functions.		their telephone number, but not for other functions.
	5.1. Certificate Extension Scope and Structure		5.1. 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 is capable of signing for any one		to have a single certificate that is capable of signing for any one
	of those numbers. Others may wish to compartmentalize authority over		of those numbers. Others may wish to compartmentalize authority over
	skipping to change at page 9, line 30 ¶		skipping to change at page 9, line 36 ¶
	when accessing certificates from caches or other sources.		when accessing certificates from caches or other sources.
	8. Verifying Certificate Scope with TN Authorization List		8. Verifying Certificate Scope with TN Authorization List
	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 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 CA has designed that the subject has authority
	subject has authority over a particular telephone number or number		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 ::= { id-ce 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
	skipping to change at page 12, line 34 ¶		skipping to change at page 12, line 34 ¶
	therefore recommends the use of OCSP in high-volume environments for		therefore recommends the use of OCSP in high-volume environments for
	validating the freshness of certificates, based on [RFC6960],		validating the freshness of certificates, based on [RFC6960],
	incorporating some (but not all) of the optimizations of [RFC5019].		incorporating some (but not all) of the optimizations of [RFC5019].
	9.2. Using OCSP with TN Auth List		9.2. Using OCSP with TN Auth List
	Certificates compliant with this specification therefore SHOULD		Certificates compliant with this specification therefore SHOULD
	include a URL pointing to an OCSP service in the Authority		include a URL pointing to an OCSP service in the Authority
	Information Access (AIA) certificate extension, via the "id-ad-ocsp"		Information Access (AIA) certificate extension, via the "id-ad-ocsp"
	accessMethod specified in [RFC5280]. Baseline OCSP however supports		accessMethod specified in [RFC5280]. Baseline OCSP however supports
	only three possible response values: good, revoked, or unknown. With		only three possible response values: good, revoked, or unknown.
	some extension, OCSP would not indicate whether the certificate is		Without some extension, OCSP would not indicate whether the
	authorized for a particular telephone number that the verifier is		certificate is authorized for a particular telephone number that the
	validating.		verifier is validating.
	[TBD] What would happen in the unknown case? Can we profile OCSP
	usage so that unknown is never returned for our extension?
	At a high level, there are two ways that a client might pose this		At a high level, there are two ways that a client might pose this
	authorization question:		authorization question:
	For this certificate, is the following number currently in its		For this certificate, is the following number currently in its
	scope of validity?		scope of validity?
	What are all the telephone numbers associated with this		What are all the telephone numbers associated with this
	certificate, or this certificate subject?		certificate, or this certificate subject?
	Only the former lends itself to piggybacking on the OCSP status		Only the former lends itself to piggybacking on the OCSP status
	mechanism; since the verifier is already asking an authority about		mechanism; since the verifier is already asking an authority about
	the certificate's status, why not reuse that mechanism, instead of		the certificate's status, why not reuse that mechanism, instead of
	creating a new service that requires additional round trips? Like		creating a new service that requires additional round trips? Like
	most PKIX-developed protocols, OCSP is extensible; OCSP supports		most PKIX-developed protocols, OCSP is extensible; OCSP supports
	request extensions (including sending multiple requests at once) and		request extensions (including sending multiple requests at once) and
	per-request extensions. It seems unlikely that the verifier will be		per-request extensions. It seems unlikely that the verifier will be
	requesting authorization checks on multiple telephone numbers in one		requesting authorization checks on multiple telephone numbers in one
	request, so a per-request extension is what is needed.		request, so a per-request extension is what is needed.
	[TBD] HVE OCSP requires SHA-1 be used as the hash algorithm,
	we're6960 obviously going to change this to be SHA-256.
	The requirement to consult OCSP in real time results in a network		The requirement to consult OCSP in real time results in a network
	round-trip time of day, which is something to consider because it		round-trip time of day, which is something to consider because it
	will add to the call setup time. OCSP server implementations		will add to the call setup time. OCSP server implementations
	commonly pre-generate responses, and to speed up HTTPS connections,		commonly pre-generate responses, and to speed up HTTPS connections,
	servers often provide OCSP responses for each certificate in their		servers often provide OCSP responses for each certificate in their
	hierarchy. If possible, both of these OCSP concepts should be		hierarchy. If possible, both of these OCSP concepts should be
	adopted for use with STIR.		adopted for use with STIR.
	9.2.1. OCSP Extension Specification		9.2.1. OCSP Extension Specification
	skipping to change at page 13, line 40 ¶		skipping to change at page 13, line 32 ¶
	syntax as defined by the OID. The criticality specified here is		syntax as defined by the OID. The criticality specified here is
	optional: per [RFC6960] Section 4.4, support for all OCSP extensions		optional: per [RFC6960] Section 4.4, support for all OCSP extensions
	is optional. If the OCSP server does not understand the requested		is optional. If the OCSP server does not understand the requested
	extension, it will still provide the baseline validation of the		extension, it will still provide the baseline validation of the
	certificate itself. Moreover, in practical STIR deployments, the		certificate itself. Moreover, in practical STIR deployments, the
	issuer of the certificate will set the accessLocation for the OCSP		issuer of the certificate will set the accessLocation for the OCSP
	AIA extension to point to an OCSP service that supports this		AIA extension to point to an OCSP service that supports this
	extension, so the risk of interoperability failure due to lack of		extension, so the risk of interoperability failure due to lack of
	support for this extension is minimal.		support for this extension is minimal.
	The OCSP TNQuery extension is included as one of the		The OCSP TNQuery extension is included as one of the request's
	requestExtensions in requests. It may also appear in the		signlerequestExtensions. It may also appear in the response's
	responseExtensions. When an OCSP server includes a number in the		singleExtensions. When an OCSP server includes a number in the
	responseExtensions, this informs the client that the certificate is		response's singleExtensions, this informs the client that the
	still valid for the number that appears in the TNQuery extension		certificate is still valid for the number that appears in the TNQuery
	field. If the TNQuery is absent from a response to a query		extension 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 singleRequestExtension, then the server
	able to validate that the number is still in the scope of authority		is not able to validate that the number is still in the scope of
	of the certificate.		authority 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		The 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 the
	these extensions in a baseline OCSP environment with some HVE		HVE optimizations augmented as follows:
	optimizations. [More TBD]
			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 as per Option 1 in [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. The value is generated as per Option 1 in [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.
	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
	if the scope of the certificate changes so that verifiers could		if the scope of the certificate changes so that verifiers could
	implement a cache. While not all possible categories of verifiers		implement a cache. While not all possible categories of verifiers
	could implement such behavior, some sort of event-driven notification		could implement such behavior, some sort of event-driven notification
	of certificate status is another potential subject of future work.		of certificate status is another potential subject of future work.
	One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based		One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based
	accessMethod for AIA might be defined (which would also be applicable		accessMethod for AIA might be defined (which would also be applicable
	to the method described in the following section) by some future		to the method described in the following section) by some future
	skipping to change at page 16, line 5 ¶		skipping to change at page 16, line 18 ¶
	numbers-1.3.6.1.5.5.7.48.1		numbers-1.3.6.1.5.5.7.48.1
	o TNS by reference access descriptor in the SMI Security for PKIX		o TNS by reference access descriptor in the SMI Security for PKIX
	Access Descriptor registry: http://www.iana.org/assignments/smi-		Access Descriptor registry: http://www.iana.org/assignments/smi-
	numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48		numbers/smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.48
	o The TN ASN.1 module in SMI Security for PKIX Module Identifier		o The TN ASN.1 module in SMI Security for PKIX Module Identifier
	registry: http://www.iana.org/assignments/smi-numbers/smi-		registry: http://www.iana.org/assignments/smi-numbers/smi-
	numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0		numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.0
			This document also makes use of the Level of Assurance (LoA) Profiles
			registry defined in [RFC6711] because as is stated in RFC 6711: "Use
			of the registry by protocols other than SAML is encouraged." IANA is
			requested to creae the STIR Levels of Assurance (LOA) sub-registry in
			the Level of Assurance (LoA) Profile registry. Instead of
			registering a SAML Context Class, the Certificate Policy's Object
			Identifier representing the LOA is included in the registry. An
			example registration is as follows:
			To: loa-profiles-experts@icann.org
			From: jrandom@example.com
			1. Name of requester: J. Random User
			2. Email address of requester: jrandom@example.com
			3. Organization of requester: Example Trust Frameworks LLP
			4. Requested registration:
			URI http://foo.example.com/assurance/loa-1
			Name foo-loa-1
			Informational URL https://foo.example.com/assurance/
			Certificate Policy Object Identifier: 0.0.0.0
			NOTE: Do not register this example. The OID is purposely invalid.
			Experts are expected to ensure the reference CP includes the OID
			being registered.
	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.		Security Considerations. For OCSP-related security considerations
			see [RFC6960] and [RFC5019]
	13. 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-03 (work in progress), June 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
	skipping to change at page 16, line 42 ¶		skipping to change at page 17, line 43 ¶
	[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>.
			[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
			Wu, "Internet X.509 Public Key Infrastructure Certificate
			Policy and Certification Practices Framework", RFC 3647,
			DOI 10.17487/RFC3647, November 2003,
			<http://www.rfc-editor.org/info/rfc3647>.
			[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
			Algorithms and Identifiers for RSA Cryptography for use in
			the Internet X.509 Public Key Infrastructure Certificate
			and Certificate Revocation List (CRL) Profile", RFC 4055,
			DOI 10.17487/RFC4055, June 2005,
			<http://www.rfc-editor.org/info/rfc4055>.
	[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>.
	[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>.
	skipping to change at page 17, line 25 ¶		skipping to change at page 18, line 42 ¶
	[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the		[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the
	Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,		Public Key Infrastructure Using X.509 (PKIX)", RFC 5912,
	DOI 10.17487/RFC5912, June 2010,		DOI 10.17487/RFC5912, June 2010,
	<http://www.rfc-editor.org/info/rfc5912>.		<http://www.rfc-editor.org/info/rfc5912>.
	[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,		[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958,
	DOI 10.17487/RFC5958, August 2010,		DOI 10.17487/RFC5958, August 2010,
	<http://www.rfc-editor.org/info/rfc5958>.		<http://www.rfc-editor.org/info/rfc5958>.
	[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words		[RFC6711] Johansson, L., "An IANA Registry for Level of Assurance
	for Use in RFCs to Indicate Requirement Levels", RFC 6919,		(LoA) Profiles", RFC 6711, DOI 10.17487/RFC6711, August
	DOI 10.17487/RFC6919, April 2013,		2012, <http://www.rfc-editor.org/info/rfc6711>.
	<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.,
	Galperin, S., and C. Adams, "X.509 Internet Public Key		Galperin, S., and C. Adams, "X.509 Internet Public Key
	Infrastructure Online Certificate Status Protocol - OCSP",		Infrastructure Online Certificate Status Protocol - OCSP",
	RFC 6960, DOI 10.17487/RFC6960, June 2013,		RFC 6960, DOI 10.17487/RFC6960, June 2013,
	<http://www.rfc-editor.org/info/rfc6960>.		<http://www.rfc-editor.org/info/rfc6960>.
	[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)		[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
	Multiple Certificate Status Request Extension", RFC 6961,		Multiple Certificate Status Request Extension", RFC 6961,
	DOI 10.17487/RFC6961, June 2013,		DOI 10.17487/RFC6961, June 2013,
	<http://www.rfc-editor.org/info/rfc6961>.		<http://www.rfc-editor.org/info/rfc6961>.
	[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>.
			[RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods
			for Generating Key Identifiers Values", RFC 7093,
			DOI 10.17487/RFC7093, December 2013,
			<http://www.rfc-editor.org/info/rfc7093>.
	[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
End of changes. 26 change blocks.
	107 lines changed or deleted		183 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/