[cabfpub] Name Constraints, Auditing and EKU

[Rob Stradling]

On 06/04/13 03:08, Ryan Sleevi wrote:
<snip>
> All of this said, I'm still quite mixed about Steve's proposal for
> incorporating this language into the BRs. It was drafted by and for
> Mozilla within a very specific context - of NSS using applications -
> and the considerations, concerns, and security trade-offs may or may
> not be broadly applicable for all applications and CAs. For example,
> nameConstraints only apply to the naming types specifically enumerated
> - meaning such constrained intermediates may be valid for any name
> types not enumerated (XMPP names, for example). For Mozilla/NSS, this
> is perfectly acceptable, but is it for the CA ecosystem at large? I'm
> sure Microsoft may be able to find other name types or key usages that
> may be applicable to their root store, given the broader set of
> applications beyond just browsers that use it.

Ryan, I share your concern about other name types, but I'd like to get 
some version of the "technically constrained" language into the BRs if 
at all possible.

AIUI, the big incentive for using Name Constraints at the moment is that 
it enables Subordinate CAs to avoid the time/cost of a WebTrust/ETSI 
audit.  If we want to see the use of Name Constraints become more 
widespread (which I think we do!) then we need to ensure that this audit 
avoidance option remains open.
We can't just consider Mozilla's "very specific context" in isolation. 
CAs have Root Certificates embedded in lots of Root Programs that 
determine their own policies.  If just one Root Program were to demand 
that without exception all Subordinate CAs must obtain a WebTrust/ETSI 
audit, then the "technically constrained" option would die.

I would hope that, if the "technically constrained" language is in the 
BRs (and not just in Mozilla's "very specific context" policy), the 
chances of this option dying would be reduced.

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online