draft-ietf-stir-cert-delegation-02.txt   draft-ietf-stir-cert-delegation-03.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Standards Track March 9, 2020 Intended status: Standards Track July 13, 2020
Expires: September 10, 2020 Expires: January 14, 2021
STIR Certificate Delegation STIR Certificate Delegation
draft-ietf-stir-cert-delegation-02 draft-ietf-stir-cert-delegation-03
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 September 10, 2020. This Internet-Draft will expire on January 14, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 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
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Delegation of STIR Certificates . . . . . . . . . . . . . . . 4 4. Delegation of STIR Certificates . . . . . . . . . . . . . . . 4
4.1. Scope of Delegation . . . . . . . . . . . . . . . . . . . 5 4.1. Scope of Delegation . . . . . . . . . . . . . . . . . . . 5
5. Authentication Services Signing with Delegate Certificates . 6 5. Authentication Services Signing with Delegate Certificates . 6
6. Verification Service Behavior for Delegate Certificate 6. Verification Service Behavior for Delegate Certificate
Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 6 Signatures . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Acquiring Certificate Chains in STIR . . . . . . . . . . . . 7 7. Acquiring Multiple Certificates in STIR . . . . . . . . . . . 7
8. Certification Authorities and Service Providers . . . . . . . 7 8. Certification Authorities and Service Providers . . . . . . . 8
8.1. ACME and Delegation . . . . . . . . . . . . . . . . . . . 8 8.1. ACME and Delegation . . . . . . . . . . . . . . . . . . . 8
8.2. Handling Multiple Certificates . . . . . . . . . . . . . 9 8.2. Handling Multiple Certificates . . . . . . . . . . . . . 9
9. Alternative Solutions . . . . . . . . . . . . . . . . . . . . 9 9. Alternative Solutions . . . . . . . . . . . . . . . . . . . . 9
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
12. Security Considerations . . . . . . . . . . . . . . . . . . . 10 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
14.1. Normative References . . . . . . . . . . . . . . . . . . 10 14.1. Normative References . . . . . . . . . . . . . . . . . . 11
14.2. Informative References . . . . . . . . . . . . . . . . . 11 14.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The STIR problem statement [RFC7340] reviews the difficulties facing The STIR problem statement [RFC7340] reviews the difficulties facing
the telephone network that are enabled by impersonation, including the telephone network that are enabled by impersonation, including
various forms of robocalling, voicemail hacking, and swatting. One various forms of robocalling, voicemail hacking, and swatting. One
of the most important components of a system to prevent impersonation of the most important components of a system to prevent impersonation
is the implementation of credentials which identify the parties who is the implementation of credentials which identify the parties who
control telephone numbers. The STIR certificates [RFC8226] control telephone numbers. The STIR certificates [RFC8226]
specification describes a credential system based on [X.509] version specification describes a credential system based on [X.509] version
skipping to change at page 4, line 20 skipping to change at page 4, line 20
carriers may be forced to sign calls with credentials that do not carriers may be forced to sign calls with credentials that do not
cover the originating number in question. Unfortunately, that cover the originating number in question. Unfortunately, that
practice would be difficult to distinguish from malicious spoofing, practice would be difficult to distinguish from malicious spoofing,
and if it becomes widespread, it could erode trust in STIR overall. and if it becomes widespread, it could erode trust in STIR overall.
4. Delegation of STIR Certificates 4. Delegation of STIR Certificates
STIR delegate certificates are certificates containing a TNAuthList STIR delegate certificates are certificates containing a TNAuthList
object that have been signed with the private key of a parent object that have been signed with the private key of a parent
certificate that itself contains a TNAuthList object. The parent certificate that itself contains a TNAuthList object. The parent
certificate needs to have its CA boolean set to "true", indicating certificate needs contain a basic constraints extension with the cA
that that it can sign certificates. Every STIR delegate certificate boolean set to "true", indicating that the subject can sign
identifies its parent certificate with a standard [RFC5280] Authority certificates. Every STIR delegate certificate identifies its parent
Key Identifier. certificate with a standard [RFC5280] Authority Key Identifier
extension.
The authority bestowed on the holder of the delegate certificate by The authority bestowed on the holder of the delegate certificate by
the parent certificate is recorded in the delegate certificate's the parent certificate is recorded in the delegate certificate's
TNAuthList. Because STIR certificates use the TNAuthList object TNAuthList. Because STIR certificates use the TNAuthList object
rather than the Subject Name for indicating the scope of their rather than the Subject Name for indicating the scope of their
authority, traditional [RFC5280] name constraints are not directly authority, traditional [RFC5280] name constraints are not directly
applicable to STIR. In a manner similar to the RPKI [RFC6480] applicable to STIR. In a manner similar to the RPKI [RFC6480]
"encompassing" semantics, each delegate certificate must have a "encompassing" semantics, each delegate certificate must have a
TNAuthList scope that is equal to or a subset of its parent TNAuthList scope that is equal to or a subset of its parent
certificate's scope: it must be "encompassed." For example, a parent certificate's scope: it must be "encompassed." For example, a parent
certificate with a TNAuthList that attested authority for the certificate with a TNAuthList that attested authority for the
numbering range +1-212-555-1000 through 1999 could issue a numbering range +1-212-555-1000 through 1999 could issue a
certificate to one delegate attesting authority for the range certificate to one delegate attesting authority for the range
+1-212-555-1500 through 1599, and to another delegate a certificate +1-212-555-1500 through 1599, and to another delegate a certificate
for the individual number +1-212-555-1824. for the individual number +1-212-555-1824.
Delegate certificates may themselves be issued with the CA boolean Delegate certificates may also contain a basic constraints extension
set to "true" so that they can serve as parent certificates to with the cA boolean set to "true", indicating that they can sign
further delegates; effectively, this delegate certificate is a cross- subordinate certificates for further delegates. In the STIR
certificate, as its issuer is not the same as its subject. In the ecosystem, CA certificates may be used to sign PASSporTs; this
STIR ecosystem, CA certificates may be used to sign PASSporTs; this
removes the need for creating a redundant end-entity certificate with removes the need for creating a redundant end-entity certificate with
an identical TNAuthList to its parent, though if for operational or an identical TNAuthList to its parent, though if for operational or
security reasons certificate holders wish to do so, they may. security reasons certificate holders wish to do so, they may.
4.1. Scope of Delegation 4.1. Scope of Delegation
STIR certificates may have a TNAuthList containing one or more SPCs, STIR certificates may have a TNAuthList containing one or more SPCs,
one or more telephone number ranges, or both. When delegating from a one or more telephone number ranges, or both. When delegating from a
STIR certificate, a child certificate may inherit from its parent STIR certificate, a child certificate may inherit from its parent
either of the above. Depending on the sort of numbering resources either of the above. Depending on the sort of numbering resources
that a delegate has been assigned, various syntaxes can be used to that a delegate has been assigned, various syntaxes can be used to
capture the delegated resource. capture the delegated resource.
Some non-carrier entities may be assigned large and complex Some non-carrier entities may be assigned large and complex
allocations of telephone numbers, which may be only partially allocations of telephone numbers, which may be only partially
contiguous or entirely disparate. Allocations may also change contiguous or entirely disparate. Allocations may also change
frequently, in minor or significant ways. These resources may be so frequently, in minor or significant ways. These resources may be so
complex, dynamic, or extensive that listing them in a certificate is complex, dynamic, or extensive that listing them in a certificate is
prohibitively difficult. [RFC8226] Section 10.1 describes one prohibitively difficult. Section 10.1 of [RFC8226] describes one
potential way to address this, including the TNAuthList in the potential way to address this, including the TNAuthList (specified in
certificate by-reference rather than by value, where a URL in the [RFC8226]) in the certificate by-reference rather than by value,
certificate points to a secure, dynamically-updated list of the where a URL in the certificate points to a secure, dynamically-
telephone numbers in the scope of authority of a certificate. For updated list of the telephone numbers in the scope of authority of a
entities that are carriers in all but name, another alternative is certificate. For entities that are carriers in all but name, another
the allocation of an SPC; this yields much the same property, as the alternative is the allocation of an SPC; this yields much the same
SPC is effectively a pointer to an external database which property, as the SPC is effectively a pointer to an external database
dynamically tracks the numbers associated with the SPC. Either of which dynamically tracks the numbers associated with the SPC. Either
these approaches may make sense for a given deployment. of these approaches may make sense for a given deployment.
Other non-carrier entities may have straightforward telephone number Other non-carrier entities may have straightforward telephone number
assignments, such as enterprises receiving a set of thousand blocks assignments, such as enterprises receiving a set of thousand blocks
from a carrier that may be kept for years or decades. Particular from a carrier that may be kept for years or decades. Particular
freephone numbers may also have a long-term association with an freephone numbers may also have a long-term association with an
enterprise and its brand. For these sorts of assignments, assigning enterprise and its brand. For these sorts of assignments, assigning
an SPC may seem like overkill, and using the TN ranges of the an SPC may seem like overkill, and using the TN ranges of the
TNAuthList (by-value) is surely sufficient. TNAuthList (by-value) is sufficient.
Whichever approach is taken to representing the delegated resource, Whichever approach is taken to representing the delegated resource,
there are fundamental trade-offs regarding when and where in the there are fundamental trade-offs regarding when and where in the
architecture a delegation is validated: that is, when the delegated architecture a delegation is validated: that is, when the delegated
TNAuthList is checked to be "encompassed" by the TNAuthList of its TNAuthList is checked to be "encompassed" by the TNAuthList of its
parent. This might be performed at the time the delegate certificate parent. This might be performed at the time the delegate certificate
is issued, or at the time that a verification service receives an is issued, or at the time that a verification service receives an
inbound call, or potentially both. It is generally desirable to inbound call, or potentially both. It is generally desirable to
offload as much of this as possible to the certification process, as offload as much of this as possible to the certification process, as
verification occurs during call setup and thus additional network verification occurs during call setup and thus additional network
skipping to change at page 6, line 23 skipping to change at page 6, line 23
number ranges, and a telephone number may belong to more than one number ranges, and a telephone number may belong to more than one
SPC, this may introduce some redundancy to the set of telephone SPC, this may introduce some redundancy to the set of telephone
numbers specified as the scope of a certificate. The presence of one numbers specified as the scope of a certificate. The presence of one
or more SPCs and one or more sets of telephone number ranges should or more SPCs and one or more sets of telephone number ranges should
similarly be treated additively, even if the telephone number ranges similarly be treated additively, even if the telephone number ranges
turn out to be redundant to the scope of an SPC. turn out to be redundant to the scope of an SPC.
5. Authentication Services Signing with Delegate Certificates 5. Authentication Services Signing with Delegate Certificates
Authentication service behavior for delegate certificates is little Authentication service behavior for delegate certificates is little
changed from baseline STIR behavior. The same checks are performed changed from [RFC8224] STIR behavior. The same checks are performed
by the authentication service, comparing the calling party number by the authentication service, comparing the calling party number
attested in call signaling with the scope of the authority of the attested in call signaling with the scope of the authority of the
signing certificate. Authentication services SHOULD NOT use a signing certificate. Authentication services SHOULD NOT use a
delegate certificate without validating that its scope of authority delegate certificate without validating that its scope of authority
is encompassed by that of its parent certificate, and if that is encompassed by that of its parent certificate, and if that
certificate in turn has its own parent, the entire certificate path certificate has a own parent, the entire certification path SHOULD be
should be validated. validated.
This delegation architecture does not require that a non-carrier This delegation architecture does not require that a non-carrier
entity act as its own authentication service. That function may be entity act as its own authentication service. That function may be
performed by any authentication service that holds the private key performed by any authentication service that holds the private key
corresponding to the delegate certificate, including one run by an corresponding to the delegate certificate, including one run by an
outbound service provider, a third party in an enterprise's outbound outbound service provider, a third party in an enterprise's outbound
call path, or in the SIP User Agent itself. call path, or in the SIP User Agent itself.
Note that authentication services creating a PASSporT for a call Note that authentication services creating a PASSporT for a call
signed with a delegate certificate MUST provide an "x5u" link signed with a delegate certificate MUST provide an "x5u" link
corresponding to the entire certificate chain, rather than just the corresponding to the entire certification path, rather than just the
delegate certificate used to sign the call, as described in delegate certificate used to sign the call, as described in
Section 7. Section 7.
6. Verification Service Behavior for Delegate Certificate Signatures 6. Verification Service Behavior for Delegate Certificate Signatures
The responsibility of a verification service validating PASSporTs The responsibility of a verification service validating PASSporTs
signed with delegate certificates, while largely following baseline signed with delegate certificates, while largely following baseline
[RFC8224] and [RFC8225], requires some additional procedures. When [RFC8224] and [RFC8225], requires some additional procedures. When
the verification service dereferences the "x5u" parameter, it will the verification service dereferences the "x5u" parameter, it will
acquire a certificate list rather than a single certificate. It MUST acquire a certificate list rather than a single certificate. It MUST
then validate all of the credentials in the list, identifying the then validate all of the credentials in the list, identifying the
parent certificate for each delegate through its AKID object. parent certificate for each delegate through its Authority Key
Identifier extension.
While ordinarily, relying parties have significant latitude in path While ordinarily, relying parties have significant latitude in
construction when validating a certificate chain, STIR assumes a more certification path construction when validating a certification path,
rigid hierarchical subordination model, rather than one where relying STIR assumes a more rigid hierarchical subordination model, rather
parties may want to derive their own chains to particular trust than one where relying parties may want to derive their own
anchors. If the certificate chain acquired from the "x5u" element of certification path to particular trust anchors. If the certificates
a PASSporT does not lead to an anchor that the verification service acquired from the "x5u" element of a PASSporT do not lead to an
trusts, it treats the validation no differently than it would when a anchor that the verification service trusts, it treats the validation
non-delegated certificate was issued by an untrusted root; in SIP, it no differently than it would when a non-delegated certificate was
MAY return a 437 "Unsupported Credential" response if the call should issued by an untrusted root; in SIP, it MAY return a 437 "Unsupported
be failed for lack of a valid Identity header. Credential" response if the call should be failed for lack of a valid
Identity header.
7. Acquiring Certificate Chains in STIR 7. Acquiring Multiple Certificates in STIR
PASSporT [RFC8225] uses the "x5u" element to convey the URL where PASSporT [RFC8225] uses the "x5u" element to convey the URL where
verification services can acquire the certificate used to sign a verification services can acquire the certificate used to sign a
PASSporT. This value is mirrored by the "info" parameter of the PASSporT. This value is mirrored by the "info" parameter of the
Identity header when a PASSporT is conveyed via SIP. Commonly, this Identity header when a PASSporT is conveyed via SIP. Commonly, this
is an HTTPS URI. is an HTTPS URI.
When a STIR delegate certificate is used to sign a PASSporT, the When a STIR delegate certificate is used to sign a PASSporT, the
"x5u" element in the PASSporT will contain a URI indicating where a "x5u" element in the PASSporT will contain a URI indicating where a
certificate list is available. While baseline JWS also supports an certificate list is available. While baseline JWS also supports an
"x5c" element specifically for certificate chains, in operational "x5c" element specifically for certificate chains, in operational
practice, chains are already being delivered in the STIR environment practice, certification path are already being delivered in the STIR
via the "x5u" element, so this specification recommends continuing to environment via the "x5u" element, so this specification recommends
use "x5u". That list will be a concatenation of PEM encoded continuing to use "x5u". That list will be a concatenation of PEM-
certificates of the type "application/pem-certificate-chain" defined encoded certificates of the type "application/pem-certificate-chain"
in [RFC8555]. The list begins with the certificate used to sign the defined in [RFC8555]. The certificate path [RFC5280] ordering MUST
PASSporT, followed by its parent, and then any subsequent be organized from the trust anchor towards the signer. The list
grandparents, great-grandparents, and so on. The ordering MUST begins with the certificate used to sign the PASSporT, followed by
conform to the AKID/SKID order chain encoded in the certs themselves. its parent, and then any subsequent grandparents, great-grandparents,
Note that ACME requires the first element in a pem-certificate-chain and so on. The key identifier in the Authority Key Identifier
to be an end-entity certificate; STIR relaxes this requirement, as CA extension in the first certificate MUST appear in the Subject Key
certificates are permitted to sign PASSporTs, so the first element in Identifier extension in the second certificate. The key identifier
a pem-certificate-chain used for STIR MAY be a CA certificate. pairing MUST match in this way throughout the entire chain of
certificates. Note that ACME [RFC8555] requires the first element in
a pem-certificate-chain to be an end-entity certificate; however,
STIR relaxes this requirement, because CA certificates are permitted
to sign PASSporTs, so for STIR, the first element in 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 resources from
they see fit. Note that the allocation to a service provider of a it as they see fit. Note that the allocation to a service provider
certificate with the CA boolean set to "true" does not require that a of a certificate with a basic constraints extension with the cA
service provider act as a certification authority itself; serving as boolean set to "true" does not require that a service provider act as
a certification authority is a function requiring specialized a certification authority itself; serving as a certification
expertise and infrastructure. A third-party certification authority, authority is a function requiring specialized expertise and
including the same one that issued the service provider its parent infrastructure. A third-party certification authority, including the
certificate, could act as the CA that issues delegate certificates same one that issued the service provider its parent certificate,
for the service provider, if the necessary business relationships could act as the CA that issues delegate certificates for the service
permit it. A service provider might in this case act as a Token provider, if the necessary business relationships permit it. A
Authority (see Section 8.1) granting its customers permissions to service provider might in this case act as a Token Authority (see
receive certificates from the CA. 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 certification path, 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 trust anchor) with the
the proper TNAuthList value, relying parties might not be able to 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
certificate outside of the TNAuthList could preserve that certificate outside of the TNAuthList could preserve that
information; this is a potential area for future work. information; this is a potential area for future work.
All CAs must detail in their practices and policies a requirement to All CAs must detail in their practices and policies a requirement to
validate that the "encompassing" of a delegate certificate by its validate that the "encompassing" of a delegate certificate by its
parent. Note that this requires that CAs have access to the parent. Note that this requires that CAs have access to the
necessary industry databases to ascertain whether, for example, a necessary industry databases to ascertain whether, for example, a
particular telephone number is encompassed by an SPC. Alternatively, particular telephone number is encompassed by an SPC. Alternatively,
a CA may acquire an Authority Token that affirms that a delegation is a CA may acquire an Authority Token that affirms that a delegation is
in the proper scope. Exactly what operational practices this entails in the proper scope. Exactly what operational practices this entails
may vary in different national telephone administrations, and are may vary in different national telephone administrations, and are
thus left to the CP/CPS. thus left to the CP/CPS [RFC3647].
8.1. ACME and Delegation 8.1. ACME and Delegation
STIR deployments commonly use ACME [RFC8555] for certificate STIR deployments commonly use ACME [RFC8555] for certificate
acquisition, and it is anticipated that delegate certificates as well acquisition, and it is anticipated that delegate certificates as well
will be acquired through an ACME interface. An entity can acquire a will be acquired through an ACME interface. An entity can acquire a
certificate from a particular CA by requesting an Authority Token certificate from a particular CA by requesting an Authority Token
[I-D.ietf-acme-authority-token] from the parent with the desired [I-D.ietf-acme-authority-token] from the parent with the desired
TNAuthList [I-D.ietf-acme-authority-token-tnauthlist] object. Note TNAuthList [I-D.ietf-acme-authority-token-tnauthlist] object. Note
that if the client intends to do further subdelegation of its own, it that if the client intends to do further subdelegation of its own, it
should request a token with the "ca" Authority Token flag set. should request a token with the "ca" Authority Token flag set.
The entity then presents that Authority Token to a CA to acquire a The entity then presents that Authority Token to a CA to acquire a
STIR delegate certificate. ACME returns an "application/pem- STIR delegate certificate. ACME returns an "application/pem-
certificate-chain" object with suitable for publishing as an HTTPS certificate-chain" object with suitable for publishing as an HTTPS
resource for retrieval with the PASSporT "x5u" mechanism as discussed resource for retrieval with the PASSporT "x5u" mechanism as discussed
in Section 7. If the CSR presented to the ACME server is for a in Section 7. If the CSR presented to the ACME server is for a
certificate with the CA boolean set to "true", then the ACME server certificate with the cA boolean set to "true", then the ACME server
makes a policy decision to determine whether or not it is appropriate makes a policy decision to determine whether or not it is appropriate
to issue that certificate to the requesting entity. That policy to issue that certificate to the requesting entity. That policy
decision will be reflected by the "ca" flag in the Authority Token. decision will be reflected by the "ca" flag in the Authority Token.
Service providers that want the capability to rapidly revoke Service providers that want the capability to rapidly revoke
delegated certificates can rely on the ACME STAR [I-D.ietf-acme-star] delegated certificates can rely on the ACME STAR [I-D.ietf-acme-star]
mechanism to automate the process of short-term certificate expiry. mechanism to automate the process of short-term certificate expiry.
8.2. Handling Multiple Certificates 8.2. Handling Multiple Certificates
skipping to change at page 9, line 42 skipping to change at page 10, line 4
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 and a "ca" boolean set to "true". Similar with a TNAuthList object and a cA boolean set to "true" in the basic
problems in the web PKI space motivated the development of TLS constraints certificate extension [RFC5280]. Similar problems in the
subcerts [I-D.ietf-tls-subcerts], which substitutes a signed web PKI space motivated the development of TLS subcerts
"delegated credential" token for a certificate for such environments. [I-D.ietf-tls-subcerts], which substitutes a signed "delegated
A comparable mechanism could be developed for the STIR space, credential" token for a certificate for such environments. A
allowing STIR certificates to sign a data object which contains comparable mechanism could be developed for the STIR space, allowing
effectively the same data as the delegate certificate specified here, STIR certificates to sign a data object which contains effectively
including a public key that could sign PASSporTs. The TLS subcerts the same data as the delegate certificate specified here, including a
system has furthermore developed ways for the issuer of a delegated public key that could sign PASSporTs. The TLS subcerts system has
credential to revoke it, as well as exploring the potential furthermore developed ways for the issuer of a delegated credential
interaction with ACME to issue short-lived certificates for temporary to revoke it, as well as exploring the potential interaction with
delegation. Specification of a TLS subcerts analog for STIR is ACME to issue short-lived certificates for temporary delegation.
deferred here to future work, at such a time as market players Specification of a mechanism similar to TLS subcerts for STIR is
require it. future work, and will be undertaken only if the market 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 34 skipping to change at page 11, line 46
[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-04 (work in progress), November 2019. authority-token-05 (work in progress), March 2020.
[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-05 (work in progress), acme-authority-token-tnauthlist-06 (work in progress),
November 2019. March 2020.
[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-06 (work in progress), February 2020. subcerts-09 (work in progress), June 2020.
[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,
<https://www.rfc-editor.org/info/rfc3647>.
[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. 26 change blocks. 
91 lines changed or deleted 105 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/