On Mon, Apr 30, 2018 at 8:27 AM, Ryan Sleevi <r...@sleevi.com> wrote:
> > > On Wed, Apr 25, 2018 at 1:03 PM, Wayne Thayer <wtha...@mozilla.com> wrote: > >> 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? >> > > 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 :) > This proposal wouldn't change the current requirement for technically constrained intermediates: For a certificate to be considered technically constrained, the certificate MUST include an Extended Key Usage (EKU) extension specifying all extended key usages that the subordinate CA is authorized to issue certificates for. The anyExtendedKeyUsage KeyPurposeId MUST NOT appear within this extension. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
