draft-ietf-stir-certificates-08.txt   draft-ietf-stir-certificates-09.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: March 13, 2017 sn3rd Expires: April 9, 2017 sn3rd
September 9, 2016 October 6, 2016
Secure Telephone Identity Credentials: Certificates Secure Telephone Identity Credentials: Certificates
draft-ietf-stir-certificates-08.txt draft-ietf-stir-certificates-09.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 March 13, 2017. This Internet-Draft will expire on April 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
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 . . . . . . . 4
4. Certificate Usage with STIR . . . . . . . . . . . . . . . . . 5 4. Certificate Usage with STIR . . . . . . . . . . . . . . . . . 5
5. Enrollment and Authorization using the TN Authorization List 6 5. Enrollment and Authorization using the TN Authorization List 6
5.1. Levels Of Assurance . . . . . . . . . . . . . . . . . . . 7 5.1. Constraints on Signing PASSporTs . . . . . . . . . . . . 8
5.2. Certificate Extension Scope and Structure . . . . . . . . 8 5.2. Certificate Extension Scope and Structure . . . . . . . . 8
6. Provisioning Private Keying Material . . . . . . . . . . . . 8 6. Provisioning Private Keying Material . . . . . . . . . . . . 9
7. Acquiring Credentials to Verify Signatures . . . . . . . . . 9 7. Acquiring Credentials to Verify Signatures . . . . . . . . . 9
8. TN Authorization List Syntax . . . . . . . . . . . . . . . . 10 8. JWT Claim Constraints Syntax . . . . . . . . . . . . . . . . 10
9. Certificate Freshness and Revocation . . . . . . . . . . . . 12 9. TN Authorization List Syntax . . . . . . . . . . . . . . . . 11
9.1. Choosing a Verification Method . . . . . . . . . . . . . 12 10. Certificate Freshness and Revocation . . . . . . . . . . . . 12
9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 13 10.1. Choosing a Verification Method . . . . . . . . . . . . . 13
9.2.1. OCSP Extension Specification . . . . . . . . . . . . 14 10.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 14
9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 16 10.2.1. OCSP Extension Specification . . . . . . . . . . . . 15
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10.3. Acquiring TN Lists By Reference . . . . . . . . . . . . 17
11. Security Considerations . . . . . . . . . . . . . . . . . . . 18 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 12. Security Considerations . . . . . . . . . . . . . . . . . . . 18
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 21 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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
skipping to change at page 3, line 9 skipping to change at page 3, line 10
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 assert that they are in fact authorized to use telephony parties can assert 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 part of the X.509 standard (X.509 supports arbitrary have long been part of the X.509 standard (X.509 supports arbitrary
naming attributes to be included in a certificate; the naming attributes to be included in a certificate; the
telephoneNumber attribute was defined in the 1988 [X.520] telephoneNumber attribute was defined in the 1988 [X.520]
specification) this document provides ways to determine authority specification) this document provides ways to determine authority
more aligned with telephone network requirements, including extending more aligned with telephone network requirements, including extending
X.509 with a Telephone Number Authorization List certificate X.509 with a Telephone Number Authorization List certificate
extension which binds certificates to asserted authority for extension which binds certificates to asserted authority for
particular telephone numbers, or potentially telephone number blocks particular telephone numbers, or potentially telephone number blocks
or ranges. or ranges.
skipping to change at page 4, line 8 skipping to change at page 4, line 14
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 existing subject of the The first approach is to leverage the existing subject of the
certificate to ascertain that the holder of the certificate is certificate to ascertain that the holder of the certificate is
authorized to claim authority over a telephone number. The subject authorized to claim authority over a telephone number. The subject
might be represented as a domain name in the SubjectAltName, such as might be represented as a domain name in the subjectAltName, such as
an "example.net" where that domain is known to relying parties as a an "example.net" where that domain is known to relying parties as a
carrier, or represented with other identifiers related to the carrier, or represented with other identifiers related to the
operation of the telephone network including Service Provider operation of the telephone network including Service Provider
Identifiers (SPIDs) could serve as a subject as well. A relying Identifiers (SPIDs) via the TN Authorization List specified in this
party could then employ an external data set or service that document. A relying party could then employ an external data set or
determines whether or not a specific telephone number is under the service that determines whether or not a specific telephone number is
authority of the carrier identified as the subject of the under the authority of the carrier identified as the subject of the
certificate, and use that to ascertain whether or not the carrier certificate, and use that to ascertain whether or not the carrier
should have authority over a telephone number. Potentially, a should have authority over a telephone number. Potentially, a
certificate extension to convey the URI of such an information certificate extension to convey the URI of such an information
service trusted by the issuer of the certificate could be developed service trusted by the issuer of the certificate could be developed
(though this specification does not propose one). Alternatively, (though this specification does not propose one). Alternatively,
some relying parties could form bilateral or multilateral trust some relying parties could form bilateral or multilateral trust
relationships with peer carriers, trusting one another's assertions relationships with peer carriers, trusting one another's assertions
just as telephone carriers in the SS7 network today rely on just as telephone carriers in the SS7 network today rely on
transitive trust when displaying the calling party telephone number transitive trust when displaying the calling party telephone number
received through SS7 signaling. received through SS7 signaling.
skipping to change at page 5, line 15 skipping to change at page 5, line 21
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, were it supported by the CA issuing the credential. List or not, were it supported by the CA issuing the credential.
Regardless of which approach is used, certificates that assert Regardless of which approach is used, certificates that assert
authority over telephone numbers are subject to the ordinary authority over telephone numbers are subject to the ordinary
operational procedures that govern certificate use per [RFC5280]. operational procedures that govern certificate use per [RFC5280].
This means that verification services must be mindful of the need to This means that verification services must be mindful of the need to
ensure that they trust the trust anchor that issued the certificate, ensure that they trust the trust anchor that issued the certificate,
and that they have some means to determine the freshness of the and that they have some means to determine the freshness of the
certificate (see Section 9). certificate (see Section 10).
4. Certificate Usage with STIR 4. Certificate Usage with STIR
[I-D.ietf-stir-rfc4474bis] Section 7.4 requires that all credential [I-D.ietf-stir-rfc4474bis] Section 7.4 requires that all credential
systems used by STIR explain how they address the requirements systems used by STIR explain how they address the requirements
enumerated below. Certificates as described in this document address enumerated below. Certificates as described in this document address
the STIR requirements as follows: the STIR requirements as follows:
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
schemes to appear in the "info" parameter. schemes to appear in the "info" parameter.
2. Procedures required to extract keying material from the resources 2. Procedures required to extract keying material from the resources
designated by the URI. Implementations perform no special designated by the URI: implementations perform no special
procedures beyond dereferencing the "info" URI. See Section 7. procedures beyond dereferencing the "info" URI. See Section 7.
3. Procedures used by the verification service to determine the 3. Procedures used by the verification service to determine the
scope of the credential. This specification effectively proposes scope of the credential: this specification effectively proposes
two methods, as outlined in Section 3: one where the subject (or two methods, as outlined in Section 3: one where the subject (or
more properly subjectAltName) of the certificate indicates the more properly subjectAltName) of the certificate indicates the
scope of authority through a domain name, and relying parties scope of authority through a domain name, and relying parties
either trust the subject entirely or have some direct means of either trust the subject entirely or have some direct means of
determining whether or not a number falls under a subject's determining whether or not a number falls under a subject's
authority; and another where an extension to the certificate as authority; and another where an extension to the certificate as
described in Section 8 identifies the scope of authority of the described in Section 9 identifies the scope of authority of the
certificate. certificate.
4. The cryptographic algorithms required to validate the 4. The cryptographic algorithms required to validate the
credentials. For this specification, that means the signature credentials: for this specification, that means the signature
algorithms used to sign certificates. This specification algorithms used to sign certificates. This specification
REQUIRES that implementations support both 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: specification:
skipping to change at page 6, line 25 skipping to change at page 6, line 33
* MUST support both ECDSA with P-256 and RSA PKCS#1 v1.5 for * MUST support both ECDSA with P-256 and RSA PKCS#1 v1.5 for
certificate signature verification. certificate signature verification.
This document also includes additional certificate-related This document also includes additional certificate-related
requirements: requirements:
o See Section 5.1 for requirements related to the certificate o See Section 5.1 for requirements related to the certificate
policies extension. policies extension.
o See Section 7 for requirements related to the TN Query certificate o See Section 7 for requirements related to relying parties
extension. acquiring credentials.
o See Section 9.2 and Section 9.3 for requirements related to the o See Section 10.2 and Section 10.3 for requirements related to the
Authority Information Access (AIA) certificate extension. Authority Information Access (AIA) certificate extension.
o See Section 9.2.1 for requirements related to the authority key o See Section 10.2.1 for requirements related to the authority key
identifier and subject key identifier certificate extensions. 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 covers three models for enrollment when using the TN This document covers three models for enrollment when using the TN
Authorization List extension. 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,
skipping to change at page 7, line 42 skipping to change at page 8, line 5
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 work might explore methods of partial delegation, where Future work might explore methods of partial delegation, where
certificate holders delegate only part of their authority. For certificate holders delegate only part of their authority. For
example, individual assignees may want to delegate to a service example, individual assignees may want to delegate to a service
authority for text messages associated with their telephone number, authority for text messages associated with their telephone number,
but not for other functions. but not for other functions.
5.1. Levels Of Assurance 5.1. Constraints on Signing PASSporTs
This specification supports different level of assurance (LOA). The The public key in the certificate is used to validate the signature
LOA indications, which are Object Identifiers (OIDs) included in the on a JSON Web Token (JWT) [RFC7519] that conforms to the conventions
certificate's certificate policies extension [RFC5280], allow CAs to specified in PASSporT [I-D.ietf-stir-passport]. This specification
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 CAs bootstrapping process, (i.e., the CP is written first and then the CA
say how they conform to the CP in the CPS). OIDs are used to says how it conforms to the CP in the CPS). A CAs that wishes to
reference the CP and if the CA wishes it can also include a reference place constraints on the JWT claims MUST include the JWT Claim
to the CPS with the certificate policies extension. CAs that wish to Constraints certificate extension in issued certificates. See
express different LOAs MUST include the certificate policies Section 8 for information about the certificate extension.
extension in issued certificates. See Section 11 for additional
information about the LOA registry.
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
one of those numbers. Others may wish to compartmentalize authority one of those numbers. Others may wish to compartmentalize authority
over subsets of the numbers they control. over subsets of the numbers they control.
skipping to change at page 9, line 13 skipping to change at page 9, line 23
particular entity in a SIP deployment architecture sign requests, particular entity in a SIP deployment architecture sign requests,
only that it be an entity with an appropriate private key; the only that it be an entity with an appropriate private key; the
authentication service role may be instantiated by any entity in a authentication service role may be instantiated by any entity in a
SIP network. For a certificate granting authority only over a SIP network. For a certificate granting authority only over a
particular number which has been issued to an end user, for example, particular number which has been issued to an end user, for example,
an end user device might hold the private key and generate the an end user device might hold the private key and generate the
signature. In the case of a service provider with authority over signature. In the case of a service provider with authority over
large blocks of numbers, an intermediary might hold the private key large blocks of numbers, an intermediary might hold the private key
and sign calls. and sign calls.
The specification recommends distribution of private keys through The specification RECOMMENDS distribution of private keys through
PKCS#8 objects signed by a trusted entity, for example through the PKCS#8 objects signed by a trusted entity, for example through the
CMS package specified in [RFC5958]. CMS package specified in [RFC5958].
7. Acquiring Credentials to Verify Signatures 7. Acquiring Credentials to Verify Signatures
This specification documents multiple ways that a verifier can gain This specification documents multiple ways that a verifier can gain
access to the credentials needed to verify a request. As the access to the credentials needed to verify a request. As the
validity of certificates does not depend on the method of their validity of certificates does not depend on the method of their
acquisition, there is no need to standardize any single mechanism for acquisition, there is no need to standardize any single mechanism for
this purpose. All entities that comply with this purpose. All entities that comply with
skipping to change at page 10, line 12 skipping to change at page 10, line 22
Note well that as an optimization, a verifier may have access to a Note well that as an optimization, a verifier may have access to a
service, a cache or other local store that grants access to service, a cache or other local store that grants access to
certificates for a particular telephone number. However, there may certificates for a particular telephone number. However, there may
be multiple valid certificates that can sign a call setup request for be multiple valid certificates that can sign a call setup request for
a telephone number, and as a consequence, there needs to be some a telephone number, and as a consequence, there needs to be some
discriminator that the signer uses to identify their credentials. discriminator that the signer uses to identify their credentials.
The Identity header "info" parameter itself can serve as such a The Identity header "info" parameter itself can serve as such a
discriminator, provided implementations use that parameter as a key discriminator, provided implementations use that parameter as a key
when accessing certificates from caches or other sources. when accessing certificates from caches or other sources.
8. TN Authorization List Syntax 8. JWT Claim Constraints Syntax
The subjects of certificates containing the JWT Claim Constraints
certificate extension are specifies values for claims that are
permitted, values for claims that are excluded, or both. When a
verifier is validating PASSporT claims, the JWT claim MUST contain
permitted values, and MUST NOT contain excluded values. The JWT
Claim Constraints certificate extension is included in the extension
field of the certificate [RFC5280]. The extension is defined with
ASN.1 [X.680][X.681][X.682] [X.683].
The JWT Claim Constraints certificate extension is identified by the
following object identifier (OID), which is defined under the id-ce
OID arc defined in [RFC5280] and managed by IANA (see Section 11):
id-ce-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-ce TBD1 }
The JWT Claim Constraints certificate extension has the following
syntax:
JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint
JWTClaimConstraint ::= SEQUENCE {
claim IA5String,
permitted [1] SEQUENCE OF IA5String OPTIONAL,
excluded [2] SEQUENCE OF IA5String OPTIONAL }
( WITH COMPONENTS { ..., permitted PRESENT } |
WITH COMPONENTS { ..., excluded PRESENT } )
The JWT Claim Constraints certificate extension places constraints on
the values that are allowed in particular JWT claims. The extension
provides claim values that the call setup signer is permitted to
include, excluded from including, or both.
9. TN Authorization List Syntax
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 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, defined in [X.680] through [X.683]. extension is defined with ASN.1 [X.680][X.681][X.682] [X.683]. What
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-ce OID arc defined in [RFC5280] and managed by IANA (see
Section 10): Section 11).
id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD } id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD2 }
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 TNEntry
TNAuthorization ::= 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 }
ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF
OCTET STRING OCTET STRING
-- When all three are present: SPID, Alt SPID, and Last Alt SPID -- 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"))
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
skipping to change at page 12, line 5 skipping to change at page 12, line 29
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. This optimization is left for future
work. work.
9. 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, because wrinkle when using the TN Authorization List extension with telephone
verifiers must establish not only that a certificate remains valid, numbers or number ranges (as opposed to SPIDs), because verifiers
but also that the certificate's scope contains the telephone number must establish not only that a certificate remains valid, but also
that the verifier is validating. Dynamic changes to number that the certificate's scope contains the telephone number that the
assignments can occur due to number portability, for example. So verifier is validating. Dynamic changes to number assignments can
even if a verifier has a valid cached certificate for a telephone occur due to number portability, for example. So even if a verifier
number (or a range containing the number), the verifier must has a valid cached certificate for a telephone number (or a range
determine that the entity that signed is still a proper authority for containing the number), the verifier must determine that the entity
that number. that signed is still a proper authority for that number.
To verify the status of the certificate, the verifier needs to To verify the status of the certificate, the verifier needs to
acquire the certificate if necessary (via the methods described in acquire the certificate if necessary (via the methods described in
Section 7), and then would need to either: Section 7), and then would need to either:
(a) Rely on short-lived certificates and not check the certificate's (a) Rely on short-lived certificates and not check the certificate's
status, or status, or
(b) Rely on status information from the authority (e.g. OCSP, see (b) Rely on status information from the authority (e.g. OCSP, see
Section 9.2) Section 10.2)
The tradeoff between short lived certificates and using status The tradeoff between short lived certificates and using status
information is that the former's burden is on the front end (i.e., information is that the former's burden is on the front end (i.e.,
enrollment) and the latter's burden is on the back end (i.e., enrollment) and the latter's burden is on the back end (i.e.,
verification). Both impact call setup time, but it is assumed that verification). Both impact call setup time, but it is assumed that
generating a short-lived certificate for each all, and consequently generating a short-lived certificate for each call, and consequently
performing enrollment for each call, is more of an impact than performing enrollment for each call, is more of an impact than
acquiring status information. This document therefore recommends acquiring status information. This document therefore details an
relying on status information. approach for relying on status information.
9.1. Choosing a Verification Method 10.1. Choosing a Verification Method
There are three common certificate verification mechanisms employed There are three common certificate verification mechanisms employed
by CAs: by CAs:
1. Certificate Revocation Lists (CRLs) [RFC5280] 1. Certificate Revocation Lists (CRLs) [RFC5280]
2. Online Certificate Status Protocol (OCSP) [RFC6960], and 2. Online Certificate Status Protocol (OCSP) [RFC6960], and
3. Server-based Certificate Validation Protocol (SCVP) [RFC5055]. 3. Server-based Certificate Validation Protocol (SCVP) [RFC5055].
skipping to change at page 13, line 26 skipping to change at page 14, line 4
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 relied upon for status purposes, but it NOT RECOMMENDED that they be relied 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 therefore RECOMMENDS the use of OCSP in high-volume environments
(HVE) for validating the freshness of certificates, based on (HVE) for validating the freshness of certificates, based on
[RFC6960], incorporating some (but not all) of the optimizations of [RFC6960], incorporating some (but not all) of the optimizations of
[RFC5019]. CRLs MUST be signed with the same algorithm as the [RFC5019]. CRLs MUST be signed with the same algorithm as the
certificate. certificate.
9.2. Using OCSP with TN Auth List 10.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]. It is RECOMMENDED that entities accessMethod specified in [RFC5280]. It is RECOMMENDED that entities
that issue certificates with the Telephone Number Authorization List that issue certificates with the Telephone Number Authorization List
certificate extension run an OCSP server for this purpose. Baseline certificate extension run an OCSP server for this purpose. Baseline
OCSP however supports only three possible response values: good, OCSP however supports only three possible response values: good,
revoked, or unknown. Without some extension, OCSP would not indicate revoked, or unknown. Without some extension, OCSP would not indicate
whether the certificate is authorized for a particular telephone whether the certificate is authorized for a particular telephone
skipping to change at page 14, line 4 skipping to change at page 14, line 28
OCSP however supports only three possible response values: good, OCSP however supports only three possible response values: good,
revoked, or unknown. Without some extension, OCSP would not indicate revoked, or unknown. Without some extension, OCSP would not indicate
whether the certificate is authorized for a particular telephone whether the certificate is authorized for a particular telephone
number that the verifier is validating. number that the verifier is validating.
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, 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 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 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
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
skipping to change at page 16, line 22 skipping to change at page 17, line 5
PKI environments as an optimization which allows web servers to send PKI environments as an optimization which allows web servers to send
up-to-date certificate status information acquired from OCSP to up-to-date certificate status information acquired from OCSP to
clients as TLS is negotiated. A similar mechanism could be clients as TLS is negotiated. A similar mechanism could be
implemented for SIP requests, in which the authentication service implemented for SIP requests, in which the authentication service
adds status information for its certificate to the SIP request, which adds status information for its certificate to the SIP request, which
would save the verifier the trouble of performing the OCSP dip would save the verifier the trouble of performing the OCSP dip
itself. Especially for high-volume authentication and verification itself. Especially for high-volume authentication and verification
services, this could result in significant performance improvements. services, this could result in significant performance improvements.
This is left as an optimization for future work. This is left as an optimization for future work.
9.3. Acquiring TN Lists By Reference 10.3. Acquiring TN Lists By Reference
Acquiring a list of the telephone numbers associated with a Acquiring a list of the telephone numbers associated with a
certificate or its subject lends itself to an application-layer certificate or its subject lends itself to an application-layer
query/response interaction outside of OCSP, one which could be query/response interaction outside of OCSP, one which could be
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-stir-tn", which uses the following AIA OID:
id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD } id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD }
When the "id-ad-stir-tn" accessMethod is used, the accessLocation When the "id-ad-stir-tn" 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 8) 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
certificate holders could give an important boost to performance. certificate holders could give an important boost to performance.
10. IANA Considerations 11. IANA Considerations
This document makes use of object identifiers for the TN Certificate This document makes use of object identifiers for the TN Certificate
Extension defined in Section 8, TN-HVE OCSP extension in Extension defined in Section 9, TN-HVE OCSP extension in
Section 9.2.1, the TN by reference AIA access descriptor defined in Section 10.2.1, the TN by reference AIA access descriptor defined in
Section 9.3, and the ASN.1 module identifier defined in Appendix A. Section 10.3, and the ASN.1 module identifier defined in Appendix A.
It therefore requests that the IANA make the following assignments: It therefore requests that the IANA make the following assignments:
o JWT Claim Constraints Certificate Extension in the SMI Security
for PKIX Certificate Extension registry:
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-
numbers-1.3.6.1.5.5.7.1
o TN Certificate Extension in the SMI Security for PKIX Certificate o TN Certificate Extension in the SMI Security for PKIX Certificate
Extension registry: http://www.iana.org/assignments/smi-numbers/ Extension registry: http://www.iana.org/assignments/smi-numbers/
smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1 smi-numbers.xhtml#smi-numbers-1.3.6.1.5.5.7.1
o TN-HVE OCSP extension in the SMI Security for PKIX Online o TN-HVE OCSP extension in the SMI Security for PKIX Online
Certificate Status Protocol (OCSP) registry: Certificate Status Protocol (OCSP) registry:
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi- http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-
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 12. Security Considerations
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.
11. 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. For OCSP-related security considerations Security Considerations. For OCSP-related security considerations
see [RFC6960] and [RFC5019] see [RFC6960] and [RFC5019]
12. Acknowledgments 13. Acknowledgments
Russ Housley, Brian Rosen, Cullen Jennings, Dave Crocker, Tony Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave
Rutkowski, John Braunberger, and Eric Rescorla provided key input to Crocker, Tony Rutkowski, John Braunberger, and Eric Rescorla provided
the discussions leading to this document. key input to the discussions leading to this document. Russ Housley
provided some direct assistance and text surrounding the ASN.1
module.
13. References 14. References
[ATIS-0300050] [ATIS-0300050]
ATIS Recommendation 0300050, "Carrier Identification Code ATIS Recommendation 0300050, "Carrier Identification Code
(CIC) Assignment Guidelines", 2012. (CIC) Assignment Guidelines", 2012.
[I-D.ietf-stir-passport] [I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Persona Assertion Token", Wendt, C. and J. Peterson, "Personal Assertion Token
draft-ietf-stir-passport-07 (work in progress), September (PASSporT)", draft-ietf-stir-passport-08 (work in
2016. progress), September 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-11 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-13
(work in progress), August 2016. (work in progress), September 2016.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
DOI 10.17487/RFC2046, November 1996, DOI 10.17487/RFC2046, November 1996,
<http://www.rfc-editor.org/info/rfc2046>. <http://www.rfc-editor.org/info/rfc2046>.
[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>.
skipping to change at page 20, line 14 skipping to change at page 20, line 20
[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>.
[RFC6711] Johansson, L., "An IANA Registry for Level of Assurance
(LoA) Profiles", RFC 6711, DOI 10.17487/RFC6711, August
2012, <http://www.rfc-editor.org/info/rfc6711>.
[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>.
skipping to change at page 21, line 45 skipping to change at page 21, line 45
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 { 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(TBD) }
DEFINITIONS EXPLICIT TAGS ::= BEGIN DEFINITIONS EXPLICIT TAGS ::= BEGIN
IMPORTS IMPORTS
id-ad, id-ad-ocsp -- From [RFC5912] id-ad, id-ad-ocsp -- 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] id-ce -- From [RFC5912]
FROM PKIX1Implicit-2009 { FROM PKIX1Implicit-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-implicit-02(59) } mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) }
EXTENSION -- From [RFC5912] EXTENSION -- From [RFC5912]
FROM PKIX-CommonTypes-2009 { FROM PKIX-CommonTypes-2009 {
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-pkixCommon-02(57) } id-mod-pkixCommon-02(57) }
; ;
-- TN Entry Certificate Extension --
-- JWT Claim Constraints Certificate Extension
--
ext-tnAuthList EXTENSION ::= { ext-jwtClaimConstraints EXTENSION ::= {
SYNTAX TNAuthorizationList IDENTIFIED BY id-ce-TNAuthList } SYNTAX JWTClaimConstraints IDENTIFIED BY id-ce-JWTClaimConstraints }
TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNAuthorization id-ce-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-ce TBD1 }
TNAuthorization ::= SEQUENCE SIZE (1..MAX) OF TNEntry JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint
TNEntry ::= CHOICE { JWTClaimConstraint ::= SEQUENCE {
spid [0] ServiceProviderIdentifierList, claim IA5String,
range [1] TelephoneNumberRange, permitted [1] SEQUENCE OF IA5String OPTIONAL,
one E164Number } excluded [2] SEQUENCE OF IA5String OPTIONAL }
( WITH COMPONENTS { ..., permitted PRESENT } |
WITH COMPONENTS { ..., excluded PRESENT } )
ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF --
OCTET STRING -- Telephone Number Authorization List Certificate Extension
--
-- When all three are present: SPID, Alt SPID, and Last Alt SPID ext-tnAuthList EXTENSION ::= {
SYNTAX TNAuthorizationList IDENTIFIED BY id-ce-TNAuthList }
TelephoneNumberRange ::= SEQUENCE { id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD2 }
start E164Number,
count INTEGER }
E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789")) TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
TNEntry ::= CHOICE {
spid [0] ServiceProviderIdentifierList,
range [1] TelephoneNumberRange,
one E164Number }
-- TN OCSP Extension ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF
OCTET STRING
re-ocsp-tn-query EXTENSION ::= { -- Allows SPID, Alt SPID, and Last Alt SPID to be present
SYNTAX TNQuery IDENTIFIED BY id-pkix-ocsp-stir-tn }
TNQuery ::= E164Number TelephoneNumberRange ::= SEQUENCE {
start E164Number,
count INTEGER }
-- TN Access Descriptor E164Number ::= IA5String (SIZE (1..15)) (FROM ("0123456789"))
id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD } --
-- Telephone Number Query OCSP Extension
--
-- re-ocsp-tn-query EXTENSION ::= {
-- Object Identifiers SYNTAX TNQuery IDENTIFIED BY id-ad-stir-tn }
--
id-pkix-ocsp OBJECT IDENTIFIER ::= id-ad-ocsp TNQuery ::= E164Number
id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD }
id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD }
END id-ad-stir-tn OBJECT IDENTIFIER ::= { id-ad TBD3 }
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. 77 change blocks. 
183 lines changed or deleted 196 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/