Re: Mozilla Security Blog re Symantec TLS Certs
On 13.03.2018 15:59, Peter Bowen wrote: >> >> Which companies, other than Apple and Google, benefit from DigiCert >> running the Manager Partner Infrastructure and from DigiCert being part >> of the exclusion list? > > An unlimited set. Any company who purchases a certificate from > DigiCert that is issued by one of the Managed Partner Infrastructure > CAs benefits. Thank you very much for this helpful statement. I understand that previously, the trust of DigiCert Partner CAs was enabled by signing from Symantec CAs. Because the keys of the managed partner CAs were never controlled by Symantec, it is deemed acceptable to allow these to remain trusted. My conclusion is, the blog post is incomplete. IIUC, the blog post should be updated to add DigiCert as another entity controlling subordinate CAs on the exception list. It might be worth to mention in the article, why the exception for these subordinate CAs is deemed acceptable. IMHO, it is important to highlight that Apple and Google aren't the only entities that own certificates that will remain valid under the Symantec hierarchy. Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla Security Blog re Symantec TLS Certs
On 13.03.2018 15:35, Ryan Sleevi via dev-security-policy wrote: > >> Are the DigiCert transition CAs, which are part of the exclusion list, >> and which you say are used for "Managed Partner Infrastructure", >> strictly limited to support the needs of the Apple and Google companies? > > > No. If the answer is "no", it means there are additional beneficials besides Apple and Google. > Apple is Apple. Google is Google. DigiCert is running the Managed Partner > Infrastructure from the consensus plan, using the two transition CAs, in > addition to the two pre-existing roots participating in Mozilla's root > store. Which companies, other than Apple and Google, benefit from DigiCert running the Manager Partner Infrastructure and from DigiCert being part of the exclusion list? Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla Security Blog re Symantec TLS Certs
On 13.03.2018 14:59, Ryan Sleevi wrote: > the blog post says, the subCAs controlled by Apple and Google are the > ONLY exceptions. > > However, the Mozilla Firefox code also treats certain DigiCert subCAs as > exceptions. > > Based on Ryan Sleevi's recent comments on this list, I had concluded > that the excluded DigiCert subCAs are used to support companies other > than Apple and Google. Is my understanding right or wrong? > > > I think your understanding is incorrect. The DigiCert SubCAs are being > treated as part of the Managed Partner Infrastructure (aka the consensus > plan), and the (cross-signed DigiCert Roots) are excluded to avoid path > building issues in Firefox. Your earlier explanations were very complex, and had increased my uncertainty about who is covered by the Managed Partner Infrastructure. In your earlier explanations, you had mentioned additional company names besides Apple and Google. This had given me the impression that the Managed Partner Infrastructure isn't limited to support the Apple and Google companies, but to also support other companies. > That is, the exclusion of those DigiCert Sub-CAs *is* the consensus plan > referred to - what else could it be? > > > Are Apple and Google really the only beneficials of the exceptions, or > should the blog post get updated to mention the additional exceptions? > > > Do you think the above clarifies? I hope we are close. I really wish we could bring it down to a simple yes or no question, and you being able to respond with a clear yes or no. Let me try again. Are the DigiCert transition CAs, which are part of the exclusion list, and which you say are used for "Managed Partner Infrastructure", strictly limited to support the needs of the Apple and Google companies? Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla Security Blog re Symantec TLS Certs
On 12.03.2018 22:19, Kathleen Wilson via dev-security-policy wrote: > Wayne and I have posted a Mozilla Security Blog regarding the current > plan for distrusting the Symantec TLS certs. > > https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/ Hello Kathleen and Wayne, could you please clarify the plan for Firefox ESR (Enterprise Support Version) ? Firefox 63 and Firefox ESR 60.3 will be released on the same date. Does Mozilla plan to implement the identical distrust in both Firefox 63 and Firefox ESR 60.3 ? Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla Security Blog re Symantec TLS Certs
On 12.03.2018 22:19, Kathleen Wilson via dev-security-policy wrote: > Wayne and I have posted a Mozilla Security Blog regarding the current > plan for distrusting the Symantec TLS certs. > > https://blog.mozilla.org/security/2018/03/12/distrust-symantec-tls-certificates/ Hello Kathleen and Wayne, the blog post says, the subCAs controlled by Apple and Google are the ONLY exceptions. However, the Mozilla Firefox code also treats certain DigiCert subCAs as exceptions. Based on Ryan Sleevi's recent comments on this list, I had concluded that the excluded DigiCert subCAs are used to support companies other than Apple and Google. Is my understanding right or wrong? Are Apple and Google really the only beneficials of the exceptions, or should the blog post get updated to mention the additional exceptions? Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 01.03.2018 18:45, Ryan Sleevi via dev-security-policy wrote: >> >> The point of my question is to clarify, if the DigiCert transition Roots >> are completely separate from the Apple/Google subCA whitelisting >> requirements. >> > > I'm not sure how to interpret the Apple/Google question, but yes, they are > treated as completely separate. I'm trying to have a clearer understanding about "who needs what". Let me reword it. Google requests that certain subCA SPKIs are whitelisted, to ensure continued trust of Symantec-issued certificates that are used by infrastructure that is operated by Google. Is whitelisting the SPKI found in the Google subCA sufficient to achieve the need of trusting Google's server infrastructure? I assume the answer is yes. If I'm right, and the answer is "yes", then it means that whitelisting the SPKIs from the DigiCert transition Roots isn't required for Google's servers. It's required for continued trust of other, non-Google server systems. Or rephrasing again: There are no Google servers that use certificates from DigiCert's Managed Partner Infrastructure. I further assume that it's possible to replace the word Google with the word Apple in all previous paragraphs, and the statements are still correct. Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
Hello Ryan, thanks again for this response. The situation appears very complex. I might follow up with a couple of clarification questions, that are hopefully simple to answer. Let me start with this one: Chromium will whitelist the SPKIs of a "CN=DigiCert Transition ECC Root" and a "CN=DigiCert Transition RSA Root" certificate, as found in this directory: https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec/managed Are there any Apple systems, servers, infrastructure, devices, that rely on any of these DigiCert transition Root CAs? Are there any Google systems, servers, infrastructure, devices, that rely on any of these DigiCert transition Root CAs? The point of my question is to clarify, if the DigiCert transition Roots are completely separate from the Apple/Google subCA whitelisting requirements. Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Deadline for whitelisting of the Apple/Google subCAs issued by Symantec?
In my opinion, Mozilla's and Google's plans to distrust the Thawte, RapidSSL, GeoTrust, Verisign, and Symantec branded CAs in the browser, should be interpreted as a recommendation to eventually distrust them for all server authentication uses. If a CA gets distrusted for https, then I think it's fair to equally consider it as no longer acceptable for other services like IMAPS or LDAPS. As Ryan said in another thread, migration of non-https services might take a longer time to migrate. However, based on Jeremy's statement in https://bugzilla.mozilla.org/show_bug.cgi?id=1437826#c3 I'd assume that the customer certificate migration efforts driven by DigiCert should also cover migration of non-https services within a reasonable amount of time, where general purpose client software is used to connect to non-https services. (I'm excluding special purpose hardware with embedded restrictions, and also excluding manually configured server to server configurations.) I conclude that for general purpose client software, that doesn't implement key pinning and doesn't have restrictions on chain length, but which wants to retain the ability to connect to services offered by Apple or Google, the whitelisting for Apple/Google subCAs is the only hindrance for eventual full distrust of the Symantec Root CAs. Are the owners of the Apple and Google subCAs able to announce a date, after which they will no longer require their Symantec-issued subCAs to be whitelisted? Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
Ryan, thanks for highlighting that I missed a few Roots. So originally, the October 2017 announcemend had mentioned: - GeoTrust Global CA - GeoTrust Primary Certification Authority - G2 - GeoTrust Primary Certification Authority - G3 Looking at the data available at https://chromium.googlesource.com/chromium/src/+/master/net/data/ssl/symantec more closely, I see a total of 5 Roots that, which issued subCAs that are listed in the "excluded" and "managed" directories (3 GeoTrust, 2 VeriSign): - VeriSign Class 3 Public Primary Certification Authority - G4 - VeriSign Class 3 Public Primary Certification Authority - G5 Now I looked again at your recent example https://crt.sh/?spkisha256=ac50b5fb738aed6cb781cc35fbfff7786f77109ada7c08867c04a573fd5cf9ee where you mentioned, that additional root CAs had to be created on December 8. In that list, I see several self-signed roots and several additional subCAs. The subCAs chain to these additional Roots: - GeoTrust Primary Certification Authority - thawte Primary Root CA - thawte Primary Root CA - G3 - VeriSign Class 3 Public Primary Certification Authority - G3 - VeriSign Universal Root Certification Authority You also said, at this time it's unknown if creation of additional subCAs might be necessary. What does that mean for non-browser SSL/TLS client software, which cannot do whitelisting based on SPKI, but which wants to ensure compatibility with non-migrated certificates? Does it mean that such software should continue to keep trusting all Symantec Roots from the Symantec Legacy infrastructure, beyond October 2018, for an currently unknown period of time? Furthermore, in the above list at crt.sh I see that several self-signed Roots were created. I don't understand why that was necessary. At https://bugzilla.mozilla.org/show_bug.cgi?id=1401384#c13 Jeremy commented that including additional Roots won't be necessary for the migration. What was the purpose of creating those new self-signed Roots? Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 13.02.2018 18:10, Ryan Sleevi wrote: > > On Tue, Feb 13, 2018 at 11:30 AM, Kai Engert <mailto:k...@kuix.de>> wrote: > > A couple more comments below: > > On 12.02.2018 19:13, Ryan Sleevi wrote: > > > > You're asking about non-browser environments that cannot > > implemented > https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F > > <https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F> > > ? I thought we'd ruled that out of scope rather comprehensively. > > Do you mean out of scope for this discussion on this list? I understand. > > > Not out of scope of discussion - I think it's good to have that > discussion. Personally, I view it more as a Tier-1 vs Tier-3 > conversation, but I realize others may see it as Tier-1 vs Tier-2, to > use > the > https://developer.mozilla.org/en-US/docs/Mozilla/Supported_build_configurations > terminology. > > As it relates to the question you posed, I don't think we can reason > about the abstract "environments", but if there's a concrete environment > you maintain and can speak to, I think it's good to have that conversation. OK. I'm researching what approach should be used for the Fedora Linux distribution, where a single CA trust list (based on Mozilla's CA trust list) is used for the whole system, including Firefox, and other applications that use other certificate validation logic, like the ones built into the GnuTLS, NSS and OpenSSL libraries. Based on the past and recent information exchanged on this list, my current thinking is: For the initial distrust phase in Spring 2018, ship the Mozilla CA list as it is released with Firefox 60 and the respective NSS version. As a consequence, the distrust of certificates issued by Symantec prior to 2016-06-01 would be limited to the Firefox and Chromium browsers (and potentially including Thunderbird). All other SSL/TLS client software on Fedora Linux would continue to allow the unlimited set of Symantec issued certificates, as allowed by the Mozilla CA list. For the second distrust phase in Autumn 2018, assume that all Symantec customers (excluding the managed CAs that are covered by the whitelisted subCA SPKIs) have been fully migrated off of the old CA hierarchies. This assumption isn't limited to SSL/TLS server certificates used for services intended to be consumed by web browsers, but includes all SSL/TLS server certificates, including those used for non-https services (e.g. email or LDAP servers). Based on this assumption, follow Mozilla's plan to fully remove all SSL/TLS trust flags from most Symantec Roots. The exception are the three GeoTrust Roots, that have been used to issue the subCAs that require special whitelisting in browsers. Because I don't expect such whitelisting to get implemented broadly in non-browser software on Fedora Linux, use the following approach: Continue to fully trust these three GeoTrust Roots for SSL/TLS, for as long as Mozilla continues to keep the subCA whitelisting active. My understanding is, by continuing to trust these three GeoTrust Roots, all the subCAs that get whitelisting in browsers will be trusted by the non-browser software in Fedora Linux, too. A side effect is that the remaining certificates issued by those Roots, which the browsers intend to distrust by the whitelist implementation, will continue to be trusted in other SSL/TLS client software on Fedora Linux, too, which is derivating from Mozilla's intentions. However, given the inability to implement the whitelisting in all SSL/TLS client software on Fedora Linux, this approach seems to be the closest possible implementation, which is realistic to get done, and which also assures full compatibility with the public web. Does this sound like a reasonable stragegy? > I'm still having trouble understanding your question. > > There are two organizations operating externally-operated sub-CAs (e.g. > fully independent infrastructure, independently audited). That's Apple > and Google. Ryan, thanks again for your very detailed explanations. > Separate from this, DigiCert was selected as the Managed Partner > Infrastructure for Symantec. Setting aside the acquisition of Symantec's > PKI business, DigiCert is running sub-CAs underneath Symantec roots, to > issue certificates for customers to enable them to make a smooth and > orderly transition to other CAs - including DigiCert's own roots. Does this mean, there are additional organizations (besides Apple, Google and DigiCert) that have been assigned subCAs, that are operated by DigiCert, which were previously depending on the Symantec Roots, and which are now being migrated by DigiCert to DigiCert Roots? Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
Hello Ryan, thanks a lot for your very helpfull response! A couple more comments below: On 12.02.2018 19:13, Ryan Sleevi wrote: > A separate question which would be good to clarified: What about > environments, which want to distrust all old Symantec roots in October > 2018, but cannot add whitelisting to their cert validation code, and > choose to explicitly trust each of the subCAs. Such an environment > should be able to find a chain to one of the explicitly trusted subCAs, > right? > > You're asking about non-browser environments that cannot > implemented > https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F > ? I thought we'd ruled that out of scope rather comprehensively. Do you mean out of scope for this discussion on this list? I understand. I wonder if we should have a separate mailing list, where secondary consumers of the Mozilla CA list could exchange thoughts on how to implement the changes intended by Mozilla as closely as possible. > > We've already seen this born out > > with respect to DigiCert and their Managed PKI intermediates, and wanted > > to avoid disruption to both Apple and Google that would otherwise > > destablize the ecosystem. > > What is the relationship between the distrust of Symantec CAs and > intermediates managed by DigiCert? Did DigiCert already run managed > intermediates, before the Symantec-to-DigiCert migration efforts begun, > that still depend on Symantec CAs to be trusted? > > I'm not sure I understand this question? I was trying to understand the origin of the additional subCAs, which need to be covered using transitional intermediates. Who created those managed CAs initially, and why are they related to the Symantec to DigiCert transition? If they were originall issued by Symantec Root CAs, why weren't they included in the initial list of subCAs that need to be excluded? This is just out of curiosity. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 09.02.2018 22:20, Ryan Sleevi wrote: > As a small clarification - while Chrome has included the certificates, > as noted in the readme, the whitelist is based on SPKI. This was > intentional, to avoid situations of interoperability issues. Hi Ryan, IIUC, the current implementation in Firefox (for the early console warnings) is based on distinguished named (DN), not SPKI: https://hg.mozilla.org/integration/autoland/rev/d3acb68f73c4 > Whitelisting by certificate, rather than either SPKI or SPKI-Tuple, > brings with it significant compatibility risks to the ecosystem in terms > of being able to respond to issues. Can these risks be avoided, too, by using the DN matching strategy that the Firefox code uses? If not, it would be helpful to list these risks, and why they can only be addressed by using SPKI matching. Is your worry that alternative subCAs (already existing, or potentially being introduced in the future) could be used in server configurations, and that path building code might fail to match unexpected subCAs against the whitelist? I hope we shouldn't have to worry about alternative, already existing subCAs. There shouldn't be alternative subCAs, because it would have been required to request their whitelisting already, right? Also, I hope we shouldn't have to worry about alternative, future subCAs. It's not allowed to use the old Symantec CA infrastructure to issue alternative subCAs that might require whitelisting, right? Maybe the compatibility risks aren't about alternative subCAs? A separate question which would be good to clarified: What about environments, which want to distrust all old Symantec roots in October 2018, but cannot add whitelisting to their cert validation code, and choose to explicitly trust each of the subCAs. Such an environment should be able to find a chain to one of the explicitly trusted subCAs, right? > We've already seen this born out > with respect to DigiCert and their Managed PKI intermediates, and wanted > to avoid disruption to both Apple and Google that would otherwise > destablize the ecosystem. What is the relationship between the distrust of Symantec CAs and intermediates managed by DigiCert? Did DigiCert already run managed intermediates, before the Symantec-to-DigiCert migration efforts begun, that still depend on Symantec CAs to be trusted? What is the potential disruption, and how are you avoiding it? Are you avoiding it by including the two DigiCert Transition RSA/ECC Root certificates in the whitelist? Why is it necessary to refer to them by SPKI, e.g. do you expect there might be future, alternative intermediates for transition roots those? Also, I noticed that Gerv's post from 2017-10-17 had mentioned 7 Apple subCAs, https://crt.sh/?id=19602712 https://crt.sh/?id=19602724 https://crt.sh/?id=21760447 https://crt.sh/?id=5250464 https://crt.sh/?id=12716200 https://crt.sh/?id=19602706 https://crt.sh/?id=19602741 but the chromium "excluded" subdirectory contains only 6 Apple subCAs. Based on your message, I just looked at them, but I see that all of them have different SPKI. Do you know why the Chromium excluded directory only lists 6 Apple subCAs? > For example, if you note, there are two Google certificates, but they > share the same SPKI and Subject Name - which is why the Chromium > whitelist only has one certificate listed, as it extracts the SPKI from > that resource as part of the whitelist. Are you referring to these two subCAs? https://crt.sh/?id=23635000 https://crt.sh/?id=142951186 It seems the first one has already expired, and it might no longer be necessary to worry about it? Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote: > The subCAs that we know of that fall into this category belong to Google > and Apple. If there are any other subCAs that fall into this category, > please let us know immediately. Google has one such subCA; Apple has seven. Besides the informal list of 9 subCAs (8 unexpired) that Gerv has posted on 2017-10-17, has Mozilla learned about any additional subCAs that will require a similar treatment? I assume that the end of the primary development phase for Firefox 60, which is early March 2018, will be the deadline to add whitelisting for any such subCAs. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 16.10.2017 20:26, Eric Mill via dev-security-policy wrote: > Adding code to Firefox to support the distrust of specified subCAs seems > like it would be a good long-term investment for Mozilla, as it would give > Mozilla a lot more flexibility during future distrust events. I think this isn't about distrust of specified subCAs, but rather about keeping subCAs actively trusted, despite their issueing roots being no longer trusted. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 16.10.2017 19:33, Gervase Markham via dev-security-policy wrote: > As per previous discussions and > https://wiki.mozilla.org/CA:Symantec_Issues, a consensus proposal[0] was > reached among multiple browser makers for a graduated distrust of > Symantec roots. > > Here is Mozilla’s planned timeline for the graduated distrust of > Symantec roots (subject to change): > > * January 2018 (Firefox 58): Notices in the Developer Console will warn > about Symantec certificates issued before 2016-06-01, to encourage site > owners to migrate their TLS certs. > > * May 2018 (Firefox 60): Websites will show an untrusted connection > error if they have a TLS cert issued before 2016-06-01 that chains up to > a Symantec root. My understanding is, this will be done without making any changes to the Mozilla CA list. Firefox will implement these initial phases by changing its certificate validation code. It seems likely that many other consumers of the Mozilla CA list, which use their own implementation for certificate validation, will likely not implement these initial phases. I'm probably stating the obvious. I'd like to thank the developers who can implement this initial distrust phase in their software, as it will clear the way for the later phase of distrust, benefitting other TLS client software which cannot easily implement the initial phases. > * October 2018 (Firefox 63): Removal/distrust of Symantec roots, with > caveats described below. This is the milestone that will affect also the secondary consumers of the Mozilla CA list. I assume the updated CA list with the removed Symantec roots will be published as part of NSS 3.39 around mid October. > However, there are some subCAs of the Symantec roots that are > independently operated by companies ... [snip] ...> There are two ways that > we can provide a smoother transition for these > subCAs. I haven't seen a follow up message with a decision on this detail. I assume it's still open for discussion. > Option 1) > Temporarily treat these subCAs as directly-included trust-anchors. > ... [snip] > > Option 2) > Add code to Firefox to disable the root such that only certain subCAs > will continue to function. So, the final dis-trust of Symantec roots may > actually involve letting one or two of the root certs remain in > Mozilla’s trust store, but having special code to distrust all but > specified subCAs. ... [snip] I assume that these subCAs are used on the public web. IIUC, after secondary consumers of the Mozilla CA list update to the newer version, they will also require a solution that allows them to continue to trust these subCAs. Option 2 solves the issue for Firefox, but it isn't a practical solution for secondary consumers of the Mozilla CA list. There are too many implementations of certificate validation, and I think it's unrealistic that each implementation can implement Option 2. Without implementing option 2, but to keep compatibility with the public web, those secondary consumers would have to modify the Mozilla CA list. There's risk they might decide to continue to trust the Symantec CAs, as that would be the easiest and most compatible approach. I think we should avoid that secondary consumers might consider this solution, as it would be counterproductive to this initiative. I understand that secondary consumers of the Mozilla CA list aren't the primary focus of Mozilla and of this policy list, but in the interest of applying the Symantec distrust initiative to the majority of the open source software ecosystem, it might be prererable to implement Option 1 in the Mozilla CA list. Gerv mentioned the following concerns on Option 1: > Mozilla prefers *not* to take this approach, because even if clearly > explained up front that it is a temporary solution with deadlines, it > would be very easy for people to start treating such a subCA as a > regular trust anchor, and thereby have that subCA become a de facto > included CA. If consumers of the Mozilla CA list usually followed Mozilla's removal decisions, why would they not follow Mozilla's removal of these CAs at a later time? Why would this be more risky than Option 2? Couldn't we similarly argue, if a secondary consumer of the Mozilla CA list decided to implement whitelisting of these subCAs in their certificate validation code, isn't there similar risk that they wouldn't remove such whitelisting from their code? I'd even argue that a code implementation has a higher risk of surviving for a longer amount of time, because changing code is more difficult than changing configuration files that contain a list of trusted CAs. > Additionally, it could become very complicated to remove > such subCAs in the future, especially if they have not performed the > recommended transitions. This message was sent in October 2017. By the time we reach October 2018, the owners of the subCAs will have known about the need to transition away from the classic Symantec PKI for one year. In the cas
Re: Statement on DigiCert’s Proposed Purchase of Symantec
On 01.11.2017 00:58, Jeremy Rowley via dev-security-policy wrote: > A couple of points of clarification (as it seems to have stirred some > questions) > 1. Migration to the DigiCert issuing and validation process only applies to > certs intended for browser use, meaning the infrastructure may issue code > signing, email, etc certs post Dec 1. These certs will be validated and > issued from existing Symantec infrastructure using Symantec validation > processes, at least until we finish migration to DigiCert. > 2. When I refer to "infrastructure" I mean Symantec's validation and issuing > systems related to TLS certificates. We may reuse the front end systems and > hardware used to provide these systems post day 1. Note that we definitely > plan to migrate customers to a consolidated experience, but I want to be > clear and transparent about what is migrating when. Dec 1 is only the TLS > backend. Jeremy, you said the classic Symantec infrastructure may continue to be used for email certificates. Because Mozilla maintains trust flags for email security, I conclude that some of the Symantec Root CAs cannot be removed from the CA list in October 2018 for Firefox 63, but rather they will have their web site trust bit removed, only. Is this correct? If yes, what is the subset of Root CAs that are used for email and must continue to be included as trusted for email? Is that subset equivalent to the set of CAs that currently have the email trust bit enabled? Is there a schedule for the removal of Symantec's email trust bits, or do you assume that the relevant set of Symantec Root CAs will need to be trusted for email until they expire? (Because code signing trust is no longer part of the Mozilla CA store, the continued issueing of code signing certs using Symantec infrastructure seems irrelevant for the Mozilla trust store.) Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Mozilla’s Plan for Symantec Roots
On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote: > > Here is Mozilla’s planned timeline for the graduated distrust of > Symantec roots (subject to change): > > * January 2018 (Firefox 58): Notices in the Developer Console will warn > about Symantec certificates issued before 2016-06-01, to encourage site > owners to migrate their TLS certs. > > * May 2018 (Firefox 60): Websites will show an untrusted connection > error if they have a TLS cert issued before 2016-06-01 that chains up to > a Symantec root. > > * October 2018 (Firefox 63): Removal/distrust of Symantec roots, with > caveats described below. > > Mozilla’s release calendar is here: > https://wiki.mozilla.org/RapidRelease/Calendar Will these changes be implemented in the ESR 59.x releases, which will be released in parallel to the above releases? Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Machine- and human-readable format for root store information?
On Mon, 2017-07-03 at 20:47 -0400, Ryan Sleevi wrote: > On Mon, Jul 3, 2017 at 11:53 AM, Kai Engert wrote: > > > > > I suspect, means anyone could plug > > > > in a modern CI > > > > CI meaning Continuous Integration ? > > > > Yes. Gerv's proposal rests on the idea of having a file committed that > explains it in human-readable and machine-readable (simultaneously) form, > and then have a continuous integration build translate that into something > consumable by NSS, and then commit that generated file back into the tree > (as I understand it). For example, the resulting certdata.txt or certdata.c Ok. Should we go that path, then I'd prefer if the new file format lived in its own repository, and that the conversion would be done as a manual step, and the conversion results (certdata.txt for NSS, something else for Firefox EV data etc.) get checked in to the NSS and Firefox repositories, together with version information about the source. This would enable us to compare the converted results and review them for correctness. > Right. And JSON can't have comments. So we'd lose substantially in > expressiveness. I agree with Rob's comment that comments could be added as attributes, if necessary. But ideally, everything that's necessary as a comment could just be added a real attributes. The tool to add new entries could produce the various human readable values that humans want to see, like the extracted subject/issuer names, fingerprints. It would be good if the tool offered a consistency check, to verify that all derived attributes match the embedded certificates. (Or simpler, just regenerate them.) > "Artifact" = generated file run as part of a build process, and then > checked back in. Thanks for the explanation. > > > Thought experiment: Why not have certdata.txt generate a CI artifact that > > > interoperates for other consumers to use? > > > > Are you suggesting that we should convert certdata.txt into a file format > > that > > others would prefer to consume? > > > > Yes, that's another option. > > > > But it wouldn't solve the idea to also store the Mozilla EV attributes in > > the > > common place. Firefox developers would have to start converting information > > found inside NSS to Firefox application code. > > > > I'm not sure I fully understand your response. My response was based on my interpretation of Gerv's suggestion, which I understood as follows: - certdata.txt remains the master, keeps maintained and published with NSS - we define a new file format that's accepted as the standard for several root stores - we convert certdata.txt to that interchange format - we publish the conversion result (the Artifact) My comment meant, if certdata.txt is the master, and if certdata.txt is supposed to be the master source for the complete set of CA trust/distrust information, then it would also be the master place to store any EV attributes. As a consequence, adding such EV attributes to the Firefox code, if required, would require an additional conversion process, from certdata.txt, to the subsets that the Firefox code needs to embed. > The suggestion was that if > there's some 'other format' that leads interoperability to downstream > consumers, it 'could' be a path to take certdata.txt and have a tool that > can generate that 'other format' from certdata.txt. Understood. I was commenting on the consequence it would have for EV and Firefox embedded code. > The purpose of this thought experiment was to find what, if any, > limitations exist in certdata.txt. You've highlighted a very apt and > meaningful one, in theory - which is that EV data is a Mozilla Firefox (and > exclusively Firefox) concept, while trust records are an aspect of the root > store, hence, the dual expression between Mozilla Firefox source and NSS > source. If we wanted to make "EV" a portion of NSS (which makes no sense > for, say, Thunderbird), we could certainly express that - but it means > carrying around unneeded and unused attributes for other NSS consumers. Correct. If we defined certdata.txt as the master source for all data, we'd have to carry all attributes that Firefox needs. I don't see a problem with that, however, it would require full agreement from the Firefox developers, that certdata.txt is indeed the master location, and that the Firefox code must never fork this information, but only ever pick up converted snapshots from certdata.txt. Not sure if this could be enforced. > I don't disagree we can - on a technical level. But I don't agree that the > ontology of invented partial distrust holds, nor is it terribly useful to > try to ex
Re: Machine- and human-readable format for root store information?
On Wed, 2017-06-28 at 15:08 -0700, Ryan Sleevi via dev-security-policy wrote: > On Wednesday, June 28, 2017 at 5:29:19 PM UTC-4, Gervase Markham wrote: > > Well, the fact that we now use Git, NSS and the root store don't use Git, it uses HG/Mercurial. > > I suspect, means anyone could plug > > in a modern CI CI meaning Continuous Integration ? > > tool that did "Oh, you changed file X. Let me regenerate > > file Y and check it in alongside". Without really needing anyone's > > permission beyond checkin access. I'd prefer a bit more control. Any conversion script, which translates from a new high level file format, to a specific technical file format used by our software, could have bugs. If everything is automated, there's more risk that changes might not get reviewed, and bugs aren't identified. > I don't believe the state of NSS infrastructure is well-placed to support that > claim. I'd be curious for Kai's/Red Hat's feedback. I'm not sure I correctly understand this sentence, but if you're asking if we have such conversion magic, we don't. There's the technicaly possibility of having commit hooks. But I'm not sure I like that approach. > > Well, I don't do the actual maintenance of certdata.txt, but I assume > > (perhaps without evidence) that telling whoever does that "hey, you now > > need to use this tool to edit the canonical information store, instead > > of the text editor you have been using" might not go down well. It > > wouldn't if it were me. > > It already (effectively) requires a tool to make sure it's done right, AIUI :) > > But I think you're still conflating "text" vs "human readable", and I'm not > sure that they represent equivalents. That is, "human readable" introduces a > subjective element that can easily lead to ratholes about whether or not > something is "readable enough", or coming up with sufficient ontologies so > that it can "logically map" - just look at XML for the case study in this. > > You can have a JSON file, but that doesn't mean it's human-readable in the > least. > > That's why I'm pushing very hard on that. I wouldn't call our existing certdata.txt format easily human readable either. It's only human readable because our tool, which produces new entries, also adds human readable comments. It would be very difficult to notice if the text differes from the binary presentation (unless you write and execute a verification script that ensures everything matches). We currently achieve the matching (hopefully) by carefully reviewing changes. I would discourage a few things when introducing a JSON file format, like, avoid unnecessary changes in line wrapping or reordering, to make it easier to compare different revisions. > > No, because NSS consumers could choose to continue consuming the > > (autogenerated by the CI tool) certdata.txt. > > The CI tools don't check in artifacts. What does artifact mean in this context? > You're proposing giving some piece of infrastructure the access to generate > and check in files? I believe Mozilla may do that, but NSS does not, and the > infrastructure is separately maintained. > > > You want me to rank my goals in order of preference? :-) > > Moreso be more explicit in the goals. It's trying to figure out how 'much' > interoperability is being targeted here :) > > > If Apple said "we are happy to use the MS format", I guess the next > > thing I would do is find Kai or whoever maintains certdata.txt and say > > "hey, it's not ideal, but what do you think, for the sake of everyone > > using the same thing?". > > Thought experiment: Why not have certdata.txt generate a CI artifact that > interoperates for other consumers to use? Are you suggesting that we should convert certdata.txt into a file format that others would prefer to consume? Yes, that's another option. But it wouldn't solve the idea to also store the Mozilla EV attributes in the common place. Firefox developers would have to start converting information found inside NSS to Firefox application code. > Which is all still a facet of the original question: Trying to determine what > your goals are / what the 'necessary' vs 'nice to have' features are :) > > > It's not a massive improvement if we are the only group using it. I > > think there is value to Mozilla even if MS and Apple don't get on board, > > because our root store gets more descriptive of reality, but that value > > alone might not be enough to convince someone like the two people who > > have expressed interest thusfar to take the time to work on the spec. I > > don't know. > > But why doesn't certdata.txt meet that already, then? It's a useful thought > experiment to find out what you see the delta as, so that we can understand > what are and are not acceptable solutions. > > > Mozilla's opinions on roots are defined by the sum total of: > > > > 1) certdata.txt > > 2) ExtendedValidation.cpp > > 3) The changes listed on > > https://wiki.mozilla.org/CA/Additional_Trust_Chang
Re: Machine- and human-readable format for root store information?
On Mon, 2017-07-03 at 15:12 +0100, Gervase Markham wrote:
>
> > I think the new format should be as complete as possible, including both
> > trust
> > and distrust information, including EV and description of rules for partial
> > distrust.
>
> I agree, as long as we can stay away from defining a format of arbitrary
> complexity.
I agree the complexity shouldn't be part of the format. It might be sufficient
to have an identifier for the type of restriction, which is described elsewhere,
plus a flexible list of {name,value} pairs for parameters.
> > Regarding the question how we create new entries for certdata.txt today, we
> > currently use the NSS tool "addbuiltin". It takes a certificate as input,
> > and
> > can create both positive trust or distrust lines in the current file format,
> > that we simply appended to the certdata.txt file.
>
> Ah, OK. So you would not be against the idea of using a tool to maintain
> the list in the future?
Do you have a particular kind of tool in mind?
I'd prefer a simple open source tool that operates on files, which can be used
from a command line, with a free license, e.g. MPL2.
> > Regarding which file format should be used for the new master trust list.
> > Unless
> > we want to change the way how NSS works, it will probably be helpful to
> > continue
> > to use the certdata.txt file format, even if it's just used as an
> > intermediate
> > in a double conversion.
>
> I certainly think we should continue to maintain the store in that
> format. The question is whether that format is the canonical format, or
> a derivative format. My feeling was that if we want to be able to add
> these new forms of restriction, EV status and so on, we should define a
> new format. Ryan seems to think we may be able to do this within the
> existing certdata.txt format.
I don't have a strong preference.
I agree that it should be possible to extend the existing certdata.txt file
format. For meta level items that NSS cannot consume yet, we could define new
identifiers that NSS ignores (or might potentially process at a later time).
However, the certdata.txt file format was built specifically around the needs of
NSS, and we currently have the flexibility to change it in any way we want to.
Also it's based on the idea that the file elements will rather directly
converted into PKCS#11 objects. Other root stores might not use PKCS#11 to store
their list of root CAs at all.
If the intention is to define a file format that is shared with other groups,
who would be the owner of the file format? What if another group needs to
introduce additional fields into the file format, that aren't of interest to
Mozilla or NSS?
Having a more abstract file format could give anyone more flexibility to add
more information, that don't need to be coordinated with others prior to adding
them, and allows consumers to ignore the fields they aren't interested in.
For example, some root store maintainer might invent the golden circle of CA
vouching, which everyone else considers questionable. It might require to store
a flexible list of vouchers for each CA. With JSON it would be trivial to add
another arbitrary length list for that.
So, if the intention is to have a shared file format that everyone can accept,
today and in the future, a more flexible file format seems more appropriate to
me.
> > Instead of requiring everything to be a single file, maybe it could even
> > work to
> > use an archive file (e.g. zip), that contains all information in easily
> > consumable pieces, which would make it unnecessary to serialize and
> > deserialize
> > the certificates while working with the list, and allows maintainers to use
> > tools that work with the certificates directly.
>
> I think that runs the greater risk of people creating systems which just
> trust every certificate in the bundle...
There could be ways to avoid that, for example by using subdirectories, named
like:
- trusted-for-ssl-tls-only
- partially-trusted-for-ssl-tls-only
- trusted-for-email-security-only
- partially-trusted-for-email-security-only
- trusted-for-multiple-uses
- partially-trusted-for-multiple-uses
- distrusted
This is just a thought. If there's too much doubt, I don't mind to stay with the
concept of having a single file that contains serializations of all attributes.
> > With this approach, we could also declare that the master location for this
> > trust list is somewhere outside of NSS (in a separate repository). If we did
> > that, the primary location could simply be its own HG/GIT repository, with
> > all
> > the individual files. Releases of Mozilla trust list could be an archive
> > file
> > that gets published with a checksum file/signature.
>
> We could do this with any approach. Are you interested in the idea of
> making the trust list an independently-maintained item, which is just
> pulled into NSS each time an NSS release is done?
Yes, I had previously suggested this here:
https://bugzilla.mozill
Re: Machine- and human-readable format for root store information?
On Fri, 2017-06-30 at 18:46 +, David Adrian wrote: > Censys validates certificates against multiple root stores. At the end of > the day, what we want is a reliable and repeatable way to get an up-to-date > version of a root store in PEM format. Can you please clarify if you're talking about the file format that starts with a header line (a) "-BEGIN CERTIFICATE-" or about the file format that starts with (b) "-BEGIN TRUSTED CERTIFICATE-" ? The Mozilla trust list cannot be correctly represented in file format (a), because it can only carry a list of certificates, but not trust information. It cannot carry information like "this CA should be trusted only for email security, but not for SSL/TLS servers". It cannot carry information like "this intermediate CA (or this end entity certificate) must NOT be trusted, although it has been issued by a trusted CA". Maybe Mozilla shouldn't publish a single, simple PEM file, in format (a) because it could give consumers the false impression that it's equivalent to the Mozilla trust. Potentially Mozilla could publish multiple different PEM files in format (a), one for the list of CAs that are trusted for email security, and another list of CAs that are trusted for web security. An additional PEM file could be published in format (a), which lists all the certificates that are explicitly blacklisted/distrusted in certdata.txt. Multiple files would be necessary, beause the standard PEM file format (a) cannot contain trust or distrust flags, therefore the name of the list would have to indicate the meaning of each list. However, file format (b) is able to represent trust and distrust information. I think it might have been been invented by the OpenSSL project. You can read more about it on the manual page that can be accessed with "man x509", see the -trustout and -addtrust and -addreject parameters. Today's certdata.txt can mostly be represented in file format (b). However, even today's certdata.txt is incomplete. It doesn't contain the list of distrusted certificates that Mozilla publishes with the OneCRL project, which means only the Mozilla applications can benefit from that information, but not other applications based on NSS. If Mozilla works on developing a consolidated CA trust and distrust list, ideally that list should contain the distrust information from OneCRL, too. But even with that, it will still exclude the dynamic distrust rules that this newsgroup has decided, which partially restrict some of the trusted CAs, such as the whitelist-only approval for some CNNIC roots, the restriction to certain domains for some ANSSI and TUBITAK roots, or the date base limitation for some StartCom and WoSign roots. If Mozilla is asked to publish a single file containing all trust in a PEM file format, which cannot express these partial distrust rules, should Mozilla include or exclude the partially trusted CAs? Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Machine- and human-readable format for root store information?
Hello Gerv, given that today we don't have a single place where all of Mozilla's certificate trust decisions can be found, introducing that would be a helpful. I think the new format should be as complete as possible, including both trust and distrust information, including EV and description of rules for partial distrust. As of today, certdata.txt contains: - whitelisted root CAs (trusted for one or more purposes) - distrusted/blacklisted certificates (which can be either CAs, intermediate CAs or end entity certificates), based on varying identification criteria (sometimes we distrust all matches based on issuer/serial, sometimes we are more specific and only distrust if the certificate also matches exactly a specific hash) But it doesn't list the additional decisions that Mozilla has implemented in code: - additional domain name constraints - additional validity constraints for issued certificates - additional required whitelist matching In the past, some consumers of the Mozilla CA list didn't even implement the few distrust decision that are already listed in certdata.txt, and had focused only on the positive trust. I don't know if this was because consumers didn't worry, or because they didn't even notice, but might have also been done because of technical limitations. It would be good if the new format made it very clear that there are distrust entries, and that trust for some CAs is only partial. The latter could make it easier for list consumers to identify the partially restricted CA. E.g. some might decide to rather not trust a restricted CA at all, if the consumer is technically unable to implement the restricting checks. We could define identifiers for each class of trust restrictions (CTR), e.g.: - permitted name constraint - excluded name constraints - restricted to serial/name whitelist - not valid for serial/name blacklist - restrict validity period of root CA - restrict allowed validity of issued EE or intermediates - require successful revocation checking - require successful Certificate Transparency lookup - ... This list could be expanded in the future, so a list consumer that has implemented all of the older CTRs could decide to not trust new CAs that have unknown CTRs defined. There were several comments in this thread about the file format and questions what we use today. Let me mention the concept to implement CTRs as "stapled certificate extensions", e.g. reuse the standard certificate format definitions, create the binary extension that implements a specific CTR, and embed it into the trust list file. This approach can allow software to load these extensions somehow in memory to the certificates, with the effect that standard certificate validation code can see and use them, without requiring additional logic. We already use this stapling approach in Firefox and NSS for name constraints. Because this requires a very specific ASN.1 encoding, we manually used tools to create such an extension, and then copy the binary data. That might be a reasonable approach even for the near future, until it can be automated completely. Currently the encoding of these name constraints was copied into source code, but this could also live inside a future trust file, if we define the file format to represent such binary extensions, and if we enhance the code to load such extensions dynamically from the list. Regarding the question how we create new entries for certdata.txt today, we currently use the NSS tool "addbuiltin". It takes a certificate as input, and can create both positive trust or distrust lines in the current file format, that we simply appended to the certdata.txt file. Regarding which file format should be used for the new master trust list. Unless we want to change the way how NSS works, it will probably be helpful to continue to use the certdata.txt file format, even if it's just used as an intermediate in a double conversion. Instead of requiring everything to be a single file, maybe it could even work to use an archive file (e.g. zip), that contains all information in easily consumable pieces, which would make it unnecessary to serialize and deserialize the certificates while working with the list, and allows maintainers to use tools that work with the certificates directly. E.g. there could be a single JSON file inside that archive, with a well-defined name, that lists all entries. For each entry, it says if it's a trust, a distrust, or a restricted-trust entry, and for which purposes (web, email, ...). It could list the filename of the certificate file this JSON entry refers to (plus the certifiate's SHA256), or if it's just a distrust entry without a full certificate, no separate file is required. It would list the CTR classes that are required. For restrictions, an archive file format would make it easier to distribute the full details, even if they are large, like whitelists. Stapled binary extensions, like prepared domain name constraints extension
Question: Transfering the private key of an EV-approved CA
Are there existing rules, in the CABForum BRs, or in the Mozilla CA policy, that define under which circumstances the private key of an actively used EV approved root CA may be transferred to a different company, that hasn't been audited for EV compliance? As soon as the private key has been given to another company, the receiving company technically has the ability to issue EV certificates (even if they never intend to do so), right? I would have naively assumed that a company, that owns an EV approved CA, is expected to strictly protect their EV issuing power, and must never share it with another company that hasn't been approved for issuing EV certificates. If this makes sense, and if there aren't any rules yet, I suggest to add them to the appropriate policy documents. Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Nation State MITM CA's ?
On Mon, 2016-01-11 at 19:45 +0100, Jakob Bohm wrote: > He is obviously referring to the fact that refusing to encrypt using > the MiTM certificate would force users to access their e-mails (etc.) > using unencrypted connections (plain HTTP, plain IMAP, plain POP3 > etc.), thus exposing themselves to wiretapping by parties other than > the government in question. Thanks for the hint! Nowadays many Internet services no longer offer the choice to connect without TLS. Many popular sites accessed using http immediately redirect to https. So, blacklisting the CA would have a mixed effect. Forced plaintext for those services that still allow plaintext, and blocked connectivity for those that require TLS (affecting all software that doesn't allow to override blacklisted certificates, such as Firefox). Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Re: Nation State MITM CA's ?
On Sat, 2016-01-09 at 14:11 +, Peter Gutmann wrote: > That would have some pretty bad consequences. With the MITM CA cert enabled, > Borat [0] can read every Kazakh user's email, but no-one else can. With the > MITM CA blacklisted, Borat can still read every Kazakh user's email, but so > can everyone else on the planet. So the choice is between privacy against > everyone but one party, and privacy against no-one. I don't understand why blacklisting a MITM CA would enable everyone to read the data that passes through the MITM. Could you please explain? (It sounds like there is either a misunderstanding on your or on my side.) Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Nation State MITM CA's ?
I think several separate points need to be discussed. (a) Inclusion as trustworthy for the global Internet You might have seen this article, which, to my surprise, can no longer be found on the site itself, so here is an archived copy: https://web.archive.org/web/20151202203337/http://telecom.kz/en/news/view/18729 They don't say it explicitly, but it sounds like they intend to inspect all encrypted Internet traffic that connects to the area outside of Kazakhstan. Unless they plausibly deny that intention, I hope it's obvious that Mozilla shouldn't trust them for issuing certificates for domains outside of Kazakhstan. The suggestions that others have already made in this discussion, which is to postpone their request for inclusion until they provide more details, seems like a good reaction at this point. (b) Including a CA as trustworthy but constrained to the Kazakhstan domain I don't know if they have requested that yet, or if that might still be an option, after (a) gets rejected. Separate discussion. (c) Blacklisting their root certificates I believe this is what Paul had suggested to do in this initial message. Independently of the request for inclusion, this group could discuss if the Kazakhstan's CAs should be blacklisted, by adding them to the Mozilla CA list using negative distrust flags, which would effectively make it impossible for them to be used in all software that is able to handle such entries, and that bases its trust on the Mozilla CA list. As a result, if a users connection is routed through a MITM system that creates false certificates for the purpose of inspection, Firefox users would no longer be able to connect to any sites using https/TLS. If Kazakhstan intended to route the Internet traffic of all users through a MITM inspection device, as a result, users of Kazakhstan would no longer be able to use Firefox to visit web sites outside of Kazakhstan, nor use other software that also uses the Mozilla CA list. I think this is a difficult decision. I assume Paul's idea was that doing natiowide MITM is a bad idea and that it should be made impossible, by blocking any CAs used for such a purpose. The question here is, would it help? If Internet users in Kazakhstan couldn't connect to the Internet without complying to laws that require mandatory MITM inspection, then users would have to make the choice whether to avoid using the Internet at all, or to comply. Those users who decided to comply would have to use a browser or a system that doesn't block Kazakhstan's CAs. I believe they would still be able to find software systems that allowed them to do that. If we decided not to blacklist, but rather, to not include those CAs at all, the users of default software would still get our usual security warnings, and have the ability to discover that their connections aren't secure. Those who decided to comply could modify their software by adding the CA as trusted themselves (like the cited website above suggests them to do). Given the text of the above web site, it seems that users are expected to modify their systems anyway, by installing that CA as trustworthy. If we blacklisted it, they would simply have to go one step further, by finding a way to undo the blacklisting. As this currently isn't easily doable in e.g. Firefox, blacklisting might force users to download specially modified software that undoes the blacklisting and changes it to active trust, instead of being able to use default software. So, as bad as this situation is, and as much as I dislike the idea of a nationwide MITM CA, which would effectively take away most (if not all) Internet privacy from citizens, blacklisting the Kazakhstan's CAs could be worse than simply not including it at all. If we wanted to do better than silent bystanders, maybe it should be considered to introduce a new kind of user interface feedback into Firefox. For example, we could maintain a list of major CAs that are known to violate best practices. Whenever a certificate from such a CA is enountered, regardless if the user has added the CA as trusted to their configuration, we could have a persistent big notification bar on the top of the browser content, which could say something like "Your connection is believed to be under active surveillance", and disable the usual security indicators. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
A pragmatic solution for the S/MIME trust bit
The earlier comments on this list have shown that S/MIME is in active use (e.g. in communication between different academic instutions), and that a decision to remove the S/MIME trust bit from the Mozilla CA list would mean a functional regression for those users. In my opinion, the discussion about the quality of the S/MIME code in NSS or in Thunderbird should be completely separate from the discussion about the trust bit, because there is non-Mozilla open source software that is able to make use that trust bit, too (e.g. OpenSSL also has an implementation for S/MIME). I don't know if we'll find sufficient resources to start a separate CA program for the S/MIME trust bit. It seems that the lobby for encrypted email is much weaker than the lobby for web site security, maybe because it isn't used to sell products or content to consumers. Nevertheless, I believe that supporting privacy in communication between individuals is an important value. The publicly agreed list of CA certificates is a very helpful resource that makes it easier for any new project that wants to buildon upson PKI for that purpose. Therefore I'd like to suggest that we attempt to find a pragmatic solution how the S/MIME trust bit could be kept alive with a minimal amount of resources on top of the great work for the SSL/TLS trust bit. Here is an attempt of a starting point for a programtic solution: (a) Only grant the S/MIME trust bit if a CA has been granted the SSL/TLS trust bit already. If Mozilla decides to remove a SSL/TLS trust bit, the S/MIME trust bit (and potentiall all other trust bits) for that CA will get removed, too. This eliminates the need to work on any CAs that are for the S/MIME purpose, only. (b) Only CAs that explicitly state they'd like to be granted the S/MIME trust bit might potentially get it. This avoids the likelyhood that any CA's root gets accidentally used for the non -SSL/TLS purpose. (c) The community on this list works together to define what additional requirements a CA needs to comply with, in order to obtain the S/MIME trust bit. The definitions of these additional requirements should be kept completely separate from the SSL/TLS trust bit documents, to allow participants of the S/MIME trust bit community to work independently. (d) Going forward, require that no intermediate certificate will ever be used to issue certificates for SSL/TLS servers and S/MIME. This is simply an idea to address an argument that has been made in the discussion, that it might be problematic to mix issueing environments. However, for practical purposes, I'd suggest it should still be allowed to issue certificates that can be used for both S/MIME and SSL/TLS client authentication. (e) Discuss if a misissuance of S/MIME certificates can have the consequence of losing the SSL/TLS trust bit, too. With an approach like this, the work required to evaluate the request of a CA for the S/MIME trust bit would be limited to: (1) A one time effort to define (c), and ocassionally the refinement of (c), mainly driven by the community, and someone who will make the final call. (2) Someone who evaluates the inclusion requests and compliance with (c). Everyone, would a policy like this make sense? Kathleen, do you think a policy like this would still require a half time position for the "someone" mentioned in (1) and (2), or could it be done with a smaller amount of time? Could the CAs be required to do most of the work to demonstrate their compliance, and only require the dedicated person to verify the documentation for plausability? Thanks, Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remove Roots used for only Email and CodeSigning?
On Fri, 2015-09-04 at 11:25 +0200, Kurt Roeckx wrote: > On 2015-09-03 20:22, Kathleen Wilson wrote: > > 2) Remove included root certs that only have the Code Signing trust bit > > enabled. To our knowledge, no one is using such root certs via the NSS > > root store. > > I'm wondering how you currently support things like java applets. As > far as I understand for some activity of them you need to have them > signed. Is this handled by the java plugin itself? Where does it get > it's root store from? A Java runtime can include its own root store. For OpenJDK on Fedora Linux, my understanding is, we configure it to use the system's trust store, which contains the Mozilla trust bits. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remove Roots used for only Email and CodeSigning?
On Mon, 2015-09-07 at 13:58 +0100, Gervase Markham wrote: > On 04/09/15 14:09, Phillip Hallam-Baker wrote: > > Has Mozilla stopped supporting Thunderbird? > > No. Mozilla-the-project still develops and supports Thunderbird. > > I had thought this was about code signing only, but reading back, I was > wrong. I would certainly oppose deprecating the email bit in our root > store. I also think it's a bad idea to deprecate the code-signing bit; > while we are the primary consumers of our database, and others use it at > their own risk, at the same time providing a transparently-managed root > store that others can use is one way that the Mozilla project blesses > and serves the security of the Internet. +1 Besides Thunderbird, the Gnome Evolution email client implements S/MIME. On Fedora Linux it uses the S/MIME trust bitm that we make available as part of the system trust store, for verifying S/MIME signatures. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remove Roots used for only Email and CodeSigning?
On Fri, 2015-09-04 at 14:26 +0200, Hubert Kario wrote: > On Thursday 03 September 2015 11:22:26 Kathleen Wilson wrote: > > 2) Remove included root certs that only have the Code Signing trust > > bit enabled. To our knowledge, no one is using such root certs via > > the NSS root store. > > I'm not familiar with the project, but Fedora Shared System > Certificates[1] does use Mozilla Root list and it does encompass Java > trust stores so Code Signing bits at the very least _should_ be used, if > not already are used. > > 1 - https://fedoraproject.org/wiki/Features/SharedSystemCertificates It's correct that Fedora and Red Hat Linux (and potentially other Linux distributions, too) use the code signing trust information for a systemwide trust store, and applications can use it to verify signatures on code. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Remove Roots used for only Email and CodeSigning?
On Fri, 2015-09-04 at 09:53 +0100, Gervase Markham wrote: > On 03/09/15 19:22, Kathleen Wilson wrote: > > 2) Remove included root certs that only have the Code Signing trust bit > > enabled. To our knowledge, no one is using such root certs via the NSS > > root store. > > This seems like a half-way house. If no-one is using our root store as a > code-signing root store, we should stop supporting the code-signing bit > entirely, remove the bit from all roots, and remove the UI associated > with it in all apps. > > But if we still want to support the code-signing use case, we shouldn't > remove these roots. Firefox Add-Ons can be signed with code signing certificates. In past versions of Firefox, there was code that checked for a signature in the Add-On, and the user interface that asked for permission to install displayed information found in the signature (the name of the owner of the code signing certificate). I no longer see this information shown by Firefox. I understand that Firefox nowadays requires Add-Ons to be signed by Mozilla. How does that work? Does Mozilla use a code-signing certificate? I looked at an example Add-On, and the signature references certificates with the following names: subject=/OU=Preliminary/C=US/L=Mountain View/O=Addons/ST=CA/CN=jid1-AQqSMBYb0a8ADg@jetpack issuer=/C=US/O=Mozilla Corporation/OU=Mozilla AMO Production Signing Service/CN= production-signing-ca.addons.mozilla.org/emailAddress=services -ops+addonsign...@mozilla.com subject=/C=US/O=Mozilla Corporation/OU=Mozilla AMO Production Signing Service/CN =production-signing-ca.addons.mozilla.org/emailAddress=services -ops+addonsign...@mozilla.com issuer=/C=US/O=Mozilla Corporation/OU=Mozilla AMO Production Signing Service/CN=root-ca-production-amo Doesn't that mean that Mozilla Firefox still relies on code signing certificates? Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On Tue, 2015-03-24 at 14:29 -0700, Ryan Sleevi wrote: > For example, is your intent to prevent Google from running its own > intermediate for its properties? That's the effect of this proposal. Ryan, thanks for your detailed response. Let me start by replying to the above part of your response. I'm not convinced my suggestion prevents your example of a corporation that wants an intermediate for their own purposes. Couldn't you get an intermediate that's constrained to the list of domains that Google controls? If you're worried that the intermediates are getting too big (because you have so many domains), couldn't you get multiple intermediates, each constrained to a subset of the domains that Google controls? In my suggestion this was scenario (a), and the CA wouldn't be repsonsible for mis-issuance by intermediates that are constrained to second-level domains (like google.com or google.co.uk). Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Forbid creation of non-constrained intermediates for external entities
On Tue, 2015-03-24 at 14:52 -0400, Daniel Micay wrote: > > Thoughts? > > I think it's a good policy, but like the current policies it cannot > really be enforced because there is no way to validate compliance. At least there'd be clarity about the immediate removal on discovery. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Forbid creation of non-constrained intermediates for external entities
This is a suggestion for stricter rules regarding the creation of intermediate CA certificates that are issued by root CA certificates included in the Mozilla CA list. Every CA organization should be ultimately responsible that the intermediate CA certificates they create will never be used in a MITM device. If an intermediate CA certificate controlled by the CA, or controlled by a subordinate entity of the CA, is used in a MITM device, or used to mis-issue a certificate, the discovery of an unrevoked mis-issued certificate will result in the immediate removal of the respective root CA certificate. If a CA provides an intermediate CA certificate to an external organization, then the intermediate CA certificate must contain a name constraint extension, which restricts the abilities of the intermediate. The constraint must either limit the intermediate to (a) a set of second level domains the external organization controls. or (b) to exactly one TLD The discovery of any unconstrained and unrevoked intermediate CA certificate that isn't controlled by the root CA organization results in the immediate removal of the root CA from the Mozilla CA list. If the CA issues an intermediate CA that is constrained to a TLD, then the primary CA is fully responsible for the actions of the external organization, including deliberate and accidental misuse of the intermediate. A misuse of the intermediate, or a misuse of any subordinate certificate, is the full responsibility of the primary CA. Because of the potential consequences of a misuse of an intermediate for the primary CA, it is recommeded that a CA shall be very careful when handing out an intermediate to an external organization, such as enclosing the intermediate's key in an HSM, and requiring a contract with the external organization, which would cover the monetary risk of closing down the business of the primary CA. The discovery of any misuse of where the primary CA has the full reponsiblity shall result in the immediate removal of the CA from the Mozilla list. Thoughts? Thanks, Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Consequences of mis-issuance under CNNIC
On Mon, 2015-03-23 at 17:47 -0500, Richard Barnes wrote: > It has been discovered that an intermediate CA under the CNNIC root has > mis-issued certificates for some Google domains. Full details can be found > in blog posts by Google [0] and Mozilla [1]. We would like to discuss what > further action might be necessary in order to maintain the integrity of the > Mozilla root program, and the safety of its users. The blog posts say that the intermediate was used in a MITM device. In February 2012, a CA communication was posted to this list, which contained the following statements: > Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for > MITM or “traffic management” of domain names or IPs that the certificate > holder > does not legitimately own or control, regardless of whether it is in a closed > and controlled environment or not. > ... > As a CA in Mozilla’s root program you are ultimately responsible for > certificates issued by you and any intermediate CAs that chain up to your > roots. After April 27, 2012, if it is found that a subordinate CA is being > used for MITM, we will take action to mitigate, including and up to removing > the corresponding root certificate. Based on Mozilla’s assessment, we may > also remove any of your other root certificates, and root certificates from > other organizations that cross-sign your certificates. (cited from https://groups.google.com/forum/#! topic/mozilla.dev.security.policy/6CX23NVaUvY ) When the above communication was sent in the past, I had hoped that any future incident, where an intermediate gets loaded into a MITM device, would have more serious consequences for the CA than simply being constrained to a TLD. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: China MITMing icloud.com
On Tue, 2014-10-21 at 11:49 +0100, Gervase Markham wrote: > https://en.greatfire.org/blog/2014/oct/china-collecting-apple-icloud-data-attack-coincides-launch-new-iphone > > Cert is here: > http://www.mediafire.com/download/ampbnqncc277krv/fakeicloudcert.zip > > I'd be very interested to know why (as reported) the Qihoo 360 browser > doesn't throw an error for this cert. Does it accept all self-signed > certs without complaint? Or is there something special about this one? > If so, what exactly? > > If anyone (presumably with a copy of Windows) wants to dig into that, it > would be really great. What's the real download location of that software? I installed a fresh Win7 VM for testing, and tried to find it. First I found se.360.cn, clicked on the green 7.1 with desktop-monitor button, to download the exe, but that download is very slow (11 hours estimated), and never completed for me. Neither directly, nor through Tor. Then I found a CNet hosted download, when installed, it identifies as 360 browser version 7.5.2.106 based on the Chromium project. Visiting one of my test pages that uses a self-signed certificate ( https://kuix.de:9453 ), the browser immediately allows the connection, shows the site's contents, but also shows a yellow warning bar (untrusted site). If that's the right Qihoo browser, it might allow access to any content, and user's might have ignored the warning. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
Hubert, what's your conclusion of your analysis? Thanks Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
On Mon, 2014-07-28 at 21:02 +0200, Kai Engert wrote: > On Mon, 2014-07-28 at 11:00 -0700, Brian Smith wrote: > > I suggest that, instead of including the cross-signing certificates in > > the NSS certificate database, the mozilla::pkix code should be changed > > to look up those certificates when attempting to find them through NSS > > fails. > > We are looking for a way to fix all applications that use NSS, not just > Firefox. Only Firefox uses the mozilla::pkix library. Actually, including intermediates in the Mozilla root CA list should even help applications that use other crypto toolkits (not just NSS). Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Removal of 1024 bit CA roots - interoperability
On Mon, 2014-07-28 at 11:00 -0700, Brian Smith wrote: > I suggest that, instead of including the cross-signing certificates in > the NSS certificate database, the mozilla::pkix code should be changed > to look up those certificates when attempting to find them through NSS > fails. We are looking for a way to fix all applications that use NSS, not just Firefox. Only Firefox uses the mozilla::pkix library. Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Revocation Policy
Can we try to gather more information about other CAs? Do we know if there are other CAs who charge for revocations? Are there CAs where getting a certificate revoked is difficult, because it's not discoverable in the CA's web interface and not mentioned in FAQs, etc.? Any experiences here? Regards Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Request to blacklist a pb certificate not complying to BR
I'd like to bring your attention to https://bugzilla.mozilla.org/show_bug.cgi?id=966350 because I haven't seen any public discussion related to this request yet. I'm quoting subsets from the bug (please refer to the above link for the full statement): "At the end of 2013, Symantec issued a cert to one of its customers that did not comply with several provisions of the CA/Browser Forum Baseline Requirements. We did this knowingly because if we had not, the customer would have experienced a significant loss of business. In addition, Symantec believed that this certificate posed very little or no risk to browser users." ... "The certificate is not intended to be used by a browser. We exhausted all other possible technical options before taking this step." Symtantec asked us to blacklist the certificate, and provided identifying attributes of the certificate. In the meantime, the complete certificate has been attached to the bug, too, together with a certificate that had expired by the end of 2013. It seems the certificate that has been issued recently, and which we have been asked to blacklist, was a replacement certificate for the one that had expired. The replacement certificate had the following attributes: - it contained a backdated "not before" attribute (identical with the earlier one) - issued directly by the root (not from an intermediate) - used a short 1024-bit key - didn't contain OCSP AIA (only CRL) - included policy OID.2.16.840.1.113733.1.7.54 which seems to describe that it's compliant with CABForum BR, although it isn't. (Please correct me if I made any mistakes in writing this summary.) This motivates me to a few questions: (a) Although the certificate is described as "not intended to be used by a browser", does that argument qualify as a justification to knowingly ignore the base line requirements? If the certificate is installed on a server on the public Internet, isn't it technically possible that a browser, which knows the server's address, could connect to the server using that certificate? I think the answer is probably "yes, a browser could still connect to the site", and that is probably the motivation for asking us to blacklist the non-complying certificate. (b) Can you please clarify, what is the value of the base line requirements, if a CA is willing to ignore them, because otherwise a "significant loss of business" would be the consequence? (c) Did the CABForum define any clear rules under which circumstances exceptions to the base line requirements are allowed, or acceptable? Are there any rules that a CA must follow when issueing non-complying certificates? If the answer to any of these question is "no", could the CABForum work on that? For example, should the CA have immediately announced the non-complying certificate (or at least the identifying attributes of the certificate) on the public cabforum mailing list, together with a detailed justifcation? (I'd personally think that a justifcation should include more than the statement "loss of business", but should include the technical facts that justified the exception.) Thanks and Regards Kai ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
