Re: [Acme] ACME breaking change: Most GETs become POSTs

> On Aug 30, 2018, at 7:48 PM, Jacob Hoffman-Andrews wrote: > > (Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's > Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)") > > On 08/30/2018 11:17 AM, Felipe Gasper wrote: > > Would it work to keep certificate

Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

On Wed, Aug 29, 2018 at 09:10:06PM -0400, Richard Barnes wrote: > Hi Ben, > > Thanks for the detailed review. Responses to the DISCUSS comments inline. > My co-author Daniel McCarney is working on the COMMENT comments. > > --Richard > > On Wed, Aug 29, 2018 at 2:53 PM Benjamin Kaduk wrote: >

Re: [Acme] ACME breaking change: Most GETs become POSTs

On 8/30/18 6:20 PM, Jacob Hoffman-Andrews wrote: ACME currently has unauthenticated GETs for some resources. This was originally discussed in January 2015[1]. We decided to put all sensitive data in the account resource and consider all GET resources public, with a slant towards transparency.

Re: [Acme] ACME breaking change: Most GETs become POSTs

(Replying to Felipe's comment from the thread "Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)") On 08/30/2018 11:17 AM, Felipe Gasper wrote: > Would it work to keep certificate fetches as plain GET? > > In shared hosting environments it’s common for a

[Acme] ACME breaking change: Most GETs become POSTs

ACME currently has unauthenticated GETs for some resources. This was originally discussed in January 2015[1]. We decided to put all sensitive data in the account resource and consider all GET resources public, with a slant towards transparency. Adam Roach recently pointed out in his Area

Re: [Acme] HTTP redirects in validation [Was: Re: FW: Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)]

On Thu, Aug 30, 2018 at 2:28 PM Ilari Liusvaara wrote: > > The main reason to allow redirects within a domain is if there is a > > unilateral redirect from example.com to www.example.com > > , which is of course incredibly common. It > > seems one should be able to

[Acme] HTTP redirects in validation [Was: Re: FW: Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)]

On Thu, Aug 30, 2018 at 12:06:35PM +, Tim Hollebeek wrote: > In the interest of openness, CAs were asked to disclose their > current redirect behavior as a basis for a discussion about what > the requirements should be. Two CAs have done so. Others are > strongly encouraged to do so.

Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

Would it work to keep certificate fetches as plain GET? In shared hosting environments it’s common for a privileged process to request certificates on behalf of user accounts. This avoids having 1,000s of ACME server registrations from a single server. While certificates are generally made

Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

It appears that we missed a security issue. Please take a look at the PR mentioned below. It removes many GET requests and turns them into POST so that the client payload can have authentication information. If you object to this change, please post a note to the list and explain why. Try

Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

My preference here would be for approach (1). I appreciate that it's a big change to make this late in the process, but that's the price we pay for missing a pretty significant issue up until now. For existing implementations, the code impact should be modest, as long as they have been

Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

On 8/30/18 8:48 AM, Felix Fontein wrote: Hello, On 8/30/18 7:55 AM, Richard Barnes wrote: Focusing on DISCUSS comment for now, will pick up COMMENTs later. On your DISCUSS, I think you're off on a couple of small things Yeah, I woke up with the sudden realization that I'd had the wrong

Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

> I guess you could argue that if you made a random URL and only distributed it in authenticated channels, then you could allow GETs to it, using the URL itself as an authenticator. Yuk. We have seen too many instances where "guessable" private URL's exposed data where they shouldn't.

Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

Hello, > On 8/30/18 7:55 AM, Richard Barnes wrote: > > Focusing on DISCUSS comment for now, will pick up COMMENTs later. > > > > On your DISCUSS, I think you're off on a couple of small things > > > Yeah, I woke up with the sudden realization that I'd had the wrong > model in my head when I

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

Thanks, Corey. Updated the PR. On Thu, Aug 30, 2018 at 9:01 AM Corey Bonnell wrote: > Hello, > > I just wanted to point out that RFC 5234 defines a core set of production > rules in Appendix B (https://tools.ietf.org/html/rfc5234#appendix-B) that > define commonly used rules such as “DIGIT”,

Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

On 8/30/18 7:55 AM, Richard Barnes wrote: Focusing on DISCUSS comment for now, will pick up COMMENTs later. On your DISCUSS, I think you're off on a couple of small things Yeah, I woke up with the sudden realization that I'd had the wrong model in my head when I talked through the cert

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

Hello, I just wanted to point out that RFC 5234 defines a core set of production rules in Appendix B (https://tools.ietf.org/html/rfc5234#appendix-B) that define commonly used rules such as “DIGIT”, “ALPHA”, etc. Using them would make the base64url rule clearer: base64url = ALPHA / DIGIT / “-“

Re: [Acme] Adam Roach's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

Focusing on DISCUSS comment for now, will pick up COMMENTs later. On your DISCUSS, I think you're off on a couple of small things, but right on the underlying point that the document doesn't really provide any guidance as to which resources a server should consider sensitive. I agree that it

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

Thanks, James. Fixed in the PR. On Wed, Aug 29, 2018 at 10:41 PM Manger, James < james.h.man...@team.telstra.com> wrote: > >> base64url = [A-Z] / [a-z] / [0-9] / "-" / "_" > > > base64url = (%x40-5A) / (%x61-7A) / (%x30-39) / "-" / "_" > > > > “A” is %x41 (not %x40) > > > > -- > > James

[Acme] FW: Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

Trimming recipients due to moderation. -Tim From: Tim Hollebeek Sent: Thursday, August 30, 2018 8:12 AM To: 'Richard Barnes' ; Salz, Rich Cc: Alexey Melnikov ; draft-ietf-acme-a...@ietf.org; IETF ACME ; Daniel McCarney ; Yoav Nir ; The IESG ; ; Alexey Melnikov Subject: RE: [Acme]

Re: [Acme] Alexey Melnikov's No Objection on draft-ietf-acme-acme-14: (with COMMENT)

For what it’s worth, there’s a discussion going on in the validation working group right now about how redirects should be handled. The most likely outcome is either pretty severe restrictions around redirects, or completely disallowing them. In the interest of openness, CAs were asked

Re: [Acme] Benjamin Kaduk's Discuss on draft-ietf-acme-acme-14: (with DISCUSS and COMMENT)

Hi all, On Thu, Aug 30, 2018, at 2:58 AM, Ben Campbell wrote: > > >> On Aug 29, 2018, at 8:10 PM, Richard Barnes wrote: >> >> >>> I am not an ART AD, but there is not yet an internationalization >>> directorate, and seeing statements like "inputs for digest >>> computations>>> MUST be