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

[David von Oheimb <[e-mail]>]

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