See below inline, thanks. Regards,
Andy On 17 Aug 2016, at 04:54, Richard Barnes <r...@ipv.sx<mailto:r...@ipv.sx>> 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 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. 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 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 <j...@eff.org<mailto:j...@eff.org>> 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 Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme _______________________________________________ Acme mailing list Acme@ietf.org<mailto:Acme@ietf.org> https://www.ietf.org/mailman/listinfo/acme
_______________________________________________ Acme mailing list Acme@ietf.org https://www.ietf.org/mailman/listinfo/acme
