draft-ietf-stir-certificates-05.txt   draft-ietf-stir-certificates-06.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: December 27, 2016 sn3rd Expires: January 8, 2017 sn3rd
June 25, 2016 July 7, 2016
Secure Telephone Identity Credentials: Certificates Secure Telephone Identity Credentials: Certificates
draft-ietf-stir-certificates-05.txt draft-ietf-stir-certificates-06.txt
Abstract Abstract
In order to prevent the impersonation of telephone numbers on the In order to prevent the impersonation of telephone numbers on the
Internet, some kind of credential system needs to exist that Internet, some kind of credential system needs to exist that
cryptographically proves authority over telephone numbers. This cryptographically proves authority over telephone numbers. This
document describes the use of certificates in establishing authority document describes the use of certificates in establishing authority
over telephone numbers, as a component of a broader architecture for over telephone numbers, as a component of a broader architecture for
managing telephone numbers as identities in protocols like SIP. managing telephone numbers as identities in protocols like SIP.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 27, 2016. This Internet-Draft will expire on January 8, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
4. Certificate Usage . . . . . . . . . . . . . . . . . . . . . . 5 4. Certificate Usage . . . . . . . . . . . . . . . . . . . . . . 5
5. Enrollment and Authorization using the TN Authorization List 6 5. Enrollment and Authorization using the TN Authorization List 6
5.1. Certificate Extension Scope and Structure . . . . . . . . 7 5.1. Certificate Extension Scope and Structure . . . . . . . . 7
6. Provisioning Private Keying Material . . . . . . . . . . . . 8 6. Provisioning Private Keying Material . . . . . . . . . . . . 8
7. Acquiring Credentials to Verify Signatures . . . . . . . . . 8 7. Acquiring Credentials to Verify Signatures . . . . . . . . . 8
8. Verifying Certificate Scope with TN Authorization List . . . 9 8. Verifying Certificate Scope with TN Authorization List . . . 9
9. Certificate Freshness and Revocation . . . . . . . . . . . . 11 9. Certificate Freshness and Revocation . . . . . . . . . . . . 11
9.1. Choosing a Verification Method . . . . . . . . . . . . . 11 9.1. Choosing a Verification Method . . . . . . . . . . . . . 11
9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 12 9.2. Using OCSP with TN Auth List . . . . . . . . . . . . . . 12
9.2.1. OCSP Extension Specification . . . . . . . . . . . . 13 9.2.1. OCSP Extension Specification . . . . . . . . . . . . 13
9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 14 9.3. Acquiring TN Lists By Reference . . . . . . . . . . . . . 15
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 18 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21
1. Introduction 1. Introduction
The STIR problem statement [RFC7340] identifies the primary enabler The STIR problem statement [RFC7340] identifies the primary enabler
of robocalling, vishing, swatting and related attacks as the of robocalling, vishing, swatting and related attacks as the
capability to impersonate a calling party number. The starkest capability to impersonate a calling party number. The starkest
examples of these attacks are cases where automated callees on the examples of these attacks are cases where automated callees on the
PSTN rely on the calling number as a security measure, for example to PSTN rely on the calling number as a security measure, for example to
access a voicemail system. Robocallers use impersonation as a means access a voicemail system. Robocallers use impersonation as a means
of obscuring identity; while robocallers can, in the ordinary PSTN, of obscuring identity; while robocallers can, in the ordinary PSTN,
skipping to change at page 3, line 22 skipping to change at page 3, line 22
ways to determine authority more aligned with telephone network ways to determine authority more aligned with telephone network
requirements, including extending X.509 with a Telephone Number requirements, including extending X.509 with a Telephone Number
Authorization List which binds certificates to authority for Authorization List which binds certificates to authority for
particular telephone numbers, or potentially telephone number blocks particular telephone numbers, or potentially telephone number blocks
or ranges. or ranges.
In the STIR in-band architecture specified in In the STIR in-band architecture specified in
[I-D.ietf-stir-rfc4474bis], two basic types of entities need access [I-D.ietf-stir-rfc4474bis], two basic types of entities need access
to these credentials: authentication services, and verification to these credentials: authentication services, and verification
services (or verifiers). An authentication service must be operated services (or verifiers). An authentication service must be operated
by an entity enrolled with the certification authority (see by an entity enrolled with the certification authority (CA, see
Section 5), whereas a verifier need only trust the root certificate Section 5), whereas a verifier need only trust the root certificate
of the authority, and have a means to access and validate the public of the authority, and have a means to access and validate the public
keys associated with these certificates. Although the guidance in keys associated with these certificates. Although the guidance in
this document is written with the STIR in-band architecture in mind, this document is written with the STIR in-band architecture in mind,
the credential system described in this document could be useful for the credential system described in this document could be useful for
other protocols that want to make use of certificates to prove other protocols that want to make use of certificates to prove
authority over telephone numbers on the Internet. authority over telephone numbers on the Internet.
This document specifies only the credential syntax and semantics This document specifies only the credential syntax and semantics
necessary to support this architecture. It does not assume any necessary to support this architecture. It does not assume any
particular certification authority or deployment environment. We particular CA or deployment environment. We anticipate that some
anticipate that some deployment experience will be necessary to deployment experience will be necessary to determine optimal
determine optimal operational models. operational models.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as "OPTIONAL" in this document are to be interpreted as described in RFC
described in RFC 2119 [RFC2119] and RFC 6919 [RFC6919]. 2119 [RFC2119].
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 subject of the certificate to The first approach is to leverage the subject of the certificate to
ascertain that the holder of the certificate is authorized to claim ascertain that the holder of the certificate is authorized to claim
authority over a telephone number. The subject might be represented authority over a telephone number. The subject might be represented
skipping to change at page 4, line 40 skipping to change at page 4, line 40
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
value in the certificate, or as a network service that allows relying value in the certificate, or as a network service that allows relying
parties to query in real time to determine that a telephone number is parties to query in real time to determine that a telephone number is
in the scope of a certificate. Using the TN Authorization list in the scope of a certificate. Using the TN Authorization list
rather than the certificate subject makes sense when, for example, rather than the certificate subject makes sense when, for example,
for privacy reasons, the certificate owner would prefer not to be for privacy reasons, the certificate owner would prefer not to be
identified, or in cases where the holder of the certificate does not identified, or in cases where the holder of the certificate does not
participate in the sort of traditional carrier infrastructure taht participate in the sort of traditional carrier infrastructure taht
the first approach assumes. the first approach assumes.
The first approach requires little change to existing PKI The first approach requires little change to existing Public Key
certificates; for the second approach, we must define an appropriate Infrastructure (PKI) certificates; for the second approach, we must
enrollment and authorization process. For the purposes of STIR, the define an appropriate enrollment and authorization process. For the
over-the-wire format specified in [I-D.ietf-stir-rfc4474bis] purposes of STIR, the over-the-wire format specified in
accommodates either of these approaches: the methods for [I-D.ietf-stir-rfc4474bis] accommodates either of these approaches:
canonicalizing, signing, for identifying and accessing the the methods for canonicalizing, signing, for identifying and
certificate and so on remain the same; it is only the verifier accessing the certificate and so on remain the same; it is only the
behavior and authorization decision that will change depending on the verifier behavior and authorization decision that will change
approach to telephone number authority taken by the certificate. For depending on the approach to telephone number authority taken by the
that reason, the two approaches are not mutually exclusive, and in certificate. For that reason, the two approaches are not mutually
fact a certificate issued to a traditional telephone network service exclusive, and in fact a certificate issued to a traditional
provider could contain a TN Authorization List or not, depending on telephone network service provider could contain a TN Authorization
the certification authority issuing the credential. Regardless of List or not, depending on the CA issuing the credential. Regardless
which approach is used, certificates that assert authority over of which approach is used, certificates that assert authority over
telephone numbers are subject to the ordinary operational procedures telephone numbers are subject to the ordinary operational procedures
that govern certificate use per [RFC5280]. This means that that govern certificate use per [RFC5280]. This means that
verification services must be mindful of the need to ensure that they verification services must be mindful of the need to ensure that they
trust the root certificate authority that issued the certificate, and trust the root certificate authority that issued the certificate, and
that they have some means to determine the freshness of the that they have some means to determine the freshness of the
certificate (see Section 9). certificate (see Section 9).
4. Certificate Usage 4. Certificate Usage
[I-D.ietf-stir-rfc4474bis] requires that all credential systems used [I-D.ietf-stir-rfc4474bis] requires that all credential systems used
skipping to change at page 5, line 50 skipping to change at page 5, line 50
algorithms used to sign certificates. This specification algorithms used to sign certificates. This specification
REQUIRES that implementations support both ECDSA with the P-256 REQUIRES that implementations support both ECDSA with the P-256
curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447] curve (see [RFC4754]) and RSA PKCS#1 v1.5 (see [RFC3447]
Section 8.2) for certificate signatures. Implementers are Section 8.2) for certificate signatures. Implementers are
advised that RS256 is mandated only as a transitional mechanism, advised that RS256 is mandated only as a transitional mechanism,
due to its widespread use in existing PKI, but we anticipate that due to its widespread use in existing PKI, but we anticipate that
this mechanism will eventually be deprecated. this mechanism will eventually be deprecated.
5. Finally, note that all certificates compliant with this 5. Finally, note that all certificates compliant with this
specification MUST provide cryptographic keying material specification MUST provide cryptographic keying material
sufficient to generate the ECDSA P-256 signatures necessary to sufficient to generate the ECDSA using P-256 and SHA-256
support the ES256 hashed signatures required by PASSporT signatures necessary to support the ES256 hashed signatures
required by PASSporT [I-D.ietf-stir-passport], which in turn
[I-D.ietf-stir-passport], which in turn follows JSON Web Token follows JSON Web Token (JWT) [RFC7519].
(JWT) [RFC7519].
5. Enrollment and Authorization using the TN Authorization List 5. Enrollment and Authorization using the TN Authorization List
This document assumes a threefold model for certificate enrollment This document assumes a threefold model for certificate enrollment
when using the TN Authorization List extension. when using the TN Authorization List extension.
The first enrollment model is one where the certification authority The first enrollment model is one where the CA acts in concert with
acts in concert with national numbering authorities to issue national numbering authorities to issue credentials to those parties
credentials to those parties to whom numbers are assigned. In the to whom numbers are assigned. In the United States, for example,
United States, for example, telephone number blocks are assigned to telephone number blocks are assigned to Local Exchange Carriers
Local Exchange Carriers (LECs) by the North American Numbering Plan (LECs) by the North American Numbering Plan Administrator (NANPA),
Administrator (NANPA), who is in turn directed by the national who is in turn directed by the national regulator. LECs may also
regulator. LECs may also receive numbers in smaller allocations, receive numbers in smaller allocations, through number pooling, or
through number pooling, or via an individual assignment through via an individual assignment through number portability. LECs assign
number portability. LECs assign numbers to customers, who may be numbers to customers, who may be private individuals or organizations
private individuals or organizations - and organizations take - and organizations take responsibility for assigning numbers within
responsibility for assigning numbers within their own enterprise. their own enterprise. This model requires top-down adoption of the
This model requires top-down adoption of the model from regulators model from regulators through to carriers.
through to carriers.
The second enrollment model is a bottom-up approach where a The second enrollment model is a bottom-up approach where a CA
certification authority requires that an entity prove control by requires that an entity prove control by means of some sort of test,
means of some sort of test, which, as with certification authorities which, as with certification authorities for web PKI, might either be
for web PKI, might either be automated or a manual administrative automated or a manual administrative process. As an example of an
process. As an example of an automated process, an authority might automated process, an authority might send a text message to a
send a text message to a telephone number containing a URL (which telephone number containing a URL (which might be dereferenced by the
might be dereferenced by the recipient) as a means of verifying that recipient) as a means of verifying that a user has control of
a user has control of terminal corresponding to that number. Checks terminal corresponding to that number. Checks of this form are
of this form are frequently used in commercial systems today to frequently used in commercial systems today to validate telephone
validate telephone numbers provided by users. This is comparable to numbers provided by users. This is comparable to existing enrollment
existing enrollment systems used by some certificate authorities for systems used by some certificate authorities for issuing S/MIME
issuing S/MIME credentials for email by verifying that the party credentials for email by verifying that the party applying for a
applying for a credential receives mail at the email address in credential receives mail at the email address in question.
question.
The third enrollment model is delegation: that is, the holder of a The third enrollment model is delegation: that is, the holder of a
certificate (assigned by either of the two methods above) might certificate (assigned by either of the two methods above) might
delegate some or all of their authority to another party. In some delegate some or all of their authority to another party. In some
cases, multiple levels of delegation could occur: a LEC, for example, cases, multiple levels of delegation could occur: a LEC, for example,
might delegate authority to a customer organization for a block of might delegate authority to a customer organization for a block of
100 numbers used by an IP PBX, and the organization might in turn 100 numbers used by an IP PBX, and the organization might in turn
delegate authority for a particular number to an individual employee. delegate authority for a particular number to an individual employee.
This is analogous to delegation of organizational identities in This is analogous to delegation of organizational identities in
traditional hierarchical Public Key Infrastructures (PKIs) who use traditional hierarchical PKIs who use the name constraints extension
the name constraints extension [RFC5280]; the root CA delegates names [RFC5280]; the root CA delegates names in sales to the sales
in sales to the sales department CA, names in development to the department CA, names in development to the development CA, etc. As
development CA, etc. As lengthy certificate delegation chains are lengthy certificate delegation chains are brittle, however, and can
brittle, however, and can cause delays in the verification process, cause delays in the verification process, this document considers
this document considers optimizations to reduce the complexity of optimizations to reduce the complexity of verification.
verification.
[TBD] Future versions of this specification may address adding a This specification supports different level of assurance (LOA). The
level of assurance indication to certificates to differentiate those LOA indications, which are Object Identifiers (OIDs) included in the
enrolled from proof-of-possession versus delegation. certificate's certificate policies extension [RFC5280], allow CAs to
differentiate those enrolled from proof-of-possession versus
delegation. A Certification Policy and a Certification Practice
Statement [RFC3647] are produced as part of the normal PKI
bootstrapping process (i.e., the CP is written first and then the CAs
say how they conform to the CP in the CPS). OIDs are used to
reference the CP and if the CA wishes it can also include a reference
to the CPS with the certificate policies extension. CAs that wish to
express different LOAs MUST include the certificate policies
extension in issued certificates. See Section 11 for additional
information about the LOA registry.
[TBD] Future versions of this specification may also discuss methods Future versions of this specification may also discuss methods of
of partial delegation, where certificate holders delegate only part partial delegation, where certificate holders delegate only part of
of their authority. For example, individual assignees may want to their authority. For example, individual assignees may want to
delegate to a service authority for text messages associated with delegate to a service authority for text messages associated with
their telephone number, but not for other functions. their telephone number, but not for other functions.
5.1. Certificate Extension Scope and Structure 5.1. Certificate Extension Scope and Structure
This specification places no limits on the number of telephone This specification places no limits on the number of telephone
numbers that can be associated with any given certificate. Some numbers that can be associated with any given certificate. Some
service providers may be assigned millions of numbers, and may wish service providers may be assigned millions of numbers, and may wish
to have a single certificate that is capable of signing for any one to have a single certificate that is capable of signing for any one
of those numbers. Others may wish to compartmentalize authority over of those numbers. Others may wish to compartmentalize authority over
skipping to change at page 9, line 30 skipping to change at page 9, line 36
when accessing certificates from caches or other sources. when accessing certificates from caches or other sources.
8. Verifying Certificate Scope with TN Authorization List 8. Verifying Certificate Scope with TN Authorization List
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 particular is to allow a verifier to TN Authorization List extension particular is to allow a verifier to
ascertain when the certification authority has designed that the ascertain when the CA has designed that the subject has authority
subject has authority over a particular telephone number or number over a particular telephone number or number range.
range.
The Telephony Number (TN) Authorization List certificate extension is The Telephony Number (TN) Authorization List certificate extension is
identified by the following object identifier: identified by the following object identifier:
id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD } id-ce-TNAuthList OBJECT IDENTIFIER ::= { id-ce TBD }
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 TNAuthorization
skipping to change at page 12, line 34 skipping to change at page 12, line 34
therefore recommends the use of OCSP in high-volume environments for therefore recommends the use of OCSP in high-volume environments for
validating the freshness of certificates, based on [RFC6960], validating the freshness of certificates, based on [RFC6960],
incorporating some (but not all) of the optimizations of [RFC5019]. incorporating some (but not all) of the optimizations of [RFC5019].
9.2. Using OCSP with TN Auth List 9.2. Using OCSP with TN Auth List
Certificates compliant with this specification therefore SHOULD Certificates compliant with this specification therefore SHOULD
include a URL pointing to an OCSP service in the Authority include a URL pointing to an OCSP service in the Authority
Information Access (AIA) certificate extension, via the "id-ad-ocsp" Information Access (AIA) certificate extension, via the "id-ad-ocsp"
accessMethod specified in [RFC5280]. Baseline OCSP however supports accessMethod specified in [RFC5280]. Baseline OCSP however supports
only three possible response values: good, revoked, or unknown. With only three possible response values: good, revoked, or unknown.
some extension, OCSP would not indicate whether the certificate is Without some extension, OCSP would not indicate whether the
authorized for a particular telephone number that the verifier is certificate is authorized for a particular telephone number that the
validating. verifier is validating.
[TBD] What would happen in the unknown case? Can we profile OCSP
usage so that unknown is never returned for our extension?
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, why not reuse that mechanism, 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.
[TBD] HVE OCSP requires SHA-1 be used as the hash algorithm,
we're6960 obviously going to change this to be SHA-256.
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 9.2.1. OCSP Extension Specification
skipping to change at page 13, line 40 skipping to change at page 13, line 32
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
extension, so the risk of interoperability failure due to lack of extension, so the risk of interoperability failure due to lack of
support for this extension is minimal. support for this extension is minimal.
The OCSP TNQuery extension is included as one of the The OCSP TNQuery extension is included as one of the request's
requestExtensions in requests. It may also appear in the signlerequestExtensions. It may also appear in the response's
responseExtensions. When an OCSP server includes a number in the singleExtensions. When an OCSP server includes a number in the
responseExtensions, this informs the client that the certificate is response's singleExtensions, this informs the client that the
still valid for the number that appears in the TNQuery extension certificate is still valid for the number that appears in the TNQuery
field. If the TNQuery is absent from a response to a query extension field. If the TNQuery is absent from a response to a query
containing a TNQuery in its requestExtensions, then the server is not containing a TNQuery in its singleRequestExtension, then the server
able to validate that the number is still in the scope of authority is not able to validate that the number is still in the scope of
of the certificate. authority of the certificate.
id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD } id-pkix-ocsp-stir-tn OBJECT IDENTIFIER ::= { id-pkix-ocsp TBD }
TNQuery ::= E164Number TNQuery ::= E164Number
Note that HVE OCSP profile [RFC5019] prohibits the use of per-request The HVE OCSP profile [RFC5019] prohibits the use of per-request
extensions. As it is anticipated that STIR will use OCSP in a high- extensions. As it is anticipated that STIR will use OCSP in a high-
volume environment, many of the optimizations recommended by HVE are volume environment, many of the optimizations recommended by HVE are
desirable for the STIR environment. This document therefore uses desirable for the STIR environment. This document therefore uses the
these extensions in a baseline OCSP environment with some HVE HVE optimizations augmented as follows:
optimizations. [More TBD]
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 as per Option 1 in [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. The value is generated as per Option 1 in [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.
Ideally, once a certificate has been acquired by a verifier, some Ideally, once a certificate has been acquired by a verifier, some
sort of asynchronous mechanism could notify and update the verifier sort of asynchronous mechanism could notify and update the verifier
if the scope of the certificate changes so that verifiers could if the scope of the certificate changes so that verifiers could
implement a cache. While not all possible categories of verifiers implement a cache. While not all possible categories of verifiers
could implement such behavior, some sort of event-driven notification could implement such behavior, some sort of event-driven notification
of certificate status is another potential subject of future work. of certificate status is another potential subject of future work.
One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based One potential direction is that a future SIP SUBSCRIBE/NOTIFY-based
accessMethod for AIA might be defined (which would also be applicable accessMethod for AIA might be defined (which would also be applicable
to the method described in the following section) by some future to the method described in the following section) by some future
skipping to change at page 16, line 5 skipping to change at page 16, line 18
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
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.
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. Security Considerations. For OCSP-related security considerations
see [RFC6960] and [RFC5019]
13. References 13. References
[I-D.ietf-stir-passport] [I-D.ietf-stir-passport]
Wendt, C. and J. Peterson, "Persona Assertion Token", Wendt, C. and J. Peterson, "Persona Assertion Token",
draft-ietf-stir-passport-03 (work in progress), June 2016. draft-ietf-stir-passport-03 (work in progress), June 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
skipping to change at page 16, line 42 skipping to change at page 17, line 43
[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>.
[RFC3647] Chokhani, S., Ford, W., Sabett, R., Merrill, C., and S.
Wu, "Internet X.509 Public Key Infrastructure Certificate
Policy and Certification Practices Framework", RFC 3647,
DOI 10.17487/RFC3647, November 2003,
<http://www.rfc-editor.org/info/rfc3647>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005,
<http://www.rfc-editor.org/info/rfc4055>.
[RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using [RFC4754] Fu, D. and J. Solinas, "IKE and IKEv2 Authentication Using
the Elliptic Curve Digital Signature Algorithm (ECDSA)", the Elliptic Curve Digital Signature Algorithm (ECDSA)",
RFC 4754, DOI 10.17487/RFC4754, January 2007, RFC 4754, DOI 10.17487/RFC4754, January 2007,
<http://www.rfc-editor.org/info/rfc4754>. <http://www.rfc-editor.org/info/rfc4754>.
[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>.
skipping to change at page 17, line 25 skipping to change at page 18, line 42
[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>.
[RFC6919] Barnes, R., Kent, S., and E. Rescorla, "Further Key Words [RFC6711] Johansson, L., "An IANA Registry for Level of Assurance
for Use in RFCs to Indicate Requirement Levels", RFC 6919, (LoA) Profiles", RFC 6711, DOI 10.17487/RFC6711, August
DOI 10.17487/RFC6919, April 2013, 2012, <http://www.rfc-editor.org/info/rfc6711>.
<http://www.rfc-editor.org/info/rfc6919>.
[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>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030, "Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013, DOI 10.17487/RFC7030, October 2013,
<http://www.rfc-editor.org/info/rfc7030>. <http://www.rfc-editor.org/info/rfc7030>.
[RFC7093] Turner, S., Kent, S., and J. Manger, "Additional Methods
for Generating Key Identifiers Values", RFC 7093,
DOI 10.17487/RFC7093, December 2013,
<http://www.rfc-editor.org/info/rfc7093>.
[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>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
 End of changes. 26 change blocks. 
107 lines changed or deleted 183 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/