On 05/19/2017 05:43 PM, Kurt Roeckx wrote: > So I think we have a few categories of certificates: > - Those issued in the past, which can still be valid for up to 3 > years. I'm not sure when the last 5 year certificates are > supposed to expire, or if they all expired, but I don't think > those take long to expire. > - Those that still get issued before they move to some new PKI. > > If you want to distrust their existing roots before those > certificates expire, this will most likely results in at least > some people having problems. And that it would be up to Symantec > to make sure those people get new certificates and started using > them. >
When it boils down to that, I'm OK with the existing certs being allowed to age out (perhaps capped to 39 months total if there are any five year certificates still floating around) as long as new issuances are stopped from the old roots within a reasonable time frame. That being said, new issuances from the existing PKI should be capped on expiration. >>From the mail about Chrome's plan, I understand that Chrome's plan > is to only allow certificates from the old PKI if they qualify for > their CT requirements. They plan to only allow certificates issued > after 2016-06-01 because that's the date when they required CT > from Symantec. It seems that Symantec can still issue new certificates > using the old PKI up to 2017-08-08 that are still valid for 3 > years. > > I'm a little concerned that Firefox and Chrome will have different > certificates they don't trust, and would hope that you can come to > some agreement about when which one would get distrusted. > This was likely unavoidable due to the simple fact that the Google-Symantec discussions happened behind closed doors. Unless we can influence Google's final policy, then this is likely going to be the case no matter what. > I have a problem with one CA signing an other unrelated CA. I > would prefer that we have a policy that forbids that, and that the > CA should make sure it's own root gets added to the root store. > The only reason I can see for cross signing is for people that still > using an old root store. > ++ here >> - I'm not sold on the idea of requiring Symantec to use third-party CAs to >> perform validation/issuance on Symantec's behalf. The most serious concerns >> that I have with Symantec's old PKI is with their third-party subCAs and >> third-party RAs. I don't have particular concern about Symantec doing the >> validation/issuance in-house. So, I think it would be better/safer for >> Symantec to staff up to do the validation/re-validation in-house rather than >> using third parties. If the concern is about regaining trust, then add >> auditing to this. > The current proposal is more complicated than that since it talks about reusing part of the original validations and OIDs to control the max length of the certificate. I rather dislike that since its both complex, and introduces the trust issues from the old hierarchy into the new one which moots the point of spinning up a new root in the first place. > So they should just create new root CAs and ask them to be > included in the root store? > Honestly, we got into this mess in the first place due to third-party signers. I don't think the right solution to stopping a gas fire is to throw more gas on it. Michael _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
