Esko Dijk <[email protected]> wrote: > The current BRSKI text to me suggests that CA:TRUE is a requirement for > the pinned-domain-cert. But I'm okay with not having CA:TRUE for this > certificate, as you propose, in which case I think the BRSKI text needs > some minor updates on the wording.
> For example, if it's just a Registrar cert with CA:FALSE and RA:TRUE
> then it shouldn't be called a "domain CA" cert or "domain cert".
> If the Registrar is not a CA, it does need to be a Registration
> Authority (RA). (See Section 2.5.3 / 2.5.5 / 5.5.4 /
> https://tools.ietf.org/html/rfc6402#section-2.10 )
> So the requirement for the pinned cert is that it is either RA or CA.
> (Both seems also possible to encode in the cert, although that seems
> equivalent to a CA.)
I think you that you are likely correct: every entry in a chain which is not
the EE, has CA:TRUE, and the last one, is the Registrar which ought to have
cmcRA set.
If I were to locate a PKIX-lawyer hat, I would say that the Pledge SHOULD
check this. Given that there is a strong desire to operate registrar's
using only certificates obtained via ACME (LE), and it will be difficult to
get cmcRA set... I don't know what to do here.
<Please insert long EMU Thread here>
We have written in the ACP document that a device SHOULD verify the cmcRA bit
is set on any EST server that the device speaks to to renew it's certificate.
Please note that I am saying "device" and not pledge!
We did not insist on cmcRA be set in section 5.1, specifically because we
didn't know if RA:TRUE was something we could insist upon here.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
