Re: [Acme] Assisted DNS, freshness tokens, and BR validation methods

NS zone. >> This >> allows for providing the servers needing automated update and retrieval of >> certificates to do so without exposing security credentials of high >> privilege over >> the primary DNS zone to the various systems needing certificates. >> Simultaneously, it

Re: [Acme] Assisted-DNS challenge type

> On Jan 22, 2018, at 7:09 PM, Jacob Hoffman-Andrews wrote: > > In a way, fetching final TXT record would be a formality: the CA could in > theory > stop once it saw the CNAME pointed at the right location, though most > likely abiding by the terms of the BRs would require

Re: [Acme] Wildcard certificate via http-01

I believe the mechanism described here would run afoul of the present baseline requirements, but could be brought into line with the BRs merely by validating control over the base domain.tld that wildcard is being requested for. Current BR method #6 specifies that control over a given FQDN

Re: [Acme] Wildcard certificate via http-01

That was a concern I had as well. As such, I suggested the enhancement that in addition validation would have to occur on the base FQDN label over which the wildcard is being requested also. In other words, to get a cert for *.example.com , I believe you should have to

Re: [Acme] Wildcard certificate via http-01

You make your own case for using a mechanism other than this, though. Your described use case of your domain strongly suggests routine frequent changes to your dns zone. Presumably you’re already using a dynamic zone. Or probably should be. Your path to wildcard certs is probably better via

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

10:04 AM, Matthew D. Hardeman <mharde...@ipifony.com> > wrote: > > Breaking that on purpose is actually why I most believe that the SNI should > be required to reflect the exact SNI of the domain label being validated. > > The threat model I was concerned about evaporat

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

Not that I think that’s a sane or normal thing to do. But apparently it’s a thing people are doing. I didn’t know about it either until I saw this twitter post and did a little research on it. https://twitter.com/eey0re/status/951622012211900416 > On Jan 12, 2018, at 10:36 AM, Matthe

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

Yes. But there are people forwarding that to the other service port so their application only has one real listener and then that non HTTP TLS server still manages to complete the TLS-SNI challenge (via port 443). > On Jan 12, 2018, at 10:33 AM, Gerd v. Egidy >

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

> On Jan 12, 2018, at 10:42 AM, Ilari Liusvaara > wrote: > > On Fri, Jan 12, 2018 at 05:20:39PM +0100, Gerd v. Egidy wrote: >> >> The problem mentioned with running HTTP-01 over HTTPS was the default-vhost >> problem. But that could be avoided with checking the SAN

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

Breaking that on purpose is actually why I most believe that the SNI should be required to reflect the exact SNI of the domain label being validated. The threat model I was concerned about evaporates if the SNI is the actual domain label and the decisioning of which TLS certificate to present

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

> On Jan 12, 2018, at 10:20 AM, Gerd v. Egidy > wrote: > > - As TLS-SNI-01/02 before, it is done completely via HTTPS on TCP port 443. > So > if HTTPS is the protocol you want to use the cert for, you wouldn't need > access to an additional TCP port like

Re: [Acme] Alternative proposal for fixing TLS-SNI / revisiting HTTPS-01 authorization

Yes. That can happen. I forget the name of it, but there was a historic web hosting framework that, in order to improve IP address costs AND maximize compatibility for those upgrading to TLS (non-SNI etc), encouraged the ultimate configuration: For a given IP address, a large number N of

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

hew D. Hardeman <mharde...@ipifony.com> > wrote: > > Hi, guys, > > I’m entirely new to this list and not sure whether or not I’m welcome, but I > have some comments on the ALPN idea. > > In order to actually be an improvement in security, the ALPN needs to be more

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

Hi, guys, I’m entirely new to this list and not sure whether or not I’m welcome, but I have some comments on the ALPN idea. In order to actually be an improvement in security, the ALPN needs to be more than a mere marker of support. Consider: The new mechanism is implemented and Let’s

Re: [Acme] Assisted DNS, freshness tokens, and BR validation methods

Allow me to throw in a twist which might more tighten the academic discussion over whether a static CNAME for a TXT record to a special zone at a CA (or other third party), over which dynamic updates to the CNAM target are available. The opposition seems to be that chasing the CNAME to the

Re: [Acme] Assisted DNS, freshness tokens, and BR validation methods

into the delegation target’s TXT record. I don’t think there’s any question that the NS zone delegation would be followed today, so why not CNAME? > On Jan 24, 2018, at 1:01 AM, Matthew D. Hardeman <mharde...@ipifony.com> > wrote: > > Whoops - quickie fix on this: > &

Re: [Acme] acme-ip reverse-dns discussion

> > There's actually a larger problem here that's been overlooked as far as I can > tell. Specifically, an operator of a site may not have authoritative control > of the reverse DNS zone unless they are the owner of of the internet routable > block (/24 or larger with IPv6, /64+ IPv6). When a

Re: [Acme] Concerning alternative formats …

My working experience is primarily outside the PKI space, but I can offer some perspectives on scalability and deployment architecture issues. WebSocket is entirely appropriate for real-time or near-real-time bidirectional communications of an asynchronous nature. The overhead of WebSocket as

Re: [Acme] Concerning alternative formats …

> On Mar 5, 2018, at 3:50 PM, Felipe Gasper <fel...@felipegasper.com> wrote: > > >> On Mar 5, 2018, at 1:13 PM, Matthew D. Hardeman <mharde...@ipifony.com> >> wrote: >> >> Especially with CT logging being a pragmatic requirement, time-to-delive

Re: [Acme] Authority Token WGLC

Hi all, I'm a subscriber & relying party in the STIR/SHAKEN ecosystem. I agree with both the comments from Chris Wendt and the proposal from Richard Barnes. I do believe that the "x5u" parameter should be optional and should only be presented when the CA is offering/committing to publicly