To be quite honest:
A section describing certificate requirements (grouping them all) is
necessary for constrained voucher and BRSKI RFC.
Suggestion: a new document?
Peter
Michael Richardson schreef op 2021-07-27 04:18:
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
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
_______________________________________________
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
