| 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. | ||||