draft-ietf-stir-cert-delegation-00.txt   draft-ietf-stir-cert-delegation-01.txt 
Network Working Group J. Peterson Network Working Group J. Peterson
Internet-Draft Neustar Internet-Draft Neustar
Intended status: Standards Track July 8, 2019 Intended status: Standards Track November 4, 2019
Expires: January 9, 2020 Expires: May 7, 2020
STIR Certificate Delegation STIR Certificate Delegation
draft-ietf-stir-cert-delegation-00.txt draft-ietf-stir-cert-delegation-01
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 January 9, 2020. This Internet-Draft will expire on May 7, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 14 skipping to change at page 2, line 14
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Delegation of STIR Certificates . . . . . . . . . . . . . . . 4 4. Delegation of STIR Certificates . . . . . . . . . . . . . . . 4
4.1. Scope of Delegation . . . . . . . . . . . . . . . . . . . 4 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 Certificate Chains in STIR . . . . . . . . . . . . 7
8. Certification Authorities and Service Providers . . . . . . . 7 8. Certification Authorities and Service Providers . . . . . . . 7
8.1. ACME and Delegation . . . . . . . . . . . . . . . . . . . 8 8.1. ACME and Delegation . . . . . . . . . . . . . . . . . . . 8
8.2. Handling Multiple Certificates . . . . . . . . . . . . . 8 8.2. Handling Multiple Certificates . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Alternative Solutions . . . . . . . . . . . . . . . . . . . . 9
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
11. Security Considerations . . . . . . . . . . . . . . . . . . . 9 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 12. Security Considerations . . . . . . . . . . . . . . . . . . . 10
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
13.1. Normative References . . . . . . . . . . . . . . . . . . 9 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
13.2. Informative References . . . . . . . . . . . . . . . . . 11 14.1. Normative References . . . . . . . . . . . . . . . . . . 10
14.2. Informative References . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12
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]
skipping to change at page 4, line 18 skipping to change at page 4, line 21
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 to have its CA boolean set to "true", indicating
that that it can sign certificates. [TBD: Do we need to explore that that it can sign certificates. Every STIR delegate certificate
alternatives (subcerts?)] Every STIR delegate certificate identifies identifies its parent certificate with a standard [RFC5280] Authority
its parent certificate with a standard [RFC5280] Authority Key Key Identifier.
Identifier.
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
skipping to change at page 6, line 5 skipping to change at page 6, line 9
outside of call processing as a largely administrative function. outside of call processing as a largely administrative function.
Ideally, if a delegate certificate can supply a by-value TN range, Ideally, if a delegate certificate can supply a by-value TN range,
then a verification service could ascertain that an attested calling then a verification service could ascertain that an attested calling
party number is within the scope of the provided certificate without party number is within the scope of the provided certificate without
requiring any additional network dip. In practice, verification requiring any additional network dip. In practice, verification
services may already incorporate network queries into their services may already incorporate network queries into their
processing (for example, to deference the "x5u" field of a PASSporT) processing (for example, to deference the "x5u" field of a PASSporT)
that could piggyback any additional information needed by the that could piggyback any additional information needed by the
verification service. verification service.
Note that the permission semantics of the [RFC8226] TNAuthList are
additive: that is, the scope of a certificate is the superset of all
of the SPCs and telephone number ranges enumerated in the TNAuthList.
As SPCs themselves are effectively pointers to a set of telephone
number ranges, and a telephone number may belong to more than one
SPC, this may introduce some redundancy to the set of telephone
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
similarly be treated additively, even if the telephone number ranges
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 baseline 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 in turn has its own parent, the entire certificate path
skipping to change at page 7, line 15 skipping to change at page 7, line 28
7. Acquiring Certificate Chains in STIR 7. Acquiring Certificate Chains 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. [TBD: is it realistic to make this certificate list is available. While baseline JWS also supports an
"x5c"?] That list will be a concatenation of PEM encoded "x5c" element specifically for certificate chains, in operational
practice, chains are already being delivered in the STIR environment
via the "x5u" element, so this specification recommends continuing to
use "x5u". That list will be a concatenation of PEM encoded
certificates of the type "application/pem-certificate-chain" defined certificates of the type "application/pem-certificate-chain" defined
in [RFC8555]. The list begins with the certificate used to sign the in [RFC8555]. The list begins with the certificate used to sign the
PASSporT, followed by its parent, and then any subsequent PASSporT, followed by its parent, and then any subsequent
grandparents, great-grandparents, and so on. The ordering MUST grandparents, great-grandparents, and so on. The ordering MUST
conform to the AKID/SKID order chain encoded in the certs themselves. conform to the AKID/SKID order chain encoded in the certs themselves.
Note that ACME requires the first element in a pem-certificate-chain Note that ACME requires the first element in a pem-certificate-chain
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.
skipping to change at page 7, line 45 skipping to change at page 8, line 13
third-party certification authority, including the same one that third-party certification authority, including the same one that
issued the service provider its parent certificate, could act as the issued the service provider its parent certificate, could act as the
CA that issues delegate certificates for the service provider, if the CA that issues delegate certificates for the service provider, if the
necessary business relationships permit it. A service provider might necessary business relationships permit it. A service provider might
in this case act as a Token Authority (see Section 8.1) granting its in this case act as a Token Authority (see Section 8.1) granting its
customers permissions to receive certificates from the CA. 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. 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
the proper TNAuthList value, relying parties might not be able to
ascertain which service provider owned those telephone numbers,
information which might be used to make an authorization decision on
the terminating side. However, some additional object in the
certificate outside of the TNAuthList could preserve that
information; this is a potential area for future work.
It is RECOMMENDED that any CA include in its practices and policies a All CAs must detail in their practices and policies a requirement to
requirement to validate that the "encompassing" of a delegate validate that the "encompassing" of a delegate certificate by its
certificate by its parent. Future versions of this specification parent. Note that this requires that CAs have access to the
will define a flag that a CA can add to a certificate indicating that necessary industry databases to ascertain whether, for example, a
this function was performed. [TBD: do we really need that? Should particular telephone number is encompassed by an SPC. Alternatively,
any CA ever not perform this function?] a CA may acquire an Authority Token that affirms that a delegation is
in the proper scope. Exactly what operational practices this entails
may vary in different national telephone administrations, and are
thus left to the CP/CPS.
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
skipping to change at page 8, line 29 skipping to change at page 9, line 8
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.
[TBD: potential interaction with STIR short-term mechanisms, or the
ACME STAR delegation work?]
8.2. Handling Multiple Certificates 8.2. Handling Multiple Certificates
In some deployments, non-carrier entities may receive telephone In some deployments, non-carrier entities may receive telephone
numbers from several different carriers. This could lead to numbers from several different carriers. This could lead to
enterprises needing to maintain a sort of STIR keyring, with enterprises needing to maintain a sort of STIR keyring, with
different certificates delegated to them from different providers, different certificates delegated to them from different providers,
potentially issued by different CAs, which they choose between when potentially issued by different CAs, which they choose between when
signing a call. This could be the case regardless of which syntax is signing a call. This could be the case regardless of which syntax is
used in the TNAuthList to represent the scope of the delegation (see used in the TNAuthList to represent the scope of the delegation (see
skipping to change at page 9, line 9 skipping to change at page 9, line 35
Authority Issuer, so that a signer would only need to sign with a Authority Issuer, so that a signer would only need to sign with a
single certificate to inherit the privileges of the other single certificate to inherit the privileges of the other
certificate(s) it has cross-certified with. In very complex certificate(s) it has cross-certified with. In very complex
delegation cases, it might make more sense to establish a bridge CA delegation cases, it might make more sense to establish a bridge CA
that cross-certifies with all of the certificates held by the that cross-certifies with all of the certificates held by the
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. IANA Considerations 9. Alternative Solutions
At the time this specification was written, STIR was only starting to
see deployment. In some future environments, the policies that
govern CAs may not permit them to issue intermediate certificates
with a TNAuthList object. Similar problems in the web PKI space
motivated the development of TLS subcerts [I-D.ietf-tls-subcerts],
which substitutes a signed "delegated credential" token for a
certificate for such environments. A similar mechanism could be
developed for the STIR space, allowing STIR certificates to sign a
data object which contains effectively the same data as the delegate
certificate specified here, including a public key that could sign
PASSporTs. The TLS subcerts system has furthermore developed ways
for the issuer of a delegated credential to revoke it, as well as
exploring the potential interaction with ACME to issue short-lived
certificates for temporary delegation. Specification of a TLS
subcerts analog for STIR is deferred here to future work, at such a
time as market players require it.
10. IANA Considerations
This document contains no actions for the IANA. This document contains no actions for the IANA.
10. 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
calling party number that is openly signaled during call setup, the calling party number that is openly signaled during call setup, the
privacy risks associated with this mechanism are not substantially privacy risks associated with this mechanism are not substantially
greater than baseline STIR. See [RFC8224] for guidance on the use of greater than baseline STIR. See [RFC8224] for guidance on the use of
anonymization mechanisms in STIR. anonymization mechanisms in STIR.
11. 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. Also see the Security Considerations of Security Considerations. Also see the Security Considerations of
[RFC8226] for general guidance on the implications of the use of [RFC8226] for general guidance on the implications of the use of
certificates in STIR. certificates in STIR.
12. Acknowledgments 13. Acknowledgments
We would like to thank Richard Barnes, Chris Wendt, Dave Hancock, We would like to thank Richard Barnes, Chris Wendt, Dave Hancock,
Russ Housley, and Sean Turner for key input to the discussions Russ Housley, and Sean Turner for key input to the discussions
leading to this document. leading to this document.
13. References 14. References
13.1. Normative References
[I-D.ietf-acme-authority-token]
Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME
Challenges Using an Authority Token", draft-ietf-acme-
authority-token-03 (work in progress), March 2019.
[I-D.ietf-acme-authority-token-tnauthlist]
Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList profile of ACME Authority Token", draft-ietf-
acme-authority-token-tnauthlist-03 (work in progress),
March 2019.
[I-D.ietf-acme-star] 14.1. Normative References
Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
Fossati, "Support for Short-Term, Automatically-Renewed
(STAR) Certificates in Automated Certificate Management
Environment (ACME)", draft-ietf-acme-star-06 (work in
progress), July 2019.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, June 2002, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>. <https://www.rfc-editor.org/info/rfc3261>.
[RFC7044] Barnes, M., Audet, F., Schubert, S., van Elburg, J., and
C. Holmberg, "An Extension to the Session Initiation
Protocol (SIP) for Request History Information", RFC 7044,
DOI 10.17487/RFC7044, February 2014,
<https://www.rfc-editor.org/info/rfc7044>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session "Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224, Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018, DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>. <https://www.rfc-editor.org/info/rfc8224>.
skipping to change at page 11, line 10 skipping to change at page 11, line 25
[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226, Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018, DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>. <https://www.rfc-editor.org/info/rfc8226>.
[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>.
13.2. Informative References 14.2. Informative References
[ATIS-0300251] [I-D.ietf-acme-authority-token]
ATIS Recommendation 0300251, "Codes for Identification of Peterson, J., Barnes, M., Hancock, D., and C. Wendt, "ACME
Service Providers for Information Exchange", 2007. Challenges Using an Authority Token", draft-ietf-acme-
authority-token-03 (work in progress), March 2019.
[DSS] National Institute of Standards and Technology, U.S. [I-D.ietf-acme-authority-token-tnauthlist]
Department of Commerce | NIST FIPS PUB 186-4, "Digital Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
Signature Standard, version 4", 2013. "TNAuthList profile of ACME Authority Token", draft-ietf-
acme-authority-token-tnauthlist-04 (work in progress),
September 2019.
[I-D.ietf-acme-star]
Sheffer, Y., Lopez, D., Dios, O., Pastor, A., and T.
Fossati, "Support for Short-Term, Automatically-Renewed
(STAR) Certificates in Automated Certificate Management
Environment (ACME)", draft-ietf-acme-star-11 (work in
progress), October 2019.
[I-D.ietf-tls-subcerts]
Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla,
"Delegated Credentials for TLS", draft-ietf-tls-
subcerts-04 (work in progress), July 2019.
[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>.
[RFC5806] Levy, S. and M. Mohali, Ed., "Diversion Indication in
SIP", RFC 5806, DOI 10.17487/RFC5806, March 2010,
<https://www.rfc-editor.org/info/rfc5806>.
[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>.
[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,
<https://www.rfc-editor.org/info/rfc7340>. <https://www.rfc-editor.org/info/rfc7340>.
[X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8, [X.509] ITU-T Recommendation X.509 (10/2012) | ISO/IEC 9594-8,
 End of changes. 22 change blocks. 
73 lines changed or deleted 97 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/