On Tue, Dec 22, 2015 at 12:02 PM, Richard Barnes <[email protected]> wrote: > I mentioned at the IETF meeting that a major next milestone for ACME > is to get it to the point where it can be used by current CAs, > including ones that require clients to pay for certificates. I've > been chatting with Andrew Ayer and a few other folks about how to do > this, and have come up with the following loose proposal (in a Gist > because it's a little long): > > https://gist.github.com/bifurcation/8c955b99bd0daec8673d > > tl;dr: > - Add an "order" resource type that can group certificates > - Reinforce the distinction between certificate requests and certificates > - Add an "activation" action or an "out-of-band" challenge type
Richard, I think that this is a good start. However I think there is a high risk of putting too much policy into the protocol. Given this, what I describe below are what I see as core building blocks that allow a CA to implement policy as they see fit. I think there are several areas where the current draft API could be enhanced to better support existing CA and places where it is worth calling out things that are out of scope and better handled via some other standard. The biggest of these is permissions and roles. The current spec only considers one The first area that probably needs work is identifier authorization. There are three main groups of methods for validating domain authorization: - Public challenge (this is what ACME has today) - Private challenge - Non-automated One popular way to validate control of an identifier is to look up the owner or registrant of the identifier, get contact info (such as a postal address) and mail them a letter containing a private challenge. Once they receive the letter, they provide the challenge to the CA/RA to provide they received the letter. Today with ACME, there is no way to have a private challenge. Additionally, given that there may be multiple contact addresses, it is necessary to give the caller a way to choose which address to use when there are multiple choices. For these challenge types, the token would would not be in the structure. Non-automated validation is another gap. There are times where it is desirable to record that an account is authorized for the identifier via some "other' mechanism. This could be via an authorization letter or research by the CA. The other item missing from domain authorization information is scope. Some CAs may determine that an authorization is good for a portion of the DNS tree larger than just the validated FQDN. For example, I might validate peterbowen.org and then be able to get foo.peterbowen.org without re-validating. I suggest reusing the scope terms from LDAP as an attribute on base, one, sub, and children as a new attribute in the identifier structure. In addition to dns identifiers, CAs that include subject identity information will need to be able to represent these identifiers. I don't expect that most of these identifiers will use any automated challenge. Instead the URL might be somewhere that scans of documents can be uploaded. In addition to identifier and challenge enhancements, the new-cert method does not align to what most CAs do today. Specifically, almost all CAs allow providing the certificate details outside of the CSR and only use the CSR to carry the public key and self-signature. The new-cert method probably should allow optional parameters for specifying identities to be included in the certificate. Many CAs also offer different certificate profiles, which is also missing from the new-cert method. Profiles can be used to determine which extensions to include, how to set key usages, and even which CA will sign the certificate. Lastly, I would extend CSR to allow for either a PKCS#10 formatted CSR or a SPKAC CSR. This would allow systems built using the HTML5 keygen element and other systems that use SPKAC formatted CSRs to use ACME. I think these changes would give a solid foundation and API upon which many different business models and issuance policies could be implemented. Thanks, Peter _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
