Re: Clarify that a ccTLD is not acceptable in permittedSubtrees

[Adriano Santoni]

That's a somewhat paradoxical scenario, but I suppose it's not altogether impossible. It is yet another reason why ccTLDs should not be allowed (IMO) in NameConstraints.permittedSubtrees of a SubCA certificate. But of course, prohibiting ccTLDs in NameConstraints would not be sufficient, in itself, to prevent a wildcard certificate for (say) *.us from being issued, as it could be issued by a non-technically constrained CA (it does not seem realistic to me, but many weird things happen in this world every day). So that's a different issue, IMO. If a wildcard certificate for a ccTLDs should never be issued by a trusted CA, regardless of such CA being "technically constrained" or not, then I suppose it should be expressly forbidden in BRs and in browser vendors' Root CA programs/policies. But again, this is a different (although related) issue than I raised. Adriano Il 11/11/2015 21:38, Eric Mill ha scritto: Regardless of whether technically allowed by the BRs -- a technically constrained subordinate CA that is not (directly) audited that is allowed to issue a valid *.us certificate would, if actually discovered in the wild, create some shockwaves. Really, any *.us certificate would create shockwaves, even if the administrator of the .us ccTLD was the owner of a publicly trusted CA and issued it using their normal processes. Before ICANN opened the door to gTLDs like .google, was there any TLD for which it would have been within the bounds of the internet's "social contract" to issue a wildcard certificate? -- Eric On Wed, Nov 11, 2015 at 1:35 PM, Steve Roylance < steve.royla...@globalsign.com> wrote: Hi Kathleen. Apologies, as I should have sent my previous request concerning hypothetical S/MIME ccTLD usage in response to this post. My main concern was not to cover S/MIME and SSL Server Certificates with a single rule. I hope that came across clearly. Thanks. Steve Sent from my iPhone On 10 Nov 2015, at 20:08, Kathleen Wilson <kwil...@mozilla.com> wrote: All, I have been asked to consider updating Mozilla's CA Certificate Policy to clarify that a ccTLD is not acceptable in permittedSubtrees for technically constraining subordinate CA certs. In section 7.1.5 of version 1.3 of the Baseline Requirement it says: "(a) For each dNSName in permittedSubtrees, the CA MUST confirm that the Applicant has registered the dNSName or has been authorized by the domain registrant to act on the registrant's behalf in line with the verification practices of section 3.2.2.4." And in https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/ section 9 says: "For each dNSName in permittedSubtrees, the issuing CA MUST confirm that the subordinate CA has registered the dNSName or has been authorized by the domain registrant to act on the registrant’s behalf. Each dNSName in permittedSubtrees must be a registered domain (with zero or more subdomains) according to the Public Suffix List algorithm." I don't see how a CA could confirm that the subordinate owns/controls all of the domains for a ccTLD (e.g. *.uk). So, it seems to me that any subordinate CA that has a ccTLD in permittedSubtrees does not meet the BR or Mozilla requirements regarding being technically constrained. So, should we specifically state (in the requirements regarding a subCA being technically constrained) that permittedSubtrees cannot contain a ccTLD? Kathleen _______________________________________________ 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 -- Adriano Santoni

smime.p7s
Description: Firma crittografica S/MIME

_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy