draft-ietf-stir-cert-delegation-01.txt   draft-ietf-stir-cert-delegation-02.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Standards Track November 4, 2019 Intended status: Standards Track March 9, 2020
Expires: May 7, 2020 Expires: September 10, 2020
STIR Certificate Delegation STIR Certificate Delegation
draft-ietf-stir-cert-delegation-01 draft-ietf-stir-cert-delegation-02
Abstract Abstract
The Secure Telephone Identity Revisited (STIR) certificate profile The Secure Telephone Identity Revisited (STIR) certificate profile
provides a way to attest authority over telephone numbers and related provides a way to attest authority over telephone numbers and related
identifiers for the purpose of preventing telephone number spoofing. identifiers for the purpose of preventing telephone number spoofing.
This specification details how that authority can be delegated from a This specification details how that authority can be delegated from a
parent certificate to a subordinate certificate. This supports a parent certificate to a subordinate certificate. This supports a
number of use cases, including those where service providers grant number of use cases, including those where service providers grant
credentials to enterprises or other customers capable of signing credentials to enterprises or other customers capable of signing
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 7, 2020. This Internet-Draft will expire on September 10, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 3, line 15 skipping to change at page 3, line 15
List of the certificate that signed the PASSporT to determine if the List of the certificate that signed the PASSporT to determine if the
caller is authorized to use that calling number. caller is authorized to use that calling number.
Initial deployment of [RFC8226] has focused on the use of Service Initial deployment of [RFC8226] has focused on the use of Service
Provider Codes (SPCs) to attest the scope of authority of a Provider Codes (SPCs) to attest the scope of authority of a
certificate. Typically, these codes are internal telephone network certificate. Typically, these codes are internal telephone network
identifiers such as the Operating Company Numbers (OCNs) assigned to identifiers such as the Operating Company Numbers (OCNs) assigned to
carriers in the United States. However, these network identifiers carriers in the United States. However, these network identifiers
are effectively unavailable to non-carrier entities, and this has are effectively unavailable to non-carrier entities, and this has
raised questions about how such entities might best participate in raised questions about how such entities might best participate in
STIR, when needed. [RFC8226] gave an overview of a certificate STIR, when needed. Additionally, a carrier may sometimes operate
enrollment model based on "delegation," whereby the holder of numbers that are formally assigned to another carrier. [RFC8226]
certificate might allocate a subset of that certificate's authority gave an overview of a certificate enrollment model based on
to another party. This specification details how delegation of "delegation," whereby the holder of certificate might allocate a
authority works for STIR certificates. subset of that certificate's authority to another party. This
specification details how delegation of authority works for STIR
certificates.
2. Terminology 2. Terminology
TThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Motivation 3. Motivation
The most pressing need for delegation in STIR arises in a set of use The most pressing need for delegation in STIR arises in a set of use
cases where callers want to use a particular calling number, but for cases where callers want to use a particular calling number, but for
whatever reason, their outbound calls will not pass through the whatever reason, their outbound calls will not pass through the
skipping to change at page 7, line 49 skipping to change at page 7, line 49
to be an end-entity certificate; STIR relaxes this requirement, as CA to be an end-entity certificate; STIR relaxes this requirement, as CA
certificates are permitted to sign PASSporTs, so the first element in certificates are permitted to sign PASSporTs, so the first element in
a pem-certificate-chain used for STIR MAY be a CA certificate. a pem-certificate-chain used for STIR MAY be a CA certificate.
8. Certification Authorities and Service Providers 8. Certification Authorities and Service Providers
Once a telephone service provider has received a CA certificate Once a telephone service provider has received a CA certificate
attesting their numbering resources, they may delegate from it as attesting their numbering resources, they may delegate from it as
they see fit. Note that the allocation to a service provider of a they see fit. Note that the allocation to a service provider of a
certificate with the CA boolean set to "true" does not require that a certificate with the CA boolean set to "true" does not require that a
service provider act as a certification authority itself; it is a service provider act as a certification authority itself; serving as
function requiring specialized expertise and infrastructure. A a certification authority is a function requiring specialized
third-party certification authority, including the same one that expertise and infrastructure. A third-party certification authority,
issued the service provider its parent certificate, could act as the including the same one that issued the service provider its parent
CA that issues delegate certificates for the service provider, if the certificate, could act as the CA that issues delegate certificates
necessary business relationships permit it. A service provider might for the service provider, if the necessary business relationships
in this case act as a Token Authority (see Section 8.1) granting its permit it. A service provider might in this case act as a Token
customers permissions to receive certificates from the CA. Authority (see Section 8.1) granting its customers permissions to
receive certificates from the CA.
Note that if the same CA that issued the parent certificate is also Note that if the same CA that issued the parent certificate is also
issuing a delegate certificate, it may be possible to shorten the issuing a delegate certificate, it may be possible to shorten the
certificate chain, which reduces the work required of verification certificate chain, which reduces the work required of verification
services. The trade-off here is that if the CA simply issued a non- services. The trade-off here is that if the CA simply issued a non-
delegate certificate (whose parent is the CA's root certificate) with delegate certificate (whose parent is the CA's root certificate) with
the proper TNAuthList value, relying parties might not be able to the proper TNAuthList value, relying parties might not be able to
ascertain which service provider owned those telephone numbers, ascertain which service provider owned those telephone numbers,
information which might be used to make an authorization decision on information which might be used to make an authorization decision on
the terminating side. However, some additional object in the the terminating side. However, some additional object in the
skipping to change at page 9, line 40 skipping to change at page 9, line 42
enterprise, rather than requiring a mesh of cross-certification enterprise, rather than requiring a mesh of cross-certification
between a large number of certificates. Again, this bridge CA between a large number of certificates. Again, this bridge CA
function would likely be performed by some existing CA in the STIR function would likely be performed by some existing CA in the STIR
ecosystem. ecosystem.
9. Alternative Solutions 9. Alternative Solutions
At the time this specification was written, STIR was only starting to At the time this specification was written, STIR was only starting to
see deployment. In some future environments, the policies that see deployment. In some future environments, the policies that
govern CAs may not permit them to issue intermediate certificates govern CAs may not permit them to issue intermediate certificates
with a TNAuthList object. Similar problems in the web PKI space with a TNAuthList object and a "ca" boolean set to "true". Similar
motivated the development of TLS subcerts [I-D.ietf-tls-subcerts], problems in the web PKI space motivated the development of TLS
which substitutes a signed "delegated credential" token for a subcerts [I-D.ietf-tls-subcerts], which substitutes a signed
certificate for such environments. A similar mechanism could be "delegated credential" token for a certificate for such environments.
developed for the STIR space, allowing STIR certificates to sign a A comparable mechanism could be developed for the STIR space,
data object which contains effectively the same data as the delegate allowing STIR certificates to sign a data object which contains
certificate specified here, including a public key that could sign effectively the same data as the delegate certificate specified here,
PASSporTs. The TLS subcerts system has furthermore developed ways including a public key that could sign PASSporTs. The TLS subcerts
for the issuer of a delegated credential to revoke it, as well as system has furthermore developed ways for the issuer of a delegated
exploring the potential interaction with ACME to issue short-lived credential to revoke it, as well as exploring the potential
certificates for temporary delegation. Specification of a TLS interaction with ACME to issue short-lived certificates for temporary
subcerts analog for STIR is deferred here to future work, at such a delegation. Specification of a TLS subcerts analog for STIR is
time as market players require it. deferred here to future work, at such a time as market players
require it.
10. IANA Considerations 10. IANA Considerations
This document contains no actions for the IANA. This document contains no actions for the IANA.
11. Privacy Considerations 11. Privacy Considerations
Any STIR certificate that identifies a narrow range of telephone Any STIR certificate that identifies a narrow range of telephone
numbers potentially exposes information about the entities that are numbers potentially exposes information about the entities that are
placing calls. As this information is necessarily a superset of the placing calls. As this information is necessarily a superset of the
skipping to change at page 11, line 30 skipping to change at page 11, line 34
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
Kasten, "Automatic Certificate Management Environment Kasten, "Automatic Certificate Management Environment
(ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
<https://www.rfc-editor.org/info/rfc8555>. <https://www.rfc-editor.org/info/rfc8555>.
14.2. Informative References 14.2. Informative References
[I-D.ietf-acme-authority-token] [I-D.ietf-acme-authority-token]
Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME
Challenges Using an Authority Token", draft-ietf-acme- Challenges Using an Authority Token", draft-ietf-acme-
authority-token-03 (work in progress), March 2019. authority-token-04 (work in progress), November 2019.
[I-D.ietf-acme-authority-token-tnauthlist] [I-D.ietf-acme-authority-token-tnauthlist]
Wendt, C., Hancock, D., Barnes, M., and J. Peterson, Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList profile of ACME Authority Token", draft-ietf- "TNAuthList profile of ACME Authority Token", draft-ietf-
acme-authority-token-tnauthlist-04 (work in progress), acme-authority-token-tnauthlist-05 (work in progress),
September 2019. November 2019.
[I-D.ietf-acme-star] [I-D.ietf-acme-star]
Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T. Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
Fossati, "Support for Short-Term, Automatically-Renewed Fossati, "Support for Short-Term, Automatically-Renewed
(STAR) Certificates in Automated Certificate Management (STAR) Certificates in Automated Certificate Management
Environment (ACME)", draft-ietf-acme-star-11 (work in Environment (ACME)", draft-ietf-acme-star-11 (work in
progress), October 2019. progress), October 2019.
[I-D.ietf-tls-subcerts] [I-D.ietf-tls-subcerts]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS", draft-ietf-tls- "Delegated Credentials for TLS", draft-ietf-tls-
subcerts-04 (work in progress), July 2019. subcerts-06 (work in progress), February 2020.
[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,
<https://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
February 2012, <https://www.rfc-editor.org/info/rfc6480>. February 2012, <https://www.rfc-editor.org/info/rfc6480>.
 End of changes. 11 change blocks. 
36 lines changed or deleted 40 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/