Re: [Acme] Hyphens in parameter names of ACME CAA extensions

There is an IETF erratum for RFC 6844 (specifically, erratum 5200: https://www.rfc-editor.org/errata/eid5200) regarding a contradiction about which character is used as a parameter delimiter in "issue"/"issuewild" property tags (section 3 defines the parameter delimiter as a semicolon, whereas

Re: [Acme] Fixing the TLS-SNI challenge type

> > If we use the "real" identifier for SNI, we'd limit that option to web > servers that natively support the ALPN value for ACME and can route based > on it. > Not sure how common this kind of setup is, if it's just a small subset of > HAProxy deployments it'd probably not have much of an

Re: [Acme] Fixing the TLS-SNI challenge type

> > I agree this approach will limit compatible TLS servers but luckily > HAProxy should be fully compatible. Alas, there's nothing like hitting send on a message to a mailing list to make you think a little bit harder. I overlooked the fact that it doesn't seem possible to select the

Re: [Acme] Hyphens in parameter names of ACME CAA extensions

➢ The implementation of CAA by major CAs has revealed a large number of serious defects with the current text of RFC 6844, and I think it's time for a RFC 6844-bis effort. This is happening, in the LAMPS working group. Phil Hallam-Baker has stepped up.

Re: [Acme] Hyphens in parameter names of ACME CAA extensions

Okay, then it needs to accelerate  I'm on that WG and I haven't seen any related traffic recently. Maybe I'll poke Phil. -Tim > -Original Message- > From: Salz, Rich [mailto:rs...@akamai.com] > Sent: Friday, January 19, 2018 8:18 AM > To: Tim Hollebeek ;

Re: [Acme] Fixing the TLS-SNI challenge type

On Fri, Jan 19, 2018 at 4:38 PM, Ilari Liusvaara wrote: > On Fri, Jan 19, 2018 at 09:51:33AM -0500, Daniel McCarney wrote: > > > > > > I agree this approach will limit compatible TLS servers but luckily > > > HAProxy should be fully compatible. > > > > > > Alas, there's

Re: [Acme] Hyphens in parameter names of ACME CAA extensions

I agree with Corey about the readability of hyphens. Also, I fully support his fix to the RFC 6844 grammar. The current grammar is a mess. The implementation of CAA by major CAs has revealed a large number of serious defects with the current text of RFC 6844, and I think it's time for a RFC

Re: [Acme] Fixing the TLS-SNI challenge type

On Fri, Jan 19, 2018 at 09:51:33AM -0500, Daniel McCarney wrote: > > > > I agree this approach will limit compatible TLS servers but luckily > > HAProxy should be fully compatible. > > > Alas, there's nothing like hitting send on a message to a mailing list to > make you think a little bit

Re: [Acme] Fixing the TLS-SNI challenge type

> Basically, for security, one needs to put the domain to be validated to the SNI > field. Not doing that was the reason for the TLS-SNI-01/02 vulernability. I agree. Not only for security, but for compliance, both with the Baseline Requirements [1] and the intended use of SNI. Abusing SNI as

Re: [Acme] Challenge "errors" -> "error"

There hasn't been any dissent on-list about this proposal. I'm going to merge the PR. Thanks all! On Fri, Jan 12, 2018 at 11:32 AM, Daniel McCarney wrote: > +1 - I'm in favour of this change as well. > > On Thu, Jan 11, 2018 at 7:24 PM, Jonathan Rudenberg

Re: [Acme] Fixing the TLS-SNI challenge type

➢ challenge: Random string of at least 128 bits of entropy. What does that mean? How can you measure if you’ve got 125 or 67 or 2 bits of entropy? ___ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] Fixing the TLS-SNI challenge type

Use: "at least 128 bits of output from a PRNG that is suitable for use in cryptographic operations", or similar. The Baseline Requirements have a similar definition. -Tim > -Original Message- > From: Salz, Rich [mailto:rs...@akamai.com] > Sent: Friday, January 19, 2018 11:34 AM > To:

Re: [Acme] Fixing the TLS-SNI challenge type

On Fri, Jan 19, 2018 at 05:24:01PM +, Tim Hollebeek wrote: > > > > I'm less worried about this constraint. If there's consensus for a > > > change, changes can be made to the BRs much more quickly than an RFC can > > be issued. > > > > Oh yeah, the minimum process latency for changing BRs