Automatic Certificate Management Environment (ACME)
draft-ietf-acme-acme-18

[Ballot comment]
Thanks for all the work that everyone has put into this protocol, and
especially for the work that went into addressing the privacy issue that I
identified. I'm excited by what ACME been able to do for the certificate
issuance sector as a whole, and truly appreciate all of the early implementors
who have put both clients and servers into active production.

[Ballot comment]
Thanks for addressing my Discuss and other points; as promised, I'm
switching to Yes.  (But I support Adam's discuss and look forward to seeing
it come to a close as well.)

This document was quite easy to read -- thank you for the clear prose and
document structure!  It did leave me with some questions as to whether
there are missing clarifications, though, so there are a pile of notes in
the section-by-section comments below.

It seems natural to feel some unease when the concept of automated
certificate issuance like this comes up.  As far as I can tell, though,
the only substantive difference between this flow and the flow it's
replacing is that this one qualitatively feels like it weakens the "know
your customer" aspect for the CA -- with current/legacy methods registering
for an account can be slow and involves real-world information.  Such can
be spoofed/forged, of course, but ACME seems to be weakening some aspect by
automating it.  Given the spoofability, though, this weakening does not
seem to be a particular concern with the document.

I was going to suggest mentioning the potential for future work in doing
time-delayed or periodic revalidation or other schemes to look at the
stability of the way that identifiers/challenges were validated, but I see
that discussion has already happened.

It's probably worth going over the examples and checking whether nonce
values are repeated in ways that are inconsistent with expected usage.  For
example, I see these three values appearing multiple times (but I did not
cross-check if a nonce returned in the Replay-Nonce response header was
then used in a JWS header attribute):
      2 K60BWPrMQG9SDxBDS_xtSw
      3 IXVHDyxIRGcTE0VSblhPzw
      4 JHb54aT_KTXBWQOzGYkt9A

Perhaps the examples could be offset by a description of what they are?
(They would probably also benefit from a disclaimer that the whitespace in
the JSON is for ease of reading only.)

Section-by-section comments follow.

Abstract (also Introduction)

If I read "authentication of domain names" with no context, I would be more
likely to think of the sort of challenge/authorization process that this
document describes, than I would be to think of using an X.509 certificate
to authenticate myself as being the owner of a given domain name.  But it's
unclear whether there's an alternative phrasing that would be better.

Section 1

  Different types of certificates reflect different kinds of CA
  verification of information about the certificate subject.  "Domain
  Validation" (DV) certificates are by far the most common type.  The
  only validation the CA is required to perform in the DV issuance
  process is to verify that the requester has effective control of the
  domain.

Can we get an (informative) ref for the "required"/requirements?

Section 6.1

W3C.CR-cors-2013-0129 shows up as "outdated" when I follow the link.

Section 6.2

IMPORTANT: The JSON Web Signature and Encryption Algorithms registry does
not appear to include an explicit indicator of whether an algorithm is
MAC-based; do we need to include text on how to make such a determination?

Section 6.3

For servers following the "SHOULD ... string equality check" and for
requests where the equality check fails, does that fall into the "MUST
reject the request as unauthorized" bucket?

Section 6.4

  In order to protect ACME resources from any possible replay attacks,
  ACME requests have a mandatory anti-replay mechanism.

We don't seem to actually define what an "ACME request" is that I can see.
From context, this requirement only applies to JWS POST bodies, and not to,
say, newNonce, but I wonder if some clarification would be useful.

IMPORTANT: How tightly are these nonces scoped?  Are they only good on a
specific TLS connection?  Bound to an account key pair?  Globally valid?
(This is not a DISCUSS point because AFAICT there is no loss in security if
the nonce space is global to the server.)

Section 6.6

IMPORTANT: Providing an accountDoesNotExist error type probably means we
need to give guidance that the server should choose account URLs in a
non-guessable way, to avoid account enumeration attacks.

  [...] Servers
  MUST NOT use the ACME URN namespace Section 9.6 for errors other than
  the standard types.

"standard" as determined by inclusion in this document, or in the IANA
registry?

Section 7.1

The "up" link relation for going from certificate to chain seems to only be
needed for alternate content types that can only represent a single
certificate.  (Also, the "alternate" link relation is used to provide
alternate certifciation chains.)  Could this text be made more clear?

Presumably this is just my confusion, but what does "GET order certificate"
mean?

Section 7.1.1

  [...] It is a JSON
  object, whose field names are drawn from the following table and
  whose values are the corresponding URLs.

Er, from the IANA registry, right?

  The following metadata items are defined, all of which are OPTIONAL:

Maybe also refer to the registry?

Section 7.1.2

IMPORTANT: I'm unclear if the "contact" is supposed to be a "talk to a
human" thing or not.  If there are supposed to be different URLs that are
used for different purposes, wouldn't more metadata be needed about them?
So it seems most likely that this is indeed "talk to a human", in which
case that might be worth mentioning.  (Are these always going to be
mailto:?)

Section 7.1.2.1

IMPORTANT: Am I reading this correctly that the GET to the orders URL does
not require the client to be authenticated, in effect relying on
security-through-obscurity (of the account URL) for indicating which
account is trying to order certificates for which identifiers?

Section 7.1.4

  challenges (required, array of objects):  For pending authorizations,
      the challenges that the client can fulfill in order to prove
      possession of the identifier.  For final authorizations (in the
      "valid" or "invalid" state), the challenges that were used.  Each
      array entry is an object with parameters required to validate the
      challenge.  A client should attempt to fulfill one of these
      challenges, and a server should consider any one of the challenges
      sufficient to make the authorization valid.

This leaves me slightly confused.  A final authorization can have multiple
challenges.  But a client should only attempt to fulfill one, and a server
should treat any one as sufficient.  So I can only get to the case with
multiple challenges present in a final order of both "should"s are
violated?  Is there a way for the server to express that multiple
challenges are going to be required?
Hmm, but Section 7.1.6's flow chart for Authorization objects says that a
single challenge's transition to valid also makes the authorization
transition to valid, which would seem to close the window?
Section 7.5.1 has inline text that implicitly assumes that only one
challenge will be completed/validated.

  wildcard (optional, boolean):  For authorizations created as a result
      of a newOrder request containing a DNS identifier with a value
      that contained a wildcard prefix this field MUST be present, and
      true.

Is there a difference between false and absent?

Section 7.3

  A client creates a new account with the server by sending a POST
  request to the server's new-account URL.  The body of the request is
  a stub account object optionally containing the "contact" and
  "termsOfServiceAgreed" fields.

Given that we go on to describe those two and also the optional
onlyReturnExisting and externalAccountBinding fields, does this list need
expanding?

IMPORTANT: How does the client know if a termsOfService in the directory is
actually required or just optional?  (There doesn't seem to be a dedicated
error type for this?)  The text as-is seems to only say that if the server
requires it, the field must be present in the directory, but not the other
way around.  I guess Section 7.3.4 describes the procedure for a similar
case; should the same thing happen for the original terms acceptance?

IMPORTANT: The example response uses what appears to be a sequential
counter for account ID in the returned account URL, which loses any sort of
security-through-obscurity protections if those were desired.  Should a
more opaque URL component be present, maybe a UUID?  (The "orders" field
would need to be modified accordingly, of course, and this pattern appears
in later examples, as well.)

Section 7.3.2

It's a little unclear to me whether the fields the client can put in the
POST are the ones listed from Section 7.3 or 7.1.2, or the full set from
the registry.  But presumably the server must ignore the "status" field,
too, or at least some values should be disallowed!  The IANA registry's
"configurable" column may not quite be the right thing for this usage,
especially given how account deactivation works.

Section 7.3.5

  The server MAY require a value for the "externalAccountBinding" field
  to be present in "newAccount" requests.

All requests including queries for the current status and modification of
existing accounts?  Or just creation of new ones?

  To enable ACME account binding, the CA operating the ACME server
  needs to provide the ACME client with a MAC key and a key identifier,
  using some mechanism outside of ACME.

This key needs to also be tied to the external account in question, right?
One might even say that it is provided not to the ACME client, but to the
external account holder, who is also running an ACME client.

  [...] The payload of
  this JWS is the account key being registered, in JWK form.

This is presumably my fault and not the document's, but I had to read this
a few time to bind it as the ACME account key, and not the external MAC
key.

  If a CA requires that new-account requests contain an
  "externalAccountBinding" field, then it MUST provide the value "true"
  in the "externalAccountRequired" subfield of the "meta" field in the
  directory object.  If the CA receives a new-account request without [...]

nit: maybe "If such a CA"?

IMPORTANT: I don't think I understand why "nonce" MUST NOT be present in
the external-binding JWS object, though I think I understand why one is not
needed in order to bind the MAC to the current transaction.  (That is, this
is in effect a "triply nested" construct, where a standalone MAC that
certifies an ACME account (public) key as being authorized by the
external-account holder to act on behal of that external account.  But this
standalone MAC will only be accepted by the ACME server in the context of
the outer JWS POST, that must be signed by the ACME account key, which is
assumed to be kept secure by the ACME client, ensuring that both
key-holding entities agree to the account linkage.)  Proof of freshness of
the commitment from the external account holder to authorize the ACME
account key would only be needed if there was a scenario where the external
account holder would revoke that association, which does not seem to be a
workflow supported by this document.  Any need to effectuate such a
revocation seems like it would involve issuing a new MAC key for the
external account (and invalidating the old one), and revoking/deactivating
the ACME account, which is a somewhat heavy hammer but perhaps reasonable
for such a scenario.
Account key rollover just says that the nonce is NOT REQUIRED, and also
uses some nicer (to me) language about "outer JWS" and "inner JWS".  It
might be nice to synchronize these two sections.

Section 7.3.7

