Resending, sorry. On 2/28/23, 7:49 PM, "Salz, Rich" <[email protected] <mailto:[email protected]>> wrote:
>Yepp. I understand the high level point in the meantime. I wonder how commonly available protocol options between registrar and CA allow to support this. FullCMC seems to support it (hence also EST if CA suports fullCMC over it), ACME does not. What other protocol options are relevant, which use-cases / type of deployments do not have a way to pick a protocol that supports this (because its not used / available in th deployments). I don't think that the IETF hasn't defined any CA/Registrar protocols, other than the BRSKI drafts. Even RFC 7030 says: "The nature of communication between an EST server and a CA is not described in this document." ACME's design assumed that clients talk directly to the CA. I'm not sure if the latest set of drafts have changed that setup. It "used to be" that almost every CA that wanted to issue certificates for enterprise customers had its own variety of Registrar integration. You couldn't walk down any of the aisles of the RSA conference and not bump into one. They were all custom, private. A subset had protocols or API's that let you plug your enterprise identity system (e.g., ActiveDirectory) into their provisioning system. I don't know if that kind of thing is still popular. All of this is a long-winded way of saying you'll have to ask around. :| As for your earlier question, could a certificate end up having things that weren't in the CSR? Yes. Often or always. The obvious ones are issuer, validity period; sometimes keyUsage and extendedKeyUsage, the submitted SubjectDN could be modified to enforce corporate policy, references to certification practice statements, and so on. Especially when an enterprise Registrar is involved, and the organization wants client-handled keygen. Hope this helps. _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
