Mike Ounsworth <[email protected]> wrote: > From my reading of the PR / draft, it links to [RFC4043 > <https://www.rfc-editor.org/rfc/rfc4043>] for the specification of a CSR > attribute for PermanentIdentifier, and to [RFC4108 > <https://www.rfc-editor.org/rfc/rfc4108>] for the specification of a CSR > attribute for HardwareModuleName.
> I don't know the right answer here, but I think I know the right question,
> which is: is it actually helpful to specify two different ways to carry
> these identifiers in an ACME request; one inside the CSR and one in the
> ACME JSON?
Two places have the interoperability challenge/possible-security issue of
what happens when they are different. Do all parties consistently use the
correct one, and if they don't, does this lead to some kind of exploit?
(The secondary question is what is the comparison function, is a human ever
involved, and if so, could the human approve one the one that says Ounswörth,
while the CA issues Ounsworth?)
I believe that the attributes need to be part of the challenge, such that the
server can see that the resulting WebAuthN response contains the right thing.
The CSR has *not* been transmitted yet. So you can't remove that part.
The document says that including it in the CSR is optional, and that it would
be ommitted if the resulting certificate would not have those attributes.
(I think that the CA can also remove them by it's own policy)
> I see three possible ways to resolve this situation:
> #1 Delete the ACME JSON mechanism -- this is what Sven's PR is attempting
> (but I agree that it doesn't currently delete it completely from the
> document).
I think it's just wrong.
> #2 Delete the CSR mechanism -- this would mean fully removing all
> references to [RFC4032] and [RFC4108] and instead defining new JSON
> structures.
I see no reason to do this either.
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
