Re: [Acme] Issuing certificates based on Simple HTTP challenges

Here is a handy list

https://cabforum.org/ipr-exclusion-notices/

On Tue, Dec 15, 2015 at 6:24 PM, Richard Barnes <rlb@ipv.sx> wrote:

> On Tue, Dec 15, 2015 at 4:17 PM, Phillip Hallam-Baker
> <phill@hallambaker.com> wrote:
> >
> >
> > On Tue, Dec 15, 2015 at 2:41 PM, Noah Kantrowitz <noah@coderanger.net>
> > wrote:
> >>
> >>
> >> > On Dec 15, 2015, at 9:48 AM, Phillip Hallam-Baker
> >> > <phill@hallambaker.com> wrote:
> >> >
> >> >
> >> >
> >> > On Tue, Dec 15, 2015 at 12:25 PM, Noah Kantrowitz <
> noah@coderanger.net>
> >> > wrote:
> >> >
> >> > > On Dec 15, 2015, at 7:17 AM, Michael Wyraz <michael@wyraz.de>
> wrote:
> >> > >
> >> > > Stephen,
> >> > >> Yes, I understand that and didn't actually refer to LE at all in my
> >> > >> mail.
> >> > > I'm sorry if I missunderstood you with that.
> >> > >
> >> > >> Basically, IMO only after we first get a "now" that works
> >> > > We have a working HTTP-01 spec, implementation and CA. What's
> missing
> >> > > for "a 'now' that works"?
> >> > >
> >> > >> Personally the optional thing in which I'm much more interested is
> a
> >> > >> simple put-challenge-in-DNS one where the CA pays attention to
> >> > >> DNSSEC,
> >> > >> since that's the use-case I have and that would provide some better
> >> > >> assurance to the certs acquired via acme. I can see that there
> might
> >> > >> also be value for some (other) folks in SRV if it means no need to
> >> > >> dynamically change DNS. But, if someone is saying "we must all do
> >> > >> these more complex things for security reasons" then they are, in
> >> > >> this
> >> > >> context, wrong. And my mail was reacting to just such a statement.
> >> > > Why not just placing a static public key to DNS that is allowed to
> >> > > sign
> >> > > ACME requests for this domain? Simple, no need for dynamic updates
> >> > > (yes,
> >> > > it's standardized for years but AFAIK not seen very often in real
> >> > > world
> >> > > scenarios).
> >> >
> >> > Anything that makes deployment _harder_ than the current LE client is
> a
> >> > move in the wrong direction. UX matters, with security more than just
> about
> >> > anything else. Unless you can propose a user flow to go with this
> change, no
> >> > amount of hypothetical correctness is worth having a tool no one will
> use.
> >> >
> >> > Harder for whom?
> >> >
> >> > The current scheme isn't going to work for any geolocation based
> systems
> >> > and is a terrible fit for enterprise.
> >>
> >> I think this is a bit of a red herring on a few fronts. You can use
> >> http-01 or similar strategies on a widely-replicated system, it is just
> >> annoying because you need to push the challenge response file to a
> bunch of
> >> places. If the geo-distributed piece is a CDN, the system is already
> >> designed to smash caches effectively so that is handled. Still, that is
> >> gross and a lot of work, but fortunately there is already a DNS
> challenge in
> >> the works that will help for some cases.
> >
> >
> > And is likely to be challenged by the IPR holder.
>
> You've mentioned IPR a couple of times.  If you have knowledge of IPR
> in this space, disclosures would be very helpful.  Same goes for
> anyone else here.
>
> Thanks,
> --Richard
>
>
> >
> > Keys in the DNS has prior art. It is also rather simpler to implement.
> >
> >
> > _______________________________________________
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
> >
>