Esko Dijk <[email protected]> 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 <[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
