On 03.09.21 19:35, Dan Harkins wrote: > On 9/3/21 10:00 AM, 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. > Well not really override, more like augment. As I understand it, the device > in this case does not know the subjectAltName that the RA wants to be included > in the CSR so it's unlikely that the CSR would have a subjectAltName (assuming > the RA didn't ask for one in the CSRAttrs) that would need to be overridden. I'd say it does not matter whether one calls this 'override' or 'augment'. The point is that the contents of the cert template in the CSR are modified (regardless in which way, by changing or adding values).
> But I'm not clear about what CMP allows either so there's that. I answered this point in the email just sent. >> While I would also prefer to enhance the RA/CA protocol, I'm not entirely >> keen on mechanisms that break the original PoP. > Agreed, but keep in mind that the CA has no idea whether the > challengePassword > field is correct or not so the assurance that the CA has that it is really > this > device that produced the CSR is through the RA vouching for it. Right. BTW, the use of the challengePassword in EST (and SCEP) is another weakness - this way the proof-of-orgin crucially depends on its value not leaking. The design would have been much more robust if MAC-based protection had been used instead, as offered, among others, by CMP. > The RA does the due diligence that the CA requires to issue a certificate. > That being the case, > how much is lost through the RA vouching for the entire thing? I agree there is not much lost - as I wrote before, the RA needs to be trusted by the CA anyway. Yet note that using PKCS#10 (as done by EST and SCEP), an on-behalf CSR is not possible simply because the CSR is required to be self-signed, which cannot be done by the RA not having the private key of the EE. > Anyway, we are going to enhance the CSRattr description to support all the > requirements. > Indeed. So it's probably moot anyway. Yep. > I really think the more elegant solution would be the RA augmenting the CSR > with > a little bit of goo. But that requires CAs to understand augmented CSRs that > have > goo and there are practical considerations to rolling out a solution here > that compel > the use of CSRAttrs. I don't agree this is elegant. It requires a secondary protocol between RA and CA just because EST (at least in its current form) is too limited. In my view it is more straightforward and future-proof to correct the EST CSRattrs mechanism and/or to use an existing more capable protocol between RA and CA. Regards, David
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
