Hello,
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.
But I'm not clear about what CMP allows either so there's that.
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. 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?
Anyway, we are going to enhance the CSRattr description to support all the
requirements.
Indeed. So it's probably moot anyway.
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.
regards,
Dan.
--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
