Remove DNS-02 and Scopes #48
Conversation
|
|
||
| This limitation becomes particularly problematic in modern deployment architectures. In multi-region deployments, separate availability zones serve the same content while avoiding cross-zone dependencies. These zones need to independently obtain and manage certificates for the same domain name. Similarly, during zero-downtime migrations, two different infrastructure setups may coexist for extended periods, with both requiring access to valid certificates. | ||
|
|
||
| This document specifies a new challenge type: `dns-account-01`, which addresses these operational needs. The `dns-account-01` challenge incorporates the ACME account URL into the DNS validation record name, allowing multiple independent ACME clients to perform domain validation concurrently. Since these authorization labels depend on the ACME account KID ({{!RFC8555, Section 7.3}}), operators can generate and configure the necessary DNS records in advance. |
There was a problem hiding this comment.
| This document specifies a new challenge type: `dns-account-01`, which addresses these operational needs. The `dns-account-01` challenge incorporates the ACME account URL into the DNS validation record name, allowing multiple independent ACME clients to perform domain validation concurrently. Since these authorization labels depend on the ACME account KID ({{!RFC8555, Section 7.3}}), operators can generate and configure the necessary DNS records in advance. | |
| This document specifies a new challenge type: `dns-account-01`, which addresses these operational needs. The `dns-account-01` challenge incorporates the ACME account URL into the DNS validation record name, allowing multiple independent ACME clients to perform domain validation concurrently. Since these authorization labels depend on the ACME account KID ({{!RFC8555, Section 6.2}}), operators can generate and configure the necessary DNS records in advance. |
There was a problem hiding this comment.
nit: I think Section 6.2 is more appropriate? Same throughout?
|
|
||
| ## DNS-ACCOUNT-01 | ||
|
|
||
| The `dns-account-01` challenge leverages the ACME account URL to present an account-unique stable challenge to an ACME server. This challenge allows any domain name to delegate its domain validation to more than one service through |
There was a problem hiding this comment.
The
dns-account-01challenge leverages the ACME account URL to present an account-unique stable challenge to an ACME server.
I have had difficulty parsing this and struggled to come up with something in place of it.
I might reframe this section to be closer to the writeups for dns-01 or
tls-alpn-01. Rather just drop this and go straight to the definition like...
https://www.rfc-editor.org/rfc/rfc8737.html#section-3
|
|
||
| --- abstract | ||
|
|
||
| This document outlines a new challenge type for the ACME protocol that enables multiple independent systems to handle domain validation for a single domain. By incorporating the ACME Account ID into the DNS validation record name, the dns-account-01 challenge allows concurrent domain validation across different environments. This is particularly valuable for multi-region deployments where multiple systems need to independently obtain certificates for the same domain. |
There was a problem hiding this comment.
| This document outlines a new challenge type for the ACME protocol that enables multiple independent systems to handle domain validation for a single domain. By incorporating the ACME Account ID into the DNS validation record name, the dns-account-01 challenge allows concurrent domain validation across different environments. This is particularly valuable for multi-region deployments where multiple systems need to independently obtain certificates for the same domain. | |
| This document outlines a new DNS-based challenge type for the ACME protocol that enables multiple independent systems to authorize a single domain name concurrently. This is particularly valuable for multi-region or multi-cloud deployments that wish to rely upon DNS-based domain control validation and need to independently obtain certificates for the same domain. |
There was a problem hiding this comment.
nit: I think this can be shortened up a bit? It seems a bit repetitive and
I wanted to highlight the concurrency and that this specifically targets DNS-based DCV. . here is probably some further simplification to be done there. I didn't think the previous abstract's first line was bad though (draft-ietf-acme-scoped-dns-challenges.mkd).
I did drop the ACME account ID description thinking it wasn't vital to the purpose of the doc.
|
|
||
| When the identifier being validated is a domain name, the client can prove control of that domain by provisioning a TXT resource record containing a designated value for a specific validation domain name. | ||
|
|
||
| ## Challenge Definition |
There was a problem hiding this comment.
optional: I would personally just follow the formatting of the tls-alpn challenge. Make it easier for folks to read both? Make it look like the same protocol, etc.
Incorporate James Kasten's comments and my own improvements to this section
| - | ||
| fullname: James Kasten | ||
| organization: Google | ||
| email: [email protected] |
There was a problem hiding this comment.
Is that still valid @jdkasten ? ;)
| - `[0:10]` is the operation that selects the first ten bytes (bytes 0 through 9 inclusive) from the previous SHA-256 operation | ||
| - base32 is the operation defined in {{!RFC4648}} | ||
| - ACCOUNT_URL is defined in {{!RFC8555, Section 7.3}} as the value in the `Location` header field | ||
| - The `"||"` operator indicates concatenation of strings |
This change removes DNS-02 and scopes.
Also, this change makes some editorial changes to make this draft easier to read.