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

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Dec 15, 2015 at 12:25 PM, Noah Kantrowitz <[e-mail]>
wrote:

>
> > On Dec 15, 2015, at 7:17 AM, Michael Wyraz <[e-mail]> 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.


The workflow for using a LRA would be as follows:

1) Set up your ACME local RA on some host, e.g. lra.example.com

2) Generate a self signed cert for the LRA

3) Calculate the fingerprint of the KeyInfo blob (see
https://tools.ietf.org/html/draft-hallambaker-udf-00)

MD2UR-3PN64-TMQ26-HERIT-PVDOR-6FI42

4) Create a CAA record with some tag:

example.com CAA acme 0 "lra.example.com
lra=MD2UR-3PN64-TMQ26-HERIT-PVDOR-6FI42"


At this point, we have published all the necessary control information to
allow acme clients to automatically discover the LRA they are to connect to
for issue of certificates and the issuing CA has all the information needed
to authenticate the requests.

Note that in this particular case, the mechanism used to authenticate the
client to the LRA is out of scope of ACME because it is no longer a WebPKI
authentication, it is an internal configuration decision.


The simplest mechanism is probably for the acme client to generate a
keypair for that particular host and use that to authenticate host requests
to the LRA. The LRA would require some UI to authorize requests of course.

In a production environment, it might not be desirable to generate the
server keys on the servers that are actually going to use them.
Alternatively we might want to use the co-operative key generation
technique I demonstrated at CFRG in Prague.


If you are managing one server, a simple protocol is simplest. If you are
managing more than one then it probably is not. One of the main ways in
which PKIX became so complicated was that people tried to make it much
simpler than the problems required. So instead of one
revocation/status/validation mechanism we ended up with four incompatible
schemes.

The use of LRAs has been absolutely standard in enterprise PKI for 20
years. This is a feature we know is essential CAA was originally designed
to present all the information required to manage certificate issue.