Esko Dijk <esko.d...@iotconsultancy.nl> wrote:
> If the EKU is present, it will restrict the allowed usage purposes of
> the certificate to only those items listed in the EKU. So, if a client
> needs to use such certificate for DTLS/TLS, it needs to add
> id-kp-clientAuth.
> And if a server needs to use such certificate for DTLS/TLS it needs
> id-kp-serverAuth.
> Consequence for a Registrar server, that MUST have id-kp-cmcRA set, is
> that it also needs id-kp-serverAuth set in the EKU. Older DTLS 1.2
> stacks for example may not check EKU yet in such a way (e.g. an older
> Scandium I used did not check) but I expect never 1.2/1.3 stacks to
> check EKU.
> @Michael this could be worth adding to our constrained-BRSKI draft as a
> clarification, as it seems non-trivial. (It was to me for sure.)
> And maybe also keep this for considerations for a BRSKI-bis document.
So, I've opened https://github.com/anima-wg/constrained-voucher/issues/146.
I agree that we should put it constrained-voucher.
It sounds like you also think it deserves an errata.
--
Michael Richardson <mcr+i...@sandelman.ca> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