IMPORTANT: The "url" in this example looks like an account URL, not an
account-deactivation url.  If they are one and the same, please include
some body text to this effect as is done for account update in Section
7.3.2.

Section 7.4

Is Section 7.1.3 or the registry a better reference for the request
payload's fields?

Does the exact-match policy (e.g., on notBefore and notAfter) result in CA
maximum lifetime policies needing to be hardcoded in client software (as
opposed to being discoverable at runtime)?

(I like the order url in the example, "[...]/order/asdf".  Not much entropy
though.)

IMPORTANT: Why does the example response include an identifier of
www.example.com that was not in the request?

Is the "order's requested identifiers appear in commonName or
subjectAltName" requirement an exclusive or?

After a valid request to finalize has been issued, are "pending" or "ready"
still valid statuses that could be returned for that order?

Section 7.4.1

Elsewhere when we list "identifier (required, object)" in a JWS payload we
also inline the "type" and "value" breakdown of the object.

How is "expires" set for this pre-authorization object?

We probably need a reference for "certificate chain as defined in TLS".

Section 7.5

"When a client receives an order from the server" is a bit jarring without
some additional context of "in a reply to a new-order request" or "an order
object" or similar.

Section 7.5.1

  To do this, the client updates the authorization object received from
  the server by filling in any required information in the elements of
  the "challenges" dictionary.

"challenges" looks like an array of objects, not directly a dictionary with
elements within it.

Section 8

IMPORTANT: What do I do if I get a challenge object that has status "valid"
but also includes an "error" field?

Section 8.1

  [...] A key authorization is a string that expresses
  a domain holder's authorization for a specified key to satisfy a
  specified challenge, [...]

I'm going to quibble with the language here and say that the
keyAuthorization string as defined does not express a specific
authorization for a specific challenge, since there is no signature
involved, and the JWK thumbprint is separable and can be attached to some
other token.  (This may just be an editorial matter with no broader impact,
depending on how it's used.)  One could perhaps argue that the mere
existence of the token constitutes an authorization for a specified key to
satisfy the challenge, since the token only gets generated upon receipt of
such an authorized request.

Section 8.3

I'm not sure that 4086 is a great cite, here.  For example, in RFC 8446 we
say that "TLS requires a [CSPRNG].  In most case, the operating system
provides an appropriate facility [...] Should these prove unsatisfactory,
[RFC4086] provides guidance on the generation of random values."  On the
other hand, citing 4086 like this is not wrong, so use your judgment.

  4.  Verify that the body of the response is well-formed key
      authorization.  The server SHOULD ignore whitespace characters at
      the end of the body.

nit: "a well-formed"

Can we get some justification for the "SHOULD follow redirects", given the
security considerations surrounding doing so?

Section 8.4

Should this "token" description include the same text about entropy as for
the HTTP challenge?

Section 9.7.1

There is perhaps some subtlety here, in that the "configurable" column
applies only to the new-account request, but its description in the
template does not reflect that restriction.  In particular, "status" values
from the client *are* accepted when posted to the account URL, e.g., for
account deactivation.


Section 10.1

Can there be overlap between the "validation server" function and the "ACME
client" function?

Section 10.2

  [...] The key authorization reflects the
  account public key, is provided to the server in the validation
  response over the validation channel and signed afterwards by the
  corresponding private key in the challenge response over the ACME
  channel.

I'm stumbling up around the comma trying to parse this sentence.  (Maybe a
serial comma or using "and is signed" would help?)
IMPORTANT: Also, I don't see where the key authorization is signed in the
challenge response -- the payload is just an empty object for both the HTTP
and DNS challenges' responses.

Some of this text sounds like we're implicitly placing requirements on all
(HTTP|DNS) server operators (not just ones trying to use ACME) to mitgate
the risks being described.  In general this sort of behavior seems like an
anti-design-pattern, though perhaps one could argue that the behaviors in
question should be avoided in general, indepnedent of ACME.

Section 10.4

  Some server implementations include information from the validation
  server's response (in order to facilitate debugging).  Such

Disambiguating "ACME server implementations" may help, since we talk about
other HTTP requests in the previous paragraph.

Section 11.1

IMPORTANT: This may be an appropriate place to recommend against reuse of
account keys, whether after an account gets deactivated or by cycling
through keys in a sequence of key-change operations (or otherwise).  I
think there are some attack scenarios possible wherein (inner) JWS objects
could be replayed against a different account, if such key reuse occurs.

Section 11.3

  The http-01, and dns-01 validation methods mandate the usage of a

nit: spurious comma.

  [...] Secondly, the entropy requirement
  prevents ACME clients from implementing a "naive" validation server
  that automatically replies to challenges without participating in the
  creation of the initial authorization request.

IMPORTANT: I'm not sure I see how this applies to the HTTP mechanism --
couldn't you write a script to reply to .well-known/acme-challenge/
with . for a fixed key thumbprint?  The validation
server would ned to know about the ACME account in question, but not about
any individual authorization request.

[Ballot comment]
(Happy with the changes in -15)

Thank you for this very important document. As you've addressed my comments, I am balloting "Yes". However I am looking forward to seeing resolution of Adam's DISCUSS.

A few remaining comments:

First mentions of JSON and HTTPS need references.

[Ballot comment]
Thank you for this very important document. As you've addressed my comments, I am balloting "Yes". However I am looking forward to seeing resolution of Adam's DISCUSS.

A few remaining comments:

First mentions of JSON and HTTPS need references.

[Ballot discuss]
Thanks for all the work that everyone has put into this protocol. I'm excited by
what it's been able to do for the certificate issuance sector as a whole, and
truly appreciate all of the early implementors who have put both clients and
servers into active production. I'm definitely balloting YES once we get clarity
on my DISCUSS, below.

---------------------------------------------------------------------------

I've looked at this several different ways, and I must be missing something
obvious -- which should make this easy to clear.

§6.2:

>  Note that authentication via signed JWS request bodies implies that
>  GET requests are not authenticated.  Servers MUST NOT respond to GET
>  requests for resources that might be considered sensitive.  Account
>  resources are the only sensitive resources defined in this
>  specification.

This doesn't seem correct.

For example, let's imagine that I, as a user, get the directory for an ACME
server, the body of which is the example in §7.1.1. Then, I go through the
new-account process, and receive the Account object in §7.1.2:

  {
    "status": "valid",
    "contact": [
      "mailto:cert-admin@example.com",
      "mailto:admin@example.com"
    ],
    "termsOfServiceAgreed": true,
    "orders": "https://example.com/acme/acct/1/orders"
  }

Huh. Suddenly, I'm not so interested in *my* orders, because I've noticed that
different users' orders are apparently at a predictable URL that varies only by
a small integer. Curious, I change the "1" to a "2" and send:

  GET /acme/acct/2/orders HTTP/1.1
  Host: example.com

And get back not *my* orders, but someone *else's* orders.

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "orders": [
      "https://example.com/acme/acct/2/order/1",
      "https://example.com/acme/acct/2/order/2",
      "https://example.com/acme/acct/2/order/3",
      "https://example.com/acme/acct/2/order/4"
    ]
  }

Interesting. So now I can do four more unauthenticated GETs and grab those order
objects.

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "status": "valid",
    ...
    "identifiers": [
      { "type": "dns", "value": "smithforcongress.example" }
    ],
    ...
    "certificate": "https://example.com/acme/cert/1234"
  }
----------
  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "status": "valid",
    ...
    "identifiers": [
      { "type": "dns", "value": "something-embarassing-with-goats.example" }
    ],
    ...
    "certificate": "https://example.com/acme/cert/5678"
  }
----------
  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "status": "valid",
    ...
    "identifiers": [
      { "type": "email", "value": "smith-personal@obscure-domain.example" }
    ],
    ...
    "certificate": "https://example.com/acme/cert/9abc"
  }
----------
  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "status": "valid",
    ...
    "identifiers": [
      { "type": "tn", "value": "+12025550172" }
    ],
    ...
    "certificate": "https://example.com/acme/cert/defg"
  }

So now I've learned that the same account has pulled certs for both
"smithforcongress.example" and "something-embarassing-with-goats.example"; that
they have control over the email address
"smith-personal@obscure-domain.example," and that their phone number is +1 202
555 0172. There's a pretty good chance that... someone didn't want all of that
to be generally known.

Clearly I've missed something, because this just seems way too obvious. What
prevents this attack (or a similar one from observing that the order URLs are
predictable?)

If I *haven't* missed something, then there appears to have been an assumption
here, never written into the document, that the URLs generated for the orders
list and for the order objects are unguessable. If that's the case, I would:

(1) Expect this to be stated in section 7.1.2.1 and 7.1.3

(2) Expect a specification of a reasonable number of bits of entropy to use in
    orders list and order object URLs.

