Hi Kas, Before launching into mechanism, maybe you could clarify what authentication property you think is lacking here?
Note that ACME already has server authentication, via TLS server authentication. All the normal PKI mitigations apply there: CT, HPKP, etc. It is also already the case that the CA can issue certificates for its ACME server; no third party is needed. Thanks, --Richard On Mon, Oct 22, 2018 at 7:06 AM Kas <kas=40lightc....@dmarc.ietf.org> wrote: > It will be regrettable and unfortunate moment to pass on such > opportunity to make the internet more secure, and please let me start > with listing the facts: > > 1_ ACME Server is CA server, if you consider it a CA server then you > don't need a third party to validate and secure the connection with such > server. > 2_ DANE is great but will not be adopted and needs years or a > catastrophic failure by some CA to go mainstream, simply too many > parties has it in conflict with their business model. > 3_ SPF and DKIM are used in plain TXT DNS records and they already > securing the internet the world. > 4_ ACME protocol is utilizing DNS TXT record to authenticate the client > so both server and client has DNS handling procedure. > 5_ There is huge security hole in providing the root certificates to > secure the internet, and in most cases it depends on the system store, > many antivirus software installs with default settings to intercept > HTTPS connection by injecting their own root certificate in system, many > things can go wrong with system store, even extensions in a browser can > do that. > > So why not authenticate ACME server in different way than DANE TLSA > record and utilize TXT record similar to DKIM and make it a obligatory, > this will allow two parties to securely communicate with only one > requirement to trust one ACME server they already asking it for > certificates, those parties can build secure internet environment based > on one ACME server, even this protocol can evolve in future to issue > certificates with only IP and no domain name, is that something wrong ? > > (listing few ideas, examples) > "acme.TLSA" TXT here you can copy the whole content of TLSA record in > JSON format encoded in base64url ( may be too much ) > "acme.certs" TXT list the hash of the acme server certificates for > secure connection ( shouldn't be the root or CA certificate ) > "acme.ckeys" TXT list the the certificates public keys in JWK format > with base64url encoding ( shouldn't be the root or CA certificate ) > "acme.aKey" TXT contain one or more public keys (RSA or ECC) in JWK > (base64url) format this key can be used to authenticate responses from > acme server or only one critical response > > > "acme.dir" TXT the directory url encoded with base64url ( in this case > the client only need the server domain name like example.com or > staging.acme.example.com to get the acme directory ) > "acme.chain" TXT url to download acme server certificate chain in secure > manner > "acme.store" TXT url to download the mini store for that acme server > certificate trust in secure manner ( if this adopted then there will be > many store provider like mozilla.com or android.com the client > application can get his own store form his own sources, client trust > Microsoft and its store but he can't be sure the store copy in his > Windows is not tainted ) > > Please consider discussion this. > > Best regards > K. Obaideen > > > _______________________________________________ > Acme mailing list > Acme@ietf.org > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
