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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
