Hi Gerv, Disclaimer...GlobalSign is not the CA behind the ccTLD constraints but we do have some questions on this subject area w.r.t S/MIME rather than SSL. As the BR's do not apply to S/MIME and the threat model of SSL and S/MIME use cases is vastly different we should not try to cover with a single brush stroke the use of ccTLD constraints. If we need a new thread then let me know.
Hypothetically, a government organization wishing to issue S/MIME certificates to citizens on a range of ccTLD based domains could be technically constrained through the inclusion of EKU's only as Mozilla's policy allows this, however the addition of the ccTLD constraint for RFC822 names would add further protection to business controls used in the system, but not down the domain level as these may not be known when the issuing CA at the point the CA is created. Do you see any issues with this implementation? A reminder that Mozilla's policy is:- https://www.mozilla.org/en-US/about/governance/policies/security-group/certs /policy/inclusion/ 8 All certificates that are capable of being used to issue new certificates, and which directly or transitively chain to a certificate included in Mozilla's CA Certificate Program, MUST be operated in accordance with Mozilla's CA Certificate Policy and MUST either be technically constrained or be publicly disclosed and audited. A certificate is deemed as capable of being used to issue new certificates if it contains an X.509v3 basicConstraints extension, with the cA boolean set to true. The term "subordinate CA" below refers to any organization or legal entity that is in possession or control of a certificate that is capable of being used to issue new certificates. These requirements include all cross-certified certificates which chain to a certificate that is included in Mozilla's CA Certificate Program. 9. We encourage CAs to technically constrain all subordinate CA certificates. 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.' [SSL portion removed as it's not applicable] If the certificate includes the id-kp-emailProtection extended key usage, then all end-entity certificates MUST only include e-mail addresses or mailboxes that the issuing CA has confirmed (via technical and/or business controls) that the subordinate CA is authorized to use. Thanks for any advice... Steve > -----Original Message----- > From: dev-security-policy [mailto:dev-security-policy- > [email protected]] On Behalf Of > Gervase Markham > Sent: 11 November 2015 11:11 > To: [email protected]; Richard Barnes > <[email protected]>; [email protected] > Cc: Kathleen Wilson <[email protected]> > Subject: Re: Clarify that a ccTLD is not acceptable in permittedSubtrees > > But the question is: do we count that as "technically constrained"? I would say No; > the point of "technically constrained" is that it can only issue certs for domains
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
