On 05/15/2017 06:05 PM, Jakob Bohm wrote: > > Ok, that's much better. >
Yay for reasonable courses of action. We'll see if it goes into the next proposal. >> I can see the point here, but I'm not sure I agree. Every time we keep >> digging, we keep finding more and more problems with these roots. >> WebPKI depends on all certificates in the root store being >> trustworthy, and Symantec as a whole has not exactly shown themselves >> to be responsive or willing to communicate publicly on the various >> issues brought up on the list. >> > > Yes, that seems to be the trend. But it has nothing to do with if the > "9 month" rule or some other measures are the best remedy. > There might be a reasonable compromise here, see below. > RAs (external companies that can decide if Symantec itself should issue > a cert) are completely different from external SubCAs (external > companies that have their own CA and a certificate chain back to a > Symantec root), which are different from internal SubCAs (CA > certificates for Symantec controlled keys, such as the SubCA that > signed normal OV certificates issued in January 2017). > > External and Internal SubCAs can be blocked by simple technical means > via TrustDB and OneCRL manipulations. RAs are indistinguishable from > Symantec itself when checking certificates, because the certificates > were in fact signed by Symantec itself. > I thought the RAs were being issued off their own intermediate branches and not off Symantec ones. Rechecking crt.sh "C=KR, O=CrossCert, OU=AccreditedCA, CN=CrossCert Class 1 Server CA" is a separate intermediate chaining to KISA so I done goofed here. Oops. Re-reading the issues, I think I got crossed between subCAs missing audits, and RA issuance. > The standard way this is done is that the old roots (which are trusted > by old browsers) cross-sign the new roots or the subCAs of the new > roots. People buying new certs get (as always) a new cert chain for > their new cert, which contains enough data to pass in browsers that > trust new root, trust the old root, or trust both roots. > > Servers with old certs still return the old certificate chain that > leads to the old roots. > > Other measures (such as browser embedded SubCA/cross certs) can be used > to reduce how much of the old CA tree Firefox/Thunderbird trust during > the transition. > Thanks for clearing this up. > I think we will need to look separately at two very different issues: > > 1. Symantec's PKI and the location of the EV trust bit unfortunately > allows non-EV SubCAs to issue EV certs that Firefox marks as green. > This same issue applies to most Mozilla trusted roots, because > Mozilla implemented the EV trust at the root CA level rather than at > a SubCA level. > > This can be fixed technically by restricting the EV trust to the > SubCAs that are supposed to issue EV certs, rather than to whatever > general WebPKI root cert resides above it (in order for legitimate EV > certs to be trusted as normal certs by old browsers). > This is a start. We'd need confirmation from Symantec which subCAs are supposed to be able to sign EV as I don't believe we have a complete list. That's also assuming that things are that nice and organized (which is far from a given). If we can successfully cut a good chunk of the crud away, it would at least help in mind keeping EV being a reasonable option. > 2. If there were any significant failures in the validation of EV > certs signed directly by the dedicated EV SubCAs at Symantec (other > than the one test cert that got some Symantec people fired some time > ago). > Can we reasonably determine we're good here beyond a reasonable doubt? The current responses to the last question found new parts of the fPKI that are chaining via the Issue Y intermediates that appear that they would be trusted by Mozilla. We also have confirmation that some of the RAs could issue EVs and could validate certificates. Symantec said that they independently checked the non-expired EV certificates, but I think I have (IMHO) justified concerns there might be additional ones here we don't know about. Given the number of unknown knows with the EV situation right now, I think I'm going to wait for more information before pushing any one specific option, but at a minimium, we need to cut down the parts of the tree that can sign for EV. There's also a third issue is "what is the correct response to the severity of Symantec's trust issues". We're fairly close to CNNIC territory here, since we've got multiple intermediates that chain to the Mozilla roots and can issue certificates which are either not BR compliant, or out of scope of an audit. In an attempt to try and get this thread to a point where the powers that be might choose to include it in their proposal, let's try the following in the addition to what is under PKI concerns in the gdoc: --- - For any Symantec-owned root certificate in the Mozilla trust program with the CKA_TRUST_SERVER_AUTH bit enabled, all leaf certificates in the chain shall contain embedded SCT information. This shall be required for the certificate to be trusted. (or in plain English: web certificates need both CT and SCT embedded. S/MIME certificates are alright without. We separate these into two separate chains of trust so they can't accidentally intermix.). - For the purposes of CKA_TRUST_EMAIL_PROTECTION, all CA and subCA certificates in the chain of trust must have embedded SCT information to be considered trusted. The leaf certificate shall be exempt from this requirement. - A three-day grace period shall be in place from the issuance date of a certificate to when it must be in the CT logs for validation reasons (this is in line with other proposals here). - Certificates issued for server authentication without SCT information being timely submitted shall be considered equivalent to a misissue. Exceptions to this policy for legacy customers may be granted on a case-by-case basis. - All server authentication certificates shall be submitted to at least two public CT logs. - Certificates issued before the effective date shall continue to be trusted until their expiration/revocation. These certificates shall be exempt from the embedded SCT requirement unless reissued. - Symantec shall identify (if possible) subCAs are supposed to be used for issuing EV certificates. The EV trust bit shall be removed from the root, and added to the intermediate certificates. - Certificates issued from the pre-existing roots after the effective date shall be limited to a maximum lifetime of nine months. --- This revised proposal achieves the following - Mozilla never trusts a certificate we can't independently audit and verify via the CT logs. This also slams the door shut on Issue Y of ever becoming an issue again since we'd immediately be able to spot it before the issue snowballs. - S/MIME and ServerAuth is clearly separated. No chance of a nasty surprise from an undisclosed CA that has only been issuing S/MIME certificates but could issue for SA due to a lack of EKUs (since S/MIME intermediates wouldn't show up in the CT logs as far as I know). - In the S/MIME case, while we can't drop the entire load into CT to find undisclosed intermediate certificates, we can mandate that the embedded SCT for those subCAs has to be there. That should force all the intermediate certificates that can sign for S/MIME into the logs so we can at least get *some* idea of the situation here. It at least helps to ensure that S/MIME intermediates are being disclosed, and we're only trusting what is being disclosed. I don't know if we can reasonably do this for the old roots though short of hardcoding all the SCTs into NSS which is likely undesirable. - The SCT exemption policy allows for legacy customers to get certificates for devices that might choke on them (since I've seen some pretty ugly embedded TLS stacks). We will never trust a certificate meant for this scenario, keeping in line with the above. - The old root certificates can't issue for longer that nine months past the effective date. That should light a serious fire to migrate ASAP, but prevent existing certificates from being heavily impacted except in the case of reissue (which should be reissued against the new roots). - For customers who pinned the old roots or can't migrate, issuance off the old certificates remain possible while lighting a fire under them to fix their infrastructure if they don't wish to reissue every nine months. - It at least limits some of the potential issues with the current EV mess. I'm still personally of the opinion that this might need to go further but at least its a start. --- Final thoughts: As far as I can tell and based on my reading, Mozilla products only care about SERVER_AUTH, CLIENT_AUTH, and EMAIL_PROTECTION, with the other trust bits being legacy. For CLIENT_AUTH, it might be worth doing something similar to the S/MIME provision, but I don't know enough to determine the actual impact here. While I think there's still discussion to be had on max life+EV, I think the mandated SCT provisions would go a *long* way in helping restoring trust in Symantec since it means any potential misissues could be detected relatively easily, and we never trust anything that can't be independently verified. It also goes a good way at lighting the necessary fires under Symantec management, though some part of me wonders if the max expiration should be lower. I realize this might be a fairly large technical burden to get implemented, so I'm willing to pitch in some way to help if someone is willing to mentor me. As always, hoping to hear comments, and the TPTB are willing to consider it and point out where I've been stupid. Michael _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
