[ Adding the mailing list ] Thanks for the thorough review, EKR. I've posted a PR with proposed resolutions:
https://github.com/ietf-wg-acme/acme/pull/425 You do hit on a couple of moderately technical points, some of which I would like the WG to take a quick look at. Those are highlighted with "DISCUSS" below. Simple edits are tagged with "EDIT", and questions for the AD are marked with "QUESTION". Ones where I don't think there's a need for a change are unmarked. Rather than split things out into separate PRs, I've just made one big PR, with issues in different commits. The various issue tags below include the ID of the corresponding commits. Chairs / AD: While there are a couple of issues here where I'd like some eyes besides the authors, I would propose that if we do a re-WGLC, it be abbreviated, say 1 week. I do not think these changes merit a new IETF LC. Thanks, --Richard > Because I am now the sponsoring AD for this document, I have performed > my own review. > > This document seems technically sound and is well-written. I have > raised a number of points below for consideration. > > > IMPORTANT > S 6.2. > > algorithm in its "alg" field > > > > o The JWS Payload MUST NOT be detached > > o The JWS Protected Header MUST include the following fields: > > > > * "alg" (Algorithm) > > Do you want to specify a set of acceptable signature algorithms here? I am inclined not to. We have already forbidden "none" and MAC. We shouldn't specify "MUST"s here, because CABF sets their own list of required algorithms, and we don't want to conflict. I guess you could specify some MUST NOTs pretty safely, but given that they're already forbidden by CABF, it seems kind of duplicative. > S 6.3. > > As noted in Section 6.2 above, all ACME request objects carry a "url" > > header parameter in their protected header. This header parameter > > encodes the URL to which the client is directing the request. On > > receiving such an object in an HTTP request, the server MUST compare > > the "url" header parameter to the request URL. If the two do not > > match, then the server MUST reject the request as unauthorized. > > I think you probably need to provide a clear definition of how you > "compare" them. Is it memcmp? Something else? This is specified further down: """ 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. """ > S 6.4.1. > > > > The value of the Replay-Nonce field MUST be an octet string encoded > > according to the base64url encoding described in Section 2 of > > [RFC7515]. Clients MUST ignore invalid Replay-Nonce values. > > > > base64url = [A-Z] / [a-z] / [0-9] / "-" / "_" > > I am surprised you need to define the BNF for this here. Aren't you > now creating a separate normative definition. I can see why this is surprising. After a bit of searching, though, I can't find another set of ABNF that matches. For example, RFC 5802 (SASL SCRAM) defines its own ABNF for Base64 (in the normal "+/=" encoding), as does RFC 8224 (SIP Identity). I note that the list of authors on the latter includes a certain Mr. Rescorla :) https://tools.ietf.org/html/rfc5802#section-7 https://tools.ietf.org/html/rfc8224#section-4 > S 7.1.2. > > initiated deactivation. > > > > contact (optional, array of string): An array of URLs that the > > server can use to contact the client for issues related to this > > account. For example, the server may wish to notify the client > > about server-initiated revocation or certificate expiration. > > How am I supposed to know the semantics of these strings? And if they > are non-mailto URLs, what am I supposed to do with them. To first order, the semantic is defined by the scheme of the URL -- "mailto" says "email me", "sip" or "tel" says "give me a call", etc. We have the "unsupportedContact" error type if the server doesn't know how to leverage a given scheme. Of course there are URL schemes that don't make sense as a contact point (e.g., "data:"), but trying to enumerate those seems quixotic. Better for the CA to check and reject with the error code we have provided. > S 7.1.3. > > authorizations required are dictated by server policy and there > > may not be a 1:1 relationship between the order identifiers and > > the authorizations required. For final orders (in the "valid" or > > "invalid" state), the authorizations that were completed. Each > > entry is a URL from which an authorization can be fetched with a > > GET request. > > This text seems inconsistent with "immutable" below, because if I have > completed authorization "a" then I don't need to complete it, but it > has to stay in the list. [[ EDIT - f4d421d ]] I don't think this is inconsistent -- the client needs to have fulfilled all the listed authorizations, even if it has done so before submitting this order. I've reworded to clarify this, and to clarify that servers can re-use authorizations if they choose. > S 7.2. > > > > 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 SHOULD also respond to GET requests > > for this resource, returning an empty body (while still providing a > > This SHOULD doesn't seem that helpful for interop. I would make it a > MUST or remove it. [[ EDIT - b13a049 ]] Agreed. I've upgraded it to MUST. > S 7.3.1. > > > > If the server already has an account registered with the provided > > account key, then it MUST return a response with a 200 (OK) status > > code and provide the URL of that account in the Location header > > field. This allows a client that has an account key but not the > > corresponding account URL to recover the account URL. > > Do I update the account with new values? [[ DISCUSS - 17e7b9f ]] Because of the differences in how fields are handled between account creation and update (e.g., w.r.t. TOS), it'll be far simpler to ignore any udpates. There's a slight developer ergonomics cost here, since you can't do a single request for "see if it exists, and if so update it". But the simplicity seems worthwhile. Nonetheless, it's worth being clear on this. I've proposed a clarification.. > S 7.3.5. > > JWS) > > > > If all of these checks pass and the CA creates a new account, then > > the CA may consider the new account associated with the external > > account corresponding to the MAC key and MUST reflect the value of > > the "externalAccountBinding" field in the resulting account object.. > > What does "MUST reflect" mean? That it contains the binding field? > Something else? [[ EDIT - f4d421d ]] Yes, I think the idea here is that the account object contains the eAB field. Tried to clarify. > S 7.4. > > > > The order object returned by the server represents a promise that if > > the client fulfills the server's requirements before the "expires" > > time, then the server will be willing to finalize the order upon > > request and issue the requested certificate. In the order object, > > any authorization referenced in the "authorizations" array whose > > What if the CSR contains extensions which are not mentioned here? For > instance, say I request a given EKU that the CA doesn't like? Or the > DelegatedUsage extension from https://tools.ietf.org/html/draft-ietf- > tls-subcerts-00#section-4.1 [[ DISCUSS - 1e9937c ]] This is an unforutunate consequence of not providing the CSR up front. It seems like the right outcome here is for the finalization request to fail. It's unclear to me whether the order should also be invalidated. I think my proposal would be to fail the finalization, but leave the order open, and the client can re-try with a CSR that the server might like better. > S 7.4.1. > > servers may also wish to enable clients to obtain authorization for > > an identifier proactively, outside of the context of a specific > > issuance. For example, a client hosting virtual servers for a > > collection of names might wish to obtain authorization before any > > virtual servers are created and only create a certificate when a > > virtual server starts up. > > Can servers cache one authorization so that they can issue new certs > for the same identity with no new authorizations? Yes, assuming you mean "issue new certs to this account". See above about clarifying this. > S 7.6. > > revoked: > > > > certificate (required, string): The certificate to be revoked, in > > the base64url-encoded version of the DER format. (Note: Because > > this field uses base64url, and does not include headers, it is > > different from PEM.) > > If I have lost the cert, I can't revoke? So, what happens if I have > issued hundreds of certificates with the same key pair (e.g., to > hosts) and then I lose they key. I don't see a way to list the keys. You are correct that with this revocation mechanism, you need the certificate, and there is no mechanism in ACME to easily identify certificates containing a given public key. It is possible, however, to enumerate *all* of the certificates this account has issued, using the "orders" array in the account object. Using scripting against that, you could fetch all the certificates you have issued, then look through those to see which ones you want to revoke. You could use something like Certificate Transparency or Censys to identify certificates issued by other CAs or by other accounts with this CA. So I think we're OK here. > COMMENTS > S 1. > > legitimately represents the domain name(s) in the certificate. > > > > 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. For > > DV validation, the CA merely verifies that the requester has > > Isn't "DV validation" redundant? [[ EDIT - f4d421d ]] Kinda, but I think it's fine here. Tried to edit around it. > S 1. > > certificate issuance, deployment, and revocation. > > > > This document describes an extensible framework for automating the > > issuance and domain validation procedure, thereby allowing servers > > and infrastructural software to obtain certificates without user > > interaction. Use of this protocol should radically simplify the > > I think at this point you might be able to claim that operational > experience demonstrates that it has done so, I'm OK with this as-is. > S 2. > > o In the background, the ACME client contacts the CA and requests > > that it issue a certificate for the intended domain name(s). > > > > o The CA verifies that the client controls the requested domain > > name(s) by having the ACME client perform some action related to > > the domain name(s). > > I know this text is informal but perhaps something sharper is required > here. Receiving email at "j...@example.org" is related to the domain > name. [[ EDIT - f4d421d ]] > S 2. > > certificates, stapled OCSP responses, or whatever else would be > > required to keep the web server functional and its credentials up- > > to-date. > > > > In this way, it would be nearly as easy to deploy with a CA-issued > > certificate as with a self-signed certificate. Furthermore, the > > Again, perhaps present tense. Disagree. Using ACME isn't always quite as easy as deploying with self-signed. > S 3. > > > > 3. Terminology > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in RFC 2119 [RFC2119]. > > Regrettably, it is time to cite 8174. Disagree. RFC 8174 is an update, not a replacement. > S 3. > > server, mail server, or some other server system which requires valid > > TLS certificates. Or, it may run on a separate server that does not > > consume the certificate, but is authorized to respond to a CA- > > provided challenge. The ACME server runs at a certification > > authority, and responds to client requests, performing the requested > > actions if the client is authorized. > > You should point out here that "client" and "server" are not being > used in the conventional sense for the Web, and that in this case the > Web server is the ACME client. I think "An ACME client may run on a web server" is sufficient. > S 3. > > consume the certificate, but is authorized to respond to a CA- > > provided challenge. The ACME server runs at a certification > > authority, and responds to client requests, performing the requested > > actions if the client is authorized. > > > > An ACME client is represented by an "account key pair". The client > > Nit: instead of "represented by" "uses an account key pair to > authenticate"? [[ EDIT - f4d421d ]] > S 4. > > Client Server > > > > Contact Information > > ToS Agreement > > Additional Data > > Signature -------> > > It would be helpful to somehow bracket the material which is signed. > [] perhaps? [[ EDIT - 3a9b8c9 ]] > S 4. > > Contact Information > > ToS Agreement > > Additional Data > > Signature -------> > > > > <------- Account > > I doubt the server is sending back an Account. Perhaps an Account id? > Or just an ack? [[ EDIT - 3a9b8c9 ]] > S 6.1. > > > > 6.1. HTTPS Requests > > > > Each ACME function is accomplished by the client sending a sequence > > of HTTPS requests to the server, carrying JSON messages > > [RFC2818][RFC7159]. Use of HTTPS is REQUIRED. Each subsection of > > Isn't this sentence redundant with the previous graf? The previous paragraph is a summary, this is the actual requirement. > S 6.1. > > (see Section 6.4). > > > > ACME clients MUST send a User-Agent header, in accordance with > > [RFC7231]. This header SHOULD include the name and version of the > > ACME software in addition to the name and version of the underlying > > HTTP client software. > > Why are you requiring this at 2119 MUST? This was discussed in the WG, I think suggested by Tim Hollebeek. It's useful to servers for debugging, and there were no concerns raised with requiring its inclusion. https://github.com/ietf-wg-acme/acme/pull/420/files > S 6.1. > > [RFC7231] to enable localization of error messages. > > > > ACME servers that are intended to be generally accessible need to use > > Cross-Origin Resource Sharing (CORS) in order to be accessible from > > browser-based clients [W3C.CR-cors-20130129]. Such servers SHOULD > > set the Access-Control-Allow-Origin header field to the value "*". > > Can you give an example of when a browser-based client would do ACME? [[ QUESTION ]] When the client is "semi-automated", in the sense that it onyl provides the ACME interface, not the validation parts. See, e.g., < https://gethttpsforfree.com/>. Do you think that needs to go here? Or are you just asking whether this provision is needed? > S 6.1. > > > > Binary fields in the JSON objects used by ACME are encoded using > > base64url encoding described in [RFC4648] Section 5, according to the > > profile specified in JSON Web Signature [RFC7515] Section 2. This > > encoding uses a URL safe character set. Trailing '=' characters MUST > > be stripped. > > Should implementations accept trailing =? [[ DISCUSS - 89bbf9c ]] No. It seems a little developer-hostile to have everything fail if your base64 library is slightly off, but it'll fail fast, and it's a small fix. > S 6.2. > > o The JWS Unencoded Payload Option [RFC7797] MUST NOT be used > > > > o The JWS Unprotected Header [RFC7515] MUST NOT be used > > > > o The JWS MUST NOT have a Message Authentication Code (MAC)-based > > algorithm in its "alg" field > > Nit: I suggest moving this up next to "none" [[ EDIT - f4d421d ]] > S 6.2. > > algorithm in its "alg" field > > > > o The JWS Payload MUST NOT be detached > > o The JWS Protected Header MUST include the following fields: > > > > * "alg" (Algorithm) > > Actually, maybe just put the "alg" levies here? [[ EDIT - f4d421d ]] > S 6.2. > > * "nonce" (defined in Section 6.4 below) > > > > * "url" (defined in Section 6.3 below) > > > > The "jwk" and "kid" fields are mutually exclusive. Servers MUST > > reject requests that contain both. > > I propose taking "jwk" and "kid" out of this list and instead merging > all their discussion into the following paragraph "For newAccount..." [[ EDIT - f4d421d ]] > S 6.2. > > > > If the client sends a JWS signed with an algorithm that the server > > does not support, then the server MUST return an error with status > > code 400 (Bad Request) and type > > "urn:ietf:params:acme:error:badSignatureAlgorithm". The problem > > document returned with the error MUST include an "algorithms" field > > This is your first use of "problem document" so a citation or > explanation would be appropriate. [[ EDIT - f4d421d ]] > S 6.6. > > | | | > > | serverInternal | The server experienced an internal | > > | | error | > > | | | > > | tls | The server received a TLS error during | > > | | validation | > > Can you expand on what this means? Suppose instead I got a 500 during > validation? [[ EDIT - 272c754 ]] I think this goes back to when the TLS-SNI challenge. It's no longer relevant here, so I've removed it. The new TLS-based challenge can re-add it if they need it. > S 7.1. > > +-----------------------+--------------------------+----------------+ > > | Action | Request | Response | > > +-----------------------+--------------------------+----------------+ > > | Get directory | GET directory | 200 | > > | | | | > > | Get nonce | HEAD newNonce | 200 | > > This HEAD is surprising. What's the reason for that? The nonce is provided in a header, so only a HEAD request is necessary. See above about GET, though. > S 7.1.3. > > "pending" or "valid" in the status field. > > > > identifiers (required, array of object): An array of identifier > > objects that the order pertains to. > > > > type (required, string): The type of identifier. > > Can you point to the list of current types. [[ EDIT - f4d421d ]] > S 7.1.4. > > > > value (required, string): The identifier itself. > > > > status (required, string): The status of this authorization. > > Possible values are: "pending", "valid", "invalid", "deactivated", > > "expired", and "revoked". > > What do each of these mean? [[ EDIT - f4d421d ]] Added references to {{status-changes}} to this and other status fields. > S 7.1.4. > > sufficient to make the authorization valid. > > > > 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. > > Out of curiousity, why does the "wildcard" flag exist? There was pretty robust mailing list discussion: https://mailarchive.ietf.org/arch/msg/acme/uFw6U60KXruYohtPluVmW_kQFlE > S 7.1.4. > > of a newOrder request containing a DNS identifier with a value > > that contained a wildcard prefix this field MUST be present, and > > true. > > > > The only type of identifier defined by this specification is a fully- > > qualified domain name (type: "dns"). If a domain name contains non- > > Why are you just defining "type" here. [[ EDIT - f4d421d ]] > S 7.1.6. > > | | | > > | | | > > Server | Client | Time after | > > revoke | deactivate | "expires" | > > V V V > > revoked deactivated expired > > Why would the server revoke a challenge? [[ EDIT - 3a9b8c9 ]] This diagram is about authorizations, not challenges. (An authorization might be revoked if, say, the server found out that the client had obtained it fraudulently.) I've added figure captions to clarify. > S 7.3. > > > > If the server wishes to present the client with terms under which the > > ACME service is to be used, it MUST indicate the URL where such terms > > can be accessed in the "termsOfService" subfield of the "meta" field > > in the directory object, and the server MUST reject new-account > > requests that do not have the "termsOfServiceAgreed" field set to > > Please describe how that happens. Perhaps unify with S 7.3.4. [[ QUESTION ]] How what happens? > S 7.3.2. > > If the client wishes to update this information in the future, it > > sends a POST request with updated information to the account URL. > > The server MUST ignore any updates to the "orders" field or any other > > fields it does not recognize. If the server accepts the update, it > > MUST return a response with a 200 (OK) status code and the resulting > > account object. > > You should reiterate here that you cannot set the terms of service bit [[ EDIT - 487977b ]] > S 7.3.5. > > > > 4. Verify that the MAC on the JWS verifies using that MAC key > > > > 5. Verify that the payload of the JWS represents the same key as was > > used to verify the outer JWS (i.e., the "jwk" field of the outer > > JWS) > > You should probably at some point walk through that this is each key > blessing the other. [[ EDIT - 8f50f84 ]] > S 7.3.6. > > "jwk": /* new key */, > > "url": "https://example.com/acme/key-change"; > > }), > > "payload": base64url({ > > "account": "https://example.com/acme/acct/1";, > > "newKey": /* new key */ > > You should explain why the newKey and jwk fields both exist, given > that they have to be identical [[ DISCUSS - 8f50f84 ]] I think this is a legacy of when we switched the order of old/new. It used to be new/old/new, then someone observed that it would be nice to always have the outer signature be with the current account key, so we swapped the outer two and ended up with old/new/new. I've revised to be old/new/old, with corresponding prose. > S 7.3.6. > > > > 7. Check that the "account" field of the key-change object contains > > the URL for the account matching the old key. > > > > 8. Check that the "newKey" field of the key-change object also > > verifies the inner JWS. > > Don't you mean that it is identical to the jwk field? Addressed by the above. > S 7.3.6. > > corresponding account by replacing the old account key with the new > > public key and returns status code 200 (OK). Otherwise, the server > > responds with an error status code and a problem document describing > > the error. If there is an existing account with the new key > > provided, then the server SHOULD use status code 409 (Conflict) and > > provide the URL of that account in the Location header field. > > You should probably explain the reasoning here: old key endorses new > key but not vice versa [[ EDIT - 8f50f84 ]] > S 7.4. > > certificates. ACME does not provide a way to reactivate a > > deactivated account. > > > > 7.4. Applying for Certificate Issuance > > > > The client requests certificate issuance by sending a POST request to > > This probably could be revised to indicate that it's not actually > requesting issuance immediately, but the server's promise of issuance. I don't think this level of distinction is needed. > S 7.4. > > The CSR encodes the client's requests with regard to the content of > > the certificate to be issued. The CSR MUST indicate the exact same > > set of requested identifiers as the initial new-order request, either > > in the commonName portion of the requested subject name, or in an > > extensionRequest attribute [RFC2985] requesting a subjectAltName > > extension. > > Must it be in the same order? [[ DISCUSS - no change ]] I don't think so, though I'm sympathetic that ordered list comparison is easier to get right than set comparison. > S 7.4.1. > > } > > > > Note that because the identifier in a pre-authorization request is > > the exact identifier to be included in the authorization object, pre- > > authorization cannot be used to authorize issuance with wildcard DNS > > identifiers. > > Why does this restriction exist? Authorizations talk about concrete identifiers you can validate. You can't validate a wildcard. Instead, you validate some set of concrete names that the server provides when you submit an order. > S 7.5. > > process assures the server of two things: > > > > 1. That the client controls the private key of the account key pair, > > and > > > > 2. That the client controls the identifier in question. > > And that the client wants to prove that, no? By the time you're at the authorization stage, the client has already submitted an explicit request for authorization, which implies that it wants to prove possession. > S 7.5. > > 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 > > authorization object in the response to that request. > > > > GET /acme/authz/1234 HTTP/1.1 > > "For example..." Don't think it's necessary to introduce the example. It's just a GET. Figure captions will help. > S 7.5.1. > > "nonce": "Q_s3MWoqT05TrdkM2MTDcw", > > "url": "https://example.com/acme/authz/1234/0"; > > }), > > "payload": base64url({}), > > "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" > > } > > What are the semantics here? "I want to do this challenge"? Yes, among the options provided by the server, with the implication, "You should attempt to validate this challenge now". > S 9.7.8. > > When evaluating a request for an assignment in this registry, the > > designated expert should ensure that the method being registered has > > a clear, interoperable definition and does not overlap with existing > > validation methods. That is, it should not be possible for a client > > and server to follow the same set of actions to fulfill two different > > validation methods. > > You may want to explain why these are reserved. [[ EDIT - f4d421d ]] > S 10.2. > > on the identifier validation challenges to ensure that the challenge > > can only be completed by someone who both (1) holds the private key > > of the account key pair, and (2) controls the identifier in question. > > > > Validation responses need to be bound to an account key pair in order > > to avoid situations where an ACME MitM can switch out a legitimate > > Its not an ACME MITM, right? It's a TLS MITM. If it's an ACME MITM, > you should explain how you got there). [[ EDIT - f4d421d ]] > S 10.2. > > provisioned by the legitimate domain holder > > > > o Because the challenges were issued in response to a message signed > > account key B, the ACME server grants authorization to account key > > B (the MitM) instead of account key A (the legitimate domain > > holder) > > A ladder diagram would help here. [[ EDIT - f4d421d ]] > S 10.2. > > transaction. For example, suppose an ACME server follows HTTP > > redirects in HTTP validation and a website operator provisions a > > catch-all redirect rule that redirects requests for unknown resources > > to a different domain. Then the target of the redirect could use > > that to get a certificate through HTTP validation since the > > validation path will not be known to the primary server. > > ACME has no defense against this, right? Just "don't host on those?? Yes. > S 10.4. > > > > Some server implementations include information from the validation > > server's response (in order to facilitate debugging). Such > > implementations enable an attacker to extract this information from > > any web server that is accessible to the ACME server, even if it is > > not accessible to the ACME client. > > For network topology reasons, primairlY? Network topology, firewalls, etc. Imagine, for example, an enterprise ACME CA that could see internal servers and for some reason had a publicly-addressable ACME interface. > S 11.1. > > certificate. ACME clients and servers SHOULD verify that a CSR > > submitted in a finalize request does not contain a public key for any > > known account key pair. In particular, when a server receives a > > finalize request, it MUST verify that the public key in a CSR is not > > the same as the public key of the account key pair used to > > authenticate that request. > > Do you want to mention TLS signing oracles? [[ QUESTION ]] Could you elaborate on this? > S 12. > > > > o Martin Thomson, Mozilla > > > > o Jakub Warmuz, University of Oxford > > > > o Sophie Herold, Hemio > > Do you want to credit Karthik Bhargavan and Andrew Ayers who both made > important technical contributions. [[ EDIT - f4d421d ]] On Fri, May 11, 2018 at 8:48 PM Eric Rescorla <e...@rtfm.com> wrote: > Rich version of this review at: > https://mozphab-ietf.devsvcdev.mozaws.net/D4266 > > > Because I am now the sponsoring AD for this document, I have performed > my own review. > > This document seems technically sound and is well-written. I have > raised a number of points below for consideration. > > > IMPORTANT > S 6.2. > > algorithm in its "alg" field > > > > o The JWS Payload MUST NOT be detached > > o The JWS Protected Header MUST include the following fields: > > > > * "alg" (Algorithm) > > Do you want to specify a set of acceptable signature algorithms here? > > > S 6.3. > > As noted in Section 6.2 above, all ACME request objects carry a > "url" > > header parameter in their protected header. This header parameter > > encodes the URL to which the client is directing the request. On > > receiving such an object in an HTTP request, the server MUST compare > > the "url" header parameter to the request URL. If the two do not > > match, then the server MUST reject the request as unauthorized. > > I think you probably need to provide a clear definition of how you > "compare" them. Is it memcmp? Something else? > > > S 6.4.1. > > > > The value of the Replay-Nonce field MUST be an octet string encoded > > according to the base64url encoding described in Section 2 of > > [RFC7515]. Clients MUST ignore invalid Replay-Nonce values. > > > > base64url = [A-Z] / [a-z] / [0-9] / "-" / "_" > > I am surprised you need to define the BNF for this here. Aren't you > now creating a separate normative definition. > > > S 7.1.2. > > initiated deactivation. > > > > contact (optional, array of string): An array of URLs that the > > server can use to contact the client for issues related to this > > account. For example, the server may wish to notify the client > > about server-initiated revocation or certificate expiration. > > How am I supposed to know the semantics of these strings? And if they > are non-mailto URLs, what am I supposed to do with them. > > > S 7.1.3. > > authorizations required are dictated by server policy and there > > may not be a 1:1 relationship between the order identifiers and > > the authorizations required. For final orders (in the "valid" or > > "invalid" state), the authorizations that were completed. Each > > entry is a URL from which an authorization can be fetched with a > > GET request. > > This text seems inconsistent with "immutable" below, because if I have > completed authorization "a" then I don't need to complete it, but it > has to stay in the list. > > > S 7.2. > > > > 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 SHOULD also respond to GET > requests > > for this resource, returning an empty body (while still providing a > > This SHOULD doesn't seem that helpful for interop. I would make it a > MUST or remove it. > > > S 7.3.1. > > > > If the server already has an account registered with the provided > > account key, then it MUST return a response with a 200 (OK) status > > code and provide the URL of that account in the Location header > > field. This allows a client that has an account key but not the > > corresponding account URL to recover the account URL. > > Do I update the account with new values? > > > S 7.3.5. > > JWS) > > > > If all of these checks pass and the CA creates a new account, then > > the CA may consider the new account associated with the external > > account corresponding to the MAC key and MUST reflect the value of > > the "externalAccountBinding" field in the resulting account object.. > > What does "MUST reflect" mean? That it contains the binding field? > Something else? > > > S 7.4. > > > > The order object returned by the server represents a promise that if > > the client fulfills the server's requirements before the "expires" > > time, then the server will be willing to finalize the order upon > > request and issue the requested certificate. In the order object, > > any authorization referenced in the "authorizations" array whose > > What if the CSR contains extensions which are not mentioned here? For > instance, say I request a given EKU that the CA doesn't like? Or the > DelegatedUsage extension from https://tools.ietf.org/html/draft-ietf- > tls-subcerts-00#section-4.1 > > > S 7.4.1. > > servers may also wish to enable clients to obtain authorization for > > an identifier proactively, outside of the context of a specific > > issuance. For example, a client hosting virtual servers for a > > collection of names might wish to obtain authorization before any > > virtual servers are created and only create a certificate when a > > virtual server starts up. > > Can servers cache one authorization so that they can issue new certs > for the same identity with no new authorizations? > > > S 7.6. > > revoked: > > > > certificate (required, string): The certificate to be revoked, in > > the base64url-encoded version of the DER format. (Note: Because > > this field uses base64url, and does not include headers, it is > > different from PEM.) > > If I have lost the cert, I can't revoke? So, what happens if I have > issued hundreds of certificates with the same key pair (e.g., to > hosts) and then I lose they key. I don't see a way to list the keys. > > > COMMENTS > S 1. > > legitimately represents the domain name(s) in the certificate. > > > > 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. For > > DV validation, the CA merely verifies that the requester has > > Isn't "DV validation" redundant? > > > S 1. > > certificate issuance, deployment, and revocation. > > > > This document describes an extensible framework for automating the > > issuance and domain validation procedure, thereby allowing servers > > and infrastructural software to obtain certificates without user > > interaction. Use of this protocol should radically simplify the > > I think at this point you might be able to claim that operational > experience demonstrates that it has done so, > > > S 2. > > o In the background, the ACME client contacts the CA and requests > > that it issue a certificate for the intended domain name(s). > > > > o The CA verifies that the client controls the requested domain > > name(s) by having the ACME client perform some action related to > > the domain name(s). > > I know this text is informal but perhaps something sharper is required > here. Receiving email at "j...@example.org" is related to the domain > name. > > > S 2. > > certificates, stapled OCSP responses, or whatever else would be > > required to keep the web server functional and its credentials > up- > > to-date. > > > > In this way, it would be nearly as easy to deploy with a CA-issued > > certificate as with a self-signed certificate. Furthermore, the > > Again, perhaps present tense. > > > S 3. > > > > 3. Terminology > > > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this > > document are to be interpreted as described in RFC 2119 [RFC2119]. > > Regrettably, it is time to cite 8174. > > > S 3. > > server, mail server, or some other server system which requires > valid > > TLS certificates. Or, it may run on a separate server that does not > > consume the certificate, but is authorized to respond to a CA- > > provided challenge. The ACME server runs at a certification > > authority, and responds to client requests, performing the requested > > actions if the client is authorized. > > You should point out here that "client" and "server" are not being > used in the conventional sense for the Web, and that in this case the > Web server is the ACME client. > > > S 3. > > consume the certificate, but is authorized to respond to a CA- > > provided challenge. The ACME server runs at a certification > > authority, and responds to client requests, performing the requested > > actions if the client is authorized. > > > > An ACME client is represented by an "account key pair". The client > > Nit: instead of "represented by" "uses an account key pair to > authenticate"? > > > S 4. > > Client Server > > > > Contact Information > > ToS Agreement > > Additional Data > > Signature -------> > > It would be helpful to somehow bracket the material which is signed. > [] perhaps? > > > S 4. > > Contact Information > > ToS Agreement > > Additional Data > > Signature -------> > > > > <------- Account > > I doubt the server is sending back an Account. Perhaps an Account id? > Or just an ack? > > > S 6.1. > > > > 6.1. HTTPS Requests > > > > Each ACME function is accomplished by the client sending a sequence > > of HTTPS requests to the server, carrying JSON messages > > [RFC2818][RFC7159]. Use of HTTPS is REQUIRED. Each subsection of > > Isn't this sentence redundant with the previous graf? > > > S 6.1. > > (see Section 6.4). > > > > ACME clients MUST send a User-Agent header, in accordance with > > [RFC7231]. This header SHOULD include the name and version of the > > ACME software in addition to the name and version of the underlying > > HTTP client software. > > Why are you requiring this at 2119 MUST? > > > S 6.1. > > [RFC7231] to enable localization of error messages. > > > > ACME servers that are intended to be generally accessible need to > use > > Cross-Origin Resource Sharing (CORS) in order to be accessible from > > browser-based clients [W3C.CR-cors-20130129]. Such servers SHOULD > > set the Access-Control-Allow-Origin header field to the value "*". > > Can you give an example of when a browser-based client would do ACME? > > > S 6.1. > > > > Binary fields in the JSON objects used by ACME are encoded using > > base64url encoding described in [RFC4648] Section 5, according to > the > > profile specified in JSON Web Signature [RFC7515] Section 2. This > > encoding uses a URL safe character set. Trailing '=' characters > MUST > > be stripped. > > Should implementations accept trailing =? > > > S 6.2. > > o The JWS Unencoded Payload Option [RFC7797] MUST NOT be used > > > > o The JWS Unprotected Header [RFC7515] MUST NOT be used > > > > o The JWS MUST NOT have a Message Authentication Code (MAC)-based > > algorithm in its "alg" field > > Nit: I suggest moving this up next to "none" > > > S 6.2. > > algorithm in its "alg" field > > > > o The JWS Payload MUST NOT be detached > > o The JWS Protected Header MUST include the following fields: > > > > * "alg" (Algorithm) > > Actually, maybe just put the "alg" levies here? > > > > S 6.2. > > * "nonce" (defined in Section 6.4 below) > > > > * "url" (defined in Section 6.3 below) > > > > The "jwk" and "kid" fields are mutually exclusive. Servers MUST > > reject requests that contain both. > > I propose taking "jwk" and "kid" out of this list and instead merging > all their discussion into the following paragraph "For newAccount..." > > > S 6.2. > > > > If the client sends a JWS signed with an algorithm that the server > > does not support, then the server MUST return an error with status > > code 400 (Bad Request) and type > > "urn:ietf:params:acme:error:badSignatureAlgorithm". The problem > > document returned with the error MUST include an "algorithms" field > > This is your first use of "problem document" so a citation or > explanation would be appropriate. > > > S 6.6. > > | | > | > > | serverInternal | The server experienced an internal > | > > | | error > | > > | | > | > > | tls | The server received a TLS error during > | > > | | validation > | > > Can you expand on what this means? Suppose instead I got a 500 during > validation? > > > S 7.1. > > > +-----------------------+--------------------------+----------------+ > > | Action | Request | Response > | > > > +-----------------------+--------------------------+----------------+ > > | Get directory | GET directory | 200 > | > > | | | > | > > | Get nonce | HEAD newNonce | 200 > | > > This HEAD is surprising. What's the reason for that? > > > S 7.1.3. > > "pending" or "valid" in the status field. > > > > identifiers (required, array of object): An array of identifier > > objects that the order pertains to. > > > > type (required, string): The type of identifier. > > Can you point to the list of current types. > > > S 7.1.4. > > > > value (required, string): The identifier itself. > > > > status (required, string): The status of this authorization. > > Possible values are: "pending", "valid", "invalid", > "deactivated", > > "expired", and "revoked". > > What do each of these mean? > > > S 7.1.4. > > sufficient to make the authorization valid. > > > > 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. > > Out of curiousity, why does the "wildcard" flag exist? > > > S 7.1.4. > > of a newOrder request containing a DNS identifier with a value > > that contained a wildcard prefix this field MUST be present, and > > true. > > > > The only type of identifier defined by this specification is a > fully- > > qualified domain name (type: "dns"). If a domain name contains non- > > Why are you just defining "type" here. > > > S 7.1.6. > > | | | > > | | | > > Server | Client | Time after | > > revoke | deactivate | "expires" | > > V V V > > revoked deactivated expired > > Why would the server revoke a challenge? > > > S 7.3. > > > > If the server wishes to present the client with terms under which > the > > ACME service is to be used, it MUST indicate the URL where such > terms > > can be accessed in the "termsOfService" subfield of the "meta" field > > in the directory object, and the server MUST reject new-account > > requests that do not have the "termsOfServiceAgreed" field set to > > Please describe how that happens. Perhaps unify with S 7.3.4. > > > S 7.3.2. > > If the client wishes to update this information in the future, it > > sends a POST request with updated information to the account URL. > > The server MUST ignore any updates to the "orders" field or any > other > > fields it does not recognize. If the server accepts the update, it > > MUST return a response with a 200 (OK) status code and the resulting > > account object. > > You should reiterate here that you cannot set the terms of service bit > > > S 7.3.5. > > > > 4. Verify that the MAC on the JWS verifies using that MAC key > > > > 5. Verify that the payload of the JWS represents the same key as > was > > used to verify the outer JWS (i.e., the "jwk" field of the outer > > JWS) > > You should probably at some point walk through that this is each key > blessing the other. > > > S 7.3.6. > > "jwk": /* new key */, > > "url": "https://example.com/acme/key-change"; > > }), > > "payload": base64url({ > > "account": "https://example.com/acme/acct/1";, > > "newKey": /* new key */ > > You should explain why the newKey and jwk fields both exist, given > that they have to be identical > > > S 7.3.6. > > > > 7. Check that the "account" field of the key-change object contains > > the URL for the account matching the old key. > > > > 8. Check that the "newKey" field of the key-change object also > > verifies the inner JWS. > > Don't you mean that it is identical to the jwk field? > > > S 7.3.6. > > corresponding account by replacing the old account key with the new > > public key and returns status code 200 (OK). Otherwise, the server > > responds with an error status code and a problem document describing > > the error. If there is an existing account with the new key > > provided, then the server SHOULD use status code 409 (Conflict) and > > provide the URL of that account in the Location header field. > > You should probably explain the reasoning here: old key endorses new > key but not vice versa > > > S 7.4. > > certificates. ACME does not provide a way to reactivate a > > deactivated account. > > > > 7.4. Applying for Certificate Issuance > > > > The client requests certificate issuance by sending a POST request > to > > This probably could be revised to indicate that it's not actually > requesting issuance immediately, but the server's promise of issuance. > > > S 7.4. > > The CSR encodes the client's requests with regard to the content of > > the certificate to be issued. The CSR MUST indicate the exact same > > set of requested identifiers as the initial new-order request, > either > > in the commonName portion of the requested subject name, or in an > > extensionRequest attribute [RFC2985] requesting a subjectAltName > > extension. > > Must it be in the same order? > > > S 7.4.1. > > } > > > > Note that because the identifier in a pre-authorization request is > > the exact identifier to be included in the authorization object, > pre- > > authorization cannot be used to authorize issuance with wildcard DNS > > identifiers. > > Why does this restriction exist? > > > S 7.5. > > process assures the server of two things: > > > > 1. That the client controls the private key of the account key > pair, > > and > > > > 2. That the client controls the identifier in question. > > And that the client wants to prove that, no? > > > S 7.5. > > 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 > > authorization object in the response to that request. > > > > GET /acme/authz/1234 HTTP/1.1 > > "For example..." > > > S 7.5.1. > > "nonce": "Q_s3MWoqT05TrdkM2MTDcw", > > "url": "https://example.com/acme/authz/1234/0"; > > }), > > "payload": base64url({}), > > "signature": "9cbg5JO1Gf5YLjjz...SpkUfcdPai9uVYYQ" > > } > > What are the semantics here? "I want to do this challenge"? > > > S 9.7.8. > > When evaluating a request for an assignment in this registry, the > > designated expert should ensure that the method being registered has > > a clear, interoperable definition and does not overlap with existing > > validation methods. That is, it should not be possible for a client > > and server to follow the same set of actions to fulfill two > different > > validation methods. > > You may want to explain why these are reserved. > > > S 10.2. > > on the identifier validation challenges to ensure that the challenge > > can only be completed by someone who both (1) holds the private key > > of the account key pair, and (2) controls the identifier in > question. > > > > Validation responses need to be bound to an account key pair in > order > > to avoid situations where an ACME MitM can switch out a legitimate > > Its not an ACME MITM, right? It's a TLS MITM. If it's an ACME MITM, > you should explain how you got there). > > > S 10.2. > > provisioned by the legitimate domain holder > > > > o Because the challenges were issued in response to a message > signed > > account key B, the ACME server grants authorization to account > key > > B (the MitM) instead of account key A (the legitimate domain > > holder) > > A ladder diagram would help here. > > > S 10.2. > > transaction. For example, suppose an ACME server follows HTTP > > redirects in HTTP validation and a website operator provisions a > > catch-all redirect rule that redirects requests for unknown > resources > > to a different domain. Then the target of the redirect could use > > that to get a certificate through HTTP validation since the > > validation path will not be known to the primary server. > > ACME has no defense against this, right? Just "don't host on those?? > > > S 10.4. > > > > Some server implementations include information from the validation > > server's response (in order to facilitate debugging). Such > > implementations enable an attacker to extract this information from > > any web server that is accessible to the ACME server, even if it is > > not accessible to the ACME client. > > For network topology reasons, primairlY? > > > S 11.1. > > certificate. ACME clients and servers SHOULD verify that a CSR > > submitted in a finalize request does not contain a public key for > any > > known account key pair. In particular, when a server receives a > > finalize request, it MUST verify that the public key in a CSR is not > > the same as the public key of the account key pair used to > > authenticate that request. > > Do you want to mention TLS signing oracles? > > > S 12. > > > > o Martin Thomson, Mozilla > > > > o Jakub Warmuz, University of Oxford > > > > o Sophie Herold, Hemio > > Do you want to credit Karthik Bhargavan and Andrew Ayers who both made > important technical contributions. > >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
