{Trimming massive CC to just lists}
Dan Harkins <[email protected]> wrote:
>> 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?
In the ACME/RFC8555 case, it seems to me that the CA could provide a
challengePassword.
I don't believe that this occurs today, but it seems like we ought to
anticipate this as a future event.
>> 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.
I agree. I'd like to see a RA->CA protocol that augments rather than replaces.
I agree that this takes time, but
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
