Yeah, I agree I don’t think it was intended. But now that I am aware of the issue, I think the crossing workaround per EKU is actually a good thing for people to be doing. Unless someone can point out why it's bad ...
Might want to give people a little more time to plan and adapt to that change though since I doubt anyone thought of it and people need planning runway to change their procedures if it is going to be interpreted this way. -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: Friday, July 13, 2018 10:17 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Do We Now Require Separate Cross-certificates for SSL and > S/MIME? > > 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 > > > bounces+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/UqWB6X0ty8ImZMghiLXK4dj9WfPgHxf31 > > > p > > > 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://clicktime.symantec.com/a/1/wNze3hZcZDNkGJs2uz- > SeEqGu_7QRemtNV2zTN4w6eA=?d=UWO2h2txAwcfMe5bqfj4PnyJC-fPf- > jWINE8QAK6rKZhjWzUPs2jCHsJL_KIV6tsKYcbL2mfdvUjwCVFDiT3BvhiR5V29scB > NCPx3iSBUFGl4Hch0iE4oi7chSA365HSr4m2CYJGYldzjUmox9DS7D7rArUAHY1XB > Mek0obO98xn3LgdmNKeL5XUoGDW4Q85610Pj4Aa_0hbpgKzl870mCIXsGjH4Xl > y28s1mHQU1dGwygaOH4n6iK6GqI1xJ20HjyZaQOkY8Sk5PE5xb8f1Cv_WcHNsPt > Wnum0eUZ9_Sn904q_2Q1aXb7Y0weCKKCaU9ELY6ugItt8ngKWOHmtVyo0Ef- > 3FzIfu1UTDqGWG169kW0w4F611kLa1gnEhpP8HmcECC0eThNLgqX57tzbUED6 > RF0iM96G520RE6U2hL2sj- > TafMqmwPdgMMlyEaDeri1vaMgRhWihiFj8th7o1JcIa5PfWas8KYPzteyOYY2jDT > 2EfeLpWB2b7&u=https%3A%2F%2Flists.mozilla.org%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
