service protection. These intermediaries can also change values in the request that are <del> not signed in the HTTPS request, e.g., the request URL and headers. ACME uses JWS to provide an integrity mechanism, which protects against an intermediary changing the request URL to another ACME URL. </del>  As noted in request-authentication above, all ACME request objects carry a "url" header parameter in their protected header.  This that the server can use to detect unauthorized replay in future client requests.  The server MUST generate the value provided in Replay-Nonce in such a way that they are unique to each message, with <del> high probability.  For instance, it is acceptable to generate Replay- Nonces randomly. </del>  The value of the Replay-Nonce field MUST be an octet string encoded according to the base64url encoding described in Section 2 of prefix this field MUST be present, and true. The only type of identifier defined by this specification is a fully- <del> qualified domain name (type: "dns").  If a domain name contains non- ASCII Unicode characters it MUST be encoded using the rules defined in RFC3492.  Servers MUST verify any identifier values that begin with the ASCII Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects.  If an authorization object conveys authorization for the base domain of a newOrder DNS type identifier with a wildcard prefix then the optional authorizations "wildcard" field MUST be present with a value of true. </del>  identifier-validation-challenges describes a set of challenges for domain name validation. these requests.  The authorization object is implicitly tied to the account key used to sign the request. <del> When a client receives an order from the server it downloads the </del>  authorization resources by sending GET requests to the indicated URLs.  If the client initiates authorization using a request to the new authorization resource, it will have already received the pending specified challenge, by concatenating the token for the challenge with a key fingerprint, separated by a "." character: <del> The "JWK_Thumbprint" step indicates the computation specified in RFC7638, using the SHA-256 digest FIPS180-4.  As noted in RFC7518 any </del>  prepended zero octets in the fields of a JWK object MUST be stripped before doing the computation. value in the challenge.  The value of the resource MUST be the ASCII representation of the key authorization.  A client responds with an empty object ({}) to acknowledge that the challenge can be validated by the server.

