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

From: Andy Ligg <[email-masked]>
Date: Mon, 15 Aug 2016 04:10:10 +0000

Hi all,

StartCom plan to use ACME protocol for StartEncrypt, we need to identify the client's validation level, so the subscriber administration can generate a special token in the StartSSL.com account that send this token to the email address used in the ACME registration.

At the registration, user need to enter email and this token with the certificate to let the CA system know this customer's validation level. 
After the CA system receive the email, the token and signing certificate, CA system know what type of certificate we can issue to this client; if this client account is class 4 validated, then the client can get EV SSL certificate, not DV SSL.
please add this a parameter to the ACME protocol, thanks.

Best Regards,

Andy Ligg
StartCom

---

From: "J.C. Jones" <[email-masked]>
Date: Mon, 15 Aug 2016 08:53:02 -0700

Hi Andy,

I'm not sure I follow exactly what the format of this token would be, or
what message(s) in the protocol you'd like to add it to. Perhaps you can
make some specific recommendations - even if they're tentative examples -
for the WG to look at and reason through?

Thanks!
J.C.

On Sun, Aug 14, 2016 at 9:10 PM, Andy Ligg <[email-masked]> wrote:

> Hi all,
>
> StartCom plan to use ACME protocol for StartEncrypt, we need to identify
> the client's validation level, so the subscriber administration can
> generate a special token in the StartSSL.com account that send this token
> to the email address used in the ACME registration.
>
> At the registration, user need to enter email and this token with the
> certificate to let the CA system know this customer's validation level.
> After the CA system receive the email, the token and signing certificate,
> CA system know what type of certificate we can issue to this client; if
> this client account is class 4 validated, then the client can get EV SSL
> certificate, not DV SSL.
> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Mon, 15 Aug 2016 09:34:51 -0700

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

One of the big open questions in ACME is how paid CAs will manage the
connection between existing accounts and accounts as defined by ACME. It
sounds like that's a need you're likely to have. Do you have any
particular ideas about how you'd like to manage it?

On 08/15/2016 08:53 AM, J.C. Jones wrote:
> Hi Andy,
>
> I'm not sure I follow exactly what the format of this token would be,
> or what message(s) in the protocol you'd like to add it to. Perhaps
> you can make some specific recommendations - even if they're tentative
> examples - for the WG to look at and reason through?
>
> Thanks!
> J.C.
>
> On Sun, Aug 14, 2016 at 9:10 PM, Andy Ligg <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Hi all,
>
>     StartCom plan to use ACME protocol for StartEncrypt, we need to
>     identify the client's validation level, so the subscriber
>     administration can generate a special token in the StartSSL.com
>     account that send this token to the email address used in the ACME
>     registration.
>
>     At the registration, user need to enter email and this token with
>     the certificate to let the CA system know this customer's
>     validation level.
>     After the CA system receive the email, the token and signing
>     certificate, CA system know what type of certificate we can issue
>     to this client; if this client account is class 4 validated, then
>     the client can get EV SSL certificate, not DV SSL.
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/acme>
>
>
>
>

---

From: "Andy Ligg" <[email-masked]>
Date: Tue, 16 Aug 2016 23:07:29 +0800

Currently, we called it as API token if you want to use StartAPI, it is a string like this: tk_dc09cfc9aff5409ea98227e212858669.

We use this API Token together with the API authentication certificate to call our API.

So if we can add this API Token in the ACME registration, then we can bind this customer to his/her StartSSL account, then we know his/her account validation level to issue the correct validation level SSL certificate. If his/her account is Class 4 validation, then we can issue EV SSL certificate. 

No more change need in ACME protocol, but for more flexible, we can add a cert type parameter to let the Class 4 validation subscriber can choose to issue EV SSL, OV SSL and DV SSL.

Please advise, thanks.

Andy

From: J.C. Jones [mailto:[email-masked]] 
Sent: Monday, August 15, 2016 11:53 PM
To: Andy Ligg <[email-masked]>
Cc: [email-masked]
Subject: Re: [Acme] Add a special token parameter in ACME registration

