The most popular options that I encounter in the wild right now, and for the last 10 years or so, for augmenting RA->CA:
* CMP CRMF requests using raVerified POP (used quite a lot) * REST or SOAP API transporting the original PKCS#10, augmenting outside of the CSR (used even more) The drive today is clearly towards using some sort of REST API. There is no standard for this of course, perhaps ACME is the closest to a standardized REST API you get today? Regards, Tomas ________________________________ From: Spasm <[email protected]> on behalf of David von Oheimb <[email protected]> Sent: Sunday, September 5, 2021 3:09 PM To: Michael Richardson <[email protected]>; Eliot Lear <[email protected]>; Dan Harkins <[email protected]>; Owen Friel <[email protected]>; Peter van der Stok <[email protected]>; max pritikin <[email protected]>; Toerless Eckert <[email protected]>; Esko Dijk <[email protected]>; [email protected] <[email protected]>; Thomas Werner <[email protected]>; [email protected] <[email protected]> Subject: Re: [lamps] [Anima] RFC8994/8995 requirements for CSRattr CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [email protected] with any questions. On 03.09.21 19:00, Michael Richardson wrote: I'm unclear if CMP allows for a standardized way to override the CSR contents, or if it simply provides more authority for the RA to create a new CSR of its own. CMP does not offer a direct/explicit "override" mechanism for CSRs, but it is foreseen that an RA checks a CSR and then modifies it, using the RAVerified option instead of the typical signature-based PoP. This is one of the use cases we describe in more detail in our new Lightweight CMP profile - see https://datatracker.ietf.org/doc/html/draft-ietf-lamps-lightweight-cmp-profile#section-5.2.3.2<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-lamps-lightweight-cmp-profile%23section-5.2.3.2&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf3c492278d354bd84ce508d970745e06%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637664468472820632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fkIbEPvkQxAsRhNmOORlU7btYOJz0l1kpArTpQp8KZQ%3D&reserved=0> BTW, CMP also offers a variety of further forms of PoP, for keys that do not have the capability for signing - see https://datatracker.ietf.org/doc/html/rfc4210#section-5.2.8.4 <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-5.2.8.4&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf3c492278d354bd84ce508d970745e06%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637664468472820632%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=iVEmOILg4eP%2Btz0gY%2FkHJ1WSml9Q2%2B45eEKANCoLxug%3D&reserved=0><https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-5.1.3.4&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf3c492278d354bd84ce508d970745e06%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637664468472830590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lOtKL1bozHRud9CSGiP5nbyj9X%2FefeTx4eGYeXWDkgo%3D&reserved=0> With EST this is not possible simply because it uses the rather limited PKCS#10 format, which requires self-signature, which is not possible at the RA (even for keys that can be used for signing) because it does not have the needed private key. In other words, PKCS#10 and thus EST does not support on-behalf CSRs. While I would also prefer to enhance the RA/CA protocol, I'm not entirely keen on mechanisms that break the original PoP. Yeah, I also prefer avoiding this - as long as the overhead to the EEs is bearable. For cases where the PoP is broken by an intermediate entity, CMP cert request message may contain the original (unmodified) CSR for reference purposes - see https://datatracker.ietf.org/doc/html/rfc4210#section-5.1.3.4<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc4210%23section-5.1.3.4&data=04%7C01%7Ctomas.gustavsson%40primekey.com%7Cf3c492278d354bd84ce508d970745e06%7Cc9ed4b459f70418aaa58f04c80848ca9%7C0%7C0%7C637664468472830590%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=lOtKL1bozHRud9CSGiP5nbyj9X%2FefeTx4eGYeXWDkgo%3D&reserved=0> Anyway, we are going to enhance the CSRattr description to support all the requirements. Good to have this option then in the future. David
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
