Jakob, On Tue, May 1, 2018 at 1:14 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote
> > However maybe an additional (clarifying or new) requirement set: > > I think the existing language in section 5.3.1 covers all of this. If not, can you point out the gaps so that I can open a new issue? 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 certific > <https://maps.google.com/?q=andards+required+for+end+entity+certific&entry=gmail&source=g>ates > of the types that the > SubCA can issue. > > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
