Re: [Acme] Add a special token parameter in ACME registration

[Andrew Ayer <[e-mail]>]

On Tue, 16 Aug 2016 16:48:27 -0400
Richard Barnes <[e-mail]> wrote:

> There are two clearly separable problems here:
> 
> 1. Associating an ACME account key to an account in some other system
> 2. Determining when to issue an EV certificate (and with what
> contents)
> 
> Let's address them each separately.  (Note that Andy filed
> https://github.com/ietf-wg-acme/acme/issues/170 for (1))
> 
> =====
> 
> For (1), it seems sufficient (as Andy suggests) to add a token to the
> registration object.  If the client has one, it can add it either in
> the new-registration request or as a later update to the
> registration.  The server just reflects this value in its
> registration object.

I like this approach.  It provides a much nicer flow than doing the
association out-of-band.

> I think we can leave the details of what this association means
> pretty much out of scope.  The only requirement that comes to my mind
> is that the CA should reflect any authorization it has granted to the
> client in application objects, even if it's only an OOB link to some
> document.

I'm afraid I don't follow.  Could you expand on this?

> It seems worth noting that one could also address this problem in the
> other direction, by letting clients set an ACME account key in the
> other account system.  However, it seems better to create minimal
> dependencies on upgrades to these systems.  And in any case, it would
> be best to have binding in *both* directions, to avoid
> unknown-key-share-like risks.
>
> =====
> 
> For (2), I can think of a few approaches:
> 
> a. Infer the certificate type from the CSR.  For example, if the
> Subject in the CSR has (C, O, CN), infer that the applicant wants EV.
> b. Have a field in the new-application request that the client can
> use to indicate what type of certificate, e.g., {"certType": "ev"} to
> indicate EV. c. Have a field in the new-application request that
> indicates which CA the applicant would like to issue the certificate,
> e.g., {"ca": "identifier-for-CA"}.
> 
> All of these are approaches have drawbacks.  Options (a) and (b) kind
> of paper over the idea that you would have one ACME service fronting
> for different CAs; I would prefer to be explicit about that.  (Option
> (a) also seems pretty brittle, since you might not always have a 1-1
> mapping between patterns of Subject fields and certificate types.)
> With Option (c), though, you would probably also want some way for
> the client to discover what CAs are available.  Option (c) also
> presumes that there's a 1-1 mapping between CAs and the policies they
> support, which seems like it should be the case, but might not be
> (you could combine it with (b) to address this).
>
> Personally, I think my preference order would be c > b >> a.  We're
> likely to need to solve the multi-CA problem at some point soon
> anyway, so we might as well do it now.  Roughly, the proposal for (c)
> here would be as follows:
> 
> - In "meta" part of the directory, add a "CAs" entry with an
> dictionary of CAs that are accessible at this ACME server.
> - For each CA, the dictionary key is a unique identifier, and the
> value has some metadata, e.g.:
>   - An identifier for the policy the CA implements ("dv", "ev", etc.)
>   - A link to more information about the CA
> - In the new-application request, allow the client to specify which
> CA it would like to issue the certificate (using the unique ID from
> the directory/meta)
> 
> Thoughts?

I like option "c" and agree that it's superior to the other options.
Note that a single CA can have numerous different products and they
don't always neatly correspond to validation level (DV, EV, etc.).  The
products might be differentiated by whether wildcards are supported,
how many subjectAltNames are supported, what key algorithm is used in
the intermediate certificate, etc.  This means that option "a" (use the
CSR) is insufficient, and option "b" (a certType field) is unappealing
because certificates can't be neatly categorized in a way that makes
sense for all CAs.

With option "c" there can be a different CA identifier for each CA,
and if a CA issues several different types of certificates, there can
be a different "CA" identifier for each type (maybe we need different
terminology).  In any case, ACME should try to be as generic as possible
and just leave it up to the server to decide what "CAs" to offer and
what each one means.

There's a question of how much metadata the CA directory should
provide.  As I alluded above, this can get very hairy with all the
various product differentiators.  Pricing makes it even worse
(e.g. Comodo's pricing for one type of product is $X + $Y per
non-wildcard identifier beyond the first 3 + $Z per wildcard
identifier, and you get a discount for multiple years).  I think
there's too much variation for ACME to try to express it all.  Perhaps
just a short description, a long description, a URL for more
information, and nothing else?

Regards,
Andrew