On Fri, Jul 13, 2018 at 3:50 PM Tim Hollebeek via dev-security-policy < [email protected]> wrote:
> 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 ... > > > I'd like to consider any new restrictions on cross-certificates separately. I've created https://github.com/mozilla/pkipolicy/issues/145 to track this idea, and added that if we go that far we should also think about restricting roots to either the Mozilla websites or email trust bit. 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. > > > It seems that we have agreement that the current change was not intended to apply to cross certificates. I think that is the meaning of the existing language, but it would be clearer if the final paragraph of section 5.3 was amended to: These requirements include all intermediate certificates signed by cross-certificates which chain to a certificate that is included in Mozilla’s CA Certificate Program. Questions: - does anyone object to that new wording? - should the official policy be updated with this change prior to 1-Jan when the requirement to separate usages of new intermediate certificates goes into effect, or can this wait since it is only a clarification? - Wayne -Tim > > > -----Original Message----- > > From: dev-security-policy [mailto:dev-security-policy- > > [email protected]] On Behalf Of > Bruce via > > dev-security-policy > > Sent: Friday, July 13, 2018 10:17 AM > > To: [email protected] > > 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- > > > > [email protected]] On Behalf Of > > > > bounces+Bruce via > > > > dev-security-policy > > > > Sent: Thursday, July 12, 2018 10:28 AM > > > > To: [email protected] > > > > 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 > > > > [email protected] > > > > > > 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 > > [email protected] > > 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 > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
