< draft-ietf-stir-certificates-10.txt		draft-ietf-stir-certificates-11.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: April 21, 2017 sn3rd		Expires: May 4, 2017 sn3rd
	October 18, 2016		October 31, 2016
	Secure Telephone Identity Credentials: Certificates		Secure Telephone Identity Credentials: Certificates
	draft-ietf-stir-certificates-10.txt		draft-ietf-stir-certificates-11.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 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 April 21, 2017.		This Internet-Draft will expire on May 4, 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 8, line 15 ¶		skipping to change at page 8, line 15 ¶
	5.1. Constraints on Signing PASSporTs		5.1. Constraints on Signing PASSporTs
	The public key in the certificate is used to validate the signature		The public key in the certificate is used to validate the signature
	on a JSON Web Token (JWT) [RFC7519] that conforms to the conventions		on a JSON Web Token (JWT) [RFC7519] that conforms to the conventions
	specified in PASSporT [I-D.ietf-stir-passport]. This specification		specified in PASSporT [I-D.ietf-stir-passport]. This specification
	supports constraints on the JWT claims, which allows the CA to		supports constraints on the JWT claims, which allows the CA 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 CA		bootstrapping process, (i.e., the CP is written first and then the CA
	says how it conforms to the CP in the CPS). A CAs that wishes to		says how it conforms to the CP in the CPS). A CA that wishes to
	place constraints on the JWT claims MUST include the JWT Claim		place constraints on the JWT claims MUST include the JWT Claim
	Constraints certificate extension in issued certificates. See		Constraints certificate extension in issued certificates. See
	Section 8 for information about the certificate extension.		Section 8 for information about the certificate extension.
	5.2. Certificate Extension Scope and Structure		5.2. 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 can be applied to signing for any		to have a single certificate that can be applied to signing for any
	skipping to change at page 10, line 34 ¶		skipping to change at page 10, line 34 ¶
	The subjects of certificates containing the JWT Claim Constraints		The subjects of certificates containing the JWT Claim Constraints
	certificate extension are specifies values for claims that are		certificate extension are specifies values for claims that are
	permitted, values for claims that are excluded, or both. When a		permitted, values for claims that are excluded, or both. When a
	verifier is validating PASSporT claims, the JWT claim MUST contain		verifier is validating PASSporT claims, the JWT claim MUST contain
	permitted values, and MUST NOT contain excluded values. The JWT		permitted values, and MUST NOT contain excluded values. The JWT
	Claim Constraints certificate extension is included in the extension		Claim Constraints certificate extension is included in the extension
	field of the certificate [RFC5280]. The extension is defined with		field of the certificate [RFC5280]. The extension is defined with
	ASN.1 [X.680][X.681][X.682] [X.683].		ASN.1 [X.680][X.681][X.682] [X.683].
	The JWT Claim Constraints certificate extension is identified by the		The JWT Claim Constraints certificate extension is identified by the
	following object identifier (OID), which is defined under the id-ce		following object identifier (OID), which is defined under the id-pe
	OID arc defined in [RFC5280] and managed by IANA (see Section 11):		OID arc defined in [RFC5280] and managed by IANA (see Section 11):
	id-ce-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-ce TBD1 }		id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 25 }
	The JWT Claim Constraints certificate extension has the following		The JWT Claim Constraints certificate extension has the following
	syntax:		syntax:
	JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint		JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint
	JWTClaimConstraint ::= SEQUENCE {		JWTClaimConstraint ::= SEQUENCE {
	claim IA5String,		claim IA5String,
	permitted [1] SEQUENCE OF IA5String OPTIONAL,		permitted [1] SEQUENCE OF IA5String OPTIONAL,
	excluded [2] SEQUENCE OF IA5String OPTIONAL }		excluded [2] SEQUENCE OF IA5String OPTIONAL }
	skipping to change at page 11, line 24 ¶		skipping to change at page 11, line 24 ¶
	TN Authorization List extension in particular is to allow a verifier		TN Authorization List extension in particular is to allow a verifier
	to ascertain when the CA has designated that the subject has		to ascertain when the CA has designated that the subject has
	authority over a particular telephone number or number range. The		authority over a particular telephone number or number range. The
	Telephony Number (TN) Authorization List certificate extension is		Telephony Number (TN) Authorization List certificate extension is
	included in the Certificate's extension field [RFC5280]. The		included in the Certificate's extension field [RFC5280]. The
	extension is defined with ASN.1 [X.680][X.681][X.682] [X.683]. What		extension is defined with ASN.1 [X.680][X.681][X.682] [X.683]. What
	follows is the syntax and semantics of the extension.		follows is the syntax and semantics of the extension.
	The Telephony Number (TN) Authorization List certificate extension is		The Telephony Number (TN) Authorization List certificate extension is
	identified by the following object identifier (OID), which is defined		identified by the following object identifier (OID), which is defined
	under the id-ce OID arc defined in [RFC5280] and managed by IANA (see		under the id-pe OID arc defined in [RFC5280] and managed by IANA (see
	Section 11).		Section 11).
	id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD2 }		id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 }
	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 TNEntry		TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
	TNEntry ::= CHOICE {		TNEntry ::= CHOICE {
	spid [0] ServiceProviderIdentifierList,		spid [0] ServiceProviderIdentifierList,
	range [1] TelephoneNumberRange,		range [1] TelephoneNumberRange,
	one E164Number }		one E164Number }
	skipping to change at page 12, line 11 ¶		skipping to change at page 12, line 11 ¶
	The TN Authorization List certificate extension indicates the		The TN Authorization List certificate extension indicates the
	authorized phone numbers for the call setup signer. It indicates one		authorized phone numbers for the call setup signer. It indicates one
	or more blocks of telephone number entries that have been authorized		or more blocks of telephone number entries that have been authorized
	for use by the call setup signer. There are three ways to identify		for use by the call setup signer. There are three ways to identify
	the block:		the block:
	1. A Service Provider Identifier (SPID, also known as an Operating		1. A Service Provider Identifier (SPID, also known as an Operating
	Company Number (OCN) as specified in [ATIS-0300251]) can be used		Company Number (OCN) as specified in [ATIS-0300251]) can be used
	to indirectly name all of the telephone numbers associated with		to indirectly name all of the telephone numbers associated with
	that service provider,		that identifier for a service provider,
	2. Telephone numbers can be listed in a range (in the		2. Telephone numbers can be listed in a range (in the
	TelephoneNumberRange format), or		TelephoneNumberRange format), which consists of a starting
			telephone number and then an integer count of numbers within the
			range, where the valid boundaries of ranges may vary according to
			national policies, or
	3. A single telephone number can be listed (as an E164Number).		3. A single telephone number can be listed (as an E164Number).
	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 is left for future		authority of this certificate. For more on this optimization, see
	work.		Section 10.3.
	10. Certificate Freshness and Revocation		10. Certificate Freshness and Revocation
	Regardless of which of the approaches in Section 3 is followed for		Regardless of which of the approaches in Section 3 is followed for
	using certificates, a certificate verification mechanism is required.		using certificates, a certificate verification mechanism is required.
	However, the traditional problem of certificate freshness gains a new		However, the traditional problem of certificate freshness gains a new
	wrinkle when using the TN Authorization List extension with telephone		wrinkle when using the TN Authorization List extension with telephone
	numbers or number ranges (as opposed to SPIDs), because verifiers		numbers or number ranges (as opposed to SPIDs), because verifiers
	must establish not only that a certificate remains valid, but also		must establish not only that a certificate remains valid, but also
	that the certificate's scope contains the telephone number that the		that the certificate's scope contains the telephone number that the
	skipping to change at page 14, line 43 ¶		skipping to change at page 14, line 48 ¶
	mechanism; since the verifier is already asking an authority about		mechanism; since the verifier is already asking an authority about
	the certificate's status, that mechanism can be reused instead of		the certificate's status, that mechanism can be reused 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.
	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 delay, which is something to consider because it will add
	will add to the call setup time. OCSP server implementations		to the call setup time. OCSP server implementations commonly pre-
	commonly pre-generate responses, and to speed up HTTPS connections,		generate responses, and to speed up HTTPS connections, servers often
	servers often provide OCSP responses for each certificate in their		provide OCSP responses for each certificate in their hierarchy. If
	hierarchy. If possible, both of these OCSP concepts should be		possible, both of these OCSP concepts should be adopted for use with
	adopted for use with STIR.		STIR.
	10.2.1. OCSP Extension Specification		10.2.1. OCSP Extension Specification
	The extension mechanism for OCSP follows X.509 v3 certificate		The extension mechanism for OCSP follows X.509 v3 certificate
	extensions, and thus requires an OID, a criticality flag, and ASN.1		extensions, and thus requires an OID, a criticality flag, and ASN.1
	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
	skipping to change at page 15, line 29 ¶		skipping to change at page 15, line 31 ¶
	The OCSP TNQuery extension is included as one of the request's		The OCSP TNQuery extension is included as one of the request's
	singleRequestExtensions. It may also appear in the response's		singleRequestExtensions. It may also appear in the response's
	singleExtensions. When an OCSP server includes a number in the		singleExtensions. When an OCSP server includes a number in the
	response's singleExtensions, this informs the client that the		response's singleExtensions, this informs the client that the
	certificate is still valid for the number that appears in the TNQuery		certificate is still valid for the number that appears in the TNQuery
	extension 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 singleRequestExtension, then the server		containing a TNQuery in its singleRequestExtension, then the server
	is not able to validate that the number is still in the scope of		is not able to validate that the number is still in the scope of
	authority 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 10 }
	TNQuery ::= E164Number		TNQuery ::= E164Number
	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
	skipping to change at page 17, line 20 ¶		skipping to change at page 17, line 20 ¶
	initiated through a separate URI included in the certificate. The		initiated through a separate URI included in the certificate. The
	AIA extension (see [RFC5280]) supports such a mechanism: it		AIA extension (see [RFC5280]) supports such a mechanism: it
	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 are authorized for use by		URI to ascertain whether the list of TNs are authorized for use by
	the caller.		the 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 numbers associated with a particular		fetching the list of telephone numbers associated with a particular
	certificate. This document defines a new AIA accessMethod, called		certificate. This document defines a new AIA accessMethod, called
	"id-ad-stir-tn", which uses the following AIA OID:		"id-ad-stirTNList", which uses the following AIA OID:
	id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD }		id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 }
	When the "id-ad-stir-tn" accessMethod is used, the accessLocation		When the "id-ad-stirTNList" 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 9)		URI will contain the complete TN Authorization List (see Section 9)
	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,
	where STIR verifiers handle a high volume of calls, maintaining an		where STIR verifiers handle a high volume of calls, maintaining an
	up-to-date and complete cache for the numbers associated with crucial		up-to-date and complete cache for the numbers associated with crucial
	skipping to change at page 18, line 47 ¶		skipping to change at page 18, line 47 ¶
	[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 | NIST FIPS PUB 186-4, "Digital		Department of Commerce | NIST FIPS PUB 186-4, "Digital
	Signature Standard, version 4", 2013.		Signature Standard, version 4", 2013.
	[I-D.ietf-stir-passport]		[I-D.ietf-stir-passport]
	Wendt, C. and J. Peterson, "Personal Assertion Token		Wendt, C. and J. Peterson, "Personal Assertion Token
	(PASSporT)", draft-ietf-stir-passport-08 (work in		(PASSporT)", draft-ietf-stir-passport-10 (work in
	progress), September 2016.		progress), October 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-13		Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-14
	(work in progress), September 2016.		(work in progress), October 2016.
	[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>.
	skipping to change at page 21, line 49 ¶		skipping to change at page 21, line 49 ¶
	The modules defined in this document are compatible with the most		The modules defined in this document are compatible with the most
	current ASN.1 specification published in 2015 (see [X.680], [X.681],		current ASN.1 specification published in 2015 (see [X.680], [X.681],
	[X.682], [X.683]). None of the newly defined tokens in the 2008		[X.682], [X.683]). None of the newly defined tokens in the 2008
	ASN.1 (DATE, DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, RELATIVE-		ASN.1 (DATE, DATE-TIME, DURATION, NOT-A-NUMBER, OID-IRI, RELATIVE-
	OID-IRI, TIME, TIME-OF-DAY)) are currently used in any of the ASN.1		OID-IRI, TIME, TIME-OF-DAY)) are currently used in any of the ASN.1
	specifications referred to here.		specifications referred to here.
	This ASN.1 module imports ASN.1 from [RFC5912].		This ASN.1 module imports ASN.1 from [RFC5912].
	TN-Module-2016 {		TN-Module-2016 {
	iso(1) identified-organization(3) dod(6) internet(1)		iso(1) identified-organization(3) dod(6) internet(1)
	security(5) mechanisms(5) pkix(7) id-mod(0)		security(5) mechanisms(5) pkix(7) id-mod(0)
	id-mod-tn-module(TBD) }		id-mod-tn-module(88) }
	DEFINITIONS EXPLICIT TAGS ::= BEGIN		DEFINITIONS EXPLICIT TAGS ::= BEGIN
	IMPORTS		IMPORTS
	id-ad, id-ad-ocsp -- From [RFC5912]		id-ad, id-ad-ocsp, id-pe -- From [RFC5912]
	FROM PKIX1Explicit-2009 {		FROM PKIX1Explicit-2009 {
	iso(1) identified-organization(3) dod(6) internet(1) security(5)		iso(1) identified-organization(3) dod(6) internet(1) security(5)
	mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) }		mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) }
	id-ce -- From [RFC5912]		EXTENSION -- From [RFC5912]
	FROM PKIX1Implicit-2009 {		FROM PKIX-CommonTypes-2009 {
	iso(1) identified-organization(3) dod(6) internet(1) security(5)		iso(1) identified-organization(3) dod(6) internet(1)
	mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) }		security(5) mechanisms(5) pkix(7) id-mod(0)
			id-mod-pkixCommon-02(57) }
	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) }
	;		id-pkix-ocsp OBECT IDENTIFIER ::= id-ad-ocsp
	--		--
	-- JWT Claim Constraints Certificate Extension		-- JWT Claim Constraints Certificate Extension
	--		--
	ext-jwtClaimConstraints EXTENSION ::= {		ext-jwtClaimConstraints EXTENSION ::= {
	SYNTAX JWTClaimConstraints IDENTIFIED BY id-ce-JWTClaimConstraints }		SYNTAX JWTClaimConstraints IDENTIFIED BY id-pe-JWTClaimConstraints }
	id-ce-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-ce TBD1 }		id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 25 }
	JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint		JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint
	JWTClaimConstraint ::= SEQUENCE {		JWTClaimConstraint ::= SEQUENCE {
	claim IA5String,		claim IA5String,
	permitted [1] SEQUENCE OF IA5String OPTIONAL,		permitted [1] SEQUENCE OF IA5String OPTIONAL,
	excluded [2] SEQUENCE OF IA5String OPTIONAL }		excluded [2] SEQUENCE OF IA5String OPTIONAL }
	( WITH COMPONENTS { ..., permitted PRESENT } |		( WITH COMPONENTS { ..., permitted PRESENT } |
	WITH COMPONENTS { ..., excluded PRESENT } )		WITH COMPONENTS { ..., excluded PRESENT } )
	--		--
	-- Telephone Number Authorization List Certificate Extension		-- Telephone Number Authorization List Certificate Extension
	--		--
	ext-tnAuthList EXTENSION ::= {		ext-tnAuthList EXTENSION ::= {
	SYNTAX TNAuthorizationList IDENTIFIED BY id-ce-TNAuthList }		SYNTAX TNAuthorizationList IDENTIFIED BY id-pe-TNAuthList }
	id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD2 }
	TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry		id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 }
	TNEntry ::= CHOICE {		TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
	spid [0] ServiceProviderIdentifierList,		TNEntry ::= CHOICE {
	range [1] TelephoneNumberRange,		spid [0] ServiceProviderIdentifierList,
	one E164Number }		range [1] TelephoneNumberRange,
			one E164Number }
	ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF		ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF
	OCTET STRING		OCTET STRING
	-- Allows SPID, Alt SPID, and Last Alt SPID to be present		-- Allows SPID, Alt SPID, and Last Alt SPID to be present
	TelephoneNumberRange ::= SEQUENCE {		TelephoneNumberRange ::= SEQUENCE {
	start E164Number,		start E164Number,
	count INTEGER }		count INTEGER }
	E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789"))		E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789"))
	--		--
	-- Telephone Number Query OCSP Extension		-- Telephone Number Query OCSP Extension
	--		--
	re-ocsp-tn-query EXTENSION ::= {		re-ocsp-tn-query EXTENSION ::= {
	SYNTAX TNQuery IDENTIFIED BY id-ad-stir-tn }		SYNTAX TNQuery IDENTIFIED BY id-pkix-ocsp-stir-tn }
	TNQuery ::= E164Number		TNQuery ::= E164Number
	id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD3 }		id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp 10 }
	END		-- TN Access Descriptor
			id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 }
			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
End of changes. 42 change blocks.
	86 lines changed or deleted		90 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/