rfc9447v2.txt | rfc9447.txt | |||
---|---|---|---|---|
Internet Engineering Task Force (IETF) J. Peterson | Internet Engineering Task Force (IETF) J. Peterson | |||
Request for Comments: 9447 M. Barnes | Request for Comments: 9447 M. Barnes | |||
Category: Standards Track Neustar | Category: Standards Track Neustar | |||
ISSN: 2070-1721 D. Hancock | ISSN: 2070-1721 D. Hancock | |||
Comcast | ||||
C. Wendt | C. Wendt | |||
Somos | Somos | |||
August 2023 | September 2023 | |||
Automated Certificate Management Environment (ACME) Challenges Using an | Automated Certificate Management Environment (ACME) Challenges Using an | |||
Authority Token | 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 | |||
skipping to change at line 307 ¶ | skipping to change at line 306 ¶ | |||
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 and | The "tkvalue" indicates the scope of the authority that the token and | |||
its semantics are outside the scope of this document, as they will be | its semantics are outside the scope of this document, as they will be | |||
specified by the "tkvalue" identifier in a separate specification. | specified by the "tkvalue" identifier in a separate specification. | |||
Following the example of [RFC9448], the “tktype” identifier type | Following the example of [RFC9448], the "tktype" identifier type | |||
could be the TNAuthList (as defined in [RFC8226]), which would be the | could be the TNAuthList (as defined in [RFC8226]), which would be the | |||
value for the “tkvalue” element 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" | |||
}), | }), | |||
skipping to change at line 433 ¶ | skipping to change at line 432 ¶ | |||
6.2. JSON Web Token Claim Registration | 6.2. JSON Web Token Claim Registration | |||
IANA has added a new claim in the "JSON Web Token Claims" registry, | IANA has added a new claim in the "JSON Web Token Claims" registry, | |||
as defined in [RFC7519], as follows: | as defined in [RFC7519], as follows: | |||
Claim name: atc | Claim name: atc | |||
Claim Description: Authority Token Challenge | Claim Description: Authority Token Challenge | |||
Change Controller: IESG | Change Controller: IETF | |||
Specification document(s): RFC 9447 | Specification document(s): RFC 9447 | |||
6.3. Creation of ACME Authority Token Challenge Types Registry | 6.3. Creation of ACME Authority Token Challenge Types Registry | |||
IANA has created a new registry for "ACME Authority Token Challenge | IANA has created a new registry for "ACME Authority Token Challenge | |||
Types" as used in these challenges, under a policy of Specification | Types" as used in these challenges, under a policy of Specification | |||
Required and following the requirements in Section 3.1, with three | Required and following the requirements in Section 3.1, with three | |||
columns: Label, Description, and Reference. The initial content of | columns: Label, Description, and Reference. The initial content of | |||
the registry is as follows: | the registry is as follows: | |||
skipping to change at line 539 ¶ | skipping to change at line 538 ¶ | |||
<https://www.rfc-editor.org/info/rfc8725>. | <https://www.rfc-editor.org/info/rfc8725>. | |||
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | |||
Ed., "HTTP Semantics", STD 97, RFC 9110, | Ed., "HTTP Semantics", STD 97, RFC 9110, | |||
DOI 10.17487/RFC9110, June 2022, | DOI 10.17487/RFC9110, June 2022, | |||
<https://www.rfc-editor.org/info/rfc9110>. | <https://www.rfc-editor.org/info/rfc9110>. | |||
[RFC9448] Wendt, C., Hancock, D., Barnes, M., and J. Peterson, | [RFC9448] Wendt, C., Hancock, D., Barnes, M., and J. Peterson, | |||
"TNAuthList Profile of Automated Certificate Management | "TNAuthList Profile of Automated Certificate Management | |||
Environment (ACME) Authority Token", RFC 9448, | Environment (ACME) Authority Token", RFC 9448, | |||
DOI 10.17487/RFC9448, July 2023, | DOI 10.17487/RFC9448, September 2023, | |||
<https://www.rfc-editor.org/info/rfc9448>. | <https://www.rfc-editor.org/info/rfc9448>. | |||
8.2. Informative References | 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, | |||
skipping to change at line 577 ¶ | skipping to change at line 576 ¶ | |||
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. 7 change blocks. | ||||
7 lines changed or deleted | 6 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. |