Subject: [Acme] I-D Action: draft-ietf-acme-acme-07.txt

From: [email-masked]
Date: Wed, 21 Jun 2017 12:00:52 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Automated Certificate Management Environment of the IETF.

        Title           : Automatic Certificate Management Environment (ACME)
        Authors         : Richard Barnes
                          Jacob Hoffman-Andrews
                          James Kasten
	Filename        : draft-ietf-acme-acme-07.txt
	Pages           : 74
	Date            : 2017-06-21

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.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-acme-acme/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-acme-acme-07
https://datatracker.ietf.org/doc/html/draft-ietf-acme-acme-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-acme-acme-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ted Hardie <[email-masked]>
Date: Wed, 21 Jun 2017 12:20:19 -0700

Howdy,

We'd like to start a short working group last call on the changes made in
response to the previous last call.  It will end June 28th, 2017, any time
zone (to accommodate any changes needed before the draft deadline the
following Monday).

Please review carefully, but please respect the discussion which have
already been held by focusing on new issues or new information about the
issues that have been resolved.

thanks,

Ted, Rich, (and now) Yoav

---------- Forwarded message ----------
From: <[email-masked]>
Date: Wed, Jun 21, 2017 at 12:00 PM
Subject: [Acme] I-D Action: draft-ietf-acme-acme-07.txt
To: [email-masked]
Cc: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Automated Certificate Management
Environment of the IETF.

        Title           : Automatic Certificate Management Environment
(ACME)
        Authors         : Richard Barnes
                          Jacob Hoffman-Andrews
                          James Kasten
        Filename        : draft-ietf-acme-acme-07.txt
        Pages           : 74
        Date            : 2017-06-21

Abstract:

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

---

From: Marcos Sanz <[email-masked]>
Date: Thu, 22 Jun 2017 10:59:50 +0200

> We'd like to start a short working group last call on the changes made 
in response to the previous last call.  It will end June 
> 28th, 2017, any time zone (to accommodate any changes needed before the 
draft deadline the following Monday).

There is this sentence in the security considerations (10.2 Integrity of 
Authorizations) that strikes me as extremely misleading:

"All of the challenges above have a binding between the account private 
key and the validation query made by the server, via the key 
authorization.  The key authorization is signed by the account private 
key, reflects the corresponding public key, and is provided to the server 
in the validation response."

The key authorization itself does NOT contain the signature of the 
account's key. It gets though signed by the account's key later on in the 
challenge response (not the validation response) over the ACME channel 
(not the validation channel). What about saying that in the chronological 
order of events:

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

Best regards,
Marcos

---

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 23 Jun 2017 09:33:46 -0400

I do not believe that I got an answer to my pre-authorization question here:
https://www.ietf.org/mail-archive/web/acme/current/msg01991.html

What would be the response of the server if the client sends the
certificate issuance request after it sends the pre-authorization request
but
before it completes the pre-authorization process?

Would the server reply with the same challenges it provided in the response
to the pre-authorization request?

Regards,
 Rifaat

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 26 Jun 2017 17:15:26 +0300

> Ted, Rich, (and now) Yoav

I was trying to write some code, and noticed a potential inconsistency:

Section 7.5.1 has in example (responding to HTTP-01 challenge):

"payload": base64url({
  "type": "http-01",
  "keyAuthorization": "IlirfxKKXA...vb29HhjjLPSggwiE"
}),

... Type field is present.

But section 8.3 has:

"payload": base64url({
  "keyAuthorization": "evaGxfADs...62jcerQ"
}),

... No type field.

And section 8.4 has:

"payload": base64url({
  "keyAuthorization": "evaGxfADs...62jcerQ"
}),

... No type field.

And section 8.5:

"payload": base64url({
  "keyAuthorization": "evaGxfADs...62jcerQ"
}),

...Ditto.

Is the type supposed to be present (I presume yes)?

-Ilari

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 26 Jun 2017 12:52:41 -0700

>   "keyAuthorization": "evaGxfADs...62jcerQ"
In general, ACME has "partial update" semantics on POSTs. So fields that
aren't changing, or aren't permitted to be changed by the client, like
"type", "status", "url" and "token", can be omitted. The spec says:

> The server updates the authorization document by updating its
representation of the challenge with the response fields provided by the
client.
> The server MUST ignore any fields in the response object that are not
specified as response fields for this type of challenge. The server
provides a 200 (OK) response with the updated challenge object as its body.

This is actually a bit confusing because we don't ever define "response
fields", but they are defined by the individual challenge types. We
should probably update the parts of those challenge definitions that
define response fields to describe them that way.
https://github.com/ietf-wg-acme/acme/issues/329

For DNS-01, HTTP-01, and TLS-SNI-02, the only response field is
"keyAuthorization". For OOB-01, the only response field is "type". I
suspect this was just to avoid having an empty payload, but I think an
empty payload is fine, and this is confusingly different from the
others, so we should change OOB-01 to just take an empty payload.
https://github.com/ietf-wg-acme/acme/issues/328

So, of the examples you point out, the one in 7.5.1 should be updated to
remove the "type" field: https://github.com/ietf-wg-acme/acme/pull/327.