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

2017-02-17 Thread Jacob Hoffman-Andrews 
On 02/17/2017 02:41 PM, Roland Bracewell Shoemaker wrote:
> 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?
Good point. I added a short section of errors likely to happen at
issuance time (caa and serverInternal).

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

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

2017-02-17 Thread Roland Bracewell Shoemaker 
+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:
> 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 
> 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   
> |
> +|

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

2017-02-17 Thread Jacob Hoffman-Andrews 
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 
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):
 :

Re: [Acme] Clarifying what to do with revocation requests with disallowed reasonCodes

2017-02-17 Thread Roland Bracewell Shoemaker 
We could add a new error type and accompany the problem document with an
extra field that defines the valid reason codes à la the 'alg' field
that is added when we return 'badSignatureAlgorithm'.

On 02/16/2017 08:16 AM, Daniel McCarney wrote:
> +1 - I think this is clearer.
> 
> Would you be open to specifying what form the rejection takes? Do you
> think it
> would be advantageous to specify a new error in Section 5.7 for the purpose
> (e.g. `urn:ietf:params:acme:error:invalidReasonCode`) or is there an
> existing
> candidate you'd use?
> 
> 
> On Tue, Feb 14, 2017 at 5:53 PM, Roland Bracewell Shoemaker
> > wrote:
> 
> The current draft leaves it ambiguous as to what the server should do
> when a it receives a revocation request containing a reasonCode that it
> disallows. I suggest we add a simple 'MUST reject request' clause to the
> relevant section to resolve this ambiguity.
> 
> PR: https://github.com/ietf-wg-acme/acme/pull/251
> 
> 
> ___
> Acme mailing list
> Acme@ietf.org 
> https://www.ietf.org/mailman/listinfo/acme
> 
> 
> 

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Remove extraneous key equivalence method

2017-02-17 Thread Roland Bracewell Shoemaker 
The spec currently defines an entirely new JWK key equivalence method
which is then only used once. Instead of adding this new method (which
seems to just be a the JWK thumbprint computation minus the use of a
digest) I propose we just re-work the key roll-over method to work
without having to compare the 'newKey' and the key used to sign the
inner JWS.

The simplest method here seems to be to just check that the 'newKey'
also verifies the inner JWS. Proposed change here:
https://github.com/ietf-wg-acme/acme/pull/263

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] Inconsistent abbreviations for resource names

2017-02-17 Thread Niklas Keller 
Morning,

the current draft contains a few inconsistencies in the resource naming.

1) https://ietf-wg-acme.github.io/acme/#rfc.section.6.1 mentions
"revoke-certificate", while it's called "revoke-cert" in the rest of the
document.

2) There's "new-account", but the account resource is called "acct", I
think it should be "account" everywhere. We don't gain anything by saving a
few keystrokes / bytes there.

Maybe we should then also rename "authz" to "authorization" and "cert" to
"certificate" everywhere.

Regards, Niklas
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] HPKP in ACME

2017-02-17 Thread Josh Soref 
Fwiw, I'm slowly reviewing[1] the specification.

Personally, for this version I'd be +1 on dropping the current pinning
text.

If you wanted to go with a weak statement, I think the statements you want
are:
1. Acme clients may support key pinning.
2. If an Acme client supports pinning, it should provide a way to enable
users to drop pins.

This enables servers to experiment without saying that any will.

[1] https://github.com/jsoref/acme/tree/review
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] HPKP in ACME

2017-02-17 Thread Daniel McCarney 
> Perhaps we could downgrade to MAY WISH TO
> https://tools.ietf.org/html/rfc6919#section-6

This feels a little wishy-washy for something I think we could tie-break
without
too much delay.

