Oliver's use-case is very similar to our own, as well. Looking exclusively at OV, for example, it's difficult to rely upon exactly what is in the CSR for issuance. While a requester knows the specific dNSName value(s) they need, they often don't know the specific legally registered entity name.
As I'm interpreting the word and intent correctly, then if a request has A, B, and O, but the provided O value in the request is not reflective of the legal entity to be represented in the certificate's O value, the CA is unable to issue the cert because they cannot assert O, but they also cannot change O to O'. Or if the request includes the Organization name and Country, but not the Locality, the CA is unable to issue the cert through ACME. On Thu, Aug 17, 2017 at 11:25 AM Oliver Weyhmüller <[email protected]> wrote: > Hello, > > I work at a "legacy CA" and there it is quite common to substitute all > components of the certificate subject except the CN when a DV certificate > is issued. Also OV and EV certificates normally include information in the > subject, that are not part of the requesting CSR. > > We think about implementing ACME, and see some potential use cases for > that. For example, a customer's order could only specify a CN in the > subject to get a free DV certificate just like LE does. In parallel the > organisation or extended validation process takes place and the customer > gets the external-account-binding mac and kid if this process completes > successfully. After configuring mac and kid at the ACME client, a renewal > could seamlessly upgrade the DV certificate to an OV or even EV one. Vice > versa a OV or EV certificate could be downgraded to a free DV certificate > if the customer cancels his contract or updated validation documents are > not provided in time, preventing the usage of an expired certificate. > > Of course, the CN and the SANs MUST NOT be altered by the CA. > > Regards, > Oliver Weyhmüller > > On Thu, Aug 17, 2017 at 5:05 PM Richard Barnes <[email protected]> wrote: > >> Yeah, I agree that the intent here is for the CSR to match the >> certificate in all material respects. >> >> This does require the client to know what it wants, so it knows what to >> put in the CSR. Do you have a use case where that's not the case? >> >> On Thu, Aug 17, 2017 at 9:54 AM, Salz, Rich <[email protected]> wrote: >> >>> >>> It's unclear to me whether an ACME CA is allowed to issue a cert with >>> a superset of identifiers that were requested in the order. I see the >>> language: >>> >>> > The server MUST return an error if it cannot fulfill the request as >>> > specified, and MUST NOT issue a certificate with contents other >>> than >>> > those requested. >>> >>> The “and MUST NOT” clause means that both parts are required to be >>> true. So if you ask for A B and you are given A B C then the server was >>> not compliant. >> >> -- > Oliver Weyhmüller > Hauptstr. 17/1 > 73098 Rechberghausen > Germany > > Tel +49 7161 9866330 <+49%207161%209866330> > Fax +49 7161 9866332 <+49%207161%209866332> > Mobile +49 160 1560508 <+49%20160%201560508> > E-Mail [email protected] > Web: https://www.weyhmueller.de > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme >
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