Hi Andy,

I'm not sure I follow exactly what the format of this token would be, or what message(s) in the protocol you'd like to add it to. Perhaps you can make some specific recommendations - even if they're tentative examples - for the WG to look at and reason through?

Thanks!

J.C.

On Sun, Aug 14, 2016 at 9:10 PM, Andy Ligg <[email-masked] <mailto:[email-masked]> > wrote:

Hi all,

Best Regards,

Andy Ligg
StartCom

---

From: "Andy Ligg" <[email-masked]>
Date: Tue, 16 Aug 2016 23:14:16 +0800

See below inline, thanks.

From: Jacob Hoffman-Andrews [mailto:[email-masked]] 
Sent: Tuesday, August 16, 2016 12:35 AM
To: J.C. Jones <[email-masked]>; Andy Ligg <[email-masked]>
Cc: [email-masked]
Subject: Re: [Acme] Add a special token parameter in ACME registration

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.

One of the big open questions in ACME is how paid CAs will manage the
connection between existing accounts and accounts as defined by ACME. It
sounds like that's a need you're likely to have. Do you have any particular
ideas about how you'd like to manage it?

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.

Thanks.

Andy 

Hi Andy,

Thanks!

J.C.

On Sun, Aug 14, 2016 at 9:10 PM, Andy Ligg <[email-masked]
<mailto:[email-masked]> > wrote:

Hi all,

StartCom plan to use ACME protocol for StartEncrypt, we need to identify the
client's validation level, so the subscriber administration can generate a
special token in the StartSSL.com account that send this token to the email
address used in the ACME registration.

At the registration, user need to enter email and this token with the
certificate to let the CA system know this customer's validation level.
After the CA system receive the email, the token and signing certificate, CA
system know what type of certificate we can issue to this client; if this
client account is class 4 validated, then the client can get EV SSL
certificate, not DV SSL.
please add this a parameter to the ACME protocol, thanks.

Best Regards,

Andy Ligg
StartCom

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 16 Aug 2016 09:04:53 -0700

On 08/16/2016 08:14 AM, Andy Ligg wrote:
> 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?

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Aug 2016 16:48:27 -0400

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 17 Aug 2016 11:11:20 +1000

> applicant would like to issue the certificate, e.g., {"ca":

Or have entirely separate ACME endpoints for the DV and EV CA.  i.e.,
https://acme.example/dv will issue DV certs, and
https://acme.example/ev will issue EV certs.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 16 Aug 2016 21:41:30 -0400

> https://acme.example/ev will issue EV certs.

Yes, that's possible.  In particular, you probably want to share new-reg
and new-authz, but not new-app.  So it's kind of isomorphic to (c); you
just provide different new-app endpoints per CA, de mixing with URL instead
of a request parameter.

---

From: Andy Ligg <[email-masked]>
Date: Wed, 17 Aug 2016 02:35:37 +0000

Regards,

Andy

> On 17 Aug 2016, at 00:11, Jacob Hoffman-Andrews <[email-masked]> wrote:
> 

A: yes, we can generate the CSR including the cert type info.

> generate a token and provide it as part of the response to new-reg?

A: the API token is obtained from StartSSL website before using ACME client, this is for identifying the client's validation level to let us know to issue the EV SSL for this client.

---

From: Andy Ligg <[email-masked]>
Date: Wed, 17 Aug 2016 02:49:21 +0000

Regards,

Andy

On 17 Aug 2016, at 04:54, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:

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.

=====

A: the API token is for binding this client to a StartSSL account that validated its identity since this token is generated by our system before using ACME client.
I also care about the token security that this token can't be used by wrong account. So server side will check the token with the correct email address to identify the correct account.

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

A: I think this is too complex that we can use CSR info to let the CA know the cert type.

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

_______________________________________________
Acme mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/acme

_______________________________________________
Acme mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/acme

---

From: Andrew Ayer <[email-masked]>
Date: Tue, 16 Aug 2016 21:04:20 -0700

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

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