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

[Richard Barnes <[e-mail]>]

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 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.

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?

--Richard



On Tue, Aug 16, 2016 at 12:04 PM, Jacob Hoffman-Andrews <[e-mail]>
wrote:

> On 08/16/2016 08:14 AM, Andy Ligg wrote:
> >> One possibility would to make it the client's responsibility to request
> >> EV by including the desired O, OU, etc. fields in the Subject DN of the
> >> CSR. It would then be the server's responsibility to accept or reject
> >> the request based on whether the account has a sufficient validation
> >> level (and payment).
> >
> > A: StartCom issued the certificate not based on CSR info, we don’t care
> > about the info in the CSR, we issue the certificate based on this
> > account validated level and validated identity information. This mode
> > don’t work, CSR is not enough to identify the certificate type.
>
> Keep in mind that you're gong to have to start using *some* of the info
> from the requested CSR, because ACME uses the hostnames embedded in a
> CSR to determine which hostnames to issue for. ACME also uses the CSR to
> convey requested extensions, like Must Staple, though obviously not all
> CAs will support all extensions.
>
> Can you say more about why a CSR is not enough to identify the
> certificate type?
>
> > A: Yes, our API call is the same way as ACME registration – using client
> > certificate for authentication. In my last email, we need to add a API
> > Token in the ACME registration, then all are OK for paid CA.
> > Sure, if the paid CA is not this way but like to use ACME, then they
> > need to change the API system.
>
> Is your proposal that `POST /acme/new-reg` would contain a token
> obtained from the StartSSL website? Or that your ACME server would
> generate a token and provide it as part of the response to new-reg?
>
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>