Subject: Re: [Acme] AD Review: draft-ietf-acme-acme-12

From: Richard Barnes <[email-masked]>
Date: Tue, 15 May 2018 01:20:14 +0000

[ 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 "[email-masked]" 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 <[email-masked]> 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 "[email-masked]" 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.
>
>

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 15 May 2018 09:37:43 +0300

> relevant here, so I've removed it.  The new TLS-based challenge can re-add

This is incorrect. It is neeed by HTTP-01 already, because that can
redirect to https://, which then tries to set up TLS, which can fail
even when the TCP connection succeeded. And given flakyness of
validation in general, one does not want misleading errors to make
things even harder.

One of the more creative ones I have heard about is misconfigured
servers that interpret the TLS ClientHello as malformed HTTP request
and sends back HTTP 400 Bad Request, which the TLS client then tries
to parse as ServerHello and obviously chokes. This issue is apparently
not that rare, in fact, Let's Encrypt specifically checks for TLS
ServerHellos that look like HTTP replies.

-Ilari

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 25 May 2018 09:08:44 -0700

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

Thanks. I am going to assume the PR is correct and just double-check
in the new draft.

> 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

This seems fine to me.

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

This is about the signatures that ACME accepts, not the signatures
in certs. Does CABF have a position on what signature algorithms
that ACME uses?

"url"
compare
> 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.
> """

Perhaps just a forward reference.

> 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 :)
>

OK.

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

Well, http would also be hard to know what to do.

My semantic question, however was: are these all equivalent and
undifferentiated?

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

OK.

requests
> Agreed.  I've upgraded it to MUST.

Thanks.

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

OK.

field.  Tried to clarify.

LGTM.

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

It seems like the implication of this is that it's not possible to
demand additional validation procedures at this time, however. I
guess that's something one could live with....

> Yes, assuming you mean "issue new certs to this account".  See above
about clarifying this.

OK.

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

OK.

> Kinda, but I think it's fine here.  Tried to edit around it.

OK.

> > experience demonstrates that it has done so,

OK.

> > here. Receiving email at "[email-masked]" is related to the domain

I would have personally said "demonstrating that control" rather than
related, but I agree this is up to the editor.

> > >         required to keep the web server functional and its
credentials up-
self-signed.

OK.

this
> Disagree.  RFC 8174 is an update, not a replacement.

I can see how you would feel that way, but I can tell you that the
IESG is now enforcing this, so you might as well do it now.

valid
not
requested
> I think "An ACME client may run on a web server" is sufficient.

OK.

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

OK.

> > >      ACME servers that are intended to be generally accessible need
to use
> 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?

Yah, mostly.

> > >      base64url encoding described in [RFC4648] Section 5, according
to the
MUST
> 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.

I don't disagree, just hat it should be clear.

result
> https://mailarchive.ietf.org/arch/msg/acme/uFw6U60KXruYohtPluVmW_kQFlE

OK.

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

OK.

> > S 7.3.
> > >
> > >      If the server wishes to present the client with terms under
which the
terms
field
> > Please describe how that happens. Perhaps unify with S 7.3.4.

Hmmmm.. Now I'm unclear. Never mind.

> 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'verevised to be old/new/old, with corresponding prose.

This seems like a pretty material change.

Given the complicated logic, perhaps it would be good to state what
statements we believe each key is attesting to.

> > >      The client requests certificate issuance by sending a POST
request to
> I don't think this level of distinction is needed.

I'm not going to fight about it, but I do think these are different.

either

I'm not pushing for either direction, just clarity.

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

OK.

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

OK.

pending

I don't really agree, but it's an editor decision.

OK.

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

Might be worth clarifying.

> > >      submitted in a finalize request does not contain a public key
for any
not
> Could you elaborate on this?

As I understand it, part of the reason for this is that TLS 1.2 provides
a signing oracle, right?

-Ekr

On Mon, May 14, 2018 at 6:20 PM, Richard Barnes <[email-masked]> wrote:

> You could use something like Certificate Transparency or Censys to
> identify certificates issued by other CAs or by other accounts with this CA.
>
> 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.
> > >
> 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.
> > >
> > >      The client requests certificate issuance by sending a POST
> request to
> >
> 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.
> Network topology, firewalls, etc.  Imagine, for example, an enterprise
> ACME CA that could see internal servers and for some reason had a

---

From: Ryan Sleevi <[email-masked]>
Date: Fri, 25 May 2018 15:06:32 -0400

> in certs. Does CABF have a position on what signature algorithms

The Baseline Requirements do not establish any policies here regarding
proof of key possession (which is not required, strictly speaking) or
domain name validation methods, or on the authentication channel between
the Applicant and CA.

For example, 3.2.2.4.6 of the BRs (at time of writing,
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.5.7-29-Apr-2018.pdf
) allow the use of MD2 or MD4 as part of their request token construction
or within the use of CSRs.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 25 May 2018 16:03:26 -0400

> validation in general, one does not want misleading errors to make

Good point.  I've backed out this change in my working copy.

--Richard

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 27 May 2018 18:11:22 -0700

Forwarding to the list, per Richard.

On Sun, May 27, 2018 at 3:00 PM, Richard Barnes <[email-masked]> wrote:

> Updated PR:
>
> Responses to comments Github: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/710ef835446231ef954b0f6e448718eef04b63fa
> Responses to this email: https://github.com/ietf-wg-
> acme/acme/pull/425/commits/3dd2a10ee55c13ff87772463374a7c0ab4205d5f
>
> Trimming points on which we agree...
>
> On Fri, May 25, 2018 at 12:09 PM Eric Rescorla <[email-masked]> wrote:
>
>> > > IMPORTANT
>> > > S 6.2.
> Good point.  As Ryan pointed out, this is not something on which there is
> currently CABF guidance.
>
> Nonetheless, I'm still disinclined to have MUSTs here for other reasons.
> If they're positive "MUST support" requirements, then we would need to come
> back and revise this document in the event of an algorithm break (though
> admittedly, that would be pretty far down on the TODO list).  And looking
> at the current list of JWS algorithms, I don't see any I would MUST NOT,
> except possibly the ones based on SHA-1.
>
>
>
>>
>>
>> > > S 6.3.
>> > > >      As noted in Section 6.2 above, all ACME request objects carry
>> a "url"
> "Further down" here just means "the next paragraph".  Over that distance,
> I don't think a forward reference is really helpful :)
>
>
>
>>
>> > > S 7.1.2.
>> > > >         initiated deactivation.
>> > > >
> I'm not sure I totally understand the question here, but I think the
> answer is "yes".  Either the server has code to handle a given contact URL
> scheme or it doesn't, in which case unsupportedContact.
>
>
>
>> > > S 7.4.
>> > > >
> I think that's coherent.  Validations only apply to identifiers, not
> things like EKUs.  The identifiers for the certificate should all be listed
> in the newOrder, and thus accounted for in the initial list of
> authorizations.
>
>
>
>>
>> > > S 2.
> Oh I see.  I agree that that's better; edited.
>
>
>
>>
>> > > S 3.
>> > > >
>> > > >   3.  Terminology
>> > > >
> I have updated this to the recommended text that you sent me 1-1.
>
>
>
>>
>> > > S 7.3.6.
>> > > >            "jwk": /* new key */,
> Added:
> To change the key associated with an account, the client sends a
> request to the server containing signatures by both the old and new
> keys.  The signature by the new key covers the account URL and the
> old key, signifying a request by the new key holder to take over the
> account from the old key holder.  The signature by the old key
> covers this request and its signature, and indicates the old key
> holder's assent to the roll-over request.
> """
>
>
>
>> > > S 7.4.
> I'll allow that it's a bit odd that the HTTP response doesn't respond to
> the "request" for certificate issuance.
>
> Revised to: "The client begins the certificate issuance process..."
>
>
>
>> > > S 7.4.
>> > I don't think so, though I'm sympathetic that ordered list comparison
>> is easier to get right than set comparison.
>>
> Added: "(These identifiers may appear in any order.)"
>
>
>>
>> > > S 10.4.
>> > > >
> For example, the ACME server might be able to access servers behind
> a firewall that would prevent access by the ACME client.
> """
>
>
>> > > S 11.1.
> Oh, I see.  Proposed:
> This assures that vulnerabilities in the protocols with which the
> certificate is used (e.g., signing oracles in TLS [JSS15]) do not result
> in
> compromise of the ACME account.
> """
>
>  --Richard
>

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 27 May 2018 20:43:13 -0700

On Sun, May 27, 2018 at 3:00 PM, Richard Barnes <[email-masked]> wrote:

> except possibly the ones based on SHA-1
>

Hmm... Common practice in security protocols is to specify MTI algorithms.
Why is this different?

OK.

> scheme or it doesn't, in which case unsupportedContact.

This doesn't seem entirely clear:
1. What do I send to the HTTP URI, if anything? What method do I use?
2. If there is >1 URI, are they all semantically equivalent.

> in the newOrder, and thus accounted for in the initial list of

Well, I could certainly imagine that you would need some extra level of
something (whether you call it validation or not) to get a certificate with
certain EKUs.

> ""

OK

> a firewall that would prevent access by the ACME client.

OK

> compromise of the ACME account.

OK

-Ekr

"""

---

From: Russ Housley <[email-masked]>
Date: Tue, 29 May 2018 00:57:37 -0400

Eric:

> Good point.  As Ryan pointed out, this is not something on which there is currently CABF guidance.
> 
> Nonetheless, I'm still disinclined to have MUSTs here for other reasons.  If they're positive "MUST support" requirements, then we would need to come back and revise this document in the event of an algorithm break (though admittedly, that would be pretty far down on the TODO list).  And looking at the current list of JWS algorithms, I don't see any I would MUST NOT, except possibly the ones based on SHA-1
> 
> Hmm... Common practice in security protocols is to specify MTI algorithms. Why is this different?

PKIX chose not to specify mandatory-to-implement algorithms.  This was done because the application that made use of the certificate needed to be able to impose such requirements.

Here is one place from the PKIX WG archive in 2011 that states this approach:

   (https://mailarchive.ietf.org/arch/msg/pkix/blSByMc7SysNNvkFlsFdcrFLrIs <https://mailarchive.ietf.org/arch/msg/pkix/blSByMc7SysNNvkFlsFdcrFLrIs>)

   PKIX defines PKI specs for a very wide range of apps, which is why we
   do not mandate any alg suite.  Different apps may use different alg suites.
   TLS, S/MIME, IPsec, SeND, etc. each gets to choose MTE algs for itself.

It seems to me that ACME is being used to support certificate enrollment for many different applications, so the same approach seems appropriate.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 29 May 2018 13:01:01 -0700

On Mon, May 28, 2018 at 9:57 PM, Russ Housley <[email-masked]> wrote:

> PKIX chose not to specify mandatory-to-implement algorithms.  This was
> done because the application that made use of the certificate needed to be
> able to impose such requirements.
>
>    (https://mailarchive.ietf.org/arch/msg/pkix/blSByMc7SysNNvkFlsFdcrFLrIs
> )
>
> It seems to me that ACME is being used to support certificate enrollment
> for many different applications, so the same approach seems appropriate.
>

Hmm... This seems like it would be more persuasive if there weren't a
dependency on TLS and its MTI algorithms

>From my perspective, this is sort of on the bubble. Historically, I've seen
the IESG insist on MTI algorithms, but it's not consistent. I would like to
understand if this is something that has strong consensus in the WG, in
which case I'll support that (though other IESG members may feel
differently) or if it just happened, in which case I'd ask the WG to
reconsider.
-Ekr

---

From: Richard Barnes <[email-masked]>
Date: Wed, 30 May 2018 14:25:01 -0400

On Tue, May 29, 2018 at 4:02 PM Eric Rescorla <[email-masked]> wrote:

>>> Nonetheless, I'm still disinclined to have MUSTs here for other
>>> reasons.  If they're positive "MUST support" requirements, then we would
>>> need to come back and revise this document in the event of an algorithm
>>> break (though admittedly, that would be pretty far down on the TODO list).
>>> And looking at the current list of JWS algorithms, I don't see any I would
>>> MUST NOT, except possibly the ones based on SHA-1
>>>
>>
>>    (
>> https://mailarchive.ietf.org/arch/msg/pkix/blSByMc7SysNNvkFlsFdcrFLrIs)
>>
> From my perspective, this is sort of on the bubble. Historically, I've
> seen the IESG insist on MTI algorithms, but it's not consistent. I would
> like to understand if this is something that has strong consensus in the
> WG, in which case I'll support that (though other IESG members may feel

I think it's more in the latter category in the former, but TBH, I think
that kind of argues in favor of the status quo -- we have a fair bit of
implementation / deployment experience, and this has not been an interop
problem.

In a similar vein, where we have had discussion of versioning (a similar
issue) there's been consensus *not* to go the traditional route of having
version numbers -- you just have to know what version of ACME the endpoint
you're talking to speaks.  It doesn't seem totally crazy to me for the same
to be true of the signing algorithms you use.

I guess I don't really know what value you're solving for here.  Just to
try to make this concrete, if you were going to propose some algorithms to
be MTI / MTnotI, what would you list?

--Richard

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 May 2018 18:45:29 +0000

I believe the working group has decided that MTI algorithms are not necessary.  If you want that confirmed on the list, we can ask.  ACME isn’t just WebPKI, as you know, it’s also becoming STIR and some have proposed home environments.

We have many implementations to serve as proof points that MTI isn’t required in the Real World.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 May 2018 12:41:30 -0700

On Wed, May 30, 2018 at 11:25 AM, Richard Barnes <[email-masked]> wrote:

>>>    (https://mailarchive.ietf.org/arch/msg/pkix/
>>> blSByMc7SysNNvkFlsFdcrFLrIs)
>>>

Well, we have a fair bit of experience of a lot of people talking to Let's
Encrypt. That's not really the same as a lot of servers and a lot of
clients.

> I guess I don't really know what value you're solving for here
>

I'm not sure what's confusing. The IETF has traditionally required MTI
algorithms to ensure that there is a baseline that allows two
implementations to talk to each other. We spent an enormous amount of time
on this in RTCWEB, so it's not exactly ancient history.

.  Just to try to make this concrete, if you were going to propose some
> algorithms to be MTI / MTnotI, what would you list?
>

I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with X25519.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 May 2018 12:42:40 -0700

On Wed, May 30, 2018 at 11:45 AM, Salz, Rich <[email-masked]> wrote:

> I believe the working group has decided that MTI algorithms are not
> necessary.  If you want that confirmed on the list, we can ask.
>

Yes, please ask. If I'm going to tell the IESG that no MTI is needed, I
want to tell them that the WG had consensus.

  ACME isn’t just WebPKI, as you know, it’s also becoming STIR and some
> have proposed home environments.
>
>
>

As I said to Richard, it seems like much of the interop is between clients
and LE. It's not hard to get interop when one side is fixed.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 May 2018 19:56:57 +0000

*   Well, we have a fair bit of experience of a lot of people talking to Let's Encrypt. That's not really the same as a lot of servers and a lot of clients.

We have multiple CA’s that support it, and other implementations as well.  Certainly LE dominates, but it’s not the only usage.  And certainly not the only anticipated future usage.

  *   I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with X25519.

That would make the MTI limited to a subset of the WebPKI supported by the latest browsers, which seems wrong.  But let’s not bikeshed too much and see what the WG consensus is.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 30 May 2018 13:05:39 -0700

On Wed, May 30, 2018 at 12:56 PM, Salz, Rich <[email-masked]> wrote:

>
>    - Well, we have a fair bit of experience of a lot of people talking to
>    Let's Encrypt. That's not really the same as a lot of servers and a lot of
>    clients.
>
>
>
> We have multiple CA’s that support it, and other implementations as well.
> Certainly LE dominates, but it’s not the only usage.  And certainly not the
> only anticipated future usage.
>

Right. And the purpose of the MTI is usually to make future interop work
better.

>
>
>    - I would match the TLS ones: MUST ECDSA with P-256, SHOULD EdDSA with
>    X25519.
>
>
>
> That would make the MTI limited to a subset of the WebPKI supported by the
> latest browsers, which seems wrong.  But let’s not bikeshed too much and
> see what the WG consensus is.
>

I'm not following your point here. Remember, I'm not talking about the MTI
for what the *certs* contain, but rather for what the protocol uses for its
in-protocol signatures. There's no reason you can't use an ECDSA key to
authorize issuance of an RSA cert (Which would presumably be in a
self-signed PKCS#10 blob with RSA), or for that matter, an XMSS cert.

The reason I chose those values is because you're already tied to TLS for
the communications and therefore you necessarily have the TLS MTI cipher
suites, which means you already have those algorithms.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 30 May 2018 20:16:40 +0000

*   The reason I chose those values is because you're already tied to TLS for the communications and therefore you necessarily have the TLS MTI cipher suites, which means you already have those algorithms.

If your toolkit exposes it.  If your toolkit is a black box or scripted such as CURL, you might as well have the message signatures be what your ultimate certificates are gonna be.  That was the point I was trying to make.

---

From: Daniel McCarney <[email-masked]>
Date: Wed, 30 May 2018 16:23:56 -0400

> We have multiple CA’s that support it, and other implementations as well.

Of the multiple CAs that support ACME, which support something resembling
the current draft? When I looked last the non-Let's Encrypt ACME server
implementations all seemed to be targeting Certbot and the "ACMEv1" era of
this draft (e.g. are not using the order based issuance flow at all). There
have been substantial backwards compatibility breaking changes in the draft
since this time.

I second EKR's sentiment that there has been little true ACME inter-op
testing of the protocol as described in draft-12 outside of that done with
Let's Encrypts ACMEv2 endpoint.

- Daniel / cpu

On Wed, May 30, 2018 at 3:56 PM, Salz, Rich <
rsalz=[email-masked]> wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>
>