Subject: [Acme] Split up errors and add an error field to orders

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 17 Feb 2017 13:02:07 -0800

https://github.com/ietf-wg-acme/acme/pull/264

Removes dnssec error type for a broader "dns" error type. It's very hard
to split out dnssec errors from regular dns problems, because recursive
resolvers can only return SERVFAIL. The new dns error type also subsumes
"unknownHost."

Introduces a new "incorrectResponse" error type for cases where
connection and request were both successful, but the content didn't match.

This also splits out the error table by the places they tend to occur:
In response to ACME requests, or in the "error" field of authorization
objects.

Introduces an error field for orders. Orders can fail independent of
authorizations because of last-minute CAA checking, failure to submit to
CT logs, timeouts, etc.

>From 7678e4ce122456c8d7c609a3fff99ebfe1ad865b Mon Sep 17 00:00:00 2001
From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 17 Feb 2017 12:52:07 -0800
Subject: [PATCH] Split up errors and add an error field to orders.

---
 draft-ietf-acme-acme.md | 32 ++++++++++++++++++++++++--------
 1 file changed, 24 insertions(+), 8 deletions(-)

diff --git a/draft-ietf-acme-acme.md b/draft-ietf-acme-acme.md
index 87810ea..ecbdd1a 100644
--- a/draft-ietf-acme-acme.md
+++ b/draft-ietf-acme-acme.md
@@ -479,28 +479,38 @@ server MAY return status code 405 (Method Not Allowed).
 When the server responds with an error status, it SHOULD provide additional
 information using problem document {{!RFC7807}}.  To facilitate automatic
 response to errors, this document defines the following standard tokens for use
-in the "type" field (within the "urn:ietf:params:acme:error:" namespace):
+in the "type" field (within the "urn:ietf:params:acme:error:" namespace).
+
+Error types that may be commonly returned from ACME requests:
 
 | 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   |
-| caa                   | CAA records forbid the CA from issuing                             |
-| connection            | The server could not connect to validation target                  |
-| dnssec                | DNSSEC validation failed                                           |
 | invalidContact        | The contact URI 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                          |
-| unknownHost           | The server could not resolve a domain name                         |
 | unsupportedIdentifier | Identifier is not supported, but may be in future                  |
-| userActionRequired    | The user visit the "instance" URL and take actions specified there |
+| userActionRequired    | Visit the "instance" URL and take actions specified there          |
+
+Error types that may be commonly included in the "error" field of challenge
+resources:
+
+| Code                  | Description                                                        |
+|:----------------------|:-------------------------------------------------------------------|
+| caa                   | CAA records forbid the CA from issuing                             |
+| connection            | The server could not connect to validation target                  |
+| dns                   | There was a problem with a DNS query during validation             |
+| rateLimited           | The request exceeds a rate limit                                   |
+| serverInternal        | The server experienced an internal error                           |
+| incorrectResponse     | Response received didn't match the challenge's requirements        |
+| tls                   | The server received a TLS error during validation                  |
 
-This list is not exhaustive. The server MAY return errors whose "type" field is
+These lists are 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 for errors other than the standard types.  Clients SHOULD display the
 "detail" field of all errors.
@@ -765,6 +775,12 @@ notAfter (optional, string):
 : The requested value of the notAfter field in the certificate, in the date
 format defined in {{!RFC3339}}.
 
+error (optional, object):
+: The error that occurred while the server was issuing the certificate, if any.
+This field is structured as a problem document {{!RFC7807}}. Note that
+this field is only for errors occurring after authorizations have been
+validated.
+
 authorizations (required, array of string):
 : For pending orders, the authorizations that the client needs to complete
 before the requested certificate can be issued (see

---

From: Roland Bracewell Shoemaker <[email-masked]>
Date: Fri, 17 Feb 2017 14:41:34 -0800

+1 this seems like a good change. I've left one typo comment on the PR
(code -> type).

Splitting the tables up based on where the errors may be encountered is
useful but adding the new 'error' field to the order object makes this
slightly confusing. Will the errors on the order be from the first table
or the second, or an entirely different set?

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

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 17 Feb 2017 14:44:55 -0800

> or the second, or an entirely different set?
Good point. I added a short section of errors likely to happen at
issuance time (caa and serverInternal).

---

From: Hugo Landau <[email-masked]>
Date: Mon, 20 Feb 2017 02:54:38 +0000

Mostly fine, some comments:

If a server processes different things in parallel, multiple errors
could occur. Should the "error" field be an array?

Moreover, is there any utility in mandating that this "error" field only
be used after (all?) authorizations have been completed? That meshes
with the implementation model this list is expecting, but it seems
simpler from a client implmentation perspective simply for the client to
balk whenever it retrieves an order object which has an error set on it.
This maximizes the flexibility of implementation on the server side.

-- 
Hugo Landau
I know of no warrant or notice of a kind defined within the Investigatory
Powers Act 2016 or the Regulation of Investigatory Powers Act 2000 that has not
been brought to the attention of the public. I will always answer questions
about these or similar matters, assuming reasonable request rates, unless
legally prevented from doing so.

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Fri, 24 Feb 2017 19:20:38 -0800

> could occur. Should the "error" field be an array?
Reading the Problem Document spec, it seems like the expected way to
handle multiple errors is with fields within the problem document,
rather than multiple problem documents.

The way Boulder has handled this has been to pick the error that matters
most. For instance, if there was a validation failure and a CAA failure,
report the validation failure, because when both fail it's usually
because of a DNS problem. However, it would also be entirely possible to
represent multiple errors in plain text.
> This maximizes the flexibility of implementation on the server side.
Yep, good point. Now it's just:

error (optional, object):
: The error that occurred while processing the order, if any.
This field is structured as a problem document {{!RFC7807}}.