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

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
>