Note the BRs define Cross Certificate as "a certificate that is used to establish a trust relationship between two Root CAs."
I think the intent was to technically restrict subordinate CAs or rather CAs which are online and issue end entity certificates. My assumption is that we want to 1) not allow a subordinate CA to issue a certificate which it was no intended to issue and 2) mitigate the risk if an online subordinate CA has been compromised. Typically, if an old root cross-certifies a new root, the purpose is to give the new root browser/OS ubiquity. The new root may be used to support end entity certificates of many types (e.g., Server Auth, S/MIME, Client Auth, Code Signing, Document Signing, Time-stamping ...). If we restrict the cross-certificate, then this will limit the use of a new root. Also note that the new root is 1) not an issuing CA and 2) is offline, so the mitigation of technical restriction may already be satisfied. Thanks, Bruce. On Tuesday, July 10, 2018 at 7:21:26 PM UTC-4, Wayne Thayer wrote: > During a 2.6 policy discussion [1], we agreed to add the following language > to section 5.3 "Intermediate Certificates": > > > Intermediate certificates created after January 1, 2019: > > > > > > * MUST contain an EKU extension; and, > > * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, > > * MUST NOT include both the id-kp-serverAuth and id-kp-emailProtection > > KeyPurposeIds in the same certificate. > > > > It has been pointed out to me that the very next paragraph of section 5.3 > states: > > These requirements include all cross-certified certificates which chain to > > a certificate that is included in Mozilla’s CA Certificate Program. > > > > The term "cross-certified certificates" could refer to the actual > cross-certificate, or it could refer to intermediate certificates that > chain up to the cross certificate. In the case of a root that is being > cross-certified, the former interpretation effectively means that distinct > cross-certificates would be required for serverAuth and emailProtection, as > follows: > > 1 - Root <-- Cross-certificate (EKU=emailProtection) <-- Intermediate > certificate (EKU=emailProtection) <-- leaf certificate (S/MIME) > 2 - Root <-- Cross-certificate (EKU=serverAuth) <-- Intermediate > certificate (EKU=serverAuth) <-- leaf certificate (SSL/TLS) > > Should our policy require cross-certificates to be constrained to either > serverAuth or emailProtection via EKU, or should this requirement only > apply to [all other] intermediate certificates? > > What is the correct interpretation of section 5.3 of the policy as > currently written? > > I would appreciate everyone's input on these questions. > > - Wayne > > [1] > https://groups.google.com/d/msg/mozilla.dev.security.policy/QIweY3cHRyA/vbtnfJ4zCAAJ _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
