Re: [lamps] [Anima] RFC8994/8995 requirements for CSRattr

[Tomas Gustavsson <[e-mail]>]

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 <[e-mail]> on behalf of David von Oheimb <[e-mail]>
Sent: Sunday, September 5, 2021 3:09 PM
To: Michael Richardson <[e-mail]>; Eliot Lear <[e-mail]>; Dan Harkins <[e-mail]>; Owen Friel <[e-mail]>; Peter van der Stok <[e-mail]>; max pritikin <[e-mail]>; Toerless Eckert <[e-mail]>; Esko Dijk <[e-mail]>; [e-mail] <[e-mail]>; Thomas Werner <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [lamps] [Anima] RFC8994/8995 requirements for CSRattr

CAUTION: External Sender - Be cautious when clicking links or opening attachments. Please email [e-mail] 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