(3) Expect the examples to show appropriately random URLs (e.g.
    https://example.com/acme/acct/9258fac3-7866-4922-90e6-bbd0c89e751a/orders)


(4) Expect a treatment in section 10 of the risks that might arise from third
    parties gaining access to orders, as doing so provides free-and-clear access
    to private certificates (which, for dns, can be trivially used to
    revoke certs; and for other types, can be used for impersonation as well)

Again, I'm still expecting that I've simply missed something obvious -- I just
can't for the life of me figure out what it is.

[Ballot discuss]
Thanks for all the work that everyone has put into this protocol. I'm excited by
what it's been able to do for the certificate issuance sector as a whole, and
truly appreciate all of the early implementors who have put both clients and
servers into active production. I'm definitely balloting YES once we get clarity
on my DISCUSS, below.

---------------------------------------------------------------------------

I've looked at this several different ways, and I must be missing something
obvious -- which should make this easy to clear.

§6.2:

>  Note that authentication via signed JWS request bodies implies that
>  GET requests are not authenticated.  Servers MUST NOT respond to GET
>  requests for resources that might be considered sensitive.  Account
>  resources are the only sensitive resources defined in this
>  specification.

This doesn't seem correct.

For example, let's imagine that I, as a user, get the directory for an ACME
server, the body of which is the example in §7.1.1. Then, I go through the
new-account process, and receive the Account object in §7.1.2:

  {
    "status": "valid",
    "contact": [
      "mailto:cert-admin@example.com",
      "mailto:admin@example.com"
    ],
    "termsOfServiceAgreed": true,
    "orders": "https://example.com/acme/acct/1/orders"
  }

Huh. Suddenly, I'm not so interested in *my* orders, because I've noticed that
different users' orders are apparently at a predictable URL that varies only by
a small integer. Curious, I change the "1" to a "2" and send:

  GET /acme/acct/2/orders HTTP/1.1
  Host: example.com

And get back not *my* orders, but someone *else's* orders.

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "orders": [
      "https://example.com/acme/acct/2/order/1",
      "https://example.com/acme/acct/2/order/2",
      "https://example.com/acme/acct/2/order/3",
      "https://example.com/acme/acct/2/order/4"
    ]
  }

Interesting. So now I can do four more unauthenticated GETs and grab those order
objects.

  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "status": "valid",
    ...
    "identifiers": [
      { "type": "dns", "value": "smithforcongress.example" }
    ],
    ...
    "certificate": "https://example.com/acme/cert/1234"
  }
----------
  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "status": "valid",
    ...
    "identifiers": [
      { "type": "dns", "value": "something-embarassing-with-goats.example" }
    ],
    ...
    "certificate": "https://example.com/acme/cert/5678"
  }
----------
  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "status": "valid",
    ...
    "identifiers": [
      { "type": "email", "value": "smith-personal@obscure-domain.example" }
    ],
    ...
    "certificate": "https://example.com/acme/cert/9abc"
  }
----------
  HTTP/1.1 200 OK
  Content-Type: application/json

  {
    "status": "valid",
    ...
    "identifiers": [
      { "type": "tn", "value": "+12025550172" }
    ],
    ...
    "certificate": "https://example.com/acme/cert/defg"
  }

So now I've learned that the same account has pulled certs for both
"smithforcongress.example" and "something-embarassing-with-goats.example"; that
they have control over the email address
"smith-personal@obscure-domain.example," and that their phone number is +1 202
555 0172. There's a pretty good chance that... someone didn't want all of that
to be generally known.

And... huh... that's interesting.

    GET /acme/cert/9abc HTTP/1.1
    Host: example.com

    HTTP/1.1 200 OK
    Content-Type: application/pem-certificate-chain
    Link: ;rel="index"

    -----BEGIN CERTIFICATE-----
    [X.509 Cert for smith-personal@obscure-domain.example]
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    [Issuer certificate contents]
    -----END CERTIFICATE-----
    -----BEGIN CERTIFICATE-----
    [Other certificate contents]
    -----END CERTIFICATE-----

Whoa. That's cool. The next thing I'm doing is configuring Thunderbird to forge
mail from smith-personal@obscure-domain.example and going on an email spree
admitting to owning a rather embarrassing domain name, in which I ask concerned
constituents to call me on my unlisted phone number to discuss the issue.

Clearly I've missed something, because this just seems way too obvious. What
prevents this attack (or a similar one from observing that the order URLs are
predictable?)

If I *haven't* missed something, then there appears to have been an assumption
here, never written into the document, that the URLs generated for the orders
list and for the order objects are unguessable. If that's the case, I would:

(1) Expect this to be stated in section 7.1.2.1 and 7.1.3

(2) Expect a specification of a reasonable number of bits of entropy to use in
    orders list and order object URLs.

