On 30/04/2018 18:47, Wayne Thayer wrote:
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.
However maybe an additional (clarifying or new) requirement set:
To be considered as a name constrained SubCA, the SubCA certificate must
satisfy all of the following:
1. Specify a specific non-empty list or permitted EKUs, which does not
include the value anyExtendedKeyUsage.
2. Specify name constraints (whitelist-based) for all the name types
that can be used with the specified permitted EKUs. Any EV-capable
such SubCA must also specify name constraints for the directory name
type.
3. Each name constraint must permit only names for which the holder of
the name constrained CA has been fully vetted as ultimately
authoritative. For example, any DNS names must correspond to domains
registered to the holder for a registration period completely
overlapping the CA cert validity period. Any Distinguished name must
correspond to the verified real world identity of the holder (for
example C=US, O=Google Inc would be a permitted dirname subtree
constraint for a subCA issued to the US headquarters of Google Inc.
The validation must be done to standards above and beyond the
standards required for end entity certificates of the types that the
SubCA can issue.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
