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 https://www.ietf.org/mailman/listinfo/acme
