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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/