draft-ietf-stir-certificates-11.txt   draft-ietf-stir-certificates-12.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: May 4, 2017 sn3rd Expires: September 14, 2017 sn3rd
October 31, 2016 March 13, 2017
Secure Telephone Identity Credentials: Certificates Secure Telephone Identity Credentials: Certificates
draft-ietf-stir-certificates-11.txt draft-ietf-stir-certificates-12.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 May 4, 2017. This Internet-Draft will expire on September 14, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . 4 3. Authority for Telephone Numbers in Certificates . . . . . . . 3
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. Constraints on Signing PASSporTs . . . . . . . . . . . . 8 5.1. Constraints on Signing PASSporTs . . . . . . . . . . . . 7
5.2. Certificate Extension Scope and Structure . . . . . . . . 8 5.2. Certificate Extension Scope and Structure . . . . . . . . 8
6. Provisioning Private Keying Material . . . . . . . . . . . . 9 6. Provisioning Private Keying Material . . . . . . . . . . . . 8
7. Acquiring Credentials to Verify Signatures . . . . . . . . . 9 7. Acquiring Credentials to Verify Signatures . . . . . . . . . 9
8. JWT Claim Constraints Syntax . . . . . . . . . . . . . . . . 10 8. JWT Claim Constraints Syntax . . . . . . . . . . . . . . . . 10
9. TN Authorization List Syntax . . . . . . . . . . . . . . . . 11 9. TN Authorization List Syntax . . . . . . . . . . . . . . . . 11
10. Certificate Freshness and Revocation . . . . . . . . . . . . 12 10. Certificate Freshness and Revocation . . . . . . . . . . . . 13
10.1. Choosing a Verification Method . . . . . . . . . . . . . 13 10.1. Acquiring TN Lists By Reference . . . . . . . . . . . . 13
10.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 14 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
10.2.1. OCSP Extension Specification . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10.3. Acquiring TN Lists By Reference . . . . . . . . . . . . 17 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 18 14.1. Normative References . . . . . . . . . . . . . . . . . . 15
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 14.2. Informative References . . . . . . . . . . . . . . . . . 17
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18
14.1. Normative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
14.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 21
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
access a voicemail system. Robocallers use impersonation as a means access a voicemail system. Robocallers use impersonation as a means
of obscuring identity; while robocallers can, in the ordinary PSTN, of obscuring identity; while robocallers can, in the ordinary PSTN,
block (that is, withhold) their caller identity, callees are less block (that is, withhold) their caller identity, callees are less
likely to pick up calls from blocked identities, and therefore likely to pick up calls from blocked identities, and therefore
appearing to calling from some number, any number, is preferable. appearing to call from some number, any number, is preferable.
Robocallers however prefer not to call from a number that can trace Robocallers however prefer not to call from a number that can trace
back to the robocaller, and therefore they impersonate numbers that back to the robocaller, and therefore they impersonate numbers that
are not assigned to them. are not assigned to them.
One of the most important components of a system to prevent One of the most important components of a system to prevent
impersonation is the implementation of credentials which identify the impersonation is the implementation of credentials which identify the
parties who control telephone numbers. With these credentials, parties who control telephone numbers. With these credentials,
parties can 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
skipping to change at page 4, line 17 skipping to change at page 4, line 11
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 codes
Identifiers (SPIDs) via the TN Authorization List specified in this (SPCs) such as OCNs or SPIDs via the TN Authorization List specified
document. A relying party could then employ an external data set or in this document. A relying party could then employ an external data
service that determines whether or not a specific telephone number is set or service that determines whether or not a specific telephone
under the authority of the carrier identified as the subject of the number is under the authority of the carrier identified as the
certificate, and use that to ascertain whether or not the carrier subject of the certificate, and use that to ascertain whether or not
should have authority over a telephone number. Potentially, a the carrier should have authority over a telephone number.
certificate extension to convey the URI of such an information Potentially, a certificate extension to convey the URI of such an
service trusted by the issuer of the certificate could be developed information service trusted by the issuer of the certificate could be
(though this specification does not propose one). Alternatively, developed (though this specification does not propose one).
some relying parties could form bilateral or multilateral trust Alternatively, some relying parties could form bilateral or
relationships with peer carriers, trusting one another's assertions multilateral trust relationships with peer carriers, trusting one
just as telephone carriers in the SS7 network today rely on another's assertions just as telephone carriers in the SS7 network
transitive trust when displaying the calling party telephone number today rely on transitive trust when displaying the calling party
received through SS7 signaling. telephone number received through SS7 signaling.
The second approach is to extend the syntax of certificates to The second approach is to extend the syntax of certificates to
include a new attribute, defined here as TN Authorization List, which include a new attribute, defined here as TN Authorization List, which
contains a list of telephone numbers defining the scope of authority contains a list of telephone numbers defining the scope of authority
of the certificate. Relying parties, if they trust the issuer of the of the certificate. Relying parties, if they trust the issuer of the
certificate as a source of authoritative information on telephone certificate as a source of authoritative information on telephone
numbers, could therefore use the TN Authorization List instead of the numbers, could therefore use the TN Authorization List instead of the
subject of the certificate to make a decision about whether or not subject of the certificate to make a decision about whether or not
the signer has authority over a particular telephone number. The TN the signer has authority over a particular telephone number. The TN
Authorization List could be provided in one of two ways: as a literal Authorization List could be provided in one of two ways: as a literal
skipping to change at page 5, line 30 skipping to change at page 5, line 24
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 10). 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 [RFC3986] schemes permitted in the SIP Identity header
parameter, as well as any special procedures required to "info" 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 [RFC7230], CID and SIP
schemes to appear in the "info" parameter. URI 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
skipping to change at page 6, line 36 skipping to change at page 6, line 28
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 relying parties o See Section 7 for requirements related to relying parties
acquiring credentials. acquiring credentials.
o See Section 10.2 and Section 10.3 for requirements related to the o See Section 10 and Section 10.1 for requirements related to
Authority Information Access (AIA) certificate extension. certificate freshness and the Authority Information Access (AIA)
certificate extension.
o See Section 10.2.1 for requirements related to the authority key
identifier and subject key identifier certificate extensions.
5. Enrollment and Authorization using the TN Authorization List 5. Enrollment and Authorization using the TN Authorization List
This document 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,
telephone number blocks are assigned to Local Exchange Carriers telephone number blocks are assigned to Local Exchange Carriers
skipping to change at page 8, line 10 skipping to change at page 7, line 45
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. 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 grant
differentiate those enrolled from proof-of-possession versus different permissions to certificate holders, for example those
delegation. A Certification Policy and a Certification Practice enrolled from proof-of-possession versus delegation. A Certification
Statement [RFC3647] are produced as part of the normal PKI Policy and a Certification Practice Statement [RFC3647] are produced
bootstrapping process, (i.e., the CP is written first and then the CA as part of the normal PKI bootstrapping process, (i.e., the CP is
says how it conforms to the CP in the CPS). A CA that wishes to written first and then the CA says how it conforms to the CP in the
place constraints on the JWT claims MUST include the JWT Claim CPS). A CA that wishes to place constraints on the JWT claims MUST
Constraints certificate extension in issued certificates. See include the JWT Claim Constraints certificate extension in issued
Section 8 for information about the certificate extension. certificates. See 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
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 10, line 8 skipping to change at page 9, line 43
request along with the signature itself. In SIP, for example, a request along with the signature itself. In SIP, for example, a
certificate could be carried in a multipart MIME body [RFC2046], and certificate could be carried in a multipart MIME body [RFC2046], and
the URI in the Identity header "info" parameter could specify that the URI in the Identity header "info" parameter could specify that
body with a CID URI [RFC2392]. However, in many environments this is body with a CID URI [RFC2392]. However, in many environments this is
not feasible due to message size restrictions or lack of necessary not feasible due to message size restrictions or lack of necessary
support for multipart MIME. support for multipart MIME.
The Identity header "info" parameter in a SIP request may contain a The Identity header "info" parameter in a SIP request may contain a
URI that the verifier dereferences. Implementations of this URI that the verifier dereferences. Implementations of this
specification are REQUIRED to support the use of SIP for this specification are REQUIRED to support the use of SIP for this
function (via the SUBSCRIBE/NOTIFY mechanism), as well as HTTP, via function (via the SUBSCRIBE/NOTIFY mechanism) as well as HTTP and
the Enrollment over Secure Transport mechanisms described in RFC 7030 HTTPS.
[RFC7030].
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. JWT Claim Constraints Syntax 8. JWT Claim Constraints Syntax
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 PASSporT claims that
permitted, values for claims that are excluded, or both. When a are permitted, values for PASSporT claims that are excluded, or both.
verifier is validating PASSporT claims, the JWT claim MUST contain The syntax of these claims is given in PASSporT; specifying new
permitted values, and MUST NOT contain excluded values. The JWT claims follows the procedures in [I-D.ietf-stir-passport]
Claim Constraints certificate extension is included in the extension (Section 8.3). When a verifier is validating PASSporT claims, the
field of the certificate [RFC5280]. The extension is defined with JWT claim MUST contain permitted values, and MUST NOT contain
ASN.1 [X.680][X.681][X.682] [X.683]. excluded values. The non-critical JWT Claim Constraints certificate
extension is included in the extension field of end entity
certificates [RFC5280]. The extension is defined with ASN.1
[X.680][X.681][X.682] [X.683].
The JWT Claim Constraints certificate extension places constraints on
the values that are allowed in particular JWT claims. This
certificate extension is optional, but if present, it constraints the
claims that authentication services may include in the PASSporT
objects they sign. For example, imagine a PASSporT extension claim
called "confidence". If a CA issue to an authentication service a
certificate that contains the value "confidence" in the "permitted"
field of the JWT Claim Constraints, then an authentication service
MAY add a "confidence" claim to any PASSporTs it generates. A
verification service MUST treat as invalid any PASSporT it receives
with a PASSporT extension claim that is not included in JWT Claim
Constraints The baseline claims of PASSporT ("orig", "dest", "iat"
and "mky") are considered to be permitted by default and SHOULD NOT
be included in a "permitted" field of the certificate." The issuer
of a certificate may similarly explicitly allow the use of a
particular claim by the holder of the certificate. If a certificate
contains no JWT Claim Constraints, the issuer of the certificate
permits all claims.
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-pe 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-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 25 } 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 SEQUENCE OF IA5String
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 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 non critical Telephony Number (TN) Authorization List certificate
included in the Certificate's extension field [RFC5280]. The extension is included in the Certificate's extension field [RFC5280].
extension is defined with ASN.1 [X.680][X.681][X.682] [X.683]. What The extension is defined with ASN.1 [X.680][X.681][X.682] [X.683].
follows is the syntax and semantics of the extension. What follows is the syntax and semantics of the extension.
The subjects of certificates containing the TN Authorization List
extension are the administrative entities to whom numbers are
assigned or delegated. In an end entity certificate, TN
Authorization List indicates the TNs which the certificate has been
authorized. In a CA certificate, the TN Authorization List limits
the set of TNs for certification paths that include this certificate.
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-pe 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-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 } 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, spc [0] ServiceProviderCodeList,
range [1] TelephoneNumberRange, range [1] TelephoneNumberRange,
one E164Number } one E164Number }
ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF ServiceProviderCodeList ::= SEQUENCE SIZE (1..3) OF
OCTET STRING IA%String
-- Allows SPID, Alt SPID, and Last Alt SPID to be present -- Service Provider Codes may be OCNs, various SPIDs, or other SP identifiers from the telephone network
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. Service Provider Codes as described in this document are a
Company Number (OCN) as specified in [ATIS-0300251]) can be used generic term for the identifiers used to designate service
to indirectly name all of the telephone numbers associated with providers in the telepohone networks today. In North American
that identifier for a service provider, context, these would include Operating Company Numbers (OCNs) as
specified in [ATIS-0300251], related Service Provide Identifiers
(SPIDs), or other similar identifiers for service providers.
SPCs can be used to indirectly name all of the telephone numbers
associated with 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), which consists of a starting TelephoneNumberRange format), which consists of a starting
telephone number and then an integer count of numbers within the telephone number and then an integer count of numbers within the
range, where the valid boundaries of ranges may vary according to range, where the valid boundaries of ranges may vary according to
national policies, or 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. For more on this optimization, see authority of this certificate. For more on this optimization, see
Section 10.3. Section 10.1.
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 SPCs), because verifiers must
must establish not only that a certificate remains valid, but also establish not only that a certificate remains valid, but also that
that the certificate's scope contains the telephone number that the the certificate's scope contains the telephone number that the
verifier is validating. Dynamic changes to number assignments can verifier is validating. Dynamic changes to number assignments can
occur due to number portability, for example. So even if a verifier occur due to number portability, for example. So even if a verifier
has a valid cached certificate for a telephone number (or a range has a valid cached certificate for a telephone number (or a range
containing the number), the verifier must determine that the entity containing the number), the verifier must determine that the entity
that signed is still a proper authority for 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 such a 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)
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 some approaches to
generating a short-lived certificate for each call, and consequently generating a short-lived certificate, like requiring one for each
performing enrollment for each call, is more of an impact than call, would incur a greater operational cost than acquiring status
acquiring status information. This document therefore details an information. This document makes no particular recommndation for a
approach for relying on status information. means of determinate certificate freshness for STIR, as this requires
further study and implementation experience. Acquiring online status
10.1. Choosing a Verification Method information for certificates has the potential to disclose private
information [RFC7258] if proper precautions are not taken. Future
There are three common certificate verification mechanisms employed specifications that define certificate freshness mechanisms for STIR
by CAs: MUST note any such risks and provide countermeasures where possible.
1. Certificate Revocation Lists (CRLs) [RFC5280]
2. Online Certificate Status Protocol (OCSP) [RFC6960], and
3. Server-based Certificate Validation Protocol (SCVP) [RFC5055].
When relying on status information, the verifier needs to obtain the
status information - but before that can happen, the verifier needs
to know where to locate it. Placing the location of the status
information in the certificate makes the certificate larger, but it
eases the client workload. The CRL Distribution Point certificate
extension includes the location of the CRL and the Authority
Information Access certificate extension includes the location of
OCSP and/or SCVP servers; both of these extensions are defined in
[RFC5280]. In all cases, the status information location is provided
in the form of an URI.
CRLs are an obviously attractive solution because they are supported
by every CA. CRLs have a reputation of being quite large (10s of
MBytes), because CAs maintain and issue one monolithic CRL with all
of their revoked certificates, but CRLs do support a variety of
mechanisms to scope the size of the CRLs based on revocation reasons
(e.g., key compromise vs CA compromise), user certificates only, and
CA certificates only as well as just operationally deciding to keep
the CRLs small. However, scoping the CRL introduces other issues
(i.e., does the RP have all of the CRL partitions).
CAs in the STIR architecture will likely all create CRLs for audit
purposes, but it NOT RECOMMENDED that they be relied upon for status
information. Instead, one of the two "online" options is preferred.
Between the two, OCSP is much more widely deployed and this document
therefore RECOMMENDS the use of OCSP in high-volume environments
(HVE) for validating the freshness of certificates, based on
[RFC6960], incorporating some (but not all) of the optimizations of
[RFC5019]. CRLs MUST be signed with the same algorithm as the
certificate.
10.2. Using OCSP with TN Auth List
Certificates compliant with this specification therefore SHOULD
include a URL pointing to an OCSP service in the Authority
Information Access (AIA) certificate extension, via the "id-ad-ocsp"
accessMethod specified in [RFC5280]. It is RECOMMENDED that entities
that issue certificates with the Telephone Number Authorization List
certificate extension run an OCSP server for this purpose. Baseline
OCSP however supports only three possible response values: good,
revoked, or unknown. Without some extension, OCSP would not indicate
whether the certificate is authorized for a particular telephone
number that the verifier is validating.
At a high level, there are two ways that a client might pose this
authorization question:
For this certificate, is the following number currently in its
scope of validity?
What are all the telephone numbers associated with this
certificate, or this certificate subject?
Only the former lends itself to piggybacking on the OCSP status
mechanism; since the verifier is already asking an authority about
the certificate's status, that mechanism can be reused instead of
creating a new service that requires additional round trips? Like
most PKIX-developed protocols, OCSP is extensible; OCSP supports
request extensions (including sending multiple requests at once) and
per-request extensions. It seems unlikely that the verifier will be
requesting authorization checks on multiple telephone numbers in one
request, so a per-request extension is what is needed.
The requirement to consult OCSP in real time results in a network
round-trip delay, which is something to consider because it will add
to the call setup time. OCSP server implementations commonly pre-
generate responses, and to speed up HTTPS connections, servers often
provide OCSP responses for each certificate in their hierarchy. If
possible, both of these OCSP concepts should be adopted for use with
STIR.
10.2.1. OCSP Extension Specification
The extension mechanism for OCSP follows X.509 v3 certificate
extensions, and thus requires an OID, a criticality flag, and ASN.1
syntax as defined by the OID. The criticality specified here is
optional: per [RFC6960] Section 4.4, support for all OCSP extensions
is optional. If the OCSP server does not understand the requested
extension, it will still provide the baseline validation of the
certificate itself. Moreover, in practical STIR deployments, the
issuer of the certificate will set the accessLocation for the OCSP
AIA extension to point to an OCSP service that supports this
extension, so the risk of interoperability failure due to lack of
support for this extension is minimal.
The OCSP TNQuery extension is included as one of the request's
singleRequestExtensions. It may also appear in the response's
singleExtensions. When an OCSP server includes a number in the
response's singleExtensions, this informs the client that the
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
containing a TNQuery in its singleRequestExtension, then the server
is not able to validate that the number is still in the scope of
authority of the certificate.
id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp 10 }
TNQuery ::= E164Number
The HVE OCSP profile [RFC5019] prohibits the use of per-request
extensions. As it is anticipated that STIR will use OCSP in a high-
volume environment, many of the optimizations recommended by HVE are
desirable for the STIR environment. This document therefore uses the
HVE optimizations augmented as follows:
o Implementations MUST use SHA-256 as the hashing algorithm for the
CertID.issuerNameHash and the CertID.issuerKeyHash values. That
is CertID.hashAlgorithm is id-sha256 [RFC4055] and the values are
truncated to 160-bits as specified Option 1 in Section 2 of
[RFC7093].
o Clients MUST include the OCSP TNQuery extension in requests'
singleRequestExtensions.
o Servers MUST include the OCSP TNQuery extension in responses'
singleExtensions.
o Servers SHOULD return responses that would otherwise have been
"unknown" as "not good" (i.e., return only "good" and "not good"
responses).
o Clients MUST treat returned "unknown" responses as "not good".
o If the server uses ResponderID, it MUST generate the KeyHash using
SHA-256 and truncate the value to 160-bits as specified in Option
1 in Section 2 of [RFC7093].
o Implementations MUST support ECDSA using P-256 and SHA-256. Note
that [RFC6960] requires RSA with SHA-256 be supported.
o There is no requirement to support SHA-1, RSA with SHA-1, or DSA
with SHA-1.
OCSP responses MUST be signed using the same algorithm as the
certificate being checked.
To facilitate matching the authority key identifier values found in
CA certificates with the KeyHash used in the OCSP response,
certificates compliant with this specification MUST generate
authority key identifiers and subject key identifiers using the
SHA-256 and truncate the value to 160-bits as specified in Option 1
in Section 2 of [RFC7093].
Ideally, once a certificate has been acquired by a verifier, some
sort of asynchronous mechanism could notify and update the verifier
if the scope of the certificate changes so that verifiers could
implement a cache. While not all possible categories of verifiers
could implement such behavior, some sort of event-driven notification
of certificate status is another potential subject of future work.
One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based
accessMethod for AIA might be defined (which would also be applicable
to the method described in the following section) by some future
specification.
Strategies for stapling OCSP [RFC6961] have become common in some web 10.1. Acquiring TN Lists By Reference
PKI environments as an optimization which allows web servers to send
up-to-date certificate status information acquired from OCSP to
clients as TLS is negotiated. A similar mechanism could be
implemented for SIP requests, in which the authentication service
adds status information for its certificate to the SIP request, which
would save the verifier the trouble of performing the OCSP dip
itself. Especially for high-volume authentication and verification
services, this could result in significant performance improvements.
This is left as an optimization for future work.
10.3. Acquiring TN Lists By Reference One alternative to checking certificate status for a particular
telephone number is simply acquiring the TN Authorization List by
reference, that is, through dereferencing a URL in the certificate,
rather than including the value of the TN Authorization List in the
certificate itself.
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 certificate status, one which
initiated through a separate URI included in the certificate. The could be initiated through a separate URI included in the
AIA extension (see [RFC5280]) supports such a mechanism: it certificate. The AIA extension (see [RFC5280]) supports such a
designates an OID to identify the accessMethod and an accessLocation, mechanism: it designates an OID to identify the accessMethod and an
which would most likely be a URI. A verifier would then follow the accessLocation, which would most likely be a URI. A verifier would
URI to ascertain whether the list of TNs are authorized for use by then follow the URI to ascertain whether the list of TNs are
the caller. authorized for use by 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-stirTNList", which uses the following AIA OID: "id-ad-stirTNList", which uses the following AIA OID:
id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 } id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 }
When the "id-ad-stirTNList" 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
skipping to change at page 17, line 40 skipping to change at page 14, line 40
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.
11. 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 9, TN-HVE OCSP extension in Extension defined in Section 9, the TN by reference AIA access
Section 10.2.1, the TN by reference AIA access descriptor defined in descriptor defined in Section 10.1, and the ASN.1 module identifier
Section 10.3, and the ASN.1 module identifier defined in Appendix A. defined in Appendix A. It therefore requests that the IANA make the
It therefore requests that the IANA make the following assignments: following assignments:
o JWT Claim Constraints Certificate Extension in the SMI Security o JWT Claim Constraints Certificate Extension in the SMI Security
for PKIX Certificate Extension registry: for PKIX Certificate Extension 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.1 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
Certificate Status Protocol (OCSP) registry:
http://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml#smi-
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
12. Security Considerations 12. Security Considerations
This document is entirely about security. For further information on This document is entirely about security. For further information on
certificate security and practices, see [RFC5280], in particular its certificate security and practices, see [RFC5280], in particular its
Security Considerations. For OCSP-related security considerations Security Considerations.
see [RFC6960] and [RFC5019]
13. Acknowledgments 13. Acknowledgments
Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave Anders Kristensen, Russ Housley, Brian Rosen, Cullen Jennings, Dave
Crocker, Tony Rutkowski, John Braunberger, and Eric Rescorla provided Crocker, Tony Rutkowski, John Braunberger, and Eric Rescorla provided
key input to the discussions leading to this document. Russ Housley key input to the discussions leading to this document. Russ Housley
provided some direct assistance and text surrounding the ASN.1 provided some direct assistance and text surrounding the ASN.1
module. module.
14. References 14. References
skipping to change at page 18, line 47 skipping to change at page 15, line 45
[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-10 (work in (PASSporT)", draft-ietf-stir-passport-11 (work in
progress), October 2016. progress), February 2017.
[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-14 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16
(work in progress), October 2016. (work in progress), February 2017.
[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>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>. 2003, <http://www.rfc-editor.org/info/rfc3447>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Algorithms and Identifiers for RSA Cryptography for use in Resource Identifier (URI): Generic Syntax", STD 66,
the Internet X.509 Public Key Infrastructure Certificate RFC 3986, DOI 10.17487/RFC3986, January 2005,
and Certificate Revocation List (CRL) Profile", RFC 4055, <http://www.rfc-editor.org/info/rfc3986>.
DOI 10.17487/RFC4055, June 2005,
<http://www.rfc-editor.org/info/rfc4055>.
[RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online [RFC5019] Deacon, A. and R. Hurst, "The Lightweight Online
Certificate Status Protocol (OCSP) Profile for High-Volume Certificate Status Protocol (OCSP) Profile for High-Volume
Environments", RFC 5019, DOI 10.17487/RFC5019, September Environments", RFC 5019, DOI 10.17487/RFC5019, September
2007, <http://www.rfc-editor.org/info/rfc5019>. 2007, <http://www.rfc-editor.org/info/rfc5019>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
skipping to change at page 20, line 11 skipping to change at page 17, line 5
[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>.
[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>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
"Enrollment over Secure Transport", RFC 7030, Protocol (HTTP/1.1): Message Syntax and Routing",
DOI 10.17487/RFC7030, October 2013, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7030>. <http://www.rfc-editor.org/info/rfc7230>.
[RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
for Generating Key Identifiers Values", RFC 7093, Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
DOI 10.17487/RFC7093, December 2013, 2014, <http://www.rfc-editor.org/info/rfc7258>.
<http://www.rfc-editor.org/info/rfc7093>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<http://www.rfc-editor.org/info/rfc7519>. <http://www.rfc-editor.org/info/rfc7519>.
[X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, [X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8,
"Information technology - Open Systems Interconnection - "Information technology - Open Systems Interconnection -
The Directory: Public-key and attribute certificate The Directory: Public-key and attribute certificate
frameworks", 2012. frameworks", 2012.
skipping to change at page 21, line 11 skipping to change at page 18, line 5
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>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S. [RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647, Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003, DOI 10.17487/RFC3647, November 2003,
<http://www.rfc-editor.org/info/rfc3647>. <http://www.rfc-editor.org/info/rfc3647>.
[RFC5055] Freeman, T., Housley, R., Malpani, A., Cooper, D., and W.
Polk, "Server-Based Certificate Validation Protocol
(SCVP)", RFC 5055, DOI 10.17487/RFC5055, December 2007,
<http://www.rfc-editor.org/info/rfc5055>.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements", Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014, RFC 7340, DOI 10.17487/RFC7340, September 2014,
<http://www.rfc-editor.org/info/rfc7340>. <http://www.rfc-editor.org/info/rfc7340>.
[RFC7375] Peterson, J., "Secure Telephone Identity Threat Model", [RFC7375] Peterson, J., "Secure Telephone Identity Threat Model",
RFC 7375, DOI 10.17487/RFC7375, October 2014, RFC 7375, DOI 10.17487/RFC7375, October 2014,
<http://www.rfc-editor.org/info/rfc7375>. <http://www.rfc-editor.org/info/rfc7375>.
[X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6, [X.520] ITU-T Recommendation X.520 (10/2012) | ISO/IEC 9594-6,
skipping to change at page 22, line 19 skipping to change at page 19, line 4
id-ad, id-ad-ocsp, id-pe -- 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) }
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) }
; ;
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-pe-JWTClaimConstraints } SYNTAX JWTClaimConstraints IDENTIFIED BY id-pe-JWTClaimConstraints }
id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 25 } id-pe-JWTClaimConstraints OBJECT IDENTIFIER ::= { id-pe 25 }
JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint JWTClaimConstraints ::= SEQUENCE SIZE (1..MAX) OF JWTClaimConstraint
skipping to change at page 23, line 4 skipping to change at page 19, line 34
-- --
-- Telephone Number Authorization List Certificate Extension -- Telephone Number Authorization List Certificate Extension
-- --
ext-tnAuthList EXTENSION ::= { ext-tnAuthList EXTENSION ::= {
SYNTAX TNAuthorizationList IDENTIFIED BY id-pe-TNAuthList } SYNTAX TNAuthorizationList IDENTIFIED BY id-pe-TNAuthList }
id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 } id-pe-TNAuthList OBJECT IDENTIFIER ::= { id-pe 26 }
TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry TNAuthorizationList ::= SEQUENCE SIZE (1..MAX) OF TNEntry
TNEntry ::= CHOICE { TNEntry ::= CHOICE {
spid [0] ServiceProviderIdentifierList, spc [0] ServiceProviderCodeList,
range [1] TelephoneNumberRange, range [1] TelephoneNumberRange,
one E164Number } one E164Number }
ServiceProviderIdentifierList ::= SEQUENCE SIZE (1..3) OF ServiceProviderCodeList ::= SEQUENCE SIZE (1..3) OF
OCTET STRING IA5STRING
-- Allows SPID, Alt SPID, and Last Alt SPID to be present -- Service Provider Codes may be OCNs, various SPIDs, or other SP identifiers from the telephone network
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
--
re-ocsp-tn-query EXTENSION ::= {
SYNTAX TNQuery IDENTIFIED BY id-pkix-ocsp-stir-tn }
TNQuery ::= E164Number
id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp 10 }
-- TN Access Descriptor -- TN Access Descriptor
id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 } id-ad-stirTNList OBJECT IDENTIFIER ::= { id-ad 14 }
END END
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
 End of changes. 50 change blocks. 
347 lines changed or deleted 170 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/