On Tue, Jan 23, 2018 at 10:12:39 +0100, Thomas Lußnig wrote: > 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.
From what I understand, this discussion basically is the same as e.g. https://github.com/ietf-wg-acme/acme/issues/88 It all boils down to "I don't want dynamic challenges, I want static authorization." -----BEGIN ADVOCATUS DIABOLI----- I hereby propose that ACME is scrapped and replaced by the following workflow: - Create asymmetric key pair (may be reused for multiple domain names!) - Create DNS record: _acme-key.<domain>. TXT "<hfunc>:<hex(hash(der(pubkey)))>" - Create key + csr (CN/SAN <domain>) - POST json([CSR, pubkey, signature]) to https://<cadomain>/acme/issue - CA fetches pubhash from DNS, verifies the request and replies with the cert. I just reduced the ACME protocol to 5 lines :-] No more bothering with jws, accounts, nonces or challenges. -----END ADVOCATUS DIABOLI----- More serious now. Why does ACME use challenges? Are there any benefits that justify the complexity of the protocol? When offering an easier way (see above), nobody will ever bother using the complex way again and those benefits no longer apply. Cheers Joern Heissler
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