Jacob, Clint, and myself all stated support for removing it. You're OK with
dropping it. I think Alan is in a similar mid-point camp. (Please weigh in
if
I'm mis-characterizing)

Does anyone else feel strongly? Can we aim for consensus for
Monday?


On Thu, Feb 16, 2017 at 5:44 PM, Richard Barnes  wrote:

>
>
> On Thu, Feb 16, 2017 at 4:24 PM, Daniel McCarney 
> wrote:
>
>> I'm supportive of removing the server pinning headers SHOULD outright.
>>
>> > but how best to word that i don't know
>>
>> I don't think there's much benefit in the ACME spec discussing pinning
>> from
>> a client perspective.
>>
>> If the clients want to pin there isn't anything about ACME that makes the
>> process different than (for e.g.) using square's okhttp library to pin
>> for any
>> other HTTPS server. Am I overlooking something?
>>
>
> There's nothing different.  The idea here was just to point people to some
> mechanisms they could use to guard against mis-issuance.  I'm OK dropping
> it if people don't like it, but I would kind of like to keep it.
>
> Perhaps we could downgrade to MAY WISH TO
> https://tools.ietf.org/html/rfc6919#section-6
>
>
>
>
>
>>
>>
>> On Mon, Feb 13, 2017 at 3:29 PM, Alan Doherty 
>> wrote:
>>
>>> I would concur that clients should endeavour to support
>>>
>>> (and thusly CAs can consider using in future, when support is available
>>> in wider librarys)
>>>
>>> but because of the risks they should only consider doing so
>>> if/when all their processes are in place to ensure failures can't occur
>>>
>>> but how best to word that i don't know
>>>
>>> At 20:09 13/02/2017  Monday, Clint Wilson wrote:
>>> >I would definitely support removing ", and servers SHOULD emit pinning
>>> headers", especially because of the footgun risk you indicated, but I think
>>> there is some merit in continuing to recommend support for HPKP on the
>>> client side.
>>> >
>>> >On Mon, Feb 13, 2017 at 12:33 PM Jacob Hoffman-Andrews <>> j...@eff.org>j...@eff.org> wrote:
>>> >Martin brought up a section I've been considering removing:
>>> >
>>> >> Clients SHOULD support HTTP public key pinning [RFC7469], and servers
>>> >SHOULD emit pinning headers.
>>> >
>>> >Here's my reasoning:
>>> >
>>> >- Public key pinning isn't implemented in most HTTPS libraries outside
>>> >of browsers, so this is a considerable burden on implementers.
>>> >- Public key pinning carries a fairly high risk of footgunning. The
>>> >consequence of a failed pin for a CA that serves many ACME clients would
>>> >be that some of those clients would fail to renew their certs, causing
>>> >cascading breakage.
>>> >- There is relatively little confidential information conveyed in ACME,
>>> >and there are other defenses built into ACME (like including the account
>>> >key as part of the challenge data), so HPKP is not strongly necessary.
>>> >
>>> >Any objections?
>>> >
>>> >PR to remove: 
>>> https://github.com/ietf-wg-acme/acme/pull/244
>>> >
>>> >___
>>> >Acme mailing list
>>> >Acme@ietf.org
>>> >https://www.ietf.org/mailman/listinfo/acme
>>> >
>>> >___
>>> >Acme mailing list
>>> >Acme@ietf.org
>>> >https://www.ietf.org/mailman/listinfo/acme
>>>
>>> ___
>>> Acme mailing list
>>> Acme@ietf.org
>>> https://www.ietf.org/mailman/listinfo/acme
>>>
>>
>>
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
>>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] UX design by standards

2017-02-17 Thread Josh Soref 
I'm still working on reviewing the document. I have one large PR which
I haven't finished and haven't published, and I have an entire design
issue (relating to errors) which I want to talk about. (And I need to
file a bug against rfc7807.) But...


> Clients SHOULD display the "detail" field of all errors. [1]

I'm reminded ... there was one specification (i can't remember if it
was Cookie, HTTP, or HTML) which had a UAs must tell users about
something (redirects? cookies?).

Browser authors never implemented the thing I'm thinking about (all I
remember is this quirk, I can't remember which thing it was).


[1] 
https://github.com/ietf-wg-acme/acme/blob/68a87b4/draft-ietf-acme-acme.md#errors

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme