< draft-ietf-stir-certificates-06.txt		draft-ietf-stir-certificates-07.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: January 8, 2017 sn3rd		Expires: January 9, 2017 sn3rd
	July 7, 2016		July 8, 2016
	Secure Telephone Identity Credentials: Certificates		Secure Telephone Identity Credentials: Certificates
	draft-ietf-stir-certificates-06.txt		draft-ietf-stir-certificates-07.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 January 8, 2017.		This Internet-Draft will expire on January 9, 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 14 ¶		skipping to change at page 2, line 14 ¶
	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 . . . . . . . 3
	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. Levels Of Assurance . . . . . . . . . . . . . . . . . . . 7
			5.2. Certificate Extension Scope and Structure . . . . . . . . 8
	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 . . . . . . . . . 9
	8. Verifying Certificate Scope with TN Authorization List . . . 9		8. Verifying Certificate Scope with TN Authorization List . . . 10
	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 . . . . . . . . . . . . . 12
	9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 12		9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 13
	9.2.1. OCSP Extension Specification . . . . . . . . . . . . 13		9.2.1. OCSP Extension Specification . . . . . . . . . . . . 13
	9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 15		9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 15
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 17		12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20		Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
	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 4 ¶		skipping to change at page 3, line 5 ¶
	Robocallers however prefer not to call from a number that can trace		Robocallers however prefer not to call from a number that can trace
	back to the robocaller, and therefore they impersonate numbers that		back to the robocaller, and therefore they impersonate numbers that
	are not assigned to them.		are not assigned to them.
	One of the most important components of a system to prevent		One of the most important components of a system to prevent
	impersonation is the implementation of credentials which identify the		impersonation is the implementation of credentials which identify the
	parties who control telephone numbers. With these credentials,		parties who control telephone numbers. With these credentials,
	parties can prove that they are in fact authorized to use telephony		parties can prove that they are in fact authorized to use telephony
	numbers, and thus distinguish themselves from impersonators unable to		numbers, and thus distinguish themselves from impersonators unable to
	present such credentials. For that reason the STIR threat model		present such credentials. For that reason the STIR threat model
	[RFC7375] stipulates, "The design of the credential system envisioned		[RFC7375] stipulates, "The design of the credential system envisioned
	as a solution to these threats must, for example, limit the scope of		as a solution to these threats must, for example, limit the scope of
	the credentials issued to carriers or national authorities to those		the credentials issued to carriers or national authorities to those
	numbers that fall under their purview." This document describes		numbers that fall under their purview." This document describes
	credential systems for telephone numbers based on X.509 version 3		credential systems for telephone numbers based on X.509 version 3
	certificates in accordance with [RFC5280]. While telephone numbers		certificates in accordance with [RFC5280]. While telephone numbers
	have long been a part of the X.509 standard, this document provides		have long been a part of the X.509 standard, this document provides
	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 (CA, 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 trust anchor of
	of the authority, and have a means to access and validate the public		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 CA or deployment environment. We anticipate that some		particular CA or deployment environment. We anticipate that some
	deployment experience will be necessary to determine optimal		deployment experience will be necessary to determine optimal
	skipping to change at page 5, line 9 ¶		skipping to change at page 5, line 10 ¶
	verifier behavior and authorization decision that will change		verifier behavior and authorization decision that will change
	depending on the approach to telephone number authority taken by the		depending on the approach to telephone number authority taken by the
	certificate. For that reason, the two approaches are not mutually		certificate. For that reason, the two approaches are not mutually
	exclusive, and in fact a certificate issued to a traditional		exclusive, and in fact a certificate issued to a traditional
	telephone network service provider could contain a TN Authorization		telephone network service provider could contain a TN Authorization
	List or not, depending on the CA issuing the credential. Regardless		List or not, depending on the CA issuing the credential. Regardless
	of 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 trust anchor that issued the certificate, and that they
	that they have some means to determine the freshness of the		have some means to determine the freshness of the certificate (see
	certificate (see Section 9).		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
	for signing the Identity header in SIP detail the following:		for signing the Identity header in SIP detail the following:
	1. The URI schemes permitted in the SIP Identity header "info"		1. The URI schemes permitted in the SIP Identity header "info"
	parameter, as well as any special procedures required to		parameter, as well as any special procedures required to
	dereference the URIs. While normative text is given below in		dereference the URIs. While normative text is given below in
	Section 7, this mechanism permits the HTTP, CID and SIP URI		Section 7, this mechanism permits the HTTP, CID and SIP URI
	skipping to change at page 5, line 49 ¶		skipping to change at page 5, line 50 ¶
	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 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:
	sufficient to generate the ECDSA using P-256 and SHA-256
	signatures necessary to support the ES256 hashed signatures		* MUST provide cryptographic keying material sufficient to
	required by PASSporT [I-D.ietf-stir-passport], which in turn		generate the ECDSA using P-256 and SHA-256 signatures
	follows JSON Web Token (JWT) [RFC7519].		necessary to support the ES256 hashed signatures required by
			PASSporT [I-D.ietf-stir-passport], which in turn follows JSON
			Web Token (JWT) [RFC7519].
			* MUST support both ECDSA with P-256 and RSA PKCS#1 v1.5 for
			certificate signature verification.
			This document also includes additional certificate-related
			requirements:
			o See Section 5.1 for requirements related to the certificate
			policies extension.
			o See Section 7 for requirements related to the TN Query certificate
			extension.
			o See Section 9.2 and Section 9.3 for requirements related to the
			Authority Information Access (AIA) certificate extension.
			o See Section 9.2.1 for requirements related to the authority key
			identifier and subject key identifier certificate extensions.
	5. Enrollment and Authorization using the TN Authorization List		5. Enrollment and Authorization using the TN Authorization List
	This document 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 CA acts in concert with		The first enrollment model is one where the CA acts in concert with
	national numbering authorities to issue credentials to those parties		national numbering authorities to issue credentials to those parties
	to whom numbers are assigned. In the United States, for example,		to whom numbers are assigned. In the United States, for example,
	telephone number blocks are assigned to Local Exchange Carriers		telephone number blocks are assigned to Local Exchange Carriers
	skipping to change at page 7, line 7 ¶		skipping to change at page 7, line 27 ¶
	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 PKIs who use the name constraints extension		traditional hierarchical PKIs who use the name constraints extension
	[RFC5280]; the root CA delegates names in sales to the sales		[RFC5280]; the root CA delegates names in sales to the sales
	department CA, names in development to the development CA, etc. As		department CA, names in development to the development CA, etc. As
	lengthy certificate delegation chains are brittle, however, and can		lengthy certificate delegation chains are brittle, however, and can
	cause delays in the verification process, this document considers		cause delays in the verification process, this document considers
	optimizations to reduce the complexity of verification.		optimizations to reduce the complexity of verification.
			Future versions of this specification may also discuss methods of
			partial delegation, where certificate holders delegate only part of
			their authority. For example, individual assignees may want to
			delegate to a service authority for text messages associated with
			their telephone number, but not for other functions.
			5.1. Levels Of Assurance
	This specification supports different level of assurance (LOA). The		This specification supports different level of assurance (LOA). The
	LOA indications, which are Object Identifiers (OIDs) included in the		LOA indications, which are Object Identifiers (OIDs) included in the
	certificate's certificate policies extension [RFC5280], allow CAs to		certificate's certificate policies extension [RFC5280], allow CAs to
	differentiate those enrolled from proof-of-possession versus		differentiate those enrolled from proof-of-possession versus
	delegation. A Certification Policy and a Certification Practice		delegation. A Certification Policy and a Certification Practice
	Statement [RFC3647] are produced as part of the normal PKI		Statement [RFC3647] are produced as part of the normal PKI
	bootstrapping process (i.e., the CP is written first and then the CAs		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		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		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		to the CPS with the certificate policies extension. CAs that wish to
	express different LOAs MUST include the certificate policies		express different LOAs MUST include the certificate policies
	extension in issued certificates. See Section 11 for additional		extension in issued certificates. See Section 11 for additional
	information about the LOA registry.		information about the LOA registry.
	Future versions of this specification may also discuss methods of		5.2. Certificate Extension Scope and Structure
	partial delegation, where certificate holders delegate only part of
	their authority. For example, individual assignees may want to
	delegate to a service authority for text messages associated with
	their telephone number, but not for other functions.
	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
	subsets of the numbers they control.		subsets of the numbers they control.
	Moreover, service providers may wish to have multiple certificates		Moreover, service providers may wish to have multiple certificates
	with the same scope of authority. For example, a service provider		with the same scope of authority. For example, a service provider
	skipping to change at page 12, line 24 ¶		skipping to change at page 12, line 43 ¶
	mechanisms to scope the size of the CRLs based on revocation reasons		mechanisms to scope the size of the CRLs based on revocation reasons
	(e.g., key compromise vs CA compromise), user certificates only, and		(e.g., key compromise vs CA compromise), user certificates only, and
	CA certificates only as well as just operationally deciding to keep		CA certificates only as well as just operationally deciding to keep
	the CRLs small. However, scoping the CRL introduces other issues		the CRLs small. However, scoping the CRL introduces other issues
	(i.e., does the RP have all of the CRL partitions).		(i.e., does the RP have all of the CRL partitions).
	CAs in the STIR architecture will likely all create CRLs for audit		CAs in the STIR architecture will likely all create CRLs for audit
	purposes, but it NOT RECOMMENDED that they be relying upon for status		purposes, but it NOT RECOMMENDED that they be relying upon for status
	information. Instead, one of the two "online" options is preferred.		information. Instead, one of the two "online" options is preferred.
	Between the two, OCSP is much more widely deployed and this document		Between the two, OCSP is much more widely deployed and this document
	therefore recommends the use of OCSP in high-volume environments for		therefore recommends the use of OCSP in high-volume environments
	validating the freshness of certificates, based on [RFC6960],		(HVE) for validating the freshness of certificates, based on
	incorporating some (but not all) of the optimizations of [RFC5019].		[RFC6960], incorporating some (but not all) of the optimizations of
			[RFC5019]. CRLs MUST be signed with the same algorithm as the
			certificate.
	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.		only three possible response values: good, revoked, or unknown.
	Without some extension, OCSP would not indicate whether the		Without some extension, OCSP would not indicate whether the
	certificate is authorized for a particular telephone number that the		certificate is authorized for a particular telephone number that the
	skipping to change at page 14, line 8 ¶		skipping to change at page 14, line 31 ¶
	The 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 the		desirable for the STIR environment. This document therefore uses the
	HVE optimizations augmented as follows:		HVE optimizations augmented as follows:
	o Implementations MUST use SHA-256 as the hashing algorithm for the		o Implementations MUST use SHA-256 as the hashing algorithm for the
	CertID.issuerNameHash and the CertID.issuerKeyHash values. That		CertID.issuerNameHash and the CertID.issuerKeyHash values. That
	is CertID.hashAlgorithm is id-sha256 [RFC4055] and the values are		is CertID.hashAlgorithm is id-sha256 [RFC4055] and the values are
	truncated as per Option 1 in [RFC7093].		truncated to 160-bits as specified Option 1 in Sectin 2 of as per
			in [RFC7093].
	o Clients MUST include the OCSP TNQuery extension in requests'		o Clients MUST include the OCSP TNQuery extension in requests'
	singleRequestExtensions.		singleRequestExtensions.
	o Servers MUST include the OCSP TNQuery extension in responses'		o Servers MUST include the OCSP TNQuery extension in responses'
	singleExtensions.		singleExtensions.
	o Servers SHOULD return responses that would otherwise have been		o Servers SHOULD return responses that would otherwise have been
	"unknown" as "not good" (i.e., return only "good" and "not good"		"unknown" as "not good" (i.e., return only "good" and "not good"
	responses).		responses).
	o Clients MUST treat returned "unknown"responses as "not good".		o Clients MUST treat returned "unknown" responses as "not good".
	o If the server uses ResponderID, it MUST generate the KeyHash using		o If the server uses ResponderID, it MUST generate the KeyHash using
	SHA-256. The value is generated as per Option 1 in [RFC7093].		SHA-256 and truncate the value to 160-bits as specified in Option
			1 in Section 2 of [RFC7093].
	o Implementations MUST support ECDSA using P-256 and SHA-256. Note		o Implementations MUST support ECDSA using P-256 and SHA-256. Note
	that [RFC6960] requires RSA with SHA-256 be supported.		that [RFC6960] requires RSA with SHA-256 be supported.
	o There is no requirement to support SHA-1, RSA with SHA-1, or DSA		o There is no requirement to support SHA-1, RSA with SHA-1, or DSA
	with SHA-1.		with SHA-1.
			OCSP responses MUST be signed using the same algorithm as the
			certificate being checked.
			To facilitate matching the authority key identifier values found in
			CA certificates with the KeyHash used in the OCSP response,
			certificates compliant with this specification MUST generate
			authority key identifiers and subject key identifers using the
			SHA-256 and truncate the value to 160-bits as specified in Option 1
			in Section 2 of [RFC7093].
	Ideally, once a certificate has been acquired by a verifier, some		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
	specification.		specification.
End of changes. 20 change blocks.
	37 lines changed or deleted		73 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/