(3) Expect the examples to show appropriately random URLs (e.g.
    https://example.com/acme/acct/9258fac3-7866-4922-90e6-bbd0c89e751a/orders)


(4) Expect a treatment in section 10 of the risks that might arise from third
    parties gaining access to orders, as doing so provides free-and-clear access
    to private certificates (which, for dns, can be trivially used to
    revoke certs; and for other types, can be used for impersonation as well)

Again, I'm still expecting that I've simply missed something obvious -- I just
can't for the life of me figure out what it is.

[Ballot comment]
I have a small handful of substantive comments, and several editorial nits.

---------------------------------------------------------------------------

General:

This protocol specifies the use of RFC 3339 time formats in several places. Most
modern protocols that reference RFC 3339 choose to place further restrictions on
the format; commonly, the time-secfrac portion is required to be omitted, and
the time-offset portion is required to be "Z". In addition to making parsing
easier, these restrictions have the property of any given time having only one
possible string representation.

My suggestion would be for ACME to include similar restrictions. Alternately, if
the full range of optionality allowed by RFC 3339 is actually intended, please
adjust the examples so that at least a few of them include fractional seconds
and non-UTC timezones.

---------------------------------------------------------------------------

§5:

For avoidance of doubt, this section should probably indicate that values that
will appear in certificates will be used and conveyed in the form present in
certificates, possibly with a reference to RFC 5280 section 7.

---------------------------------------------------------------------------

§6.4.1:

>  The server MUST generate the value provided in
>  Replay-Nonce in such a way that they are unique to each message, with
>  high probability.  For instance, it is acceptable to generate Replay-
>  Nonces randomly.

It's not clear whether the values need to also be unpredictable; e.g., would it
be okay if the value of the nonce for operation n+1 could be easily derived or
guessed from the nonce for operation n?

---------------------------------------------------------------------------

§7.4.2:

>  GET /acme/cert/asdf HTTP/1.1
>  Host: example.com
>  Accept: application/pkix-cert
>
>  HTTP/1.1 200 OK
>  Content-Type: application/pem-certificate-chain

This pairing of "Accept: application/pkix-cert" with "Content-Type:
application/pem-certificate-chain" seems to be at odds with the description in
RFC 7231 §5.3.2. I know that proactive negotiation is optional in HTTP, but it
seems that it would be much better to show this as something like:

  GET /acme/cert/asdf HTTP/1.1
  Host: example.com
  Accept: application/pkix-cert, application/pem-certificate-chain;q=0.5

===========================================================================

All of my remaining comments are editorial in nature, and most of those are
minor editorial nits.


i-d nits reports:

  ** There are 3 instances of too long lines in the document, the longest one
    being 15 characters in excess of 72.

I'm not sure it's reasonable to expect the RFC editor to have enough knowledge
to know how to best split the key authorization across lines (or to elide
portions of it, whichever makes more sense).

---------------------------------------------------------------------------

i-d nits also reports:

  -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not
    defined in RFC 2119.  If it is intended as a requirements expression, it
    should be rewritten using one of the combinations defined in RFC 2119;
    otherwise it should not be all-uppercase.

---------------------------------------------------------------------------

§1:

>  Existing Web PKI certificate authorities tend to use a set of ad hoc
>  protocols for certificate issuance and identity verification.  In the
>  case of DV certificates, a typical user experience is something like:

I expect this text won't age gracefully. Even at the time of publication of
this document, over 64% of all certificates issued on the web have been issued
using the ACME protocol, arguably making it the "typical user experience." (see
https://censys.io/certificates/report?q=tags%3Atrusted&field=parsed.issuer.organization.raw&max_buckets=50)

I suggest caveating this paragraph with text along the lines of "prior to the
advent of the protocol described by this document, the typical user experience
was..."

---------------------------------------------------------------------------

§1:

>  For example, as of this writing, there is
>  ongoing work to use ACME for issuance of Web PKI certificates
>  attesting to IP addresses [I-D.ietf-acme-ip] and STIR certificates
>  attesting to telephone numbers [I-D.ietf-acme-telephone].

Suggestion: consider including [draft-ietf-acme-email-smime] in this list.

---------------------------------------------------------------------------

§6.2:

>  These intermediaries can also change values in the request that are
>  not signed in the HTTPS request, e.g., the request URL and headers.

Nit: "...header fields."

---------------------------------------------------------------------------

§6.4:

>  An error response with the
>  "badNonce" error type MUST include a Replay-Nonce header with a fresh
>  nonce.

Nit: "...header field..."

---------------------------------------------------------------------------

§6.5:

>  "urn:ietf:params:acme:error:rateLimited".  Additionally, the server
>  SHOULD send a "Retry-After" header [RFC7231] indicating when the
>  current request may succeed again.

Nit: "...header field..."

>  In addition to the human-readable "detail" field of the error
>  response, the server MAY send one or multiple link relations in the
>  "Link" header  [RFC8288] pointing to documentation about the specific
>  rate limit that was hit, using the "help" link relation type.

Nit: "...header field..."

---------------------------------------------------------------------------

§7.1:

>  The "->" is a mnemonic for a Location
>  header pointing to a created resource.

Nit: "...header field..."

---------------------------------------------------------------------------

§7.1.2.1:

>  The server MAY
>  return an incomplete list, along with a Link header with a "next"
>  link relation indicating where further entries can be acquired.

Nit: "...header field..."

---------------------------------------------------------------------------

§7.3.4:

>  This response MUST
>  include a Link header with link relation "terms-of-service" and the
>  latest terms-of-service URL.

Nit: "...header field..."

---------------------------------------------------------------------------

§7.4.2:

>  Because certificate resources are immutable once issuance is
>  complete, the server MAY enable the caching of the resource by adding
>  Expires and Cache-Control headers specifying a point in time in the
>  distant future.  These headers have no relation to the certificate's
>  period of validity.

Nit: "...header fields..." (twice)

>  The ACME client MAY request other formats by including an Accept
>  header [RFC7231] in its request.

Nit: "...header field..."

>  provide one or more "Link: rel="up"" headers pointing to an issuer or

Nit: "...header fields..."

---------------------------------------------------------------------------

§7.5:

>  When a client receives an order from the server it downloads the
>  authorization resources by sending GET requests to the indicated
>  URLs.

Nit: "...from the server, it downloads..."

[Ballot discuss]
This is a great thing to have, and I intend to eventually ballot Yes, but I
do have some questions that may require further discussion before this
document is approved.

It looks like the server returns an unauthenticated "badSignatureAlgorithm"
error when the client sends a JWS using an unsupported signature algorithm
(Section 6.2).  What prevents an active attacker from performing a
downgrade attack on the signature algorithm used?

Similarly, since we include in the threat model a potentially hostile
CDN/MitM between the ACME client and ACME server, can that attacker strip a
success response and replace it with a badNonce error, causing the client
to retry (and thus duplicate the request processing on the server)?

I am not an ART AD, but there is not yet an internationalization
directorate, and seeing statements like "inputs for digest computations
MUST be encoded using the UTF-8 character set" (Section 5) without
additional discussion of normalization and/or what the canonical form for
the digest input is makes me nervous.  Has sufficient internationalization
review been performed to ensure that there are no latent issues in this
space?

Section 6.1 has text discussing TLS 1.3's 0-RTT mode.  If this text is
intended to be a profile that defines/allows the use of TLS 1.3 0-RTT data
for the ACME protocol, I think you need to be more specific and say
something like "MAY allow clients to send early data (0-RTT); there are no
ACME-specific restrictions on which types of requests are permitted in
0-RTT", since the runtime configuration is just 0-RTT yes/no, and the
protocol spec is in charge of saying which PDUs are allowed or not.

Section 6.2 notes that servers MUST NOT respond to GET requests for
sensitvie resources.  Why are account resources the only sensitive ones?
Are authorizations not sensitive?  Or are those considered to fall under
the umbrella of "account resources" (Section 7.1 seems pretty clear that
they do not)?

Section 7.1.1 discusses how the server can include a caaIdentities element
in its directory metadata; does this (or anything else) need to be
integrity protected by anything stronger than the Web PKI cert
authenticating the HTTPS connection?  It seems that a bogus caaIdentities
value could lead to an unfortunate DoS in some cases.

I am also a bit uncertain if the document is internally consistent about
whether one challenge verification suffices or there can be cases when
multiple challenge verifications are required for a successful
authorization.  I attmpted to note relevant snippets of the text in my
comments on Section 7.1.4.

I also have some important substantive comments in the section-by-section
COMMENTS, since they would not in and of themselves block publication.

[Ballot comment]
This document was quite easy to read -- thank you for the clear prose and
document structure!  It did leave me with some questions as to whether
there are missing clarifications, though, so there are a pile of notes in
the section-by-section comments below.

It seems natural to feel some unease when the concept of automated
certificate issuance like this comes up.  As far as I can tell, though,
the only substantive difference between this flow and the flow it's
replacing is that this one qualitatively feels like it weakens the "know
your customer" aspect for the CA -- with current/legacy methods registering
for an account can be slow and involves real-world information.  Such can
be spoofed/forged, of course, but ACME seems to be weakening some aspect by
automating it.  Given the spoofability, though, this weakening does not
seem to be a particular concern with the document.

I was going to suggest mentioning the potential for future work in doing
time-delayed or periodic revalidation or other schemes to look at the
stability of the way that identifiers/challenges were validated, but I see
that discussion has already happened.

It's probably worth going over the examples and checking whether nonce
values are repeated in ways that are inconsistent with expected usage.  For
example, I see these three values appearing multiple times (but I did not
cross-check if a nonce returned in the Replay-Nonce response header was
then used in a JWS header attribute):
      2 K60BWPrMQG9SDxBDS_xtSw
      3 IXVHDyxIRGcTE0VSblhPzw
      4 JHb54aT_KTXBWQOzGYkt9A

Perhaps the examples could be offset by a description of what they are?
(They would probably also benefit from a disclaimer that the whitespace in
the JSON is for ease of reading only.)

Section-by-section comments follow.

Abstract (also Introduction)

If I read "authentication of domain names" with no context, I would be more
likely to think of the sort of challenge/authorization process that this
document describes, than I would be to think of using an X.509 certificate
to authenticate myself as being the owner of a given domain name.  But it's
unclear whether there's an alternative phrasing that would be better.

Section 1

  Different types of certificates reflect different kinds of CA
  verification of information about the certificate subject.  "Domain
  Validation" (DV) certificates are by far the most common type.  The
  only validation the CA is required to perform in the DV issuance
  process is to verify that the requester has effective control of the
  domain.

Can we get an (informative) ref for the "required"/requirements?

Section 6.1

W3C.CR-cors-2013-0129 shows up as "outdated" when I follow the link.

Section 6.2

IMPORTANT: The JSON Web Signature and Encryption Algorithms registry does
not appear to include an explicit indicator of whether an algorithm is
MAC-based; do we need to include text on how to make such a determination?

Section 6.3

For servers following the "SHOULD ... string equality check" and for
requests where the equality check fails, does that fall into the "MUST
reject the request as unauthorized" bucket?

Section 6.4

  In order to protect ACME resources from any possible replay attacks,
  ACME requests have a mandatory anti-replay mechanism.

We don't seem to actually define what an "ACME request" is that I can see.
From context, this requirement only applies to JWS POST bodies, and not to,
say, newNonce, but I wonder if some clarification would be useful.

IMPORTANT: How tightly are these nonces scoped?  Are they only good on a
specific TLS connection?  Bound to an account key pair?  Globally valid?
(This is not a DISCUSS point because AFAICT there is no loss in security if
the nonce space is global to the server.)

Section 6.6

IMPORTANT: Providing an accountDoesNotExist error type probably means we
need to give guidance that the server should choose account URLs in a
non-guessable way, to avoid account enumeration attacks.

  [...] Servers
  MUST NOT use the ACME URN namespace Section 9.6 for errors other than
  the standard types.

"standard" as determined by inclusion in this document, or in the IANA
registry?

Section 7.1

The "up" link relation for going from certificate to chain seems to only be
needed for alternate content types that can only represent a single
certificate.  (Also, the "alternate" link relation is used to provide
alternate certifciation chains.)  Could this text be made more clear?

Presumably this is just my confusion, but what does "GET order certificate"
mean?

Section 7.1.1

  [...] It is a JSON
  object, whose field names are drawn from the following table and
  whose values are the corresponding URLs.

Er, from the IANA registry, right?

  The following metadata items are defined, all of which are OPTIONAL:

Maybe also refer to the registry?

Section 7.1.2

IMPORTANT: I'm unclear if the "contact" is supposed to be a "talk to a
human" thing or not.  If there are supposed to be different URLs that are
used for different purposes, wouldn't more metadata be needed about them?
So it seems most likely that this is indeed "talk to a human", in which
case that might be worth mentioning.  (Are these always going to be
mailto:?)

Section 7.1.2.1

IMPORTANT: Am I reading this correctly that the GET to the orders URL does
not require the client to be authenticated, in effect relying on
security-through-obscurity (of the account URL) for indicating which
account is trying to order certificates for which identifiers?

Section 7.1.4

  challenges (required, array of objects):  For pending authorizations,
      the challenges that the client can fulfill in order to prove
      possession of the identifier.  For final authorizations (in the
      "valid" or "invalid" state), the challenges that were used.  Each
      array entry is an object with parameters required to validate the
      challenge.  A client should attempt to fulfill one of these
      challenges, and a server should consider any one of the challenges
      sufficient to make the authorization valid.

This leaves me slightly confused.  A final authorization can have multiple
challenges.  But a client should only attempt to fulfill one, and a server
should treat any one as sufficient.  So I can only get to the case with
multiple challenges present in a final order of both "should"s are
violated?  Is there a way for the server to express that multiple
challenges are going to be required?
Hmm, but Section 7.1.6's flow chart for Authorization objects says that a
single challenge's transition to valid also makes the authorization
transition to valid, which would seem to close the window?
Section 7.5.1 has inline text that implicitly assumes that only one
challenge will be completed/validated.

  wildcard (optional, boolean):  For authorizations created as a result
      of a newOrder request containing a DNS identifier with a value
      that contained a wildcard prefix this field MUST be present, and
      true.

Is there a difference between false and absent?

Section 7.3

  A client creates a new account with the server by sending a POST
  request to the server's new-account URL.  The body of the request is
  a stub account object optionally containing the "contact" and
  "termsOfServiceAgreed" fields.

Given that we go on to describe those two and also the optional
onlyReturnExisting and externalAccountBinding fields, does this list need
expanding?

IMPORTANT: How does the client know if a termsOfService in the directory is
actually required or just optional?  (There doesn't seem to be a dedicated
error type for this?)  The text as-is seems to only say that if the server
requires it, the field must be present in the directory, but not the other
way around.  I guess Section 7.3.4 describes the procedure for a similar
case; should the same thing happen for the original terms acceptance?

IMPORTANT: The example response uses what appears to be a sequential
counter for account ID in the returned account URL, which loses any sort of
security-through-obscurity protections if those were desired.  Should a
more opaque URL component be present, maybe a UUID?  (The "orders" field
would need to be modified accordingly, of course, and this pattern appears
in later examples, as well.)

Section 7.3.2

It's a little unclear to me whether the fields the client can put in the
POST are the ones listed from Section 7.3 or 7.1.2, or the full set from
the registry.  But presumably the server must ignore the "status" field,
too, or at least some values should be disallowed!  The IANA registry's
"configurable" column may not quite be the right thing for this usage,
especially given how account deactivation works.

Section 7.3.5

  The server MAY require a value for the "externalAccountBinding" field
  to be present in "newAccount" requests.

All requests including queries for the current status and modification of
existing accounts?  Or just creation of new ones?

  To enable ACME account binding, the CA operating the ACME server
  needs to provide the ACME client with a MAC key and a key identifier,
  using some mechanism outside of ACME.

This key needs to also be tied to the external account in question, right?
One might even say that it is provided not to the ACME client, but to the
external account holder, who is also running an ACME client.

  [...] The payload of
  this JWS is the account key being registered, in JWK form.

This is presumably my fault and not the document's, but I had to read this
a few time to bind it as the ACME account key, and not the external MAC
key.

  If a CA requires that new-account requests contain an
  "externalAccountBinding" field, then it MUST provide the value "true"
  in the "externalAccountRequired" subfield of the "meta" field in the
  directory object.  If the CA receives a new-account request without [...]

nit: maybe "If such a CA"?

IMPORTANT: I don't think I understand why "nonce" MUST NOT be present in
the external-binding JWS object, though I think I understand why one is not
needed in order to bind the MAC to the current transaction.  (That is, this
is in effect a "triply nested" construct, where a standalone MAC that
certifies an ACME account (public) key as being authorized by the
external-account holder to act on behal of that external account.  But this
standalone MAC will only be accepted by the ACME server in the context of
the outer JWS POST, that must be signed by the ACME account key, which is
assumed to be kept secure by the ACME client, ensuring that both
key-holding entities agree to the account linkage.)  Proof of freshness of
the commitment from the external account holder to authorize the ACME
account key would only be needed if there was a scenario where the external
account holder would revoke that association, which does not seem to be a
workflow supported by this document.  Any need to effectuate such a
revocation seems like it would involve issuing a new MAC key for the
external account (and invalidating the old one), and revoking/deactivating
the ACME account, which is a somewhat heavy hammer but perhaps reasonable
for such a scenario.
Account key rollover just says that the nonce is NOT REQUIRED, and also
uses some nicer (to me) language about "outer JWS" and "inner JWS".  It
might be nice to synchronize these two sections.

Section 7.3.7

IMPORTANT: The "url" in this example looks like an account URL, not an
account-deactivation url.  If they are one and the same, please include
some body text to this effect as is done for account update in Section
7.3.2.

Section 7.4

Is Section 7.1.3 or the registry a better reference for the request
payload's fields?

Does the exact-match policy (e.g., on notBefore and notAfter) result in CA
maximum lifetime policies needing to be hardcoded in client software (as
opposed to being discoverable at runtime)?

(I like the order url in the example, "[...]/order/asdf".  Not much entropy
though.)

IMPORTANT: Why does the example response include an identifier of
www.example.com that was not in the request?

Is the "order's requested identifiers appear in commonName or
subjectAltName" requirement an exclusive or?

After a valid request to finalize has been issued, are "pending" or "ready"
still valid statuses that could be returned for that order?

Section 7.4.1

Elsewhere when we list "identifier (required, object)" in a JWS payload we
also inline the "type" and "value" breakdown of the object.

How is "expires" set for this pre-authorization object?

We probably need a reference for "certificate chain as defined in TLS".

Section 7.5

"When a client receives an order from the server" is a bit jarring without
some additional context of "in a reply to a new-order request" or "an order
object" or similar.

Section 7.5.1

  To do this, the client updates the authorization object received from
  the server by filling in any required information in the elements of
  the "challenges" dictionary.

"challenges" looks like an array of objects, not directly a dictionary with
elements within it.

Section 8

IMPORTANT: What do I do if I get a challenge object that has status "valid"
but also includes an "error" field?

Section 8.1

  [...] A key authorization is a string that expresses
  a domain holder's authorization for a specified key to satisfy a
  specified challenge, [...]

I'm going to quibble with the language here and say that the
keyAuthorization string as defined does not express a specific
authorization for a specific challenge, since there is no signature
involved, and the JWK thumbprint is separable and can be attached to some
other token.  (This may just be an editorial matter with no broader impact,
depending on how it's used.)  One could perhaps argue that the mere
existence of the token constitutes an authorization for a specified key to
satisfy the challenge, since the token only gets generated upon receipt of
such an authorized request.

Section 8.3

I'm not sure that 4086 is a great cite, here.  For example, in RFC 8446 we
say that "TLS requires a [CSPRNG].  In most case, the operating system
provides an appropriate facility [...] Should these prove unsatisfactory,
[RFC4086] provides guidance on the generation of random values."  On the
other hand, citing 4086 like this is not wrong, so use your judgment.

  4.  Verify that the body of the response is well-formed key
      authorization.  The server SHOULD ignore whitespace characters at
      the end of the body.

nit: "a well-formed"

Can we get some justification for the "SHOULD follow redirects", given the
security considerations surrounding doing so?

Section 8.4

Should this "token" description include the same text about entropy as for
the HTTP challenge?

Section 9.7.1

There is perhaps some subtlety here, in that the "configurable" column
applies only to the new-account request, but its description in the
template does not reflect that restriction.  In particular, "status" values
from the client *are* accepted when posted to the account URL, e.g., for
account deactivation.


Section 10.1

Can there be overlap between the "validation server" function and the "ACME
client" function?

Section 10.2

  [...] The key authorization reflects the
  account public key, is provided to the server in the validation
  response over the validation channel and signed afterwards by the
  corresponding private key in the challenge response over the ACME
  channel.

I'm stumbling up around the comma trying to parse this sentence.  (Maybe a
serial comma or using "and is signed" would help?)
IMPORTANT: Also, I don't see where the key authorization is signed in the
challenge response -- the payload is just an empty object for both the HTTP
and DNS challenges' responses.

Some of this text sounds like we're implicitly placing requirements on all
(HTTP|DNS) server operators (not just ones trying to use ACME) to mitgate
the risks being described.  In general this sort of behavior seems like an
anti-design-pattern, though perhaps one could argue that the behaviors in
question should be avoided in general, indepnedent of ACME.

Section 10.4

  Some server implementations include information from the validation
  server's response (in order to facilitate debugging).  Such

Disambiguating "ACME server implementations" may help, since we talk about
other HTTP requests in the previous paragraph.

Section 11.1

IMPORTANT: This may be an appropriate place to recommend against reuse of
account keys, whether after an account gets deactivated or by cycling
through keys in a sequence of key-change operations (or otherwise).  I
think there are some attack scenarios possible wherein (inner) JWS objects
could be replayed against a different account, if such key reuse occurs.

Section 11.3

  The http-01, and dns-01 validation methods mandate the usage of a

nit: spurious comma.

  [...] Secondly, the entropy requirement
  prevents ACME clients from implementing a "naive" validation server
  that automatically replies to challenges without participating in the
  creation of the initial authorization request.

IMPORTANT: I'm not sure I see how this applies to the HTTP mechanism --
couldn't you write a script to reply to .well-known/acme-challenge/
with . for a fixed key thumbprint?  The validation
server would ned to know about the ACME account in question, but not about
any individual authorization request.

[Ballot comment]
Thank you for this very important document. I would like to switch to "Yes", but please first review and respond to my comments:

First mentions of JSON and HTTPS need references.

6.4.1.  Replay-Nonce

  The "Replay-Nonce" header field includes a server-generated value
  that the server can use to detect unauthorized replay in future
  client requests.  The server MUST generate the value provided in
  Replay-Nonce in such a way that they are unique to each message, with
  high probability.  For instance, it is acceptable to generate Replay-
  Nonces randomly.

  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.  The
  ABNF [RFC5234] for the Replay-Nonce header field follows:

    base64url = [A-Z] / [a-z] / [0-9] / "-" / "_"

This is not correct ABNF. Change range syntax in Section 3.4 of RFC 5234

    Replay-Nonce = *base64url

You allow for empty nonce here. Should this be "1*base64url"?



Please add normative references for Retry-After and Link header fields.


In Section 6.6:

  | unsupportedIdentifier  | Identifier is not supported, but may be |
  |                        | in future   

Do you mean "identifier type", not identifier?

  This list is not exhaustive.  The server MAY return errors whose
  "type" field is set to a URI other than those defined above.  Servers
  MUST NOT use the ACME URN namespace Section 9.6 for errors other than
  the standard types.

I think this text is misleading, as you create a registry for these.
I suggest you rephrase and add a reference to the registry.


In 7.1.1:

  caaIdentities (optional, array of string):  Each string MUST be a
      lowercase hostname which the ACME server recognizes as referring

Is hostname fully qualified? U-label IDNA domains not allowed here? Please clarify.

      to itself for the purposes of CAA record validation as defined in
      [RFC6844].  This allows clients to determine the correct issuer
      domain name to use when configuring CAA records.


Example in 7.1.1 (or maybe even earlier): You probably should say that some header fields are omitted here.


In 7.1.2:

  contact (optional, array of string):  An array of URLs that the

Which URI schemes are allowed (or at least expected) here?

      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.


In 7.4:

  Clients SHOULD NOT make any assumptions about the sort order of
  "identifiers" or "authorizations" elements in the returned order
  object.

Why is this a SHOULD NOT and not a MUST NOT?

(Similar text in other sections!)


7.4.2.  Downloading the Certificate


  GET /acme/cert/asdf HTTP/1.1
  Host: example.com
  Accept: application/pkix-cert

I think your example is wrong, as Accept value needs to match application/pem-certificate-chain returned below:

  HTTP/1.1 200 OK
  Content-Type: application/pem-certificate-chain
  Link: ;rel="index"

  -----BEGIN CERTIFICATE-----
  [End-entity certificate contents]
  -----END CERTIFICATE-----
  -----BEGIN CERTIFICATE-----
  [Issuer certificate contents]
  -----END CERTIFICATE-----
  -----BEGIN CERTIFICATE-----
  [Other certificate contents]
  -----END CERTIFICATE-----

In 8.3:

  The server SHOULD follow redirects when dereferencing the URL.

Why only a SHOULD?


9.1.  MIME Type: application/pem-certificate-chain

  The "Media Types" registry should be updated with the following
  additional value:

  MIME media type name: application

  MIME subtype name: pem-certificate-chain

  Required parameters: None

  Optional parameters: None

  Encoding considerations: None

This value has to be one of "7bit", "8bit", "binary" or "framed". I think this should be "7bit", as PEM is ASCII.


  Security considerations: Carries a cryptographic certificate and its
  associated certificate chain

I suggest you add text saying that this media type doesn't include active content.


  Interoperability considerations: None

  Published specification: draft-ietf-acme-acme [[ RFC EDITOR: Please
  replace draft-ietf-acme-acme above with the RFC number assigned to
  this ]]

  Applications which use this media type: Any MIME-compliant transport

This text is not actually useful for Media Type reviewers or users.
You should say "ACME client and servers" or something like this. Giving more examples of use would be a plus.


You are also missing some fields from the registration template. In particular, who is the Change Controller? (IETF or IESG)


9.6.  URN Sub-namespace for ACME (urn:ietf:params:acme)

  Repository:  URL-TBD

Who needs to fix this value?




9.7.1.  Fields in Account Objects

  o  Field type: The type of value to be provided, e.g., string,
      boolean, array of string

Here and in all similar registries: I think you should insert "JSON" before "type" to make it clear that types are only restricted to JSON type choices.

9.7.8.  Validation Methods

  Template:

  o  Identifier Type: The type of identifier that this method applies
      to

I think you should add "or a special keyword RESERVED", as otherwise the table below might be confusing.

  o  ACME: "Y" if the validation method corresponds to an ACME
      challenge type; "N" otherwise.

I think this could have been clearer, as it is not obvious when "N" can be used. For example you use "N" for "RESERVED" values.

[Ballot comment]
Thanks for the work on this; I'm happy to see it nearing completion. I have a few minor comments:

*** Substantive ***

§6.1: "The ACME server acts
  as an HTTP and HTTPS client when validating challenges via HTTP."

Section 8.3 says that HTTP challenge validation cannot use HTTPS. Also, §6 says that all interactions between the client and server use HTTPS. I recognize challenge validation is not really an interaction between the client and server, but I suspect some readers may be confused.

- "ACME servers SHOULD follow the recommendations of [RFC7525] when
  configuring their TLS implementations."
Why not MUST?

§7.3: "... and the server MUST reject new-account
  requests that do not have the "termsOfServiceAgreed" field set to
  "true". "

The MUST seems overly strong there; is there no room for local policy? Would it be completely insane to offer optional ToS? (For example, maybe one gets some additional service for agreeing to terms, but still gets a cert either way.)

- "Clients SHOULD NOT automatically agree to terms by default."
Why not MUST NOT?

§8.3:

- Is there a lifetime after which a provisioned HTTP resource in response to a challenge should go away?


*** Editorial and Nits ***

§2, first paragraph: Is the "user" the person requesting services from the ACME server?



§10.2: "
  It is RECOMMENDED that the server perform DNS queries and make HTTP
  connections from various network perspectives..."

§7.3.6: " The inner JWS is NOT REQUIRED to have a "nonce" header parameter."

"NOT REQUIRED" is not among the terms defined by 2119/8174. I suspect this is intended as a statement of fact, and should therefore not be capitalized.

I'm not sure what that means. Given that this uses an upper-case RECOMMENDED, can it be stated more concretely?

§13.3: Is this section also to be removed?

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has completed its review of draft-ietf-acme-acme-13. If any part of this review is inaccurate, please let us know.

The IANA Functions Operator understands that, upon approval of this document, there are fourteen actions which we must complete.

First, in the application media types registry located at:

https://www.iana.org/assignments/media-types/

a single, new media type is to be registered as follows:

Name: pem-certificate-chain
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, in the Well-Known URIs registry located at:

https://www.iana.org/assignments/well-known-uris/

a single, new URI is to be registered as follows:

URI Suffix: acme-challenge
Change Controller: IETF
Reference: [ RFC-to-be; Section 8.3 ]
Related Information:
Date Registered: [ TBD-at-Registration ]
Date Modified:

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Third, in the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

a single new message header will be registered as follows:

Header Field Name: Replay-Nonce
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be; Section 6.4.1 ]

As this also requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, in the JSON Web Signature and Encryption Header Parameters registry on the JSON Object Signing and Encryption (JOSE) web page located at:

https://www.iana.org/assignments/jose/

a single new parameter will be registered as follows:

Header Parameter Name: url
Header Parameter Description: URL
Header Parameter Usage Location: JWE, JWS
Change Controller: IESG
Reference: [ RFC-to-be; Section 6.3.1 ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fifth, also in the JSON Web Signature and Encryption Header Parameters registry on the JSON Object Signing and Encryption (JOSE) web page located at:

https://www.iana.org/assignments/jose/

a single, new parameter will be registered as follows:

Header Parameter Name: nonce
Header Parameter Description: Nonce
Header Parameter Usage Location: JWE, JWS
Change Controller: IESG
Reference: [ RFC-to-be; Section 4.4.2 ]

As this also requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Sixth, in the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry on the Uniform Resource Name (URN) Namespace for IETF Use registry page located at:

https://www.iana.org/assignments/params/

a single, new identifier will be registered as follows:

Registered Parameter Identifier: acme
Reference: [ RFC-to-be ]
IANA Registry Reference: [ see the notes to IANA Action #7 ]

Seventh, a new registry is to be created called the ACME Account Object Fields registry. The location of this new registry will be on a new registry page with the title Automated Certificate Management Environment (ACME) Protocol. All the registries on this new registry page will be managed via Specification Required as defined by RFC 8126. This new registry page is also to be used as the IANA Registry Reference for the sixth IANA Action for this document [ see above ].

There are initial registrations in the new registry as follows:

+------------------------+-------------+--------------+----------------+
| Field Name | Field Type | Configurable | Reference |
+------------------------+-------------+--------------+----------------+
| status | string | false | [ RFC-to-be ] |
| | | | |
| contact | array of | true | [ RFC-to-be ] |
| | string | | |
| | | | |
| externalAccountBinding | object | true | [ RFC-to-be ] |
| | | | |
| termsOfServiceAgreed | boolean | true | [ RFC-to-be ] |
| | | | |
| orders | string | false | [ RFC-to-be ] |
+------------------------+-------------+--------------+----------------+

Eighth, a new registry is to be created called the ACME Order Object Fields registry. The location of this new registry will be on the new registry page created for the Automated Certificate Management Environment (ACME) Protocol in IANA Action #7 [ see above]. The new registry will be managed via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+------------------------+------------+--------------+----------------+
| Field Name | Field Type | Configurable | Reference |
+------------------------+------------+--------------+----------------+
| status | string | false | [ RFC-to-be ] |
| | | | |
| contact | array of | true | [ RFC-to-be ] |
| | string | | |
| | | | |
| externalAccountBinding | object | true | [ RFC-to-be ] |
| | | | |
| termsOfServiceAgreed | boolean | true | [ RFC-to-be ] |
| | | | |
| orders | string | false | [ RFC-to-be ] |
+------------------------+------------+--------------+----------------+

Ninth, a new registry is to be created called the ACME Authorization Object Fields registry. The location of this new registry will be on the new registry page created for the Automated Certificate Management Environment (ACME) Protocol in IANA Action #7 [ see above ]. The new registry will be managed via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+------------+-----------------+--------------+----------------+
| Field Name | Field Type | Configurable | Reference |
+------------+-----------------+--------------+----------------+
| identifier | object | true | [ RFC-to-be ] |
| | | | |
| status | string | false | [ RFC-to-be ] |
| | | | |
| expires | string | false | [ RFC-to-be ] |
| | | | |
| challenges | array of object | false | [ RFC-to-be ] |
| | | | |
| wildcard | boolean | false | [ RFC-to-be ] |
+------------+-----------------+--------------+----------------+

Tenth, a new registry is to be created called the ACME Error Types registry. The location of this new registry will be on the new registry page created for the Automated Certificate Management Environment (ACME) Protocol in IANA Action #7 [ see above ]. The new registry will be managed via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows {IANA NOTE: For each one of these initial registrations, the reference will be set to [ RFC-to-be ]}:

+-------------------------+----------------------------------------+
| Type | Description |
+-------------------------+----------------------------------------+
| accountDoesNotExist | The request specified an account that |
| | does not exist |
| | |
| badCSR | The CSR is unacceptable (e.g., due to |
| | a short key) |
| | |
| badNonce | The client sent an unacceptable anti- |
| | replay nonce |
| | |
| badRevocationReason | The revocation reason provided is not |
| | allowed by the server |
| | |
| badSignatureAlgorithm | The JWS was signed with an algorithm |
| | the server does not support |
| | |
| caa | Certification Authority Authorization |
| | (CAA) records forbid the CA from |
| | issuing |
| | |
| compound | Specific error conditions are indicated|
| | in the "subproblems" array. |
| | |
| connection | The server could not connect to |
| | validation target |
| | |
| dns | There was a problem with a DNS query |
| | |
| externalAccountRequired | The request must include a value for |
| | the "externalAccountBinding" field |
| | |
| incorrectResponse | Response received didn't match the |
| | challenge's requirements |
| | |
| invalidContact | A contact URL for an account was |
| | invalid |
| | |
| malformed | The request message was malformed |
| | |
| rateLimited | The request exceeds a rate limit |
| | |
| rejectedIdentifier | The server will not issue for the |
| | identifier |
| | |
| serverInternal | The server experienced an internal |
| | error |
| | |
| tls | The server received a TLS error during |
| | validation |
| | |
| unauthorized | The client lacks sufficient |
| | authorization |
| | |
| unsupportedContact | A contact URL for an account used an |
| | unsupported protocol scheme |
| | |
| unsupportedIdentifier | Identifier is not supported, but may be|
| | in future |
| | |
| userActionRequired | Visit the "instance" URL and take |
| | actions specified there |
+-------------------------+----------------------------------------+

Eleventh, a new registry is to be created called the ACME Resource Types registry. The locateion of this new registry will be on the new registry page created for the Automated Certificate Management Environment (ACME) Protocol in IANA Action #7 [ see above ]. The new registry will be managed via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+------------+--------------------+----------------+
| Field Name | Resource Type | Reference |
+------------+--------------------+----------------+
| newNonce | New nonce | [ RFC-to-be ] |
| | | |
| newAccount | New account | [ RFC-to-be ] |
| | | |
| newOrder | New order | [ RFC-to-be ] |
| | | |
| newAuthz | New authorization | [ RFC-to-be ] |
| | | |
| revokeCert | Revoke certificate | [ RFC-to-be ] |
| | | |
| keyChange | Key change | [ RFC-to-be ] |
| | | |
| meta | Metadata object | [ RFC-to-be ] |
+------------+--------------------+----------------+

Twelfth, a new registry is to be created called the ACME Directory Metadata Fields registry. The locateion of this new registry will be on the new registry page created for the Automated Certificate Management Environment (ACME) Protocol in IANA Action #7 [ see above ]. The new registry will be managed via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+-------------------------+-----------------+----------------+
| Field Name | Field Type | Reference |
+-------------------------+-----------------+----------------+
| termsOfService | string | [ RFC-to-be ] |
| | | |
| website | string | [ RFC-to-be ] |
| | | |
| caaIdentities | array of string | [ RFC-to-be ] |
| | | |
| externalAccountRequired | boolean | [ RFC-to-be ] |
+-------------------------+-----------------+----------------+

Thirteenth, a new registry is to be created called the ACME Identifier Types registry. The locateion of this new registry will be on the new registry page created for the Automated Certificate Management Environment (ACME) Protocol in IANA Action #7 [ see above ]. The new registry will be managed via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+-------+----------------+
| Label | Reference |
+-------+----------------+
| dns | [ RFC-to-be ] |
+-------+----------------+

Fourteenth, a new registry is to be created called the ACME Validation Methods registry. The locateion of this new registry will be on the new registry page created for the Automated Certificate Management Environment (ACME) Protocol in IANA Action #7 [ see above ]. The new registry will be managed via Specification Required as defined in RFC 8126.

There are initial registrations in the new registry as follows:

+------------+-----------------+------+----------------+
| Label | Identifier Type | ACME | Reference |
+------------+-----------------+------+----------------+
| http-01 | dns | Y | [ RFC-to-be ] |
| | | | |
| dns-01 | dns | Y | [ RFC-to-be ] |
| | | | |
| tls-sni-01 | RESERVED | N | [ RFC-to-be ] |
| | | | |
| tls-sni-02 | RESERVED | N | [ RFC-to-be ] |
+------------+-----------------+------+----------------+

The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-08-08):

From: The IESG
To: IETF-Announce
CC: Yoav Nir , ekr@rtfm.com, draft-ietf-acme-acme@ietf.org, acme@ietf.org, ynir.ietf@gmail.com, acme-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Automatic Certificate Management Environment (ACME)) to Proposed Standard

NOTE: This is a second last call because of significant changes in -13.

The IESG has received a request from the Automated Certificate Management
Environment WG (acme) to consider the following document: - 'Automatic
Certificate Management Environment (ACME)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-08-08. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Certificates in PKI using X.509 (PKIX) are used for a number of
  purposes, the most significant of which is the authentication of
  domain names.  Thus, certificate authorities in the Web PKI are
  trusted to verify that an applicant for a certificate legitimately
  represents the domain name(s) in the certificate.  Today, this
  verification is done through a collection of ad hoc mechanisms.  This
  document describes a protocol that a certification authority (CA) and
  an applicant can use to automate the process of verification and
  certificate issuance.  The protocol also provides facilities for
  other certificate management functions, such as certificate
  revocation.

  RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
  this draft is maintained in GitHub.  Suggested changes should be
  submitted as pull requests at https://github.com/ietf-wg-acme/acme
  [1].  Instructions are on that page as well.  Editorial changes can
  be managed in GitHub, but any substantive change should be discussed
  on the ACME mailing list (acme@ietf.org).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ballot/


No IPR declarations have been submitted directly on this I-D.

Summary
  Richard Barnes, Jacob Hoffman-Andrews, and James Kasten are the authors.
  Yoav Nir is the document shepherd. Eric Rescorla is the responsible Area
  Director.
 
  Certificates in PKI using X.509 (PKIX) are used for a number of
  purposes, the most significant of which is the authentication of
  domain names.  Thus, certificate authorities in the Web PKI are
  trusted to verify that an applicant for a certificate legitimately
  represents the domain name(s) in the certificate.  Today, this
  verification is done through a collection of ad hoc mechanisms.  This
  document describes a protocol that a certification authority (CA) and
  an applicant can use to automate the process of verification and
  certificate issuance.  The protocol also provides facilities for
  other certificate management functions, such as certificate
  revocation.
 
Review and Consensus
  This document represents the consensus of the ACME working group. The draft
  has been the main document of the group for the last two years, and has been
  through WGLC since February 2017.
  Much of the discussion since then has been feedback from commercial CAs
  about integrating the protocol with their processes. Several of them are now
  committed to deploy this protocol following publication.
  Most of the session in IETF 99 was devoted to verifying that there are no
  more open issues for this draft.

Intellectual Property
  The authors have stated that they do not have any IPR related to this
  document, and that they are not aware of any IPR claims made by others about
  the content of this document.

Other Points
  None
 

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-acme-acme-10. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are thirteen actions which we must complete.

First, in the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

a new registration is to be made as follows:

Name: pem-certificate-chain
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Second, in the Well-Known URI registry located at:

https://www.iana.org/assignments/well-known-uris/

the existing registration for:

URI Suffix: acme-challenge
Change Controller: IETF
Reference: [ RFC-to-be ]
Related Information:
Date Registered: [ TBD-at-Registration ]
Date Modified:

will be updated to have its reference changed to [ RFC-to-be ].

Third, in the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

a single, new registration is to be made as follows:

Header Field Name: Replay-Nonce
Template:
Protocol: http
Status: standard
Reference: [ RFC-to-be Section 6.4.1 ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fourth, in the JSON Web Signature and Encryption Header Parameters registry on the JSON Object Signing and Encryption (JOSE) registry page located at:

https://www.iana.org/assignments/jose/

a single, new registration will be made as follows:

Header Parameter Name: url
Header Parameter Description: URL
Header Parameter Usage Location(s): JWE, JWS
Change Controller: IESG
Reference: [ RFC-to-be Section 6.3.1 ]

As this also requests a registration in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Fifth, also in the JSON Web Signature and Encryption Header Parameters registry on the JSON Object Signing and Encryption (JOSE) registry page located at:

https://www.iana.org/assignments/jose/

a single, new registration will be made as follows:

Header Parameter Name: nonce
Header Parameter Description: Nonce
Header Parameter Usage Location(s): JWE, JWS
Change Controller: IESG
Reference: [ RFC-to-be Section 6.4.2 ]

As this also requests a registration in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

Sixth, in the IETF URN Sub-namespace for Registered Protocol Parameter Identifiers registry on the Uniform Resource Name (URN) Namespace for IETF Use registry page located at:

https://www.iana.org/assignments/params/

a single, new registration will be made as follows:

Registered Parameter Identifier: acme
Reference: [ RFC-to-be ]
IANA Registry Reference: [ TBD-at-Registration ]

The remainder of the requests in the IANA Considerations section of the current version of the document requests the creation of seven new registries.

1. ACME Account Object Fields (Section 9.7.1)
2. ACME Order Object Fields (Section 9.7.2)
3. ACME Error Types (Section 9.7.4)
4. ACME Resource Types (Section 9.7.5)
5. ACME Directory Metadata Fields (Section 9.7.6)
6. ACME Identifier Types (Section 9.7.7)
7. ACME Validation Methods (Section 9.7.8)

IANA Question --> Where should these new registries be located? Should they be added to an existing registry page? If not, do they belong in an existing category at http://www.iana.org/protocols?

IANA Question --> Section 9.7.3 appears to request the creation of a new registry for fields in authorization objects, but the request does not appear in the list in the introduction to Section 9. Do the authors intend that Section 9.7.3 define an additional, new registry that is not listed in Section 9?

Seventh, a new registry is to be created called the ACME Account Object Fields registry. The location of the new registry will be determined at a later time. The registration rules for the new registry are Specification Required as defined in [ RFC 8126 ].

There are initial registrations in the new registry as follows:

+------------------------+-------------+--------------+----------------+
| Field Name | Field Type | Configurable | Reference |
+------------------------+-------------+--------------+----------------+
| status | string | false | [ RFC-to-be ] |
| | | | |
| contact | array of | true | [ RFC-to-be ] |
| | string | | |
| | | | |
| externalAccountBinding | object | true | [ RFC-to-be ] |
| | | | |
| termsOfServiceAgreed | boolean | true | [ RFC-to-be ] |
| | | | |
| orders | string | false | [ RFC-to-be ] |
+------------------------+-------------+--------------+----------------+

Eighth, a new registry is to be created called the ACME Order Object Fields registry. The location of the new registry will be determined at a later time. The registration rules for the new registry are Specification Required as defined in [ RFC 8126 ].

There are initial registrations in the new registry as follows:

+----------------+-----------------+--------------+----------------+
| Field Name | Field Type | Configurable | Reference |
+----------------+-----------------+--------------+----------------+
| status | string | false | [ RFC-to-be ] |
| | | | |
| expires | string | false | [ RFC-to-be ] |
| | | | |
| identifiers | array of object | true | [ RFC-to-be ] |
| | | | |
| notBefore | string | true | [ RFC-to-be ] |
| | | | |
| notAfter | string | true | [ RFC-to-be ] |
| | | | |
| authorizations | array of string | false | [ RFC-to-be ] |
| | | | |
| finalize | string | false | [ RFC-to-be ] |
| | | | |
| certificate | string | false | [ RFC-to-be ] |
+----------------+-----------------+--------------+----------------+

Ninth, a new registry is to be created called the ACME Error Types registry. The location of the new registry will be determined at a later time. The registration rules for the new registry are Specification Required as defined in [ RFC 8126 ].

There are initial registrations in the new registry as follows:

[ Note that the reference for each one of the new registrations is to be [ RFC-to-be ] ]
+-------------------------+-----------------------------------------+
| Type | Description |
+-------------------------+-----------------------------------------+
| badCSR | The CSR is unacceptable (e.g., due to a |
| | short key) |
| | |
| badNonce | The client sent an unacceptable anti- |
| | replay nonce |
| | |
| badSignatureAlgorithm | The JWS was signed with an algorithm |
| | the server does not support |
| | |
| invalidContact | A contact URL for an account was |
| | invalid |
| | |
| unsupportedContact | A contact URL for an account used an |
| | unsupported protocol scheme |
| | |
| externalAccountRequired | The request must include a value for |
| | the "externalAccountBinding" field |
| | |
| accountDoesNotExist | The request specified an account that |
| | does not exist |
| | |
| malformed | The request message was malformed |
| | |
| rateLimited | The request exceeds a rate limit |
| | |
| rejectedIdentifier | The server will not issue for the |
| | identifier |
| | |
| serverInternal | The server experienced an internal |
| | error |
| | |
| unauthorized | The client lacks sufficient |
| | authorization |
| | |
| unsupportedIdentifier | Identifier is not supported, but may be |
| | in future |
| | |
| userActionRequired | Visit the "instance" URL and take |
| | actions specified there |
| | |
| badRevocationReason | The revocation reason provided is not |
| | allowed by the server |
| | |
| caa | Certification Authority Authorization |
| | (CAA) records forbid the CA from |
| | issuing |
| | |
| dns | There was a problem with a DNS query |
| | |
| connection | The server could not connect to |
| | validation target |
| | |
| tls | The server received a TLS error during |
| | validation |
| | |
| incorrectResponse | Response received didn't match the |
| | challenge's requirements |
+-------------------------+-----------------------------------------+

Tenth, a new registry is to be created called the ACME Resource Types registry. The location of the new registry will be determined at a later time. The registration rules for the new registry are Specification Required as defined in [ RFC 8126 ].

There are initial registrations in the new registry as follows:

+------------+--------------------+----------------+
| Field Name | Resource Type | Reference |
+------------+--------------------+----------------+
| newNonce | New nonce | [ RFC-to-be ] |
| | | |
| newAccount | New account | [ RFC-to-be ] |
| | | |
| newOrder | New order | [ RFC-to-be ] |
| | | |
| newAuthz | New authorization | [ RFC-to-be ] |
| | | |
| revokeCert | Revoke certificate | [ RFC-to-be ] |
| | | |
| keyChange | Key change | [ RFC-to-be ] |
| | | |
| meta | Metadata object | [ RFC-to-be ] |
+------------+--------------------+----------------+

Eleventh, a new registry is to be created called the ACME Directory Metadata Fields registry. The location of the new registry will be determined at a later time. The registration rules for the new registry are Specification Required as defined in [ RFC 8126 ].

There are initial registrations in the new registry as follows:

+-------------------------+-----------------+----------------+
| Field Name | Field Type | Reference |
+-------------------------+-----------------+----------------+
| termsOfService | string | [ RFC-to-be ] |
| | | |
| website | string | [ RFC-to-be ] |
| | | |
| caaIdentities | array of string | [ RFC-to-be ] |
| | | |
| externalAccountRequired | boolean | [ RFC-to-be ] |
+-------------------------+-----------------+----------------+

Twelveth, a new registry is to be created called the ACME Identifier Types registry. The location of the new registry will be determined at a later time. The registration rules for the new registry are Specification Required as defined in [ RFC 8126 ].

There are initial registrations in the new registry as follows:

+-------+----------------+
| Label | Reference |
+-------+----------------+
| dns | [ RFC-to-be ] |
+-------+----------------+

Thirteenth, a new registry is to be created called the ACME Validation Methods registry. The location of the new registry will be determined at a later time. The registration rules for the new registry are Specification Required as defined in [ RFC 8126 ].

There are initial registrations in the new registry as follows:

+------------+-----------------+------+----------------+
| Label | Identifier Type | ACME | Reference |
+------------+-----------------+------+----------------+
| http-01 | dns | Y | [ RFC-to-be ] |
| | | | |
| dns-01 | dns | Y | [ RFC-to-be ] |
| | | | |
| tls-sni-01 | RESERVED | N | N/A |
| | | | |
| tls-sni-02 | RESERVED | N | N/A |
+------------+-----------------+------+----------------+

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-04-18):

From: The IESG
To: IETF-Announce
CC: Yoav Nir , draft-ietf-acme-acme@ietf.org, acme@ietf.org, ynir.ietf@gmail.com, Kathleen.Moriarty.ietf@gmail.com, acme-chairs@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Automatic Certificate Management Environment (ACME)) to Proposed Standard


