Subject: [Acme] Editorial fixes in GitHub

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 19 Jan 2017 11:55:40 -0800

Hi all,

I did a top-to-bottom review of the spec to look for coherency (since
we've changed a number of concepts), mistakes, and general consistency.
I filed several pull requests on GitHub:

https://github.com/ietf-wg-acme/acme/pull/231
https://github.com/ietf-wg-acme/acme/pull/232
https://github.com/ietf-wg-acme/acme/pull/233
https://github.com/ietf-wg-acme/acme/pull/234
https://github.com/ietf-wg-acme/acme/pull/235

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 23 Jan 2017 14:46:45 -0800

In review, Rich pointed out that some of these are more substantive and
should be reviewed as such, so I broke them out into their own PRs:

Remove SCT link relation. https://github.com/ietf-wg-acme/acme/pull/234
Specify multi-viewpoint validation.
https://github.com/ietf-wg-acme/acme/pull/239
Specify server MAY follow HTTP redirects.
https://github.com/ietf-wg-acme/acme/pull/238

Note: the last one is more of a clarification of current behavior, since
HTTP already says "MAY" for redirects. But a lot of ACME implementers
have been surprised to hear that redirects are followed, so I think it's
important to clarify.

On 01/19/2017 11:55 AM, Jacob Hoffman-Andrews wrote:
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Daniel McCarney <[email-masked]>
Date: Tue, 24 Jan 2017 10:07:15 -0500

I've reviewed each and left comments or positive +1's in the form of
approved
Github reviews.

I'm in favour of removing the SCT link relation. It's unnecessary and as
Richard pointed out, easy to add back if it turns out the other SCT delivery
mechanisms aren't sufficient for a concrete use-case.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 25 Jan 2017 13:29:40 +0000

WG members.  We'd like to get into last call very soon.

Please look at the issues that Jacob lists below and post commentary here.

> Specify multi-viewpoint validation. https://github.com/ietf-wg-acme/acme/pull/239
> Specify server MAY follow HTTP redirects. https://github.com/ietf-wg-acme/acme/pull/238
> 
> Note: the last one is more of a clarification of current behavior, since HTTP
> already says "MAY" for redirects. But a lot of ACME implementers have been
> surprised to hear that redirects are followed, so I think it's important to
> clarify.

---

From: Josh Soref <[email-masked]>
Date: Wed, 25 Jan 2017 08:32:45 -0500

Please don't. I just started and haven't had time to explain the problems certbot and boulder are experiencing. 

But, on the spot:
The error handling approach doesn't scale well, doesn't lead to good errors for end users, and makes it virtually impossible for clients (like certbot) to provide localized error messages.

---

From: Niklas Keller <[email-masked]>
Date: Wed, 25 Jan 2017 17:28:34 +0100

I already posted a comment on GitHub, but didn't get a response there, so
I'm posting here again.

> Standardize on new-account rather than new-acct; previously there was a
mix.

"authz" and "new-authz" seem to be the only abbreviated resources now. I
guess we should change that one to new-authorization then? Feels
inconsistent in the current way.

https://github.com/ietf-wg-acme/acme/pull/232#issuecomment-273894220

Regards, Niklas

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 25 Jan 2017 19:57:43 +0200

On Wed, Jan 25, 2017 at 08:32:45AM -0500, Josh Soref wrote:
> Please don't. I just started and haven't had time to explain the
> problems certbot and boulder are experiencing. 
> 
> But, on the spot:
> The error handling approach doesn't scale well, doesn't lead to
> good errors for end users, and makes it virtually impossible for
> clients (like certbot) to provide localized error messages.

The primary task of those error message is for users to troubleshoot.

>From LE community forum threads, the following seem to be the most
frequent validation errors (in no practicular order)

- Rate limiting errors (certs per FQDNset)
- Rate limiting errors (certs per domain).
- Bad DNS names requested
- DNS names classed as high-risk.
- DNS names blocked by GSB.
- NXDOMAIN from DNS.
- Horked DNS server doesn't understand 0x20 hack.
- Horked DNS server barfs on CAA records.
- Various temporary DNS server horkage (rarely DNSSEC).
- Only RFC1918 IP in DNS (for HTTP-01/TLS-SNI-01).
- No IPs at all (no A nor AAAA) in DNS (for HTTP-01/TLS-SNI-01)
- Wrong IP in DNS.
- Connect failure to 80 or 443 port (either firewall or not
  listening at all).
- Port 443 responding with HTTP (yes, really).
- HTTP-01 responds with 4XX error.
- HTTP-01 responds with spew of HTML with 200 code
- HTTP-01 redirects to unexpected place.
- TLS-SNI-01 sends some default cert.
- TLS-SNI-01 sends fatal alert.
- DNS-01 propagation failure.

Of course, most have variety of causes.

-Ilari

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 25 Jan 2017 10:00:52 -0800

On 01/25/2017 08:28 AM, Niklas Keller wrote:
> I already posted a comment on GitHub, but didn't get a response there,
> so I'm posting here again.
>
> > Standardize on new-account rather than new-acct; previously there
> was a mix.
>
> "authz" and "new-authz" seem to be the only abbreviated resources now.
> I guess we should change that one to new-authorization then? Feels
Yep, agreed. Also, we have a number of "asdf" tokens still in there that
I'd like to change to something a little more formal.

I think this change would conflict with some of my outstanding
purely-editorial PRs, so I'm waiting on merging them.

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Wed, 25 Jan 2017 11:17:43 -0800

> mechanisms aren't sufficient for a concrete use-case.

I'm fine losing this as LE doesn't plan on implementing it but I think
there is a valid argument to keep it if any other CA plans on
implementing ACME and CT but not embedding SCTs.

That said if it does stay the language definitely needs to be reworked
as it currently implies a certificate would only have a single SCT and
provides no guidance to how a list of SCTs should be presented to the
client/user from the endpoint.

> 
> On Mon, Jan 23, 2017 at 5:46 PM, Jacob Hoffman-Andrews <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Remove SCT link relation.
>     <https://github.com/ietf-wg-acme/acme/pull/234>
>     <https://github.com/ietf-wg-acme/acme/pull/239>
>     <https://github.com/ietf-wg-acme/acme/pull/238>
> 
>     <https://github.com/ietf-wg-acme/acme/pull/231>
>     <https://github.com/ietf-wg-acme/acme/pull/232>
>     <https://github.com/ietf-wg-acme/acme/pull/233>
>     <https://github.com/ietf-wg-acme/acme/pull/234>
>     <https://github.com/ietf-wg-acme/acme/pull/235>
>     >
>     > [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/acme>
>     >
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/acme>
> 
> 
> 
>