URL URL
Trivial wordsmith suggestions. LGTM. Thanks NAME NAME Looks good to me. I'll be proposing some additional text for section 5. Benjamin Kaduk has entered the following ballot position for draft-ietf-acme-acme-14: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to URL for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: URL DISCUSS: This is a great thing to have, and I intend to eventually ballot Yes, but I do have some questions that may require further discussion before this document is approved. It looks like the server returns an unauthenticated "badSignatureAlgorithm" error when the client sends a JWS using an unsupported signature algorithm (Section 6.2). What prevents an active attacker from performing a downgrade attack on the signature algorithm used? Similarly, since we include in the threat model a potentially hostile CDN/MitM between the ACME client and ACME server, can that attacker strip a success response and replace it with a badNonce error, causing the client to retry (and thus duplicate the request processing on the server)? I am not an ART AD, but there is not yet an internationalization directorate, and seeing statements like "inputs for digest computations MUST be encoded using the UTF-8 character set" (Section 5) without additional discussion of normalization and/or what the canonical form for the digest input is makes me nervous. Has sufficient internationalization review been performed to ensure that there are no latent issues in this space? Section 6.1 has text discussing TLS 1.3's 0-RTT mode. If this text is intended to be a profile that defines/allows the use of TLS 1.3 0-RTT data for the ACME protocol, I think you need to be more specific and say something like "MAY allow clients to send early data (0-RTT); there are no ACME-specific restrictions on which types of requests are permitted in 0-RTT", since the runtime configuration is just 0-RTT yes/no, and the protocol spec is in charge of saying which PDUs are allowed or not. Section 6.2 notes that servers MUST NOT respond to GET requests for sensitvie resources. Why are account resources the only sensitive ones? Are authorizations not sensitive? Or are those considered to fall under the umbrella of "account resources" (Section 7.1 seems pretty clear that they do not)? Section 7.1.1 discusses how the server can include a caaIdentities element in its directory metadata; does this (or anything else) need to be integrity protected by anything stronger than the Web PKI cert authenticating the HTTPS connection? It seems that a bogus caaIdentities value could lead to an unfortunate DoS in some cases. I am also a bit uncertain if the document is internally consistent about whether one challenge verification suffices or there can be cases when multiple challenge verifications are required for a successful authorization. I attmpted to note relevant snippets of the text in my comments on Section 7.1.4. I also have some important substantive comments in the section-by-section COMMENTS, since they would not in and of themselves block publication. COMMENT: This document was quite easy to read -- thank you for the clear prose and document structure! It did leave me with some questions as to whether there are missing clarifications, though, so there are a pile of notes in the section-by-section comments below. It seems natural to feel some unease when the concept of automated certificate issuance like this comes up. As far as I can tell, though, the only substantive difference between this flow and the flow it's replacing is that this one qualitatively feels like it weakens the "know your customer" aspect for the CA -- with current/legacy methods registering for an account can be slow and involves real-world information. Such can be spoofed/forged, of course, but ACME seems to be weakening some aspect by automating it. Given the spoofability, though, this weakening does not seem to be a particular concern with the document. I was going to suggest mentioning the potential for future work in doing time-delayed or periodic revalidation or other schemes to look at the stability of the way that identifiers/challenges were validated, but I see that discussion has already happened. It's probably worth going over the examples and checking whether nonce values are repeated in ways that are inconsistent with expected usage. For example, I see these three values appearing multiple times (but I did not cross-check if a nonce returned in the Replay-Nonce response header was then used in a JWS header attribute): 2 K60BWPrMQG9SDxBDSxtSw 3 IXVHDyxIRGcTE0VSblhPzw 4 JHb54aTKTXBWQOzGYkt9A Perhaps the examples could be offset by a description of what they are? (They would probably also benefit from a disclaimer that the whitespace in the JSON is for ease of reading only.) Section-by-section comments follow. Abstract (also Introduction) If I read "authentication of domain names" with no context, I would be more likely to think of the sort of challenge/authorization process that this document describes, than I would be to think of using an X.509 certificate to authenticate myself as being the owner of a given domain name. But it's unclear whether there's an alternative phrasing that would be better. Section 1 Different types of certificates reflect different kinds of CA verification of information about the certificate subject. "Domain Validation" (DV) certificates are by far the most common type. The only validation the CA is required to perform in the DV issuance process is to verify that the requester has effective control of the domain. Can we get an (informative) ref for the "required"/requirements? Section 6.1 W3C.CR-cors-2013-0129 shows up as "outdated" when I follow the link. Section 6.2 IMPORTANT: The JSON Web Signature and Encryption Algorithms registry does not appear to include an explicit indicator of whether an algorithm is MAC-based; do we need to include text on how to make such a determination? Section 6.3 For servers following the "SHOULD ... string equality check" and for requests where the equality check fails, does that fall into the "MUST reject the request as unauthorized" bucket? Section 6.4 In order to protect ACME resources from any possible replay attacks, ACME requests have a mandatory anti-replay mechanism. We don't seem to actually define what an "ACME request" is that I can see. >From context, this requirement only applies to JWS POST bodies, and not to, say, newNonce, but I wonder if some clarification would be useful. IMPORTANT: How tightly are these nonces scoped? Are they only good on a specific TLS connection? Bound to an account key pair? Globally valid? (This is not a DISCUSS point because AFAICT there is no loss in security if the nonce space is global to the server.) Section 6.6 IMPORTANT: Providing an accountDoesNotExist error type probably means we need to give guidance that the server should choose account URLs in a non-guessable way, to avoid account enumeration attacks. [...] Servers MUST NOT use the ACME URN namespace Section 9.6 for errors other than the standard types. "standard" as determined by inclusion in this document, or in the IANA registry? Section 7.1 The "up" link relation for going from certificate to chain seems to only be needed for alternate content types that can only represent a single certificate. (Also, the "alternate" link relation is used to provide alternate certifciation chains.) Could this text be made more clear? Presumably this is just my confusion, but what does "GET order certificate" mean? Section 7.1.1 [...] It is a JSON object, whose field names are drawn from the following table and whose values are the corresponding URLs. Er, from the IANA registry, right? The following metadata items are defined, all of which are OPTIONAL: Maybe also refer to the registry? Section 7.1.2 IMPORTANT: I'm unclear if the "contact" is supposed to be a "talk to a human" thing or not. If there are supposed to be different URLs that are used for different purposes, wouldn't more metadata be needed about them? So it seems most likely that this is indeed "talk to a human", in which case that might be worth mentioning. (Are these always going to be mailto:?) Section 7.1.2.1 IMPORTANT: Am I reading this correctly that the GET to the orders URL does not require the client to be authenticated, in effect relying on security-through-obscurity (of the account URL) for indicating which account is trying to order certificates for which identifiers? Section 7.1.4 challenges (required, array of objects): For pending authorizations, the challenges that the client can fulfill in order to prove possession of the identifier. For final authorizations (in the "valid" or "invalid" state), the challenges that were used. Each array entry is an object with parameters required to validate the challenge. A client should attempt to fulfill one of these challenges, and a server should consider any one of the challenges sufficient to make the authorization valid. This leaves me slightly confused. A final authorization can have multiple challenges. But a client should only attempt to fulfill one, and a server should treat any one as sufficient. So I can only get to the case with multiple challenges present in a final order of both "should"s are violated? Is there a way for the server to express that multiple challenges are going to be required? Hmm, but Section 7.1.6's flow chart for Authorization objects says that a single challenge's transition to valid also makes the authorization transition to valid, which would seem to close the window? Section 7.5.1 has inline text that implicitly assumes that only one challenge will be completed/validated. wildcard (optional, boolean): For authorizations created as a result of a newOrder request containing a DNS identifier with a value that contained a wildcard prefix this field MUST be present, and true. Is there a difference between false and absent? Section 7.3 A client creates a new account with the server by sending a POST request to the server's new-account URL. The body of the request is a stub account object optionally containing the "contact" and "termsOfServiceAgreed" fields. Given that we go on to describe those two and also the optional onlyReturnExisting and externalAccountBinding fields, does this list need expanding? IMPORTANT: How does the client know if a termsOfService in the directory is actually required or just optional? (There doesn't seem to be a dedicated error type for this?) The text as-is seems to only say that if the server requires it, the field must be present in the directory, but not the other way around. I guess Section 7.3.4 describes the procedure for a similar case; should the same thing happen for the original terms acceptance? IMPORTANT: The example response uses what appears to be a sequential counter for account ID in the returned account URL, which loses any sort of security-through-obscurity protections if those were desired. Should a more opaque URL component be present, maybe a UUID? (The "orders" field would need to be modified accordingly, of course, and this pattern appears in later examples, as well.) Section 7.3.2 It's a little unclear to me whether the fields the client can put in the POST are the ones listed from Section 7.3 or 7.1.2, or the full set from the registry. But presumably the server must ignore the "status" field, too, or at least some values should be disallowed! The IANA registry's "configurable" column may not quite be the right thing for this usage, especially given how account deactivation works. Section 7.3.5 The server MAY require a value for the "externalAccountBinding" field to be present in "newAccount" requests. All requests including queries for the current status and modification of existing accounts? Or just creation of new ones? To enable ACME account binding, the CA operating the ACME server needs to provide the ACME client with a MAC key and a key identifier, using some mechanism outside of ACME. This key needs to also be tied to the external account in question, right? One might even say that it is provided not to the ACME client, but to the external account holder, who is also running an ACME client. [...] The payload of this JWS is the account key being registered, in JWK form. This is presumably my fault and not the document's, but I had to read this a few time to bind it as the ACME account key, and not the external MAC key. If a CA requires that new-account requests contain an "externalAccountBinding" field, then it MUST provide the value "true" in the "externalAccountRequired" subfield of the "meta" field in the directory object. If the CA receives a new-account request without [...] nit: maybe "If such a CA"? IMPORTANT: I don't think I understand why "nonce" MUST NOT be present in the external-binding JWS object, though I think I understand why one is not needed in order to bind the MAC to the current transaction. (That is, this is in effect a "triply nested" construct, where a standalone MAC that certifies an ACME account (public) key as being authorized by the external-account holder to act on behal of that external account. But this standalone MAC will only be accepted by the ACME server in the context of the outer JWS POST, that must be signed by the ACME account key, which is assumed to be kept secure by the ACME client, ensuring that both key-holding entities agree to the account linkage.) Proof of freshness of the commitment from the external account holder to authorize the ACME account key would only be needed if there was a scenario where the external account holder would revoke that association, which does not seem to be a workflow supported by this document. Any need to effectuate such a revocation seems like it would involve issuing a new MAC key for the external account (and invalidating the old one), and revoking/deactivating the ACME account, which is a somewhat heavy hammer but perhaps reasonable for such a scenario. Account key rollover just says that the nonce is NOT REQUIRED, and also uses some nicer (to me) language about "outer JWS" and "inner JWS". It might be nice to synchronize these two sections. Section 7.3.7 IMPORTANT: The "url" in this example looks like an account URL, not an account-deactivation url. If they are one and the same, please include some body text to this effect as is done for account update in Section Section 7.4 Is Section 7.1.3 or the registry a better reference for the request payload's fields? Does the exact-match policy (e.g., on notBefore and notAfter) result in CA maximum lifetime policies needing to be hardcoded in client software (as opposed to being discoverable at runtime)? (I like the order url in the example, "[...]/order/asdf". Not much entropy though.) IMPORTANT: Why does the example response include an identifier of URL that was not in the request? Is the "order's requested identifiers appear in commonName or subjectAltName" requirement an exclusive or? After a valid request to finalize has been issued, are "pending" or "ready" still valid statuses that could be returned for that order? Section 7.4.1 Elsewhere when we list "identifier (required, object)" in a JWS payload we also inline the "type" and "value" breakdown of the object. How is "expires" set for this pre-authorization object? We probably need a reference for "certificate chain as defined in TLS". Section 7.5 "When a client receives an order from the server" is a bit jarring without some additional context of "in a reply to a new-order request" or "an order object" or similar. Section 7.5.1 To do this, the client updates the authorization object received from the server by filling in any required information in the elements of the "challenges" dictionary. "challenges" looks like an array of objects, not directly a dictionary with elements within it. Section 8 IMPORTANT: What do I do if I get a challenge object that has status "valid" but also includes an "error" field? Section 8.1 [...] A key authorization is a string that expresses a domain holder's authorization for a specified key to satisfy a specified challenge, [...] I'm going to quibble with the language here and say that the keyAuthorization string as defined does not express a specific authorization for a specific challenge, since there is no signature involved, and the JWK thumbprint is separable and can be attached to some other token. (This may just be an editorial matter with no broader impact, depending on how it's used.) One could perhaps argue that the mere existence of the token constitutes an authorization for a specified key to satisfy the challenge, since the token only gets generated upon receipt of such an authorized request. Section 8.3 I'm not sure that 4086 is a great cite, here. For example, in RFC 8446 we say that "TLS requires a [CSPRNG]. In most case, the operating system provides an appropriate facility [...] Should these prove unsatisfactory, [RFC4086] provides guidance on the generation of random values." On the other hand, citing 4086 like this is not wrong, so use your judgment. Verify that the body of the response is well-formed key authorization. The server SHOULD ignore whitespace characters at the end of the body. nit: "a well-formed" Can we get some justification for the "SHOULD follow redirects", given the security considerations surrounding doing so? Section 8.4 Should this "token" description include the same text about entropy as for the HTTP challenge? Section 9.7.1 There is perhaps some subtlety here, in that the "configurable" column applies only to the new-account request, but its description in the template does not reflect that restriction. In particular, "status" values from the client are accepted when posted to the account URL, e.g., for account deactivation. Section 10.1 Can there be overlap between the "validation server" function and the "ACME client" function? Section 10.2 [...] The key authorization reflects the account public key, is provided to the server in the validation response over the validation channel and signed afterwards by the corresponding private key in the challenge response over the ACME channel. I'm stumbling up around the comma trying to parse this sentence. (Maybe a serial comma or using "and is signed" would help?) IMPORTANT: Also, I don't see where the key authorization is signed in the challenge response -- the payload is just an empty object for both the HTTP and DNS challenges' responses. Some of this text sounds like we're implicitly placing requirements on all (HTTP|DNS) server operators (not just ones trying to use ACME) to mitgate the risks being described. In general this sort of behavior seems like an anti-design-pattern, though perhaps one could argue that the behaviors in question should be avoided in general, indepnedent of ACME. Section 10.4 Some server implementations include information from the validation server's response (in order to facilitate debugging). Such Disambiguating "ACME server implementations" may help, since we talk about other HTTP requests in the previous paragraph. Section 11.1 IMPORTANT: This may be an appropriate place to recommend against reuse of account keys, whether after an account gets deactivated or by cycling through keys in a sequence of key-change operations (or otherwise). I think there are some attack scenarios possible wherein (inner) JWS objects could be replayed against a different account, if such key reuse occurs. Section 11.3 The http-01, and dns-01 validation methods mandate the usage of a nit: spurious comma. [...] Secondly, the entropy requirement prevents ACME clients from implementing a "naive" validation server that automatically replies to challenges without participating in the creation of the initial authorization request. IMPORTANT: I'm not sure I see how this applies to the HTTP mechanism -- couldn't you write a script to reply to .well-known/acme-challenge/ with . for a fixed key thumbprint? The validation server would ned to know about the ACME account in question, but not about any individual authorization request. Thanks for addressing my Discuss and other points; as promised, I'm switching to Yes.  (But I support Adam's discuss and look forward to seeing it come to a close as well.) This document was quite easy to read -- thank you for the clear prose and document structure!  It did leave me with some questions as to whether there are missing clarifications, though, so there are a pile of notes in the section-by-section comments below. It seems natural to feel some unease when the concept of automated certificate issuance like this comes up.  As far as I can tell, though, the only substantive difference between this flow and the flow it's replacing is that this one qualitatively feels like it weakens the "know your customer" aspect for the CA -- with current/legacy methods registering for an account can be slow and involves real-world information.  Such can be spoofed/forged, of course, but ACME seems to be weakening some aspect by automating it.  Given the spoofability, though, this weakening does not seem to be a particular concern with the document. I was going to suggest mentioning the potential for future work in doing time-delayed or periodic revalidation or other schemes to look at the stability of the way that identifiers/challenges were validated, but I see that discussion has already happened. It's probably worth going over the examples and checking whether nonce values are repeated in ways that are inconsistent with expected usage.  For example, I see these three values appearing multiple times (but I did not cross-check if a nonce returned in the Replay-Nonce response header was then used in a JWS header attribute): Perhaps the examples could be offset by a description of what they are? (They would probably also benefit from a disclaimer that the whitespace in the JSON is for ease of reading only.) Section-by-section comments follow. Abstract (also Introduction) If I read "authentication of domain names" with no context, I would be more likely to think of the sort of challenge/authorization process that this document describes, than I would be to think of using an X.509 certificate to authenticate myself as being the owner of a given domain name.  But it's unclear whether there's an alternative phrasing that would be better. Can we get an (informative) ref for the "required"/requirements? W3C.CR-cors-2013-0129 shows up as "outdated" when I follow the link. IMPORTANT: The JSON Web Signature and Encryption Algorithms registry does not appear to include an explicit indicator of whether an algorithm is MAC-based; do we need to include text on how to make such a determination? For servers following the "SHOULD ... string equality check" and for requests where the equality check fails, does that fall into the "MUST reject the request as unauthorized" bucket? We don't seem to actually define what an "ACME request" is that I can see. From context, this requirement only applies to JWS POST bodies, and not to, say, newNonce, but I wonder if some clarification would be useful. IMPORTANT: How tightly are these nonces scoped?  Are they only good on a specific TLS connection?  Bound to an account key pair?  Globally valid? (This is not a DISCUSS point because AFAICT there is no loss in security if the nonce space is global to the server.) IMPORTANT: Providing an accountDoesNotExist error type probably means we need to give guidance that the server should choose account URLs in a non-guessable way, to avoid account enumeration attacks. "standard" as determined by inclusion in this document, or in the IANA registry? The "up" link relation for going from certificate to chain seems to only be needed for alternate content types that can only represent a single certificate.  (Also, the "alternate" link relation is used to provide alternate certifciation chains.)  Could this text be made more clear? Presumably this is just my confusion, but what does "GET order certificate" mean? Er, from the IANA registry, right? Maybe also refer to the registry? IMPORTANT: I'm unclear if the "contact" is supposed to be a "talk to a human" thing or not.  If there are supposed to be different URLs that are used for different purposes, wouldn't more metadata be needed about them? So it seems most likely that this is indeed "talk to a human", in which case that might be worth mentioning.  (Are these always going to be mailto:?) IMPORTANT: Am I reading this correctly that the GET to the orders URL does not require the client to be authenticated, in effect relying on security-through-obscurity (of the account URL) for indicating which account is trying to order certificates for which identifiers? This leaves me slightly confused.  A final authorization can have multiple challenges.  But a client should only attempt to fulfill one, and a server should treat any one as sufficient.  So I can only get to the case with multiple challenges present in a final order of both "should"s are violated?  Is there a way for the server to express that multiple challenges are going to be required? Hmm, but Section 7.1.6's flow chart for Authorization objects says that a single challenge's transition to valid also makes the authorization transition to valid, which would seem to close the window? Section 7.5.1 has inline text that implicitly assumes that only one challenge will be completed/validated. Is there a difference between false and absent? Given that we go on to describe those two and also the optional onlyReturnExisting and externalAccountBinding fields, does this list need expanding? IMPORTANT: How does the client know if a termsOfService in the directory is actually required or just optional?  (There doesn't seem to be a dedicated error type for this?)  The text as-is seems to only say that if the server requires it, the field must be present in the directory, but not the other way around.  I guess Section 7.3.4 describes the procedure for a similar case; should the same thing happen for the original terms acceptance? IMPORTANT: The example response uses what appears to be a sequential counter for account ID in the returned account URL, which loses any sort of security-through-obscurity protections if those were desired.  Should a more opaque URL component be present, maybe a UUID?  (The "orders" field would need to be modified accordingly, of course, and this pattern appears in later examples, as well.) It's a little unclear to me whether the fields the client can put in the POST are the ones listed from Section 7.3 or 7.1.2, or the full set from the registry.  But presumably the server must ignore the "status" field, too, or at least some values should be disallowed!  The IANA registry's "configurable" column may not quite be the right thing for this usage, especially given how account deactivation works. All requests including queries for the current status and modification of existing accounts?  Or just creation of new ones? This key needs to also be tied to the external account in question, right? One might even say that it is provided not to the ACME client, but to the external account holder, who is also running an ACME client. This is presumably my fault and not the document's, but I had to read this a few time to bind it as the ACME account key, and not the external MAC key. nit: maybe "If such a CA"? IMPORTANT: I don't think I understand why "nonce" MUST NOT be present in the external-binding JWS object, though I think I understand why one is not needed in order to bind the MAC to the current transaction.  (That is, this is in effect a "triply nested" construct, where a standalone MAC that certifies an ACME account (public) key as being authorized by the external-account holder to act on behal of that external account.  But this standalone MAC will only be accepted by the ACME server in the context of the outer JWS POST, that must be signed by the ACME account key, which is assumed to be kept secure by the ACME client, ensuring that both key-holding entities agree to the account linkage.)  Proof of freshness of the commitment from the external account holder to authorize the ACME account key would only be needed if there was a scenario where the external account holder would revoke that association, which does not seem to be a workflow supported by this document.  Any need to effectuate such a revocation seems like it would involve issuing a new MAC key for the external account (and invalidating the old one), and revoking/deactivating the ACME account, which is a somewhat heavy hammer but perhaps reasonable for such a scenario. Account key rollover just says that the nonce is NOT REQUIRED, and also uses some nicer (to me) language about "outer JWS" and "inner JWS".  It might be nice to synchronize these two sections. IMPORTANT: The "url" in this example looks like an account URL, not an account-deactivation url. If they are one and the same, please include some body text to this effect as is done for account update in Section 7.3.2. Is Section 7.1.3 or the registry a better reference for the request payload's fields? Does the exact-match policy (e.g., on notBefore and notAfter) result in CA maximum lifetime policies needing to be hardcoded in client software (as opposed to being discoverable at runtime)? (I like the order url in the example, "[...]/order/asdf".  Not much entropy though.) IMPORTANT: Why does the example response include an identifier of www.example.com that was not in the request? Is the "order's requested identifiers appear in commonName or subjectAltName" requirement an exclusive or? After a valid request to finalize has been issued, are "pending" or "ready" still valid statuses that could be returned for that order? Elsewhere when we list "identifier (required, object)" in a JWS payload we also inline the "type" and "value" breakdown of the object. How is "expires" set for this pre-authorization object? We probably need a reference for "certificate chain as defined in TLS". "When a client receives an order from the server" is a bit jarring without some additional context of "in a reply to a new-order request" or "an order object" or similar. "challenges" looks like an array of objects, not directly a dictionary with elements within it. IMPORTANT: What do I do if I get a challenge object that has status "valid" but also includes an "error" field? I'm going to quibble with the language here and say that the keyAuthorization string as defined does not express a specific authorization for a specific challenge, since there is no signature involved, and the JWK thumbprint is separable and can be attached to some other token.  (This may just be an editorial matter with no broader impact, depending on how it's used.)  One could perhaps argue that the mere existence of the token constitutes an authorization for a specified key to satisfy the challenge, since the token only gets generated upon receipt of such an authorized request. I'm not sure that 4086 is a great cite, here.  For example, in RFC 8446 we say that "TLS requires a [CSPRNG].  In most case, the operating system provides an appropriate facility [...] Should these prove unsatisfactory,[RFC4086] provides guidance on the generation of random values."  On the other hand, citing 4086 like this is not wrong, so use your judgment. nit: "a well-formed" Can we get some justification for the "SHOULD follow redirects", given the security considerations surrounding doing so? Should this "token" description include the same text about entropy as for the HTTP challenge? There is perhaps some subtlety here, in that the "configurable" column applies only to the new-account request, but its description in the template does not reflect that restriction.  In particular, "status" values from the client *are* accepted when posted to the account URL, e.g., for account deactivation. Can there be overlap between the "validation server" function and the "ACME client" function? I'm stumbling up around the comma trying to parse this sentence.  (Maybe a serial comma or using "and is signed" would help?) IMPORTANT: Also, I don't see where the key authorization is signed in the challenge response -- the payload is just an empty object for both the HTTP and DNS challenges' responses. Some of this text sounds like we're implicitly placing requirements on all (HTTP|DNS) server operators (not just ones trying to use ACME) to mitgate the risks being described.  In general this sort of behavior seems like an anti-design-pattern, though perhaps one could argue that the behaviors in question should be avoided in general, indepnedent of ACME. Disambiguating "ACME server implementations" may help, since we talk about other HTTP requests in the previous paragraph. IMPORTANT: This may be an appropriate place to recommend against reuse of account keys, whether after an account gets deactivated or by cycling through keys in a sequence of key-change operations (or otherwise).  I think there are some attack scenarios possible wherein (inner) JWS objects could be replayed against a different account, if such key reuse occurs. nit: spurious comma. IMPORTANT: I'm not sure I see how this applies to the HTTP mechanism -- couldn't you write a script to reply to .well-known/acme-challenge/<foo> with <foo>.<key thumbprint> for a fixed key thumbprint?  The validation server would ned to know about the ACME account in question, but not about any individual authorization request.

service protection. These intermediaries can also change values in the request that are  <ins> not signed in the HTTPS request, e.g., the request URL and header fields.  ACME uses JWS to provide an integrity mechanism, which protects against an intermediary changing the request URL to another ACME URL. </ins> As noted in request-authentication above, all ACME request objects carry a "url" header parameter in their protected header.  This that the server can use to detect unauthorized replay in future client requests.  The server MUST generate the value provided in Replay-Nonce in such a way that they are unique to each message, with  <ins> high probability, and unpredictable to anyone besides the server. For instance, it is acceptable to generate Replay-Nonces randomly. </ins> The value of the Replay-Nonce field MUST be an octet string encoded according to the base64url encoding described in Section 2 of prefix this field MUST be present, and true. The only type of identifier defined by this specification is a fully-  <ins> qualified domain name (type: "dns").  The domain name MUST be encoded in the form in which it would apper in a certificate.  That is, it MUST be encoded according to the rules in Section 7 of RFC5280. Servers MUST verify any identifier values that begin with the ASCII Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects.  If an authorization object conveys authorization for the base domain of a newOrder DNS type identifier with a wildcard prefix then the optional authorizations "wildcard" field MUST be present with a value of true. </ins> identifier-validation-challenges describes a set of challenges for domain name validation. these requests.  The authorization object is implicitly tied to the account key used to sign the request.  <ins> When a client receives an order from the server, it downloads the </ins> authorization resources by sending GET requests to the indicated URLs.  If the client initiates authorization using a request to the new authorization resource, it will have already received the pending specified challenge, by concatenating the token for the challenge with a key fingerprint, separated by a "." character:  <ins> The "Thumbprint" step indicates the computation specified in RFC7638, using the SHA-256 digest FIPS180-4.  As noted in RFC7518 any </ins> prepended zero octets in the fields of a JWK object MUST be stripped before doing the computation. value in the challenge.  The value of the resource MUST be the ASCII representation of the key authorization. <ins> (In the above, "..." indicates that the token and the JWK thumbprint in the key authorization have been truncated to fit on the page.) </ins> A client responds with an empty object ({}) to acknowledge that the challenge can be validated by the server.


requests without an entity body are not authenticated, in particular GET requests.  Except for the cases described in this section, if the server receives a GET request, it MUST return an error with status <del> code 405 "Method Not Allowed" and type "malformedRequest". </del>  If a client wishes to fetch a resource from the server (which would otherwise be done with a GET), then it MUST send a POST request with degree of access control by assigning them capability URLs W3C.WD- capability-urls-20140218.  As above, if the server does not allow GET requests for a given resource, it MUST return an error with status <del> code 405 "Method Not Allowed" and type "malformedRequest". </del>  6.4. anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal.  A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.

As suggested by David Hancock, change the certificate fetch examples to use POST-as-GET, noting that GET is optional As suggested by Felix Fontein, use the correct error code for "malformed" in the description of what servers should do in response to inappropriate GET requests
Since doesn't look like it will be merged anytime soon, would it be possible to move the editorial (undisputed) stuff (trailing comma, authz -> challenge in URL) into this PR?
NAME I think I've gotten all the trailing commas and errant headersgit di.
NAME Looks good to me!
editorial clarifications, looks good to me.

requests without an entity body are not authenticated, in particular GET requests.  Except for the cases described in this section, if the server receives a GET request, it MUST return an error with status  <ins> code 405 "Method Not Allowed" and type "malformed". </ins> If a client wishes to fetch a resource from the server (which would otherwise be done with a GET), then it MUST send a POST request with degree of access control by assigning them capability URLs W3C.WD- capability-urls-20140218.  As above, if the server does not allow GET requests for a given resource, it MUST return an error with status  <ins> code 405 "Method Not Allowed" and type "malformed". </ins> 6.4. anchors.  Clients can fetch these alternates and use their own heuristics to decide which is optimal. <ins> An ACME client MAY attempt to fetch the certificate with a GET request.  If the server does not allow GET requests for certificate resources, then it will return an error as described in post-as-get. On receiving such an error, the client SHOULD fall back to a POST-as- GET request. </ins> A certificate resource represents a single, immutable certificate. If the client wishes to obtain a renewed certificate, the client initiates a new order process to request one.


these resources.  This enables clients to bootstrap into the ACME authentication system. <del> The server MAY allow GET requests for certificate resources in order to allow certificates to be fetched by a lower-privileged process, e.g., the web server that will use the referenced certificate chain. (See I-D.ietf-acme-star for more advanced cases.)  A server that allows GET requests for certificate resources can still provide a degree of access control by assigning them capability URLs W3C.WD- capability-urls-20140218.  As above, if the server does not allow GET requests for a given resource, it MUST return an error with status code 405 "Method Not Allowed" and type "malformed". </del> 6.4. It is common in deployment for the entity terminating TLS for HTTPS

This exception doesn't actually improve interop for STAR clients, and it introduces complexity into the security analysis of ACME. STAR can easily solve the problem by defining a new field on orders that provides an explicitly GETtable URL, with whatever security properties the STAR project needs.
Do not merge this without discussion on the mailing list.
Merging based on out-of-band approval from NAME

these resources.  This enables clients to bootstrap into the ACME authentication system.  6.4. It is common in deployment for the entity terminating TLS for HTTPS


The major guiding use case for ACME is obtaining certificates for Web sites (HTTPS RFC2818).  In that case, the server is intended to speak for one or more domains, and the process of certificate issuance is <del> intended to verify that the server actually speaks for the domain. </del>  Different types of certificates reflect different kinds of CA verification of information about the certificate subject.  "Domain can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "certificates" field is an array of strings, where each string is the URI of a certificate.  The <del> server SHOULD NOT include expired certificates. </del>  5.3. If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was <del> submitted to a CT log.  An SCT can be included as a extension in the </del>  certificate or as an extension to OCSP responses for the certificate. The server can also provide the client with direct access to an SCT for a certificate using a Link relation header field with relation 7. <del> There are few types of identifier in the world for which there is a </del>  standardized mechanism to prove possession of a given identifier.  In all practical cases, CAs rely on a variety of means to test whether an entity applying for a certificate with a given identifier actually by their account keys, so this overall goal breaks down into two more precise goals: <del> Only an entity that controls a identifier can get an account key </del>  authorized for that identifier Once authorized, an account key's authorizations cannot be holder) All of the challenges above that require an out-of-band query by the <del> server have a binding to the account private key, such that the only the account private key holder can successfully respond to the validation query: </del>  HTTP: The value provided in the validation request is signed by the account private key.

editorial change
These LGTM as editorial. I note that the inclusion of "revoked" in URL is on the edge, but I think it was intended and could be merged as a result.
I did think the mentioned change might be an edge case, too, but came to the same conclusion. Happy to be of any help.
LGTM as well. Thanks NAME

The major guiding use case for ACME is obtaining certificates for Web sites (HTTPS RFC2818).  In that case, the server is intended to speak for one or more domains, and the process of certificate issuance is  <ins> intended to verify that the server actually speaks for the domain(s). </ins> Different types of certificates reflect different kinds of CA verification of information about the certificate subject.  "Domain can be fetched via a GET request.  The result of the GET request MUST be a JSON object whose "certificates" field is an array of strings, where each string is the URI of a certificate.  The  <ins> server SHOULD NOT include expired or revoked certificates. </ins> 5.3. If the CA participates in Certificate Transparency (CT) RFC6962, then they may want to provide the client with a Signed Certificate Timestamp (SCT) that can be used to prove that a certificate was  <ins> submitted to a CT log.  An SCT can be included as an extension in the </ins> certificate or as an extension to OCSP responses for the certificate. The server can also provide the client with direct access to an SCT for a certificate using a Link relation header field with relation 7.  <ins> There are few types of identifiers in the world for which there is a </ins> standardized mechanism to prove possession of a given identifier.  In all practical cases, CAs rely on a variety of means to test whether an entity applying for a certificate with a given identifier actually by their account keys, so this overall goal breaks down into two more precise goals:  <ins> Only an entity that controls an identifier can get an account key </ins> authorized for that identifier Once authorized, an account key's authorizations cannot be holder) All of the challenges above that require an out-of-band query by the  <ins> server have a binding to the account private key, such that only the account private key holder can successfully respond to the validation query: </ins> HTTP: The value provided in the validation request is signed by the account private key.


POST-as-GET request to the URL returns "Not Found" or "Unauthorized". For example, suppose that the CA uses highly structured URLs with <del> several low-entropy fields: </del>  Accounts: https://example.com/:accountID <del> Orders: https://example.com/:accountID/:orderID </del>  <del> Authorizations: https://example.com/:accountID/:authorizationID </del>  <del> Certificates: https://example.com/:accountID/:certID </del>  <del> If the ID fields have low entropy, then an attacker can find out how many users a CA has, how many authorizations each account has, etc. </del>  <del> In order to avoid leaking these correlations, servers SHOULD assign capability URLs for dynamically-created resources W3C.WD-capability- urls-20140218.  These URLs incorporate large unpredictable components to prevent third parties from guessing them.  These URLs SHOULD NOT have a structure that would enable a third party to infer correlations between resources. For example, a CA might assign URLs for each resource type from an independent namespace, using unpredictable IDs for each resource: </del>  Accounts: https://example.com/acct/:accountID

Fix a misuse of the term "capability URL." Change the example. Hiding the number of accounts was not a great example, because even with randomized account URLs, an attacker could probe the space of URLs to estimate their density.
Thanks for slimming this down. I can live with this version.Thanks NAME This looks fine to me.

POST-as-GET request to the URL returns "Not Found" or "Unauthorized". For example, suppose that the CA uses highly structured URLs with  <ins> guessable fields: </ins> Accounts: https://example.com/:accountID  <ins> Orders: https://example.com/:accountID/:domainName </ins>  <ins> Authorizations: https://example.com/:accountID/:domainName </ins>  <ins> Certificates: https://example.com/:accountID/:domainName </ins>  <ins> Under that scheme, an attacker could probe for which domain names are associated with which accounts, which may allow correlation of ownership between domain names, if the CA does not otherwise permit it. </ins>  <ins> To avoid leaking these correlations, CAs SHOULD assign URLs with an unpredictable component.  For example, a CA might assign URLs for each resource type from an independent namespace, using unpredictable IDs for each resource: </ins> Accounts: https://example.com/acct/:accountID


The ACME client MAY request other formats by including an Accept header field RFC7231 in its request.  For example, the client could <del> use the media type "application/pkix-cert" RFC2585 or "applicaiton/ </del>  pkcs7-mime" RFC5751 to request the end-entity certificate in DER format.  Server support for alternate formats is OPTIONAL.  For formats that can only express a single certificate, the server SHOULD including the key in the PEM file returned in response to a query for a certificate URL. <del> When processing an file of type "application/pem-certificate-chain", a client SHOULD verify that the file contains only encoded </del>  certificates.  If anything other than a certificate is found (i.e., if the string "-----BEGIN" is ever followed by anything other than "CERTIFICATE"), then the client MUST reject the file as invalid.

Change "applicaiton" to "application"
With any luck we'll have to catch this in the RFC editor queue; hopefully there won't be another draft.
Thanks NAME

The ACME client MAY request other formats by including an Accept header field RFC7231 in its request.  For example, the client could  <ins> use the media type "application/pkix-cert" RFC2585 or "application/ </ins> pkcs7-mime" RFC5751 to request the end-entity certificate in DER format.  Server support for alternate formats is OPTIONAL.  For formats that can only express a single certificate, the server SHOULD including the key in the PEM file returned in response to a query for a certificate URL.  <ins> When processing a file of type "application/pem-certificate-chain", a client SHOULD verify that the file contains only encoded </ins> certificates.  If anything other than a certificate is found (i.e., if the string "-----BEGIN" is ever followed by anything other than "CERTIFICATE"), then the client MUST reject the file as invalid.


unauthorized. Except for the directory resource, all ACME resources are addressed <del> with URLs provided to the client by the server.  In requests sent to these resources, the client MUST set the "url" header parameter to the exact string provided by the server (rather than performing any re-encoding on the URL).  The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" header parameter.  The server MUST reject the request as unauthorized if the string equality check fails. </del>  6.4.1. new nonce, e.g., on its first request to the server or if an existing nonce is no longer valid. <del> To get a fresh nonce, the client sends a HEAD request to the new- nonce resource on the server.  The server's response MUST include a Replay-Nonce header field containing a fresh nonce and SHOULD have status code 200 (OK).  The server MUST also respond to GET requests for this resource, returning an empty body (while still providing a Replay-Nonce header) with a status code of 204 (No Content). </del>  <del> Proxy caching of responses from the new-nonce resource can cause </del>  clients to receive the same nonce repeatedly, leading to "badNonce" errors.  The server MUST include a Cache-Control header field with <del> the "no-store" directive in responses for the new-nonce resource, in </del>  order to prevent caching of this resource. 7.3. this request and its signature, and indicates the old key holder's assent to the rollover request. <del> To create this request object, the client first constructs a key- change object describing the account to be updated and its account </del>  key: The URL for the account being modified.  The content of this field The JWK representation of the old key. <del> The client then encapsulates the key-change object in an "inner" JWS, </del>  signed with the requested new account key.  This "inner" JWS becomes the payload for the "outer" JWS that is the body of the ACME request. old key.  The "outer" JWS represents the current account holder's assent to this request. <del> On receiving key-change request, the server MUST perform the following steps in addition to the typical JWS validation: </del>  Validate the POST request belongs to a currently active account, as described in message-transport. Check that the inner JWS verifies using the key in its "jwk" field. <del> Check that the payload of the inner JWS is a well-formed key- change object (as described above). </del>  Check that the "url" parameters of the inner and outer JWSs are the same. <del> Check that the "account" field of the key-change object contains </del>  the URL for the account matching the old key (i.e., the "kid" field in the outer JWS). <del> Check that the "oldKey" field of the key-change object is the same </del>  as the account key for the account in question. Check that no account exists whose account key is the same as the The "ACME Order Object Fields" registry lists field names that are defined for use in ACME order objects.  Fields marked as <del> "configurable" may be included in a new-order request. </del>  Template: The "ACME Authorization Object Fields" registry lists field names that are defined for use in ACME authorization objects.  Fields <del> marked as "configurable" may be included in a new-authorization request. </del>  Template: MitM registers account key pair B <del> Legitimate domain holder sends a new-order request signed using </del>  account key A MitM suppresses the legitimate request but sends the same request

This PR is collecting changes to make sure we address during the editing window. Editorial clarifications only, please.
Both and are also TODO's for AUTH48.
Section 7.4 says: It should say , not . NAME Would you mind fixing this typo in this PR?
NAME Turns out the RFC editor caught that one (see ), so I don't have to fix it here :)
LGTM

unauthorized. Except for the directory resource, all ACME resources are addressed  <ins> with URLs provided to the client by the server.  In POST requests sent to these resources, the client MUST set the "url" header parameter to the exact string provided by the server (rather than performing any re-encoding on the URL).  The server SHOULD perform the corresponding string equality check, configuring each resource with the URL string provided to clients and having the resource check that requests have the same string in their "url" header parameter. The server MUST reject the request as unauthorized if the string equality check fails. </ins> 6.4.1. new nonce, e.g., on its first request to the server or if an existing nonce is no longer valid.  <ins> To get a fresh nonce, the client sends a HEAD request to the newNonce resource on the server.  The server's response MUST include a Replay- Nonce header field containing a fresh nonce and SHOULD have status code 200 (OK).  The server MUST also respond to GET requests for this resource, returning an empty body (while still providing a Replay- Nonce header) with a status code of 204 (No Content). </ins>  <ins> Proxy caching of responses from the newNonce resource can cause </ins> clients to receive the same nonce repeatedly, leading to "badNonce" errors.  The server MUST include a Cache-Control header field with  <ins> the "no-store" directive in responses for the newNonce resource, in </ins> order to prevent caching of this resource. 7.3. this request and its signature, and indicates the old key holder's assent to the rollover request.  <ins> To create this request object, the client first constructs a keyChange object describing the account to be updated and its account </ins> key: The URL for the account being modified.  The content of this field The JWK representation of the old key.  <ins> The client then encapsulates the keyChange object in an "inner" JWS, </ins> signed with the requested new account key.  This "inner" JWS becomes the payload for the "outer" JWS that is the body of the ACME request. old key.  The "outer" JWS represents the current account holder's assent to this request.  <ins> On receiving keyChange request, the server MUST perform the following steps in addition to the typical JWS validation: </ins> Validate the POST request belongs to a currently active account, as described in message-transport. Check that the inner JWS verifies using the key in its "jwk" field.  <ins> Check that the payload of the inner JWS is a well-formed keyChange object (as described above). </ins> Check that the "url" parameters of the inner and outer JWSs are the same.  <ins> Check that the "account" field of the keyChange object contains </ins> the URL for the account matching the old key (i.e., the "kid" field in the outer JWS).  <ins> Check that the "oldKey" field of the keyChange object is the same </ins> as the account key for the account in question. Check that no account exists whose account key is the same as the The "ACME Order Object Fields" registry lists field names that are defined for use in ACME order objects.  Fields marked as  <ins> "configurable" may be included in a newOrder request. </ins> Template: The "ACME Authorization Object Fields" registry lists field names that are defined for use in ACME authorization objects.  Fields  <ins> marked as "configurable" may be included in a newAuthz request. </ins> Template: MitM registers account key pair B  <ins> Legitimate domain holder sends a newOrder request signed using </ins> account key A MitM suppresses the legitimate request but sends the same request


true, indicates the client's agreement with the terms of service. This field cannot be updated by the client.  A URL from which a list of orders submitted by this account can be fetched via a POST-as-GET request, as described in orders-list. allows a client to look up an account URL based on an account key (see finding-an-account-url-given-a-key). <del> An optional field for binding the new account with an existing non-ACME account (see external-account-binding ). </del>  The server MUST ignore any values provided in the "orders" fields in <del> account bodies sent by the client, as well as any other fields that </del>  it does not recognize.  If new fields are specified in the future, the specification of those fields MUST describe whether they can be <del> provided by the client. In general, the server MUST ignore any fields in the request object that it does not recognize.  In particular, it MUST NOT reflect unrecognized fields in the resulting account object.  This allows clients to detect when servers do not support an extension field. </del>  The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server.  If the server validates Initial contents: The fields and descriptions defined in account- objects.  9.7.2. The "ACME Order Object Fields" registry lists field names that are

From Section 7.3: "MUST URL account bodies sent by the URL other fields that it does not recognize" in the first paragraph seems to be unnecessarily repeated by "MUST ignore any fields in the request object that it does not recognize" in the second paragraph. This PR merges these two paragraphs and discards the duplicated text. Also, "account bodies" isn't used anywhere else in the document, so this PR changes it to "account objects".
This looks reasonable to handle in AUTH48.
the last part isn't purely editorial, but okay.

true, indicates the client's agreement with the terms of service. This field cannot be updated by the client. <ins> Including this field in a newAccount request indicates approval by the holder of an existing non-ACME account to bind that account to this ACME account.  This field is not updateable by the client. (See external-account-binding). </ins> A URL from which a list of orders submitted by this account can be fetched via a POST-as-GET request, as described in orders-list. allows a client to look up an account URL based on an account key (see finding-an-account-url-given-a-key).  <ins> Same meaning as the corresponding server field defined in </ins> The server MUST ignore any values provided in the "orders" fields in  <ins> account objects sent by the client, as well as any other fields that </ins> it does not recognize.  If new fields are specified in the future, the specification of those fields MUST describe whether they can be  <ins> provided by the client.  The server MUST NOT reflect the "onlyReturnExisting" field or any unrecognized fields in the resulting account object.  This allows clients to detect when servers do not support an extension field. </ins> The server SHOULD validate that the contact URLs in the "contact" field are valid and supported by the server.  If the server validates Initial contents: The fields and descriptions defined in account- objects. <ins> | Field Name | Field Type | Requests | Reference | |:-----------------|:-----------|:---------|:-------| ======= | status | string | new, account | RFC 8555 | | contact | array of string | new, account | RFC 8555 | | externalAccountBinding | object | new | RFC 8555 | | termsOfServiceAgreed | boolean | new | RFC 8555 | | onlyReturnExisting | boolean | new | RFC 8555 | | orders | string | none | RFC 8555 | </ins> 9.7.2. The "ACME Order Object Fields" registry lists field names that are


unwilling to issue a certificate corresponding to the submitted CSR. For example: <del> If the order indicated does not have status "ready" </del> If the CSR and order identifiers differ If the account is not authorized for the identifiers indicated in server SHOULD leave the order in the "ready" state, to allow the client to submit a new finalize request with an amended CSR. <del> A request to finalize an order will return the order to be finalized. The client should begin polling the order by sending a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take: </del>  "invalid": The certificate will not be issued.  Consider this order process abandoned.

draft-ietf-acme-acme-18 §7.4 has two conflicting statements regarding what an ACME server should do when it receives a request to finalize an order that is not in the "ready" state: 'If the order indicated does not have status "ready" ... the problem document returned by the server SHOULD use error code "badCSR"'. 'A request to finalize an order will return the order to be finalized. The client should begin polling the order by sending a POST-as-GET request to the order resource to obtain its current state. The status of the order will indicate what action the client should take:', where values other than "ready" are listed. This PR proposes to resolve this conflict by requiring servers to return a new 'badState' error in response to a request to finalize an order that is not in the "ready" state. The client should respond to a "badState" error by re-fetching the order object and examining the status field to determine what to do.
I think a better name for this very specific error would be badOrderState or orderNotReady. That avoids potential confusion with bad states for authzs or challenges. Posted a proposed change in URL
Thanks NAME - this clarification makes sense to me. I'm +1 to applying your diff with the other AUTH48 changes. cc NAME Not really just editorial, but okay.

unwilling to issue a certificate corresponding to the submitted CSR. For example:  If the CSR and order identifiers differ If the account is not authorized for the identifiers indicated in server SHOULD leave the order in the "ready" state, to allow the client to submit a new finalize request with an amended CSR.  <ins> A request to finalize an order will result in error if the order is not in the "ready" state.  In such cases, the server MUST return a 403 (Forbidden) error with a problem document of type "badState". The client should then send a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take (see below). If a request to finalize an order is successful, the server will return a 200 (OK) with an updated order object.  The status of the order will indicate what action the client should take: </ins> "invalid": The certificate will not be issued.  Consider this order process abandoned.


This field MUST be present and true for authorizations created as a result of a newOrder request containing a DNS identifier with a <del> value that contained a wildcard prefix.  For other authorizations, it MUST be absent. </del>  The only type of identifier defined by this specification is a fully qualified domain name (type: "dns").  The domain name MUST be encoded Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects.  If an authorization object <del> conveys authorization for the base domain of a newOrder DNS type identifier with a wildcard prefix, then the optional authorizations "wildcard" field MUST be present with a value of true. </del>  identifier-validation-challenges describes a set of challenges for domain name validation. A request to finalize an order will result in error if the order is not in the "ready" state.  In such cases, the server MUST return a <del> 403 (Forbidden) error with a problem document of type "badState". The client should then send a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take (see below). </del>  If a request to finalize an order is successful, the server will return a 200 (OK) with an updated order object.  The status of the Note that because the identifier in a pre-authorization request is the exact identifier to be included in the authorization object, pre- <del> authorization cannot be used to authorize issuance with wildcard DNS identifiers. </del>  Before processing the authorization request, the server SHOULD determine whether it is willing to issue certificates for the

badState should be orderNotReady Use "wildcard domain name" consistently instead of "wildcard prefix"
Thanks NAME :ballotboxwith_check:

This field MUST be present and true for authorizations created as a result of a newOrder request containing a DNS identifier with a  <ins> value that was a wildcard domain name.  For other authorizations, it MUST be absent.  Wildcard domain names are described in order- objects. </ins> The only type of identifier defined by this specification is a fully qualified domain name (type: "dns").  The domain name MUST be encoded Compatible Encoding prefix "xn--" as defined in RFC5890 are properly encoded.  Wildcard domain names (with "*" as the first label) MUST NOT be included in authorization objects.  If an authorization object  <ins> conveys authorization for the base domain of a newOrder DNS identifier containing a wildcard domain name, then the optional authorizations "wildcard" field MUST be present with a value of true. </ins> identifier-validation-challenges describes a set of challenges for domain name validation. A request to finalize an order will result in error if the order is not in the "ready" state.  In such cases, the server MUST return a  <ins> 403 (Forbidden) error with a problem document of type "orderNotReady".  The client should then send a POST-as-GET request to the order resource to obtain its current state.  The status of the order will indicate what action the client should take (see below). </ins> If a request to finalize an order is successful, the server will return a 200 (OK) with an updated order object.  The status of the Note that because the identifier in a pre-authorization request is the exact identifier to be included in the authorization object, pre-  <ins> authorization cannot be used to authorize issuance of certificates containing wildcard domain names. </ins> Before processing the authorization request, the server SHOULD determine whether it is willing to issue certificates for the


Additional information: <del> Deprecated alias names for this type: n/a Magic number(s): n/a File extension(s): .pem Macintosh file type code(s): n/a </del> Person & email address to contact for further information: See Authors' Addresses section. Field type: The type of value to be provided, e.g., string, boolean, array of string <del> Client configurable: Boolean indicating whether the server should accept values provided by the client </del>  Reference: Where this field is defined

For pem-certificate-chain, the "Addition information" section was getting jumbled all onto one line by the Markdown to HTML generator. The table for Fields in Account Objects was jumbled. In the template for some registries, a field was called "Client configurable" in the next but "Configurable" in the table. Changed to always say "Configurable."

Additional information:  Person & email address to contact for further information: See Authors' Addresses section. Field type: The type of value to be provided, e.g., string, boolean, array of string  <ins> Configurable: Boolean indicating whether the server should accept values provided by the client </ins> Reference: Where this field is defined


prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under that name.  For example, if the domain name being validated is <del> "example.org", then the client would provision the following DNS </del>  record: A client responds with an empty object ({}) to acknowledge that the

Since is consistently used to represent the ACME server, we should always use to represent the ACME client. Whenever there's a single hostname we prefer the variant because the prefix makes it easier to quickly distinguish from . When there are two hostnames we use both and . Since we already used one order ID consistently through the doc, I made sure that its identifiers, notBefore, and notAfter were always the same. I tweaked the "expires" so it would be in a reasonable range (not precisely equal to the notBefore). Note that the "pending" version of the order has a slightly different expires than the "valid" order. One version of the finalized order had a cert ID of jWCdfHVGY2M and another had mAt3xBGaobw. Harmonized on mAt3xBGaobw since it was also used in the certificate retrieval example. Also fixed an accidentally duplicated nonce.
:100:

prepending the label "_acme-challenge" to the domain name being validated, then provisions a TXT record with the digest value under that name.  For example, if the domain name being validated is  <ins> "www.example.org", then the client would provision the following DNS </ins> record: A client responds with an empty object ({}) to acknowledge that the


multiple entities to manage certificates). Authorization resources are created by the server in response to <del> newOrder or newAuthorization requests submitted by an account key holder; their URLs are provided to the client in the responses to these requests.  The authorization object is implicitly tied to the account key used to sign the request. </del>  When a client receives an order from the server in reply to a newOrder request, it downloads the authorization resources by sending

"newAuthorization" -> "newAuthz" Reverted the indentation on the IANA considerations since that resulted in the wrong XML

multiple entities to manage certificates). Authorization resources are created by the server in response to  <ins> newOrder or newAuthz requests submitted by an account key holder; their URLs are provided to the client in the responses to these requests.  The authorization object is implicitly tied to the account key used to sign the request. </ins> When a client receives an order from the server in reply to a newOrder request, it downloads the authorization resources by sending


the server for information about its account (e.g., to examine the "contact" or "certificates" fields), then it SHOULD do so by sending a POST request with an empty update.  That is, it should send a JWS <del> whose payload is trivial ({"resource":"reg"}). </del>  6.3.1. The client needs to respond with information to complete the challenges.  To do this, the client updates the authorization object received from the server by filling in any required information in <del> the elements of the "challenges" dictionary.  For example, if the client wishes to complete the "simpleHttp" challenge, it needs to provide the "path" component.  (This is also the stage where the client should perform any actions required by the challenge.) </del>  The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type, an entity applying for a certificate with a given identifier actually controls that identifier. <del> Challenges provide the server with assurance the an account key </del>  holder is also the entity that controls an identifier.  For each type of challenge, it must be the case that in order for an entity to successfully complete the challenge the entity must both: its control over a domain name by proving that it can provision resources on an HTTP server that responds for that domain name.  The ACME server challenges the client to provision a file with a specific <del> string as its contents. </del>  As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA The string "simpleHttp" <del> The value to be provisioned in the file.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any non-ASCII characters. </del>  A client responds to this challenge by signing a JWS object and provisioning it as a resource on the HTTP server for the domain in question.  The payload of the JWS MUST be a JSON dictionary <del> containing the fields "type", "token", "path", and "tls" from the ACME challenge and response (see below), and no other fields.  If the </del>  "tls" field is not included in the response, then validation object MUST have its "tls" field set to "true".  The JWS MUST be signed with the client's account key pair.  This JWS is NOT REQUIRED to have a HTTPS server. Verify that the Content-Type header of the response is either <del> absent, or has the value "application/jose+json" </del>  <del> Verify that the body of the response is a valid JWS of the type indicated by the Content-Type header (if present), signed with the client's account key </del>  Verify that the payload of the JWS meets the following criteria: * <del> It is a valid JSON dictionary * It has exactly four fields * Its "type" field is set to "simpleHttp" * Its "token" field is equal to the "token" field in the challenge * Its "path" field is equal to the "path" field in the response * Its "tls" field is equal to the "tls" field in the response, or "true" if the "tls" field was absent </del>  <del> Comparisons of the "path" and "token" fields MUST be performed in terms of Unicode code points, taking into account the encodings of the stored nonce and the body of the request. </del>  If all of the above verifications succeed, then the validation is successful.  If the request fails, or the body does not pass these The string "dvsni" <del> A random value with at least 128 bits of entropy, base64-encoded </del>  In response to the challenge, the client uses its account private key to sign a JWS over a JSON object describing the challenge.  The The string "dvsni" <del> A random value with at least 128 bits of entropy, base64-encoded </del>  The client serializes the validation object to UTF-8, then uses its account private key to sign a JWS with the serialized JSON object as The string "dns" <del> A random value with at least 128 bits of entropy.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </del>  In response to this challenge, the client uses its account private key to sign a JWS over a JSON object describing the challenge.  The The string "dns" <del> The token value in the challenge </del>  The client serializes the validation object to UTF-8, then uses its account private key to sign a JWS with the serialized JSON object as

(As part of closing out the letsencrypt/acme-spec repo.)

the server for information about its account (e.g., to examine the "contact" or "certificates" fields), then it SHOULD do so by sending a POST request with an empty update.  That is, it should send a JWS  <ins> whose payload is trivial ({"resource":"reg"}).  In this case the server reply MUST contain the same link headers sent for a new registration, to allow a client to retreive the "new-authorization" and "terms-of-service" URI </ins> 6.3.1. The client needs to respond with information to complete the challenges.  To do this, the client updates the authorization object received from the server by filling in any required information in  <ins> the elements of the "challenges" dictionary.  (This is also the stage where the client should perform any actions required by the challenge.) </ins> The client sends these updates back to the server in the form of a JSON object with the response fields required by the challenge type, an entity applying for a certificate with a given identifier actually controls that identifier.  <ins> Challenges provide the server with assurance that an account key </ins> holder is also the entity that controls an identifier.  For each type of challenge, it must be the case that in order for an entity to successfully complete the challenge the entity must both: its control over a domain name by proving that it can provision resources on an HTTP server that responds for that domain name.  The ACME server challenges the client to provision a file with a specific  <ins> JWS as its contents. </ins> As a domain may resolve to multiple IPv4 and IPv6 addresses, the server will connect to at least one of the hosts found in A and AAAA The string "simpleHttp"  <ins> The value to be used in generation of validation JWS.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </ins> A client responds to this challenge by signing a JWS object and provisioning it as a resource on the HTTP server for the domain in question.  The payload of the JWS MUST be a JSON dictionary  <ins> containing the fields "type", "token", and "tls" from the ACME challenge and response (see below), and no other fields.  If the </ins> "tls" field is not included in the response, then validation object MUST have its "tls" field set to "true".  The JWS MUST be signed with the client's account key pair.  This JWS is NOT REQUIRED to have a HTTPS server. Verify that the Content-Type header of the response is either  <ins> absent, or has the value "application/jose+json". </ins>  <ins> Verify that the body of the response is a valid JWS, signed with the client's account key. </ins> Verify that the payload of the JWS meets the following criteria: *  <ins> it is a valid JSON dictionary; * it has exactly three fields; * its "type" field is set to "simpleHttp"; * its "token" field is equal to the "token" field in the challenge; * its "tls" field is equal to the "tls" field in the response, or "true" if the "tls" field was absent. </ins>  <ins> Comparisons of the "token" field MUST be performed in terms of Unicode code points, taking into account the encodings of the stored nonce and the body of the request. </ins> If all of the above verifications succeed, then the validation is successful.  If the request fails, or the body does not pass these The string "dvsni"  <ins> The value to be used in generation of validation certificate. This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </ins> In response to the challenge, the client uses its account private key to sign a JWS over a JSON object describing the challenge.  The The string "dvsni"  <ins> The token value from the server-provided challenge object </ins> The client serializes the validation object to UTF-8, then uses its account private key to sign a JWS with the serialized JSON object as The string "dns"  <ins> The value to be used in generation of validation record to be provisioned in DNS.  This value MUST have at least 128 bits of entropy, in order to prevent an attacker from guessing it.  It MUST NOT contain any characters outside the URL-safe Base64 alphabet. </ins> In response to this challenge, the client uses its account private key to sign a JWS over a JSON object describing the challenge.  The The string "dns"  <ins> The token value from the server-provided challenge object </ins> The client serializes the validation object to UTF-8, then uses its account private key to sign a JWS with the serialized JSON object as


domain(s). DV certificate validation commonly checks claims about properties <del> related to control of a domain name - properties that can be observed by the certificate issuer in an interactive process that can be conducted purely online.  That means that under typical </del>  circumstances, all steps in the request, verification, and issuance process can be represented and performed by Internet protocols with no out-of-band human intervention. The ACME client periodically contacts the CA to get updated certificates, stapled Online Certificate Status Protocol (OCSP) <del> responses, or whatever else would be required to keep the web server functional and its credentials up to date. </del>  In this way, it would be nearly as easy to deploy with a CA-issued certificate as with a self-signed certificate.  Furthermore, the 4. ACME allows a client to request certificate management actions using <del> a set of JavaScript Object Notation (JSON) messages carried over HTTPS RFC8259 RFC2818.  Issuance using ACME resembles a traditional CA's issuance process, in which a user creates an account, requests a </del>  certificate, and proves control of the domain(s) in that certificate in order for the CA to issue the requested certificate. 6.1. Each ACME function is accomplished by the client sending a sequence <del> of HTTPS requests to the server, carrying JSON messages RFC8259.  Use of HTTPS is REQUIRED.  Each subsection of certificate-management below describes the message formats used by the function and the order in which messages are sent. </del>  In most HTTPS transactions used by ACME, the ACME client is the HTTPS client and the ACME server is the HTTPS server.  The ACME server acts query, since the status of the challenge will not change until that time. <del> Clients can explicitly request a retry by resending their response to a challenge in a new POST request (with a new nonce, etc.).  This </del>  allows clients to request a retry when the state has changed (e.g., after firewall rules have been updated).  Servers SHOULD retry a request immediately on receiving such a POST request.  In order to

Thanks NAME - diff looks fine to me.Looks fine to mepurely editorial, good for me.

domain(s). DV certificate validation commonly checks claims about properties  <ins> related to control of a domain name -- properties that can be observed by the certificate issuer in an interactive process that can be conducted purely online.  That means that under typical </ins> circumstances, all steps in the request, verification, and issuance process can be represented and performed by Internet protocols with no out-of-band human intervention. The ACME client periodically contacts the CA to get updated certificates, stapled Online Certificate Status Protocol (OCSP)  <ins> responses RFC6960, or whatever else would be required to keep the web server functional and its credentials up to date. </ins> In this way, it would be nearly as easy to deploy with a CA-issued certificate as with a self-signed certificate.  Furthermore, the 4. ACME allows a client to request certificate management actions using  <ins> a set of JavaScript Object Notation (JSON) messages RFC8259 carried over HTTPS RFC2818.  Issuance using ACME resembles a traditional CA's issuance process, in which a user creates an account, requests a </ins> certificate, and proves control of the domain(s) in that certificate in order for the CA to issue the requested certificate. 6.1. Each ACME function is accomplished by the client sending a sequence  <ins> of HTTPS requests to the server RFC2818, carrying JSON messages RFC8259.  Use of HTTPS is REQUIRED.  Each subsection of certificate- management below describes the message formats used by the function and the order in which messages are sent. </ins> In most HTTPS transactions used by ACME, the ACME client is the HTTPS client and the ACME server is the HTTPS server.  The ACME server acts query, since the status of the challenge will not change until that time.  <ins> Clients can explicitly request a retry by re-sending their response to a challenge in a new POST request (with a new nonce, etc.).  This </ins> allows clients to request a retry when the state has changed (e.g., after firewall rules have been updated).  Servers SHOULD retry a request immediately on receiving such a POST request.  In order to


can be accessed in a Link header with link relation "terms-of- service".  As noted above, the client may indicate its agreement with these terms by updating its registration to include the "agreement" <del> field, with the terms URI as its value. </del>  If the client wishes to update this information in the future, it sends a POST request with updated information to the registration

I'm not sure whether we should add something like:
I think "in a way that requires an agreement update" as you've written is clear enough. Users won't need to re-agree if just fixing a typographical error.

can be accessed in a Link header with link relation "terms-of- service".  As noted above, the client may indicate its agreement with these terms by updating its registration to include the "agreement"  <ins> field, with the terms URI as its value.  When these terms change in a way that requires an agreement update, the server MUST use a different URI in the Link header. </ins> If the client wishes to update this information in the future, it sends a POST request with updated information to the registration


CAs that use ACME to automate issuance will need to ensure that their servers perform all necessary checks before issuing. <del> 10.  References </del>  <del> 10.1.  URIs </del>  [1] https://github.com/ietf-wg-acme/acme

At the IETF meeting, we discussed the possibility of simplifying the "tls-sni-01" challenge to remove the iterations, as suggested in . NAME noted that if we were going to do that, we should recommend some ways for CAs to check whether a default vhost was in play. This PR adds such a note, and creates an "Operational Considerations" section for any future such notes that might come along.

CAs that use ACME to automate issuance will need to ensure that their servers perform all necessary checks before issuing.  <ins> 10. </ins>  <ins> There are certain factors that arise in operational reality that operators of ACME-based CAs will need to keep in mind when configuring their services. [[ TODO: Other operational considerations ]] 10.1. In many cases, TLS-based services are deployed on hosted platforms that use the Server Name Indication (SNI) TLS extension to distinguish between different hosted services or "virtual hosts". When a client initiates a TLS connection with an SNI value indicating a provisioned host, the hosting platform routes the connection to that host. When a connection come in with an unknown SNI value, one might expect the hosting platform to terminate the TLS connection.  However, some hosting platforms will choose a virtual host to be the "default", and route connections with unknown SNI values to that host. In such cases, the owner of the default virtual host can complete a TLS-based challenge (e.g., "tls-sni-01") for any domain with an A record that points to the hosting platform.  This could result in mis-issuance in cases where there are multiple hosts with different owners resident on the hosting platform. A CA that accepts TLS-based proof of domain control should attempt to check whether a domain is hosted on a domain with a default virtual host before allowing an authorization request for this host to use a TLS-based challenge.  A default virtual host can be detected by initiating TLS connections to the host with random SNI values within the namespace used for the TLS-based challenge (the "acme.invalid" namespace for "tls-sni-01"). 11.  References 11.1.  URIs </ins> [1] https://github.com/ietf-wg-acme/acme


The server provides the following fields as part of the challenge: <del> The string "proofOfPossession-01" </del>  An array of certificates, in Base64url-encoded DER format, that contain acceptable public keys. object including data related to the challenge.  The validation object covered by the signature has the following fields: <del> The string "proofOfPossession" </del>  A list of identifiers for which the holder of the prior key authorizes the new key with a signature over that nonce by one of the private keys requested by the server. <del> The string "proofOfPossession" </del>  The validation JWS Decode the payload of the JWS as UTF-8 encoded JSON Verify that there are exactly three fields in the decoded object, <del> and that: * The "type" field is set to "proofOfPossession" * The </del>  "identifier" field contains the identifier for which authorization is being validated * The "accountKey" field matches the account key for which the challenge was issued

awesome thanks :+1:
Any reason for the inconsistent naming of the challenge types? Specifically vs Wouldn't it make sense to stick to dash delimited words? or just camelCase, not that it matter as long as its consistent. I would personally avoid camelcase in that context since there is already a lot acronyms.

The server provides the following fields as part of the challenge:  <ins> The string "proof-of-possession-01" </ins> An array of certificates, in Base64url-encoded DER format, that contain acceptable public keys. object including data related to the challenge.  The validation object covered by the signature has the following fields:  <ins> The string "proof-of-possession" </ins> A list of identifiers for which the holder of the prior key authorizes the new key with a signature over that nonce by one of the private keys requested by the server.  <ins> The string "proof-of-possession" </ins> The validation JWS Decode the payload of the JWS as UTF-8 encoded JSON Verify that there are exactly three fields in the decoded object,  <ins> and that: * The "type" field is set to "proof-of-possession" * The </ins> "identifier" field contains the identifier for which authorization is being validated * The "accountKey" field matches the account key for which the challenge was issued


In order to help clients configure themselves with the right URIs for each ACME operation, ACME servers provide a directory object.  This <del> should be the root URL with which clients are configured.  It is a JSON dictionary, whose keys are the "resource" values listed in https-requests, and whose values are the URIs used to accomplish the </del>  corresponding function.  Clients access the directory by sending a GET request to the directory URI.

The current wording ("root URL") may lead readers to believe that the ACME directory URI's path is "/", whereas it could actually be anything. Reword to "only URL" and provide examples which emphasize that the choice of the URL for the dictionary object is arbitrary.

In order to help clients configure themselves with the right URIs for each ACME operation, ACME servers provide a directory object.  This  <ins> should be the only URL needed to configure clients.  It is a JSON dictionary, whose keys are the "resource" values listed in https- requests, and whose values are the URIs used to accomplish the </ins> corresponding function. <ins> There is no constraint on the actual URI of the directory except that it should be different from the other ACME server resources' URIs, and that it should not clash with other services.  For instance: a host which function as both an ACME and Web server may want to keep the root path "/" for an HTML "front page", and and place the ACME directory under path "/acme". a host which only functions as an ACME server could place the directory under path "/". </ins> Clients access the directory by sending a GET request to the directory URI.


"pending", "processing", "valid", "invalid" and "revoked".  If this field is missing, then the default value is "pending". <del> The date after which the server will consider this authorization invalid, encoded in the format specified in RFC 3339 RFC3339. </del>  The challenges that the client needs to fulfill in order to prove possession of the identifier (for pending authorizations).  For

Also fixes some RFC3339 timestamps shown in examples, which must include seconds.
Authorization expiry should be a timestamp not a date, to allow for authorizations with very short expiry times. All discussion should be done on the mailing list.

"pending", "processing", "valid", "invalid" and "revoked".  If this field is missing, then the default value is "pending".  <ins> The timestamp after which the server will consider this authorization invalid, encoded in the format specified in RFC 3339 RFC3339. </ins> The challenges that the client needs to fulfill in order to prove possession of the identifier (for pending authorizations).  For


validation query to a server of the attacker's choosing.  There are a few different mitigations that ACME servers can apply: <del> Checking the DNSSEC status of DNS records used in ACME validation (for zones that are DNSSEC-enabled) </del>  Querying the DNS from multiple vantage points to address local attackers the namespace used for the TLS-based challenge (the "acme.invalid" namespace for "tls-sni-01").  11.  References 11.1.  URIs

I approve of this change.
This looks good to me. I would like to tighten up the language a bit to clarify that this applies to validation of DNS identifiers, but will do that in a follow-on PR.

validation query to a server of the attacker's choosing.  There are a few different mitigations that ACME servers can apply:  <ins> Always querying the DNS using a DNSSEC-validating resolver (enhancing security for zones that are DNSSEC-enabled) </ins> Querying the DNS from multiple vantage points to address local attackers the namespace used for the TLS-based challenge (the "acme.invalid" namespace for "tls-sni-01"). <ins> 10.2. An ACME-based CA needs to make DNS lookups when processing challenges.  Because the security of an ACME-based CA ultimately depends entirely on the authenticity of DNS data, every possible precaution should be taken to secure such lookups.  It is therefore RECOMMENDED that ACME-based CAs make all DNS resolutions via DNSSEC- validating stub or recursive resolvers.  This provides additional protection to domains which choose to make use of DNSSEC. An ACME-based CA must use only a resolver if it trusts the resolver and every component of the network route by which it is accessed.  It is therefore RECOMMENDED that ACME-based CAs operate their own DNSSEC-validating resolvers within their trusted network and use these resolvers both for all CAA record lookups and all record lookups in furtherance of a challenge scheme (A, AAAA, TXT, etc.). </ins> 11.  References 11.1.  URIs