On Tue, Apr 24, 2018 at 9:24 AM, Ryan Sleevi <r...@sleevi.com> 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? On Mon, Apr 23, 2018 at 3:42 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Sun, Apr 22, 2018 at 2:56 PM, pfuentes69--- via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >> > I think you should consider an an exception Issuing CAs including Name >> > Constraints. This would keep allowing root signing services for >> corporate >> > CAs without forcing multiple CAs. >> > >> >> Thank you for the suggestion. It seems reasonable to me. If no one >> objects, >> I will move the proposed language to section 5.3.2 so that it applies only >> to unconstrained intermediates. >> >> - Wayne >> _______________________________________________ >> dev-security-policy mailing list >> dev-security-policy@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-security-policy >> > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
