Hi,
instead of an FIXED cname that does not ensure that the requestor
possess access to the dns.
I would prefer to use an static TXT record whith the Account Key hashed.
This would prove that
only an person possesing an specified private key is allowed to request.
Or to use TLSA record to verify that the requested zertificate would be
valid for dane.
This would weaken the DNS-SEC Requirement for DANE but would not
introduce an weakness compared
to the suggested solution.
Gruß Thomas
Am 2018-01-23 09:09, schrieb Niklas Keller:
2018-01-23 8:09 GMT+01:00 Ilari Liusvaara <[email protected]>:
On Mon, Jan 22, 2018 at 05:09:53PM -0800, Jacob Hoffman-Andrews
wrote:
To fix that, the CA could assist the user by providing
narrowly-scoped
DNS hosting: It would serve only TXT records used in validating
DNS
challenges. The CA instruct subscribers to delegate the
_acme-challenge
subdomain to a subdomain of the CA's hosted DNS domain. For
instance, if
a subscriber has account number 1234, the CA would say: Please
deploy a
CNAME record like so:
_acme-challenge.example.com [1]. CNAME
1234.challenges.ca.example.net [2].
The assisted-dns-01 challenge would then be validated like dns-01,
except: As the first step in validation, the CA would deploy the
expected TXT value at 1234.challenges.ca.example.net [2]. Then the
CA would
continue to look up "TXT _acme-challenge.example.com [1]." 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 following the
formal lookup steps.
This challenge has the big advantage that subscribers only need to
do a
one-time CNAME setup, and renewals can be reliably automated
without
requiring that renewing systems have permission to update DNS. In
effect, the CNAME record would act like a long-term delegation
permitting the CA to issue continuously for the base domain.
I came up with very similar method when trying to figure out how the
Amazon Certificate Manager DNS challenge works. It has similar
"standing authentication" property, and yet needs to comply with the
BRs.
This seems very much like a circumvention of the BRs. Either this
circumvention should be forbidden, because it effectively doesn't
re-prove ownership, or the BRs can be changed to allow permanent
authorization for accounts, then we don't need the CA to host anything
like that.
We could then allow e.g. an account key thumbprint to authorize a
specific account key to request certificates. Using the account key
would allow that key to request those certificates from any ACME
supporting CA, not just one. A binding could be introduced, but I
guess CAA already solves that.
Regards, Niklas
Links:
------
[1] http://acme-challenge.example.com
[2] http://1234.challenges.ca.example.net
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme
