Agreed that old cross-certificates will not be impacted, but this does impact new cross-certificates. I assume the work around would be to just issue more than one cross-certificate with different EKUs, but I don't assume that was intended by this policy change.
Bruce. On Friday, July 13, 2018 at 8:02:00 AM UTC-4, Tim Hollebeek wrote: > Doesn't the "created after January 1, 2019" mean that there is no problem > with old crosses? It would just be a new policy for new crosses as of next > year? > > -Tim > > > -----Original Message----- > > From: dev-security-policy [mailto:dev-security-policy- > > bounces+tim.hollebeek=digicert....@lists.mozilla.org] On Behalf Of Bruce via > > dev-security-policy > > Sent: Thursday, July 12, 2018 10:28 AM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: Do We Now Require Separate Cross-certificates for SSL and > > S/MIME? > > > > 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://clicktime.symantec.com/a/1/82jRdde1a_TDsUNagUMK3MwXRBX4JdeH > > iAL > > > jfsD2zgM=?d=5n7PC5UMMMf8ow60aA_zACOHRkVy- > > 9DLApGl29o_1WR_vWTXMDk0d9kBFu > > > > > rU6JcvMPF1WEp4WBRfAgKXpN15C1244hstaDLxsVmE8bwd8UMj0MNvk5w_Q > > C8ibEWzPC_L > > > UljJwJbyQ12v- > > eTKN6FpHJwudbiXqkteAL6SsQfa0QGrVhJI2REzKkz7jXD0KovgoCzWAR > > > mueHAHVd9wo- > > Zf8cGao91RrkdklVah1kaEBTyUKOPMlGbnavPLTjmV4ZRDrnrDCFX4rkD1 > > > Lo77olEchKsy8cAbTYPtzG0lkCI1j4UDxcZ-FUsyVeArS- > > GdV0BnikfsrccHi35Z67abn6 > > > -KrVJCFHHsHbG6kEl9IjbK_HVe2tyNOP4Fkxpq2kv_Dws_N9PMOE- > > HQoRmqNABl-nFDxHu > > > Oru- > > 2ncWO24MRiohMbTk2xrGlehqHvYR2QII6nyw79ouwqK9GVtOi8GsmBewEssvkv > > Y6H_ > > > > > W_xOw3VB6Mp7gtxMSK0v72SLI%3D&u=https%3A%2F%2Fgroups.google.com > > %2Fd%2Fm > > > sg%2Fmozilla.dev.security.policy%2FQIweY3cHRyA%2FvbtnfJ4zCAAJ > > > > _______________________________________________ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://clicktime.symantec.com/a/1/UqWB6X0ty8ImZMghiLXK4dj9WfPgHxf31p > > FYXlE5W5k=?d=5n7PC5UMMMf8ow60aA_zACOHRkVy- > > 9DLApGl29o_1WR_vWTXMDk0d9kBFurU6JcvMPF1WEp4WBRfAgKXpN15C1244 > > hstaDLxsVmE8bwd8UMj0MNvk5w_QC8ibEWzPC_LUljJwJbyQ12v- > > eTKN6FpHJwudbiXqkteAL6SsQfa0QGrVhJI2REzKkz7jXD0KovgoCzWARmueHAH > > Vd9wo- > > Zf8cGao91RrkdklVah1kaEBTyUKOPMlGbnavPLTjmV4ZRDrnrDCFX4rkD1Lo77olE > > chKsy8cAbTYPtzG0lkCI1j4UDxcZ-FUsyVeArS-GdV0BnikfsrccHi35Z67abn6- > > KrVJCFHHsHbG6kEl9IjbK_HVe2tyNOP4Fkxpq2kv_Dws_N9PMOE-HQoRmqNABl- > > nFDxHuOru- > > 2ncWO24MRiohMbTk2xrGlehqHvYR2QII6nyw79ouwqK9GVtOi8GsmBewEssvkv > > Y6H_W_xOw3VB6Mp7gtxMSK0v72SLI%3D&u=https%3A%2F%2Flists.mozilla.or > > g%2Flistinfo%2Fdev-security-policy _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
