On Wed, Apr 25, 2018 at 1:03 PM, Wayne Thayer <[email protected]> wrote:
> On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi <[email protected]> wrote: > >> I'm not sure I underestand the use case. I'm hoping that they can clarify >> more. >> >> Pedro - can you explain more about why this is important? > > That is, it would seem valuable as part of the technical constraint >> exercise to ensure the EKUs are restsricted. This is particularly true due >> to how nameConstraints work - they are blacklists (effectively), rather >> than whitelists, which means that combined with EKUs, they can be used for >> unconstrained purposes. >> >> Similar to the discussions regarding nameConstraints and name types, this >> has the effect of discouraging the introduction of new EKUs, as such >> intermediates would be unconstrained for these potential new and novel EKU >> use cases. >> >> Ryan - can you explain this concern in more detail? If, for instance, the > srvName type was added for TLS certificates, new intermediates would be > required to constrain that name type due to the "fail open" nature of name > constraints. If a single intermediate contained both the serverAuth and > emailProtection EKUs, how does that make the situation worse? Is it just > that now all of the S/MIME certificates issued under the intermediate must > also expire or be replaced so that the old intermediate (without a > constraint on srvName) can be revoked? > You're absolutely correct that if an intermediate certificate contains serverAuth and emailProtection EKUs, then we are bounded in the types of certificates it issues. It is only in the situation where it lacks an EKU, or where it's granted the anyExtendedKeyusage EKU, that we're in a situation where we're failing "open". My understanding of the proposal to "make an exception" for nameConstrained CAs was to allow any of these - that is, a combination of explicit EKUs, lacking an EKU, and an anyEKU. The consequence of this would be that the introduction of srvName for TLS, in the case of (lacking an EKU, any EKU), would mean that such an intermediate is unconstrained for TLS issuance - even if it was only 'intended' for something such as S/MIME and smart-card auth. If the proposal is to allow multiple (explicit) EKUs on an intermediate, when the intermediate also has constraints appropriate for each of the enumerated EKUs, then I think we're in a better place, although we should understand the motivation more :) _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
