rfc9447.original   rfc9447.txt 
Network Working Group J. Peterson Internet Engineering Task Force (IETF) J. Peterson
Internet-Draft M. Barnes Request for Comments: 9447 M. Barnes
Intended status: Standards Track Neustar Category: Standards Track Neustar
Expires: 27 April 2023 D. Hancock ISSN: 2070-1721 D. Hancock
Comcast
C. Wendt C. Wendt
Somos Somos
24 October 2022 September 2023
ACME Challenges Using an Authority Token Automated Certificate Management Environment (ACME) Challenges Using an
draft-ietf-acme-authority-token-09 Authority Token
Abstract Abstract
Some proposed extensions to the Automated Certificate Management Some proposed extensions to the Automated Certificate Management
Environment (ACME) rely on proving eligibility for certificates Environment (ACME) rely on proving eligibility for certificates
through consulting an external authority that issues a token through consulting an external authority that issues a token
according to a particular policy. This document specifies a generic according to a particular policy. This document specifies a generic
Authority Token challenge for ACME which supports subtype claims for Authority Token Challenge for ACME that supports subtype claims for
different identifiers or namespaces that can be defined separately different identifiers or namespaces that can be defined separately
for specific applications. for specific applications.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 27 April 2023. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9447.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2023 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
Please review these documents carefully, as they describe your rights carefully, as they describe your rights and restrictions with respect
and restrictions with respect to this document. Code Components to this document. Code Components extracted from this document must
extracted from this document must include Revised BSD License text as include Revised BSD License text as described in Section 4.e of the
described in Section 4.e of the Trust Legal Provisions and are Trust Legal Provisions and are provided without warranty as described
provided without warranty as described in the Revised BSD License. in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language
3. ACME Authority Token Challenge . . . . . . . . . . . . . . . 3 3. ACME Authority Token Challenge
3.1. Token Type Requirements . . . . . . . . . . . . . . . . . 4 3.1. Token Type Requirements
3.2. Authority Token Scope . . . . . . . . . . . . . . . . . . 5 3.2. Authority Token Scope
3.3. Binding Challenges . . . . . . . . . . . . . . . . . . . 6 3.3. Binding Challenges
4. Authority Token Challenge tkauth-type Registration . . . . . 6 4. Authority Token Challenge tkauth-type Registration
5. Acquiring a Token . . . . . . . . . . . . . . . . . . . . . . 8 5. Acquiring a Token
5.1. Basic REST Interface . . . . . . . . . . . . . . . . . . 9 5.1. Basic REST Interface
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6.1. ACME Validation Method Registration
7.1. ACME Validation Method Registration . . . . . . . . . . . 10 6.2. JSON Web Token Claim Registration
7.2. JSON Web Token Claim Registration . . . . . . . . . . . . 10 6.3. Creation of ACME Authority Token Challenge Types Registry
7.3. Creation of ACME Authority Token Challenge Type 7. Security Considerations
Registry . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 Acknowledgements
9.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
ACME [RFC8555] is a mechanism for automating certificate management ACME [RFC8555] is a mechanism for automating certificate management
on the Internet. It enables administrative entities to prove on the Internet. It enables administrative entities to prove
effective control over resources like domain names, and automates the effective control over resources, like domain names, and automates
process of issuing certificates that attest control or ownership of the process of issuing certificates that attest control or ownership
those resources. of those resources.
In some cases, proving effective control over an identifier requires In some cases, proving effective control over an identifier requires
an attestation from a third party who has authority over the an attestation from a third party who has authority over the
resource, for example, an external policy administrator for a resource, for example, an external policy administrator for a
namespace other than the DNS application ACME was originally designed namespace other than the DNS application ACME was originally designed
to support. In order to automate the process of issuing certificates to support. In order to automate the process of issuing certificates
for those resources, this specification defines a generic Authority for those resources, this specification defines a generic Authority
Token challenge that ACME servers can issue in order to require Token Challenge that ACME servers can issue in order to require
clients to return an Authority Token that authorizes a given clients to return an Authority Token that authorizes a given
issuance. The challenge contains a type indication that tells the issuance. The challenge contains a type indication that tells the
client what sort of token it needs to acquire. It is expected that client what sort of token it needs to acquire. It is expected that
the Authority Token challenge will be usable for a variety of the Authority Token Challenge will be usable for a variety of
identifier types. In particular, this document describes an identifier types. In particular, this document describes an
architecture for Authority Tokens, defines a JSON Web Token (JWT, architecture for Authority Tokens, defines a JSON Web Token (JWT)
[RFC7519]) Authority Token format along with a protocol for token [RFC7519] Authority Token format along with a protocol for token
acquisition, and shows how to integrate these tokens into an ACME acquisition, and shows how to integrate these tokens into an ACME
challenge. challenge.
As a concrete example, [I-D.ietf-acme-authority-token-tnauthlist] As a concrete example, [RFC9448] provides a mechanism that allows
provides a mechanism that allows service providers to acquire service providers to acquire certificates corresponding to a Service
certificates corresponding to a Service Provider Code (SPC) as Provider Code (SPC) as defined in [RFC8226] by consulting an external
defined in [RFC8226] by consulting an external authority responsible authority responsible for those codes. Furthermore, Communications
for those codes. Furthermore, Communications Service Providers Service Providers (CSPs) can delegate authority over numbers to their
(CSPs) can delegate authority over numbers to their customers, and customers, and those CSPs who support ACME can then help customers to
those CSPs who support ACME can then help customers to acquire acquire certificates for those numbering resources with ACME. This
certificates for those numbering resources with ACME. This can can permit number acquisition flows compatible with those shown in
permit number acquisition flows compatible with those shown in
[RFC8396]. [RFC8396].
2. Terminology 2. Requirements Language
The 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
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. ACME Authority Token Challenge 3. ACME Authority Token Challenge
Proving that a device on the Internet has effective control over a Proving that a device on the Internet has effective control over a
non-Internet resource is not as straightforward as proving control non-Internet resource is not as straightforward as proving control
over an Internet resources like a DNS zone or a web page. Provided over Internet resources, like a DNS zone or a web page. Provided
that the issuer of identifiers in a namespace, or someone acting on that the issuer of identifiers in a namespace, or someone acting on
the issuer's behalf, can implement a service that grants Authority the issuer's behalf, can implement a service that grants Authority
Tokens to the people to whom it has issued identifiers, a generic Tokens to the people to whom it has issued identifiers, a generic
token could be used as a response to an ACME challenge. This token could be used as a response to an ACME challenge. This
specification, therefore, defines an Authority Token issued by an specification, therefore, defines an Authority Token issued by an
authority over a namespace to an ACME client for delivery to an ACME authority over a namespace to an ACME client for delivery to an ACME
server in response to a challenge. Authority over a hierarchical server in response to a challenge. Authority over a hierarchical
namespace can also be delegated, so that delegates of a root namespace can also be delegated so that delegates of a root authority
authority can themselves act as Token Authorities for certain types can themselves act as Token Authorities for certain types of names.
of names.
This architecture assumes a trust relationship between CAs and Token This architecture assumes a trust relationship between certification
Authorities: that CAs are willing to accept the attestation of Token authorities (CAs) and Token Authorities, i.e., that CAs are willing
Authorities for particular types of identifiers as sufficient proof to accept the attestation of Token Authorities for particular types
to issue a credential. It furthermore assumes that ACME clients have of identifiers as sufficient proof to issue a credential. It
a relationship with Token Authorities which permits them to furthermore assumes that ACME clients have a relationship with Token
authenticate and authorize the issuance of Authority Tokens to the Authorities, which permits them to authenticate and authorize the
proper entities. This ACME challenge has no applicability to issuance of Authority Tokens to the proper entities. This ACME
identifiers or authorities where those pre-associations cannot be challenge has no applicability to identifiers or authorities where
assumed. those pre-associations cannot be assumed.
The ACME Authority Token Challenge type, "tkauth-01", is here The ACME Authority Token Challenge type, "tkauth-01", is here
specified for use with the "TNAuthList" ACME Identifier Type specified for use with the "TNAuthList" (Telephone Number
described in [I-D.ietf-acme-authority-token-tnauthlist]; in order to Authentication List) ACME Identifier Type described in [RFC9448]; in
use "tkauth-01" Validation Method with an ACME Identifier type other order to use the "tkauth-01" Validation Method with an ACME
than "TNAuthList," that identifier type would need to be listed in a Identifier Type other than "TNAuthList", that identifier type would
new registration in the ACME Validation Methods registry maintained need to be listed in a new registration in the ACME Validation
by IANA. "tkauth-01" furthermore supports different token subtypes. Methods registry maintained by IANA. "tkauth-01" furthermore supports
The token subtype is determined by a new ACME challenge field, different token subtypes. The token subtype is determined by a new
tkauth-type. An IANA registry is used to manage the values of ACME challenge field, tkauth-type. An IANA registry is used to
tkauth-type, see Section 7.3. Additionally, this challenge type also manage the values of tkauth-type (see Section 6.3). Additionally,
has a new "token-authority" field to designate a location where a this challenge type also has a new "token-authority" field to
token can be acquired. designate a location where a token can be acquired.
3.1. Token Type Requirements 3.1. Token Type Requirements
The IANA will maintain a registry of tkauth-types under a policy of IANA will maintain a registry of tkauth-types under a policy of
Specification Required. In order to register a new tkauth-type, Specification Required. In order to register a new tkauth-type,
specifications must address the following requirements; in cases specifications must address the following requirements; in cases
where a tkauth-type admits of its own subtypes, subtypes inherit where a tkauth-type admits of its own subtypes, subtypes inherit
these requirements. these requirements.
While Authority Token types do not need to be specific to a While Authority Token types do not need to be specific to a
namespace, every token must carry enough information for a CA to namespace, every token must carry enough information for a CA to
determine the name for which certificate issuance is authorized. determine the name for which certificate issuance is authorized.
Some types of Authority Token types might be reusable for a number of Some types of Authority Token types might be reusable for a number of
different namespaces; others might be specific to a particular type different namespaces; others might be specific to a particular type
skipping to change at page 5, line 22 skipping to change at line 198
authority assignments. Typically, a CA will expect a regular authority assignments. Typically, a CA will expect a regular
refreshing of the token. refreshing of the token.
3.2. Authority Token Scope 3.2. Authority Token Scope
An Authority Token is used to answer a challenge from an ACME server, An Authority Token is used to answer a challenge from an ACME server,
upon a request for the issuance of a certificate. It could be that upon a request for the issuance of a certificate. It could be that
the Authority Token is requested from the Token Authority after a the Authority Token is requested from the Token Authority after a
challenge has been received, or it could be that the Authority Token challenge has been received, or it could be that the Authority Token
was acquired prior to the initial ACME client request. A Token was acquired prior to the initial ACME client request. A Token
Authority could grant to a client an Authority Token that has the Authority could grant an Authority Token that has the exact same
exact same scope as the requested certificate; alternatively, an scope as the requested certificate to a client; alternatively, an
Authority Token could attest to all of the resources that the client Authority Token could attest to all of the resources that the client
is eligible to receive certificates for, which could be a superset of is eligible to receive certificates for, which could be a superset of
the scope of the requested certificate. the scope of the requested certificate.
For example, imagine a case where an Authority for DNS names knows For example, imagine a case where a Token Authority for DNS names
that a client is eligible to receive certificates for "example.com" knows that a client is eligible to receive certificates for
and "example.net". The client asks an ACME server for a certificate "example.com" and "example.net". The client asks an ACME server for
for "example.com", the server directs the client to acquire an a certificate for "example.com", and the server directs the client to
Authority Token from the Token Authority. When the client sends an acquire an Authority Token from the Token Authority. When the client
acquisition request (see Section 5) to the Token Authority, the Token sends an acquisition request (see Section 5) to the Token Authority,
Authority could issue a token scoped just to "example.com", or a the Token Authority could issue a token scoped just to "example.com"
token that attests the client is eligible to receive certificates for or a token that attests the client is eligible to receive
both "example.com" or "example.net". The advantage of the latter is certificates for both "example.com" or "example.net". The advantage
that if, at a later time (but one within the expiry of the token), of the latter is that if, at a later time (but one within the expiry
the client wanted to acquire a certificate for "example.net", it of the token), the client wanted to acquire a certificate for
would not have to return to the Token Authority, as the Token "example.net", it would not have to return to the Token Authority, as
effectively pre-authorized the issuance of that certificate. the Token effectively pre-authorized the issuance of that
certificate.
Applications of the Authority Token to different identifier types Applications of the Authority Token to different identifier types
might require different scopes, so registrations of tkauth-types might require different scopes, so registrations of tkauth-types
should be clear if and how a scope greater than that of the requested should be clear about if and how a scope greater than that of the
certificate would be conveyed in a token. requested certificate would be conveyed in a token.
3.3. Binding Challenges 3.3. Binding Challenges
Applications that use the Authority Token need a way to correlate Applications that use the Authority Token need a way to correlate
tokens issued by a Token Authority with the proper ACME client, to tokens issued by a Token Authority with the proper ACME client to
prevent replay or cut-and-paste attacks using a token issued for a prevent replay or cut-and-paste attacks using a token issued for a
different purpose. To mitigate this, Authority Tokens contain a different purpose. To mitigate this, Authority Tokens contain a
binding signed by a Token Authority; an ACME server can use the binding signed by a Token Authority; an ACME server can use the
binding to determine that a Token presented by a client was in fact binding to determine that a Token presented by a client was in fact
granted by the Token Authority based on a request from the client, granted by the Token Authority based on a request from the client and
and not from some other entity. It is RECOMMENDED that the ACME not from some other entity. It is RECOMMENDED that the ACME account
account fingerprint be used for this purpose. fingerprint be used for this purpose.
Creating a binding from an Authority Token to a particular ACME Creating a binding from an Authority Token to a particular ACME
account entails that the Token could be reused up until its expiry account entails that the Token could be reused up until its expiry
for multiple challenges issued by an ACME server. This might be a for multiple challenges issued by an ACME server. This might be a
desirable property when using short-lived certificates, for example, desirable property when using short-lived certificates, for example,
or in any cases where the ACME server issues challenges more in any cases where the ACME server issues challenges more frequently
frequently that an Authority Token can or should issue tokens, or in that an Authority Token can or should issue tokens or in cases where
cases where the Authority Token scope (see Section 3.2) is broad, so the Authority Token scope (see Section 3.2) is broad, so certificates
certificates with a more narrow scope may periodically be issued. with a more narrow scope may periodically be issued.
For some identifier types, it may be more appropriate to bind the For some identifier types, it may be more appropriate to bind the
Authority Token to a nonce specific to the challenge rather than to Authority Token to a nonce specific to the challenge rather than to
an ACME account fingerprint. Any specification of the use of the an ACME account fingerprint. Any specification of the use of the
nonce or other factors for this purpose is left to the identifier nonce or other factors for this purpose is left to the identifier
type profile for the Authority Token. type profile for the Authority Token.
Note that the fingerprint value in the client's JWT is reflected in Note that the fingerprint value in the client's JWT is reflected in
the Authority Token returned by the Token Authority; the Token the Authority Token returned by the Token Authority; the Token
Authority has no requirement to validate that fingerprint. Were a Authority has no requirement to validate that fingerprint. Were a
fingerprint to be captured by an attacker which had its own account fingerprint to be captured by an attacker that had its own account
with the Token Authority, it could replay that fingerprint in its own with the Token Authority, it could replay that fingerprint in its own
JWT in order to receive an Authority Token with that fingerprint. JWT in order to receive an Authority Token with that fingerprint.
However, were the attacker to present that Authority Token to an ACME However, were the attacker to present that Authority Token to an ACME
service, the service would see the fingerprint does not match the service, the service would see the fingerprint does not match the
attacker's ACME account fingerprint. So unless an attacker can attacker's ACME account fingerprint. So unless an attacker can
compromise a target ACME account or gain similar privileges, the compromise a target ACME account or gain similar privileges, the
binding would be secure. binding would be secure.
4. Authority Token Challenge tkauth-type Registration 4. Authority Token Challenge tkauth-type Registration
This draft specifies a tkauth-type of "atc" which contains a standard This document specifies a tkauth-type of "atc", which contains a
JWT [RFC7519] using a JWS-defined signature string [RFC7515]. The standard JWT [RFC7519] using a signature string defined by a JSON Web
"atc" tkauth-type MAY be used for any number of different ACME Signature (JWS) [RFC7515]. The "atc" tkauth-type MAY be used for any
identifier types in the ACME challenge. number of different ACME Identifier Types in the ACME challenge.
A new JWT claim, "atc", is defined below and lists the identifier A new JWT claim, "atc", is defined below and lists the identifier
type used in this Authority Token. The "atc" tkauth-type is type used in this Authority Token. The "atc" tkauth-type is
restricted to the JWTs; if a non-JWT format is desired for the ACME restricted to the JWTs; if a non-JWT format is desired for the ACME
Authority Token Challenge, a different tkauth-type should be Authority Token Challenge, a different tkauth-type should be
specified and registered in the "ACME Authority Token Challenge specified and registered in the "ACME Authority Token Challenge
Types" registry defined in Section 8. Types" registry defined in Section 6.3.
For this ACME Authority Token usage of JWT, the payload of the JWT For this ACME Authority Token usage of a JWT, it is OPTIONAL for the
OPTIONALLY contain an "iss" indicating the Token Authority that payload of the JWT to contain an "iss", indicating the Token
generated the token, if the "x5u" or "x5c" element in the header does Authority that generated the token if the "x5u" or "x5c" element in
not already convey that information; typically, this will be the same the header does not already convey that information; typically, this
location that appeared in the "token-authority" field of the ACME will be the same location that appeared in the "token-authority"
challenge, when present. In order to satisfy the requirement for field of the ACME challenge, when present. In order to satisfy the
replay prevention the JWT MUST contain a "jti" element, and an "exp" requirement for replay prevention, the JWT MUST contain a "jti"
claim; the "exp" claim manages token freshness. In addition to element and an "exp" claim; the "exp" claim manages token freshness.
helping to manage replay, the "jti" provides a convenient way to In addition to helping to manage replay, the "jti" provides a
reliably track when the same "atc" Authority Token is being used for convenient way to reliably track when the same "atc" Authority Token
multiple challenges over time within its set lifetime. is being used for multiple challenges over time within its set
lifetime.
The JWT payload MUST also contain a new JWT claim, "atc", for The JWT payload MUST also contain a new JWT claim, "atc", for
Authority Token Challenge, which contains three mandatory elements in Authority Token Challenge, which contains three mandatory elements in
a JSON map: the ATC identifier type ("tktype"), the identifier value a JSON map: the ATC identifier type ("tktype"), the identifier value
("tkvalue"), and the binding ("fingerprint"). The use of "tktype" is ("tkvalue"), and the binding ("fingerprint"). The use of "tktype" is
restricted to the values in the "ACME Identifier Types" registry as restricted to the values in the "ACME Identifier Types" registry, as
defined by [RFC8555]. The identifier type and value are those given defined by [RFC8555]. The identifier type and value are those given
in the ACME challenge and conveyed to the Token Authority by the ACME in the ACME challenge and conveyed to the Token Authority by the ACME
client. For the purposes of the "atc" tkauth-type, the binding client. For the purposes of the "atc" tkauth-type, the binding
"fingerprint" is assumed to be a fingerprint of the ACME credential "fingerprint" is assumed to be a fingerprint of the ACME credential
for the account used to request the certificate, but the for the account used to request the certificate, but the
specification of how the binding is generated is left to the specification of how the binding is generated is left to the
identifier type profile for the Authority Token (see Section 3.3). identifier type profile for the Authority Token (see Section 3.3).
The "tkvalue" indicates the scope of the authority that the token, The "tkvalue" indicates the scope of the authority that the token and
and its semantics are outside the scope of this document, as they its semantics are outside the scope of this document, as they will be
will be specified by the "tkvalue" identifier in a separate specified by the "tkvalue" identifier in a separate specification.
specification.
Following the example of [I-D.ietf-acme-authority-token-tnauthlist], Following the example of [RFC9448], the "tktype" identifier type
the "tktype" identifier type could be the TNAuthList, with a could be the TNAuthList (as defined in [RFC8226]), which would be the
"tkvalue" as defined in [RFC8226] that the Token Authority is value for the "tkvalue" element that the Token Authority is
attesting. Practically speaking, that scope may comprise a list of attesting. Practically speaking, that scope may comprise a list of
Service Provider Code elements, telephone number range elements, and/ Service Provider Code elements, telephone number range elements, and/
or individual telephone numbers. So for example: or individual telephone numbers. So for example:
{ {
"protected": base64url({ "protected": base64url({
"typ":"JWT", "typ":"JWT",
"alg":"ES256", "alg":"ES256",
"x5u":"https://authority.example.org/cert" "x5u":"https://authority.example.org/cert"
}), }),
"payload": base64url({ "payload": base64url({
"iss":"https://authority.example.org/authz", "iss":"https://authority.example.org/authz",
"exp":1300819380, "exp":1300819380,
"jti":"id6098364921", "jti":"id6098364921",
"atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","fingerprint": "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==",
"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50: "fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:
9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"}
}), }),
"signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ"
} }
Optionally, the "atc" claim may contain a fourth boolean element, Optionally, the "atc" claim may contain a fourth boolean element,
"ca". If set to "true", the "ca" element indicates that the Token "ca". If set to "true", the "ca" element indicates that the Token
Authority is granting permission to issue a certification authority Authority is granting permission to issue a certification authority
certificate rather than an end-entity certificate for the names in certificate rather than an end-entity certificate for the names in
question. This permits subordinate delegations from the issued question. This permits subordinate delegations from the issued
certificate (using [RFC9115] or similar mechanisms). If the "ca" certificate (using [RFC9115] or similar mechanisms). If the "ca"
element is absent, the Token Authority is explicitly withholding element is absent, the Token Authority is explicitly withholding
permission. The "atc" object in the example above would then look permission. The "atc" object in the example above would then look
like: like:
"atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==","ca":true, "atc":{"tktype":"TnAuthList","tkvalue":"F83n2a...avn27DN3==",
"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:71:D3:BA:B9:19:81:F8:50: "ca":true,"fingerprint":"SHA256 56:3E:CF:AE:83:CA:4D:15:B0:29:FF:1B:
9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} } 71:D3:BA:B9:19:81:F8:50:9B:DF:4A:D4:39:72:E2:B1:F0:B9:38:E3"} }
Specifications of "tktype" identifier types may define additional Specifications of "tktype" identifier types may define additional
optional "atc" elements. optional "atc" elements.
5. Acquiring a Token 5. Acquiring a Token
The acquisition of an Authority Token requires a network interface, The acquisition of an Authority Token requires a network interface,
apart from potential use cases where the entity that acts as an ACME apart from potential use cases where the entity that acts as an ACME
client itself also acts as a Token Authority trusted by the ACME client itself also acts as a Token Authority trusted by the ACME
server. Implementations compliant with this specification MUST server. Implementations compliant with this specification MUST
support an HTTPS interface for Authority Token acquisition as support an HTTPS interface for Authority Token acquisition as
described below, though other interfaces MAY be supported as well. described below, though other interfaces MAY be supported as well.
5.1. Basic REST Interface 5.1. Basic REST Interface
In order to request an Authority Token from a Token Authority, a In order to request an Authority Token from a Token Authority, a
client sends a HTTPS POST request [RFC7231] . This specification client sends a HTTPS POST request [RFC9110]. This specification
assumes that Token Authority URIs are known to clients through assumes that Token Authority URIs are known to clients through
preexisting business relationships, and that the credentials and preexisting business relationships and that the credentials and
related authentication and authorization for Authority Token related authentication and authorization for Authority Token
acquisition are encompassed in that relationship. Different services acquisition are encompassed in that relationship. Different services
may organize their web resources in domain-specific ways, but the may organize their web resources in domain-specific ways, but the
resource locator should specify the account of the client, an resource locator should specify the account of the client, an
identifier for the service provider, and finally a locator for the identifier for the service provider, and finally a locator for the
token. token.
POST /at/account/:id/token HTTP/1.1 POST /at/account/:id/token HTTP/1.1
Host: authority.example.com Host: authority.example.com
Content-Type: application/json Content-Type: application/json
skipping to change at page 9, line 35 skipping to change at line 386
the client is requesting the Token Authority generate. In this way, the client is requesting the Token Authority generate. In this way,
the client proposes the scope of the Authority Token it would like to the client proposes the scope of the Authority Token it would like to
receive from the Token Authority. receive from the Token Authority.
In common use cases, the "tkvalue" in this request is asking that the In common use cases, the "tkvalue" in this request is asking that the
Token Authority issue a token that attests the entire scope of Token Authority issue a token that attests the entire scope of
authority to which the client is entitled. The client may also authority to which the client is entitled. The client may also
request an Authority Token with some subset of its own authority via request an Authority Token with some subset of its own authority via
the "tkvalue" element in the Authority Token Challenge object. The the "tkvalue" element in the Authority Token Challenge object. The
way that "tkvalue" is defined will necessarily be specific to the way that "tkvalue" is defined will necessarily be specific to the
identifier type. For the TNAuthlist identifier type, for example, an identifier type. For the TNAuthList identifier type, for example, an
object requesting an Authority Token could request authority for only object requesting an Authority Token could request authority for only
a single telephone number in a way that is defined in the TNAuthList a single telephone number in a way that is defined in the TNAuthList
specification. specification.
Finally, the JSON object MAY also contain an optional boolean element Finally, the JSON object MAY also contain an optional boolean
"ca" which signifies that the client is requesting that the Token element, "ca", which signifies that the client is requesting that the
Authority issue an Authority Token with the "ca" flag set, as Token Authority issue an Authority Token with the "ca" flag set, as
described in Section 4. described in Section 4.
After an HTTPS-level challenge (e.g. a 401 HTTP response code) to After an HTTPS-level challenge (e.g., a 401 HTTP response code) to
verify the identity of the client and subsequently making an verify the identity of the client and subsequently making an
authorization decision about whether the client should receive an authorization decision about whether the client should receive an
Authority Token with the requested scope, then in the success case, Authority Token with the requested scope, then in the success case,
the Token Authority MUST return a 200 OK with a body of type the Token Authority MUST return a 200 OK with a body of type
"application/json" containing the Authority Token. "application/json" containing the Authority Token.
A full example of "atc" token acquisition using the HTTP interface, A full example of "atc" token acquisition using the HTTP interface,
with the "tktype" of "TNAuthList", is given in with the "tktype" of "TNAuthList", is given in Section 5.5 of
[I-D.ietf-acme-authority-token-tnauthlist] Section 5.5. [RFC9448].
6. Acknowledgements 6. IANA Considerations
We would like to Roman Danyliw and Ben Kaduk for contributions to 6.1. ACME Validation Method Registration
this problem statement and framework.
7. IANA Considerations IANA has added a new ACME Validation Method (per [RFC8555]) in the
"ACME Validation Methods" subregistry of the "Automated Certificate
Management Environment (ACME) Protocol" registry group as follows:
7.1. ACME Validation Method Registration Label: tkauth-01
This document requests that IANA populate a new ACME Validation Identifier Type: TNAuthList
Method (again per [RFC8555]) in the ACME Validation Methods sub-
registry of the Automated Certificate Management Environment (ACME)
Protocol registry group for the label "tkauth-01", identifier type
"TNAuthList", an ACME value of "Y", and a reference pointing to
[RFCThis].
Note to the RFC Editor: Please replace [RFCThis] throughout this ACME: Y
document with the RFC number assigned to this specification.
7.2. JSON Web Token Claim Registration Reference: RFC 9447
This document asks IANA to populate a new claim in the "JSON Web 6.2. JSON Web Token Claim Registration
Token Claims" registry as defined in [RFC7519] as follows:
Claim name: atc IANA has added a new claim in the "JSON Web Token Claims" registry,
as defined in [RFC7519], as follows:
Claim Description: Authority Token Challenge Claim name: atc
Change Controller: IESG Claim Description: Authority Token Challenge
Specification document(s): [RFCThis] Change Controller: IETF
7.3. Creation of ACME Authority Token Challenge Type Registry Specification document(s): RFC 9447
This document requests that the IANA create a new registry for "ACME 6.3. Creation of ACME Authority Token Challenge Types Registry
Authority Token Challenge Types" as used in these challenges, under a
policy of Specification Required and following the requirements in
Section 3.1, with three columns: Label, Reference and Description.
The registry should be pre-populated with a Label of "atc" per
Section 4 with a Reference value of [RFCThis], and a Description of
"JSON Web Token (JWT) challenge type."
8. Security Considerations IANA has created a new registry for "ACME Authority Token Challenge
Types" as used in these challenges, under a policy of Specification
Required and following the requirements in Section 3.1, with three
columns: Label, Description, and Reference. The initial content of
the registry is as follows:
Label: atc (as defined in Section 4)
Description: JSON Web Token (JWT) challenge type
Reference: RFC 9447
7. Security Considerations
Per the guidance in [RFC8555], ACME transactions MUST use TLS, and Per the guidance in [RFC8555], ACME transactions MUST use TLS, and
similarly the HTTPS REST transactions used to request and acquire similarly, the HTTPS REST transactions used to request and acquire
Authority Tokens MUST use TLS. These measures are intended to Authority Tokens MUST use TLS. These measures are intended to
prevent the capture of Authority Tokens by eavesdroppers. A prevent the capture of Authority Tokens by eavesdroppers. A
preexisting trust relationship between the HTTPS REST client and the preexisting trust relationship between the HTTPS REST client and the
Token Authority must also exist in order for the parties to Token Authority must also exist in order for the parties to
meaningfully authenticate one another. The security considerations meaningfully authenticate one another. The security considerations
of [RFC8555] apply to the use of the mechanism in this specification. of [RFC8555] apply to the use of the mechanism in this specification.
Implementations should follow the best practices identified in Implementations should follow the best practices identified in
[RFC8725]. [RFC8725].
As described in Section 3.2, an Authority Token can either have a As described in Section 3.2, an Authority Token can either have a
scope that attests all of the resources which a client is eligible to scope that attests all of the resources that a client is eligible to
receive certificates for, or potentially a more limited scope that is receive certificates for or potentially a more limited scope that is
intended to capture only those resources for which a client will intended to capture only those resources for which a client will
receive a certificate from a particular certification authority. Any receive a certificate from a particular certification authority. Any
certification authority that sees an Authority Token can learn certification authority that sees an Authority Token can learn
information about the resources a client can claim. In cases where information about the resources a client can claim. In cases where
this incurs a privacy risk, Authority Token scopes should be limited this incurs a privacy risk, Authority Token scopes should be limited
to only the resources that will be attested by the requested ACME to only the resources that will be attested by the requested ACME
certificate. certificate.
In cases where a tkauth-type as defined in Section 4 admits of its In cases where a tkauth-type, as defined in Section 4, admits of its
own subtypes, the security of features like binding challenges (see own subtypes, the security of features like binding challenges (see
Section 3.3) will depend on the subtype specification. Section 3.3) will depend on the subtype specification.
The capture of Authority Tokens by an adversary could enable an The capture of Authority Tokens by an adversary could enable an
attacker to acquire a certificate from a CA. Therefore, all attacker to acquire a certificate from a CA. Therefore, all
Authority Tokens MUST contain a field that identifies to the CA which Authority Tokens MUST contain a field that identifies to the CA which
ACME client requested the token from the Token Authority; here that ACME client requested the token from the Token Authority; here, that
is the fingerprint specified in Section 4). All Authority Tokens is the fingerprint specified in Section 4. All Authority Tokens must
must specify an expiry (of the token itself as proof for a CA, as specify an expiry (of the token itself as proof for a CA, as opposed
opposed to the expiry of the name), and for some application, it may to the expiry of the name), and for some applications, it may make
make sense of that expiry to be quite short. ACME services relying sense for that expiry to be quite short. ACME services relying on
on Authority Tokens SHOULD not issue certificates with a longer Authority Tokens SHOULD NOT issue certificates with a longer expiry
expiry than the expiry of the Authority Token. Any protocol used to than the expiry of the Authority Token. Any protocol used to
retrieve Authority Tokens from a Token Authority MUST use retrieve Authority Tokens from a Token Authority MUST use
confidentiality to prevetn eavesdroppers from acquiring an Authority confidentiality to prevent eavesdroppers from acquiring an Authority
Token. The details of this protocol are out of the scope of this Token. The details of this protocol are out of the scope of this
specification. specification.
This document only specifies SHA256 for the fingerprint hash. This document only specifies SHA256 for the fingerprint hash.
However, the syntax of the fingerprint object would permit other keys However, the syntax of the fingerprint object would permit other keys
if, due to concerns about algorithmic agility, a more robust if, due to concerns about algorithmic agility, a more robust
algorithm were required at a future time. Future specifications can algorithm were required at a future time. Future specifications can
define new keys for the fingerprint object as needed. define new keys for the fingerprint object as needed.
9. References 8. References
9.1. Normative References
[I-D.ietf-acme-authority-token-tnauthlist] 8.1. Normative References
Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList profile of ACME Authority Token", Work in
Progress, Internet-Draft, draft-ietf-acme-authority-token-
tnauthlist-10, 16 September 2022,
<https://www.ietf.org/archive/id/draft-ietf-acme-
authority-token-tnauthlist-10.txt>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>. 2015, <https://www.rfc-editor.org/info/rfc7515>.
[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>. <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,
skipping to change at page 13, line 10 skipping to change at line 530
[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>.
[RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best [RFC8725] Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
Current Practices", BCP 225, RFC 8725, Current Practices", BCP 225, RFC 8725,
DOI 10.17487/RFC8725, February 2020, DOI 10.17487/RFC8725, February 2020,
<https://www.rfc-editor.org/info/rfc8725>. <https://www.rfc-editor.org/info/rfc8725>.
9.2. Informative References [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
[RFC9448] Wendt, C., Hancock, D., Barnes, M., and J. Peterson,
"TNAuthList Profile of Automated Certificate Management
Environment (ACME) Authority Token", RFC 9448,
DOI 10.17487/RFC9448, September 2023,
<https://www.rfc-editor.org/info/rfc9448>.
8.2. Informative References
[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>.
[RFC8396] Peterson, J. and T. McGarry, "Managing, Ordering, [RFC8396] Peterson, J. and T. McGarry, "Managing, Ordering,
Distributing, Exposing, and Registering Telephone Numbers Distributing, Exposing, and Registering Telephone Numbers
(MODERN): Problem Statement, Use Cases, and Framework", (MODERN): Problem Statement, Use Cases, and Framework",
RFC 8396, DOI 10.17487/RFC8396, July 2018, RFC 8396, DOI 10.17487/RFC8396, July 2018,
<https://www.rfc-editor.org/info/rfc8396>. <https://www.rfc-editor.org/info/rfc8396>.
[RFC9115] Sheffer, Y., López, D., Pastor Perales, A., and T. [RFC9115] Sheffer, Y., López, D., Pastor Perales, A., and T.
Fossati, "An Automatic Certificate Management Environment Fossati, "An Automatic Certificate Management Environment
(ACME) Profile for Generating Delegated Certificates", (ACME) Profile for Generating Delegated Certificates",
RFC 9115, DOI 10.17487/RFC9115, September 2021, RFC 9115, DOI 10.17487/RFC9115, September 2021,
<https://www.rfc-editor.org/info/rfc9115>. <https://www.rfc-editor.org/info/rfc9115>.
Acknowledgements
We would like to Roman Danyliw and Ben Kaduk for contributions to
this problem statement and framework.
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
Neustar, Inc. Neustar, Inc.
Email: jon.peterson@team.neustar Email: jon.peterson@team.neustar
Mary Barnes Mary Barnes
Neustar, Inc. Neustar, Inc.
Email: mary.ietf.barnes@gmail.com Email: mary.ietf.barnes@gmail.com
David Hancock David Hancock
Comcast Somos
Email: davidhancock.ietf@gmail.com Email: davidhancock.ietf@gmail.com
Chris Wendt Chris Wendt
Somos Somos
Email: chris-ietf@chriswendt.net Email: chris-ietf@chriswendt.net
 End of changes. 69 change blocks. 
226 lines changed or deleted 215 lines changed or added

This html diff was produced by rfcdiff 1.48.