Re: [Acme] Optional "Wildcard" authorization field

2018-03-02 Thread Daniel McCarney
Richard: That's up to the client and the situation. In the linked Certbot issues there were questions about error output/UX. In this case if the client saw an error attached to an authorization with the identifier `{ "type": "dns", "value": "example.com"}` and the authorization had `wildcard:

[Acme] Optional "Wildcard" authorization field

2018-03-02 Thread Daniel McCarney
Hi folks, There is a slight disconnect with the current specification between identifiers in newOrder/newAuthz requests and identifiers in authorization objects. The former is allowed to include wildcard domains in the value of DNS type identifiers while the latter is forbidden. Let's Encrypt's

Re: [Acme] Optional "Wildcard" authorization field

2018-03-02 Thread Richard Barnes
Daniel: I don't have a strong objection here, but could you elaborate what the client is expected to do differently based on this flag? On Fri, Mar 2, 2018 at 12:22 PM, Daniel McCarney wrote: > Hi folks, > > There is a slight disconnect with the current specification

Re: [Acme] -09 draft: Challenge objects?

2018-03-02 Thread Daniel McCarney
> > Would it be sensible to move the common list of parameters there as well, > for parity with how the other object types are described? I think the forward pointer is probably sufficient. Richard: What do you think? On Fri, Mar 2, 2018 at 10:43 AM, Felipe Gasper

Re: [Acme] Optional "Wildcard" authorization field

2018-03-02 Thread Felipe Gasper
One (fairly) obvious use of the “wildcard” flag is for status reporting without the context of the original newOrder. The client can thus more easily say: Authorization for “*.example.com”: $message … without having to correlate the authz object with the order. -FG > On Mar 2, 2018, at 12:32

Re: [Acme] Optional "Wildcard" authorization field

2018-03-02 Thread Richard Körber
Hi! I also see the problem that clients might get confused because there are seemingly two authentications for the very same domain ("example.com"). Without a proper flag, they could only be distinguished by the different set of challenges, but that would assume knowledge of server internas.

Re: [Acme] Optional "Wildcard" authorization field

2018-03-02 Thread Richard Körber
Hi! I also see the problem that clients might get confused because there are seemingly two authentications for the very same domain ("example.com"). Without a proper flag, they could only be distinguished by the different set of challenges, but that would assume knowledge of server internas.

Re: [Acme] Specify which JWS serialization is used

2018-03-02 Thread Logan Widick
I think the follow-on (#398) includes the Accept header in error responses (to requests with unacceptable serializations). Also, there may need to be another follow-on regarding how to serialize "nested" JWS instances (like the externalAccountBinding and the inner JWS for a key change). Logan

Re: [Acme] Optional "Wildcard" authorization field

2018-03-02 Thread Brad Warren
In a similar vein, another small but real world example where this being standardized would be useful is Certbot has the flag —allow-subset-of-names that causes it to not treat it as a failure if you cannot complete all authorizations and instead obtain a certificate only for the identifiers

Re: [Acme] Optional "Wildcard" authorization field

2018-03-02 Thread Sophie Herold
On 02/03/18 18:32, Daniel McCarney wrote: > Richard: That's up to the client and the situation. In the linked Certbot > issues there were questions about error output/UX. In this case if the > client saw an error attached to an authorization with the identifier `{ > "type": "dns", "value":

Re: [Acme] Optional "Wildcard" authorization field

2018-03-02 Thread Daniel McCarney
> > This sounds like you want to provide the order identifiers that > triggered this authorization within the authorization object? Generally speaking yes. In principle, several order identifiers could lead to a single > authorization I guess? > I think in principle that's true. ACME doesn't

Re: [Acme] Optional "Wildcard" authorization field

2018-03-02 Thread Richard Barnes
This is seeming like a lot of work for a pretty minor use case. I would propose we stick with a simpler solution here. While Sophie's solution does seem more general, in the interest of getting the spec shipped, I would propose we just add the boolean flag and write an extension spec if a more

Re: [Acme] Specify which JWS serialization is used

2018-03-02 Thread Jacob Hoffman-Andrews
> If you have suggestions here, a PR would be welcome.  TBH, this issue > kind of makes me want to reverse course and say "all flattened JSON", > but I get the sense that other folks disagree? I'd be very much in favor of "all flattened JSON." When we started ACME, I think there was some concern

Re: [Acme] Optional "Wildcard" authorization field

2018-03-02 Thread Daniel McCarney
> > I would propose we stick with a simpler solution here. While Sophie's > solution does seem more general, in the interest of getting the spec > shipped, I would propose we just add the boolean flag and write an > extension spec if a more general solution is needed. That sounds sensible to

[Acme] I-D Action: draft-ietf-acme-tls-alpn-00.txt

2018-03-02 Thread internet-drafts
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 WG of the IETF. Title : ACME TLS ALPN Challenge Extension Author : Roland Bracewell Shoemaker

Re: [Acme] "Status" field clarification

2018-03-02 Thread Logan Widick
Are challenge retries still supported? If so, how will retries affect the state transitions? What state would a server use to indicate that something had an error but could be retried later? Sincerely, Logan Widick On Mar 2, 2018 08:04, "Richard Barnes" wrote: Hey all, We had a

Re: [Acme] -09 draft: Challenge objects?

2018-03-02 Thread Daniel McCarney
Hi Felipe, Does this PR from Richard Barnes address your feedback? https://github.com/ietf-wg-acme/acme/pull/399 Thanks! On Sat, Jan 13, 2018 at 8:50 AM, Felipe Gasper wrote: > Hello, > > I’ve been looking over the -09 draft and have created a Perl > client

Re: [Acme] Specify which JWS serialization is used

2018-03-02 Thread Richard Barnes
Hey all, I merged #395 last night (thanks, Logan!). While I was reviewing that, I noticed that we need to cover the case where the client sends an encoding that the server doesn't understand. So I've posted a follow-on that adds an error code and requires its usage. LMK if you have any

[Acme] "Status" field clarification

2018-03-02 Thread Richard Barnes
Hey all, We had a couple of GitHub issues and mailing list posts expressing confusion about the "status" field in ACME objects. To try to clear all of that up, I've posted a PR that lays out required state transitions and aligns the field descriptions with that description. All the description

Re: [Acme] "Status" field clarification

2018-03-02 Thread Richard Barnes
Good catch. I think the right answer is to keep the challenge in "processing". We already have the following text in "Retrying Challenges" (amended s/pending/processing/): """ While the server is still trying, the status of the challenge remains “pending”; it is only marked “invalid” once the

[Acme] Adopting the ALPN I-D

2018-03-02 Thread Salz, Rich
There were no messages opposed, so we will adopt the TLS ALPN draft. Please resubmit as draft-ietf-acme… Please do it before Sunday so we can have it accepted (by WG chairs) before the deadline. Thanks! ___ Acme mailing list Acme@ietf.org

Re: [Acme] -09 draft: Challenge objects?

2018-03-02 Thread Felipe Gasper
Hi Daniel, It definitely helps, yes. Would it be sensible to move the common list of parameters there as well, for parity with how the other object types are described? -Felipe > On Mar 2, 2018, at 9:34 AM, Daniel McCarney wrote: > > Hi Felipe, > > Does this

Re: [Acme] Specify which JWS serialization is used

2018-03-02 Thread Felipe Gasper
Could there be some way of using a header like “Accept” for a server to indicate whether it supports jose, jose+json, or both? -F > On Mar 2, 2018, at 9:50 AM, Richard Barnes wrote: > > Hey all, > > I merged #395 last night (thanks, Logan!). While I was reviewing that, I >