The IESG has received a request from the Automated Certificate Management
Environment WG (acme) to consider the following document: - 'Automatic
Certificate Management Environment (ACME)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-04-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  Certificates in PKI using X.509 (PKIX) are used for a number of
  purposes, the most significant of which is the authentication of
  domain names.  Thus, certificate authorities in the Web PKI are
  trusted to verify that an applicant for a certificate legitimately
  represents the domain name(s) in the certificate.  Today, this
  verification is done through a collection of ad hoc mechanisms.  This
  document describes a protocol that a certification authority (CA) and
  an applicant can use to automate the process of verification and
  certificate issuance.  The protocol also provides facilities for
  other certificate management functions, such as certificate
  revocation.

  RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for
  this draft is maintained in GitHub.  Suggested changes should be
  submitted as pull requests at https://github.com/ietf-wg-acme/acme
  [1].  Instructions are on that page as well.  Editorial changes can
  be managed in GitHub, but any substantive change should be discussed
  on the ACME mailing list (acme@ietf.org).




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/ballot/


No IPR declarations have been submitted directly on this I-D.

Last call has been extended an additional 2 weeks due to last call being issued during an IETF meeting.

Summary
  Richard Barnes, Jacob Hoffman-Andrews, and James Kasten are the authors.
  Yoav Nir is the document shepherd. Kathleen Moriarty is the responsible Area
  Director.
 
  Certificates in PKI using X.509 (PKIX) are used for a number of
  purposes, the most significant of which is the authentication of
  domain names.  Thus, certificate authorities in the Web PKI are
  trusted to verify that an applicant for a certificate legitimately
  represents the domain name(s) in the certificate.  Today, this
  verification is done through a collection of ad hoc mechanisms.  This
  document describes a protocol that a certification authority (CA) and
  an applicant can use to automate the process of verification and
  certificate issuance.  The protocol also provides facilities for
  other certificate management functions, such as certificate
  revocation.
 
Review and Consensus
  This document represents the consensus of the ACME working group. The draft
  has been the main document of the group for the last two years, and has been
  through WGLC since February 2017.
  Much of the discussion since then has been feedback from commercial CAs
  about integrating the protocol with their processes. Several of them are now
  committed to deploy this protocol following publication.
  Most of the session in IETF 99 was devoted to verifying that there are no
  more open issues for this draft.

Intellectual Property
  The authors have stated that they do not have any IPR related to this
  document, and that they are not aware of any IPR claims made by others about
  the content of this document.

Other Points
  None
 

Summary
  Richard Barnes, Jacob Hoffman-Andrews, and James Kasten are the authors.
  Yoav Nir is the document shepherd. Kathleen Moriarty is the responsible Area
  Director.
 
  Certificates in PKI using X.509 (PKIX) are used for a number of
  purposes, the most significant of which is the authentication of
  domain names.  Thus, certificate authorities in the Web PKI are
  trusted to verify that an applicant for a certificate legitimately
  represents the domain name(s) in the certificate.  Today, this
  verification is done through a collection of ad hoc mechanisms.  This
  document describes a protocol that a certification authority (CA) and
  an applicant can use to automate the process of verification and
  certificate issuance.  The protocol also provides facilities for
  other certificate management functions, such as certificate
  revocation.
 
Review and Consensus
  This document represents the consensus of the ACME working group. The draft
  has been the main document of the group for the last two years, and has been
  through WGLC since February 2017.
  Much of the discussion since then has been feedback from commercial CAs
  about integrating the protocol with their processes. Several of them are now
  committed to deploy this protocol following publication.
  Most of the session in IETF 99 was devoted to verifying that there are no
  more open issues for this draft.

Intellectual Property
  The authors have stated that they do not have any IPR related to this
  document, and that they are not aware of any IPR claims made by others about
  the content of this document.

Other Points
  None
 

As we agreed at IETF-97 (Seoul), we will have a slightly longer WGLC period to encourage implementations and interop.

Are there any volunteers to read and review this document?  Please post to acme@ietf.org.

Does anyone have an implementation in progress and would be interested in doing interop at the IETF Hackathon at IETF-98 in Chicago?  Please post to acme@ietf.org