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 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://datatracker.ietf.org/doc/html/rfc4210#section-5.1.3.4>
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 > 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
