| Apologies for the delay in responding...it got lost amongst the other things on my plate. I'll answer the easier question first: admin certs. I wasn't so much confused by their presence in the CPS as I was discontent with the similar-but-different manner in which they were discussed. I think keeping them separate from the DV-SSL cert discussions will limit ambiguity and confusion. As for my "different machine" comment, I wasn't very clear so I'll try to fix that. I'm not actually concerned with the number of machines involved in obtaining a cert, but I do wonder what might happen when one of them becomes compromised. In an ACME setting I think the consequences could be worse than the status quo/traditional setting, but it's more accurate to say I just can't tell. I would need to review a more complete spec than I was able to find before I could draw any real conclusions. At issue is the degree to which automation is featured in the operating model of the Let's Encrypt CA. Fast, easy, cheap, and with little chance for human intervention or oversight...that's a recipe for abuse. If ACME means that I, as the bad guy, can compromise one machine and start getting certs issued to me for my nefarious purposes, then I'm a huge fan and Let's Encrypt will be my go-to source for certs. If instead ACME makes it harder for me to do that, then I'll be sad but it's probably a boon to Internet security. I know there are other comments I've made that probably deserve scrutiny and fleshing out so I hope people will feel free to speak up and let me know.
On Wednesday, 8 June 2016 13:56:44 UTC+1, Peter Kurrasch wrote: > Section 3.2.1 is where this whole thing falls apart for me. I am not familiar with the ACME protocol nor the ACME client so this is the first time I'm seeing that the client might be running on a different machine than the one getting the cert. This raises all sorts of security concerns. How so? As you correctly observed the subscriber is not a machine but a person, and the ACME process obtains reasonable confidence this person (whether through the operation of one machine, two machines as is common or dozens of machines in some complicated scenarios) is only issued with certificates for names they control. Consider the mundane situation of a customer of a traditional commercial CA. Perhaps Dave Cameron. Dave wishes to obtain a certificate for the name www.example.com, and so he uses a laptop, machine #1 to view pages from the CA's web server, machine #2, he types www.example.com into a web form, picks a few items from lists, types in his credit card details. After a while, email is sent to the address [email protected], which is the WHOIS admin contact for the example.com 2LD, the email asks to confirm that Dave wants the certificate issued. This email is delivered somehow to the example.org mail server (machine #3) and Dave views it on his iPhone (machine #4). Dave clicks "Yes, confirm" and duly receives the certificate. This everyday process for issuing DV certificates involves four machines outside the Certificate Authority systems themselves, none of which is www.example.com, and the process achieves its confidence as to Dave's legitimate control of www.example.com by a rather circuitous route, but it has been accepted as "good enough" and goes unremarked upon in applications to these trust stores. ACME is, if anything, simpler and more robust in its assurance, your lack of familiarity with it aside. If you object already to the status quo then an inclusion request thread is the wrong place to do that. You also seem confused by the existence of Administrative Certificates, which are needed for infrastructure. The document already lists examples of Administrative Certificates such as OCSP responders, and the intermediates for issuing leaf certificates to end users. They aren't some sort of alternative to ACME for end users. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy | ||
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
