Re: [Acme] ACME for pre-ACME CAs

[Peter Bowen <[e-mail]>]

On Tue, Dec 22, 2015 at 12:02 PM, Richard Barnes <[e-mail]> 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