On Mon, Nov 1, 2021 at 3:43 PM Corey Bonnell <[email protected]>
wrote:

> > I'm not sure I follow? A SHOULD NOT is not any more onerous, as it's not
> a prohibition.
>
>
>
> BR 7.1.2.2 (g) currently reads:
>
> “For Subordinate CA Certificates that will be used to issue TLS
> certificates, the value id-kp-serverAuth [RFC5280] MUST be present. The
> value id-kp-clientAuth [RFC5280] MAY be present”.
>
>
>
> The current proposed Mozilla Policy text essentially changes the MAY to a
> SHOULD NOT. While not a concrete prohibition, it is certainly more
> onerous/strict than the BRs. As you know and from the RFC 2119 text you
> quoted, “SHOULD NOTs” are indicative of some practice that Root Programs
> generally frown upon, which is why I brought this up.
>

Sure, but more strict is not synonymous with more onerous though, is it?
That is, it doesn't seem "oppressively burdensome" (Oxford) or imposing a
burden (Meriam Webster) to require that CAs consider the full implications
of allowing a certificate to be used as a client identity? Especially given
the CA incidents seen around the use of TLS certificates for mutual
authentication leading to delayed revocation.

As for SHOULD NOTs being something "generally frowned upon", that's not
really consistent, is it? It may indicate something that may eventually
become a MUST NOT, based on the evolving landscape of complexities, but it
merely acts to signify that there are complexities present and to be
considered, and that it's not truly zero-cost/free to use or not use (as a
MAY implies). I think the thing typically frowned upon is a lack of
carefully weighing the implications, not that implications need to be
weighed.

-- 
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAErg%3DHHaznewVT%2Bsu0NUZv1iekjxY3CFnjxF1s%2B%3DEgnL_t%2BY_g%40mail.gmail.com.

Reply via email to