Re: Updating Root Inclusion Criteria
I would like to thank everyone for your constructive input on this topic. At the outset I stated a desire to ‘establish some objective criteria that can be measured and applied fairly’. While some suggestions have been made, no clear set of criteria has emerged. At the same time, we’ve heard the argument that our time would be better spent on raising the bar for all CAs in the program, regardless of their subjective value to typical users of our products. Some thought was also given to applying unique technical criteria to new CAs, such as limiting certificate lifetime to 90 days or requiring ACME support. It was pointed out, however, that this favors incumbents and doesn’t drive improvement in the overall ecosystem. The conclusion from this discussion is that we will not attempt to restrict organizations from participating in the Mozilla CA program based on a judgement of their value to our users. We will continue to require applicants to demonstrate compliance with our policies, and reserve the right to deny membership to any CA at our discretion, e.g. because they have a documented pattern of misbehavior or we believe they intend to violate our policies. Here is a proposed update to the Mozilla Root Store Policy reflecting this decision: https://github.com/mozilla/pkipolicy/compare/master...inclusion-criteria?quick_pull=1 As always, comments are welcome. I intend to begin a discussion of the next version of the policy soon and will plan to include this change in it. - Wayne ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On Fri, Jan 19, 2018 at 3:04 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 18/01/18 14:24, Ryan Sleevi wrote: > > Isn't this effectively the VISA situation? When were their first audits - > > late 2016 / early 2017? > > I'm not certain; I'll ask Kathleen. > > Visa's first BR audit was a PITRA dated 31 March 2016. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria (organizations)
On 22/01/2018 10:47, Gervase Markham wrote: On 19/01/18 13:20, Jakob Bohm wrote: My suggestions are only meant to inspire formal rules written / chosen by module leaders such as you. But the entire point of this discussion is that we are pointing out it's hard to make such rules in the way you have just made them without being arbitrary, and arbitrariness is something we want to avoid. So giving us an example arbitrary ruleset is not really moving the discussion forward much. Ok, I was replying mostly to your assessment that this would be subject to approval of each CA by /me/. For the too-big-to-ignore case, a formal no-human-judgement required criteria would be something like the issue affecting at least a certain percentage of Internet traffic of the relevant protocol (such as https+imaps+pop3s+smtps and the "STARTTLS" equivalents for TLS uses in Mozilla code, or e-mail traffic for S/MIME), not including internal traffic by the CA owner and their closest partners. For the vertical CA case, a formal criteria would be either prior inclusion in the Mozilla root program or acceptance from two other root programs in the CAB/F. Though in both cases, I think that human judgement by the relevant Mozilla people after public discussion would be a more accurate test, since both are meant to be exceptional cases, not the norm. As an actual policy decision would be involved, the category approval (as opposed to the technical approval) would need more than the usual 3 week discussion. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria (organizations)
On 19/01/18 13:20, Jakob Bohm wrote: > My suggestions are only meant to inspire formal rules written / chosen > by module leaders such as you. But the entire point of this discussion is that we are pointing out it's hard to make such rules in the way you have just made them without being arbitrary, and arbitrariness is something we want to avoid. So giving us an example arbitrary ruleset is not really moving the discussion forward much. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria (organizations)
On 19/01/2018 11:09, Gervase Markham wrote: On 19/01/18 01:05, Jakob Bohm wrote: On 18/01/2018 11:01, Gervase Markham wrote: On 17/01/18 19:49, Jakob Bohm wrote: 3. Major vertical CAs for high value business categories that issue publicly trusted certificates at better than EV level integrity. For How do you define "major"? And "high value business category"? Major would be the biggest 1 to 3 of their kind, ignoring any covering only a small fraction of the relevant web site/e-mail population even if in the top 3. Also any not doing this globally is not major. I guess my question was ambiguous. Clearly it's very easy to come up with arbitrary definitions for these things, but what's the rationale? Why 1-3? Why not 1-8? My suggestions are only meant to inspire formal rules written / chosen by module leaders such as you. Point of this is to avoid a bloated situation with 50+ financial industry specific CAs and 50+ medical profession CAs etc. This would generally be for single worldwide organizations, with an option to handle some kind of alliance schism in the industry, e.g. between those who align with EuroCard/Visa/Mastercard (EVM) and another global group that explicitly wants as little to do with the first group as possible. High value business category would be a category where web users have an extremely high need for genuineness. Banks/central payment systems would be the canonical example, with the VISA CA/SET combination as a possible historic example (noting that it looks like they don't currently qualify even if they did in the past). You've just shifted the definitional problem to the words "extremely high need for genuineness". Proving examples of what you personally mean by these terms is not sufficient to make a definition, unless the Mozilla policy becomes "whatever Jakob Bohm decides". Gerv Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria (organizations)
On 19/01/18 01:05, Jakob Bohm wrote: > On 18/01/2018 11:01, Gervase Markham wrote: >> On 17/01/18 19:49, Jakob Bohm wrote: >>> 3. Major vertical CAs for high value business categories that issue >>> publicly trusted certificates at better than EV level integrity. For >> >> How do you define "major"? And "high value business category"? > > Major would be the biggest 1 to 3 of their kind, ignoring any covering > only a small fraction of the relevant web site/e-mail population even if > in the top 3. Also any not doing this globally is not major. I guess my question was ambiguous. Clearly it's very easy to come up with arbitrary definitions for these things, but what's the rationale? Why 1-3? Why not 1-8? > High value business category would be a category where web users have an > extremely high need for genuineness. Banks/central payment systems > would be the canonical example, with the VISA CA/SET combination as a > possible historic example (noting that it looks like they don't > currently qualify even if they did in the past). You've just shifted the definitional problem to the words "extremely high need for genuineness". Proving examples of what you personally mean by these terms is not sufficient to make a definition, unless the Mozilla policy becomes "whatever Jakob Bohm decides". Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 18/01/18 14:24, Ryan Sleevi wrote: > Or, conversely, that we cannot discuss inclusion policies in isolation from > discussion root policies - we cannot simultaneously work to strengthen > inclusion without acknowledging the elephant in the room of the extant CAs. We aren't necessarily "strengthening" inclusion, in the sense of making it harder to get in - the outcome of the discussion could be a loosening. If we come up with new inclusion criteria and some existing CAs do not meet them, we would need to have a separate discussion to decide what to do, with the main options being grandfathering them in, restricting them in some way, or removing them. > Isn't this effectively the VISA situation? When were their first audits - > late 2016 / early 2017? I'm not certain; I'll ask Kathleen. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria (organizations)
On 18/01/2018 11:01, Gervase Markham wrote: On 17/01/18 19:49, Jakob Bohm wrote: 3. Major vertical CAs for high value business categories that issue publicly trusted certificates at better than EV level integrity. For How do you define "major"? And "high value business category"? Major would be the biggest 1 to 3 of their kind, ignoring any covering only a small fraction of the relevant web site/e-mail population even if in the top 3. Also any not doing this globally is not major. High value business category would be a category where web users have an extremely high need for genuineness. Banks/central payment systems would be the canonical example, with the VISA CA/SET combination as a possible historic example (noting that it looks like they don't currently qualify even if they did in the past). Another example could be if a global medical organization (WHO or ICRC or some NGO) were to issue certificates for secure communication with doctors anywhere people might live or travel, using their specific knowledge and resources to ensure that only actual doctors could get certificates. Here the high value would be the users life and physical health, not money. On the other hand, similar certificate services for e-commerce sites or drugstores would probably not qualify as sufficiently high value to entertain a category specific root inclusion. Similarly a CA that only vouches for Banks in the US and Britain would not qualify as Major, even if no larger banks-only CA exists. 4. Selected company CAs for a handful of too-bit-to-ignore companies that refuse to use a true public CA. So you think Mozilla's policy should include formal acknowledgement that some companies are too big to ignore? How do you decide which companies are in this category? This would very much be a subjective assessment. And would only be on a provisional basis. The key criteria would be how much normal users would be hurt by that CA not being trusted. Another key criteria would be if they were already included (Google and Amazon). For example, if users can't access the most popular search engine (Google), cannot access key services for their OS (Microsoft in some cases), or cannot access sites hosted by one of the top hosting providers (Amazon) that would be a reason to include that root in preference to forcing users to switch to a browser that does (Chrome, IE, some Amazon browser). As most large companies will have a hard time creating this situation from scratch (because they would not be initially trusted by browsers they can't get away with creating a situation where adding them to browsers becomes a necessity), this will be mostly a transitional / grandfathering category. Note that with my more strict definition of a global public CA, cloud providers (or other providers) that only vouch for their own customers don't qualify in that category, since they are not open to all comers. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
Self-assessment is insufficient :-) That's why we require audits, review issued certificates for technical violations, and attempt to empower domain owners to identify misissuance. As we move to a world with greater participation of public CAs in Certificate Transparency (hopefully 100% eventually), we can increasingly rely on objective measures to judge across CAs. Alex On Thu, Jan 18, 2018 at 4:23 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/01/18 14:54, Alex Gaynor wrote:> In summary, I think we should > focus less on the questions of whether a CA > > is "appropriate" or "deserving" of participation in the Mozilla Root > > Program, and more on whether they are willing and able to fulfill the > > expectations of them as a steward of global trust on the internet. > > If you ask any applicant "are you willing and able to fulfil what is > expected of you as a steward of global trust on the Internet?", and they > know they have to say "Yes" to get in, they will say "Yes". So is the > upshot of your position that anyone who wants to apply can get in? > > Gerv > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On Thu, Jan 18, 2018 at 9:33 AM, Ryan Sleevi wrote: > > > On Thu, Jan 18, 2018 at 9:11 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On 18/01/18 13:55, Ryan Sleevi wrote: >> > Was it your intent to redefine the problem like that? If not, do you >> have >> > those concerns about the objective measures, or is your goal to find >> > objective measures which you subjectively believe to be 'fair'? For >> > example, an objective measure would be "Paid for a 2-week vacation for >> > Gervase Markham and family every year to a location of their choosing", >> but >> > I suspect that you might argue it's subjectively 'not fair'? >> >> If every CA had to do it, it would both be an objective measure and >> subjectively fair. (Although one could argue it was unfair if I asked >> one CA to send us to Bogor Regis and another to send us to the Maldives. >> it would also mean a maximum of 26 CAs in the program at one time, and >> in the past we have decided against a hard numerical limit.) >> >> I would like to find a set of objective measures which the group >> considers as a whole to be "fair", in that the objective measures do not >> use criteria which are irrelevant to operating as a CA (such as buying >> my family a holiday). This may not be possible, of course - we will see >> - but that doesn't stop me wanting it. > > > To be honest, I think this highlights one of the challenges - namely, the > lack of a numerical limit of CAs. > > Absent a numerical limit, there will always be the risk that CAs that > "shouldn't" be in are accepted. One way to mitigate that is to try to raise > the floor - but with the risk of rejecting CAs that "should" be in, for > some value of "should" and "shouldn't" (both in terms of past failures and > prediction of future failures). > > Another way to attempt to address that is to work to mitigate the damage > of those that 'shouldn't' be in - both to the ecosystem and users - and > inevitably, a key part of that would include some notion of agility. That > agility extends to both software updates and to ecosystem updates. > > For example, an objective criteria might be that every new CA supports the > ACME protocol with some minimum prescribed set of interoperable validation > methods. In that model, all new CAs are afforded the same 'advantages' (or, > from the CA perspective, 'disadvantages') of having an interoperable > system, while addressing the ecosystem need by allowing ACME supporting > clients to rapidly transition to other ACME supporting CAs in the event > that the CA is determined they "shouldn't" be in (because they MITMed, for > example) > > Similarly, requiring all CAs disclose their trusted certificates via > Certificate Transparency offers an objective measure (modulo the nuance of > defining what constitutes 'disclosure'), thus reducing the risk involved > with scrying the various business purposes - and potentially providing > incentives for those that /could/ use private PKIs to do so if they have > concerns with such disclosure. > > Alternatively, all new CAs could be required to issue certificates for, at > most, 90 days. This further helps reduce the risk of 'getting it wrong'. > > These are all objective measures that avoid the attempt to divine purpose > and intent, and instead provide objective criteria based on the underlying > set of concerns that necessitate the worry about intent. However, as you > can also see, this inherently favors incumbents - so unless we treat an > inclusion policy equivalent to an acceptance policy, it doesn't > meaningfully improve the overall set of trust. > > This is why I think that some of the current proposals - such as scope or > size - are problematic, as they are attempts to try to mitigate through > policy the set of concerns that we could alternatively (and equitably) > mitigate through technology, and with a greater benefit to the overall > ecosystem :) > Apologies, accidentally tabbed to the send. I was going to highlight the contrast of those proposals with an alternative proposal. Limit the number of trusted root CAs to some arbitrary number (say, 26). At that point, your criteria for who to include becomes "Whomever is better than one of the existing 26, on whatever dimensions the community values". At that point, you're no longer trying to subjectively determine if the new CA rises past some abstract notion of the minimum - you've instead got 26 concrete instances of some measure that you can compare against, and see whether the new CA topples any of the incumbents. In the absence of having a strict limit, however, this isn't possible - and so I think the answer needs to be "more agility" rather than "more policy". Alternatively, if we (the community) want to limit to some subset, then we can and should talk about the dimensions we value, and how to pit CAs against eachother in a "Security and Policy Thunderdome" - where the most secure CAs, the ones that provide
Re: Updating Root Inclusion Criteria
On Thu, Jan 18, 2018 at 9:11 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 18/01/18 13:55, Ryan Sleevi wrote: > > Was it your intent to redefine the problem like that? If not, do you have > > those concerns about the objective measures, or is your goal to find > > objective measures which you subjectively believe to be 'fair'? For > > example, an objective measure would be "Paid for a 2-week vacation for > > Gervase Markham and family every year to a location of their choosing", > but > > I suspect that you might argue it's subjectively 'not fair'? > > If every CA had to do it, it would both be an objective measure and > subjectively fair. (Although one could argue it was unfair if I asked > one CA to send us to Bogor Regis and another to send us to the Maldives. > it would also mean a maximum of 26 CAs in the program at one time, and > in the past we have decided against a hard numerical limit.) > > I would like to find a set of objective measures which the group > considers as a whole to be "fair", in that the objective measures do not > use criteria which are irrelevant to operating as a CA (such as buying > my family a holiday). This may not be possible, of course - we will see > - but that doesn't stop me wanting it. To be honest, I think this highlights one of the challenges - namely, the lack of a numerical limit of CAs. Absent a numerical limit, there will always be the risk that CAs that "shouldn't" be in are accepted. One way to mitigate that is to try to raise the floor - but with the risk of rejecting CAs that "should" be in, for some value of "should" and "shouldn't" (both in terms of past failures and prediction of future failures). Another way to attempt to address that is to work to mitigate the damage of those that 'shouldn't' be in - both to the ecosystem and users - and inevitably, a key part of that would include some notion of agility. That agility extends to both software updates and to ecosystem updates. For example, an objective criteria might be that every new CA supports the ACME protocol with some minimum prescribed set of interoperable validation methods. In that model, all new CAs are afforded the same 'advantages' (or, from the CA perspective, 'disadvantages') of having an interoperable system, while addressing the ecosystem need by allowing ACME supporting clients to rapidly transition to other ACME supporting CAs in the event that the CA is determined they "shouldn't" be in (because they MITMed, for example) Similarly, requiring all CAs disclose their trusted certificates via Certificate Transparency offers an objective measure (modulo the nuance of defining what constitutes 'disclosure'), thus reducing the risk involved with scrying the various business purposes - and potentially providing incentives for those that /could/ use private PKIs to do so if they have concerns with such disclosure. Alternatively, all new CAs could be required to issue certificates for, at most, 90 days. This further helps reduce the risk of 'getting it wrong'. These are all objective measures that avoid the attempt to divine purpose and intent, and instead provide objective criteria based on the underlying set of concerns that necessitate the worry about intent. However, as you can also see, this inherently favors incumbents - so unless we treat an inclusion policy equivalent to an acceptance policy, it doesn't meaningfully improve the overall set of trust. This is why I think that some of the current proposals - such as scope or size - are problematic, as they are attempts to try to mitigate through policy the set of concerns that we could alternatively (and equitably) mitigate through technology, and with a greater benefit to the overall ecosystem :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On Thu, Jan 18, 2018 at 9:06 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 18/01/18 13:53, Ryan Sleevi wrote: > > But Gerv, Mozilla's policies already unequally favor the incumbent CAs, > at > > the detriment to both user security and the ecosystem. If your goal is > for > > policies that do not favor incumbents, then it seems a significantly > > different discussion should happen - and proposals such as Jonathan's > > inherently provide a way to normalize that field. > > If Jonathan's proposal were applied to all CAs, it might well reduce > incumbent advantage. But that would be a different discussion from > inclusion criteria. If it were applied only to new CAs, it would be > relevant to the current discussion - but then it would entrench > incumbent advantage. > Or, conversely, that we cannot discuss inclusion policies in isolation from discussion root policies - we cannot simultaneously work to strengthen inclusion without acknowledging the elephant in the room of the extant CAs. > > A prime example, recently highlighted in ongoing CA inclusion > discussions, > > is whether or not a CA must have an unbroken series of audits since their > > key was created (the PITRA). > > Yes. It seems that we have come to the position that it does not > necessarily have to. But I would raise an eyebrow at a root that had > been operating for 10 years and had only got its first set of audits > last week. > Isn't this effectively the VISA situation? When were their first audits - late 2016 / early 2017? This is why it's important to have that discussion - incumbents are already being granted advantages in inclusion policies. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Updating Root Inclusion Criteria
> I think this is a vote for the status quo, in which we have been accepting > CAs that don't meet the guidance provided under 'who may apply' Perhaps slightly less strong than that. I think Mozilla should be willing to consider accepting them if there is a compelling reason to do so. “Why aren’t you running/participating in a private PKI?” should always be the first question, with the recognition that there are valid answers to that question. -Tim smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
Hi Ryan, On 18/01/18 13:55, Ryan Sleevi wrote: > I do want to point out that you are substantially changing the goals from > what Wayne posited. That is, you have moved the goalpost from being > 'objective' to being what is 'fair', and 'fair' will inherently be a > subjective evaluation. One of my goals in this discussion is to record some of the thoughts I had on the topic, of which this is one. Those thoughts are far from unchallengeable - as you have recognised, since you are challenging one of them :-) > Was it your intent to redefine the problem like that? If not, do you have > those concerns about the objective measures, or is your goal to find > objective measures which you subjectively believe to be 'fair'? For > example, an objective measure would be "Paid for a 2-week vacation for > Gervase Markham and family every year to a location of their choosing", but > I suspect that you might argue it's subjectively 'not fair'? If every CA had to do it, it would both be an objective measure and subjectively fair. (Although one could argue it was unfair if I asked one CA to send us to Bogor Regis and another to send us to the Maldives. it would also mean a maximum of 26 CAs in the program at one time, and in the past we have decided against a hard numerical limit.) I would like to find a set of objective measures which the group considers as a whole to be "fair", in that the objective measures do not use criteria which are irrelevant to operating as a CA (such as buying my family a holiday). This may not be possible, of course - we will see - but that doesn't stop me wanting it. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
> On Jan 18, 2018, at 08:53, Ryan Sleevi wrote: > > If Mozilla was committed to an equitable set of criteria for both incumbents > and newcomers, then one natural consequence of this is that all incumbents > should be required to rotate their keys to new roots, created under audit > criteria acceptable to Mozilla, and to transition issuance to these roots. > This is, for what it's worth, notably similar to the consensus proposal > regarding Symantec and the Managed Partner Infrastructure, and serves to > mitigate a broad swath of risks. > > So I don't see any argument suggesting it *shouldn't* apply to existing roots > - if anything, such a policy requirement would go substantially to both > reduce the benefits afforded to incumbents through entropy, and to ensure > that Mozilla's users are adequately protected as the emerging security and > threat landscape changes. It does not prevent devices which cannot update (as > you can cross-certify), but ensures that the security critical, > responsibly-developed applications that do update can ensure their users are > protected. Yes, this is what I was thinking when I wrote the initial email. There are massive security benefits to Mozilla’s users if all CAs roll their roots and are re-evaluated after implementing an updated inclusion policy and ongoing requirements based on the goals that Alex described. I don’t think the conversations are separate. They are necessarily the same. It doesn’t make sense to update the inclusion policies and not look at roots that are already included unless you want to continue favoring incumbents. Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 18/01/18 13:53, Ryan Sleevi wrote: > But Gerv, Mozilla's policies already unequally favor the incumbent CAs, at > the detriment to both user security and the ecosystem. If your goal is for > policies that do not favor incumbents, then it seems a significantly > different discussion should happen - and proposals such as Jonathan's > inherently provide a way to normalize that field. If Jonathan's proposal were applied to all CAs, it might well reduce incumbent advantage. But that would be a different discussion from inclusion criteria. If it were applied only to new CAs, it would be relevant to the current discussion - but then it would entrench incumbent advantage. > A prime example, recently highlighted in ongoing CA inclusion discussions, > is whether or not a CA must have an unbroken series of audits since their > key was created (the PITRA). Yes. It seems that we have come to the position that it does not necessarily have to. But I would raise an eyebrow at a root that had been operating for 10 years and had only got its first set of audits last week. > Obviously, during the introduction of the > Baseline Requirements, this was not the case for any incumbents - and > Mozilla further granted an effective 3 years for incumbents beyond the BRs > effective date to come up to date, while simultaneously examining new CAs > against the modernized criteria. I'm not sure it was that long, and even if it was, I think this criticism is a little harsh given that we have been at the forefront of giving the BRs any teeth at all. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On Thu, Jan 18, 2018 at 4:59 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/01/18 19:14, Ryan Hurst wrote: > > Since Google's PKI was mentioned as an example, I can publicly state > > that the plan is for Google to utilize the Google Trust Services > > infrastructure to satisfy its SSL certificate needs. While I can not > > announce specific product roadmaps I can say that this includes the > > issuance of certificates for Google offerings involving hosting of > > products and services for customers. > > This is an interesting situation because it points to an interesting > ramification of a requirement which is anything like "issues certs to > the public". > > We can compare large companies who happen to be in the cloud hosting > business (e.g. Google, Amazon, Microsoft) with those that are not. The > former category can pass a "issuing certs to the public" test and so > qualify for inclusion, and can then use that same infra to issue their > internal certs, or certs for their own public-facing domains and > hostnames. A large company which happens not to be in the cloud hosting > business cannot pass that test, and so has to use a 3rd party CA for > their cert requirements. > > One could argue that deciding whether a large tech company gets the > convenience of a self-hosted root based on whether they provide a > particular service is not very fair. Gerv, I do want to point out that you are substantially changing the goals from what Wayne posited. That is, you have moved the goalpost from being 'objective' to being what is 'fair', and 'fair' will inherently be a subjective evaluation. Was it your intent to redefine the problem like that? If not, do you have those concerns about the objective measures, or is your goal to find objective measures which you subjectively believe to be 'fair'? For example, an objective measure would be "Paid for a 2-week vacation for Gervase Markham and family every year to a location of their choosing", but I suspect that you might argue it's subjectively 'not fair'? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On Thu, Jan 18, 2018 at 4:24 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/01/18 15:13, Jonathan Rudenberg wrote: > > I like this concept a lot. Some concrete ideas in this space: > > > > - Limit the validity period of root certificates to a few years, so that > the criteria can be re-evaluated, updated, and re-applied on a rolling > basis. > > Are you saying we should do this for new entrants only? If so, surely > that would give existing CAs a significant competitive advantage? Or, if > not, what is the relevance of your point to the question under > consideration? > But Gerv, Mozilla's policies already unequally favor the incumbent CAs, at the detriment to both user security and the ecosystem. If your goal is for policies that do not favor incumbents, then it seems a significantly different discussion should happen - and proposals such as Jonathan's inherently provide a way to normalize that field. A prime example, recently highlighted in ongoing CA inclusion discussions, is whether or not a CA must have an unbroken series of audits since their key was created (the PITRA). Obviously, during the introduction of the Baseline Requirements, this was not the case for any incumbents - and Mozilla further granted an effective 3 years for incumbents beyond the BRs effective date to come up to date, while simultaneously examining new CAs against the modernized criteria. This allows for substantial undetectable, unreported misissuance (which, for what it's worth, we have seen in the processing of root inclusion requests) for those that are 'grandfathered' in. If Mozilla was committed to an equitable set of criteria for both incumbents and newcomers, then one natural consequence of this is that all incumbents should be required to rotate their keys to new roots, created under audit criteria acceptable to Mozilla, and to transition issuance to these roots. This is, for what it's worth, notably similar to the consensus proposal regarding Symantec and the Managed Partner Infrastructure, and serves to mitigate a broad swath of risks. So I don't see any argument suggesting it *shouldn't* apply to existing roots - if anything, such a policy requirement would go substantially to both reduce the benefits afforded to incumbents through entropy, and to ensure that Mozilla's users are adequately protected as the emerging security and threat landscape changes. It does not prevent devices which cannot update (as you can cross-certify), but ensures that the security critical, responsibly-developed applications that do update can ensure their users are protected. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria (organizations)
On 17/01/18 19:49, Jakob Bohm wrote: > 3. Major vertical CAs for high value business categories that issue > publicly trusted certificates at better than EV level integrity. For How do you define "major"? And "high value business category"? > 4. Selected company CAs for a handful of too-bit-to-ignore companies > that refuse to use a true public CA. So you think Mozilla's policy should include formal acknowledgement that some companies are too big to ignore? How do you decide which companies are in this category? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 17/01/18 19:14, Ryan Hurst wrote: > Since Google's PKI was mentioned as an example, I can publicly state > that the plan is for Google to utilize the Google Trust Services > infrastructure to satisfy its SSL certificate needs. While I can not > announce specific product roadmaps I can say that this includes the > issuance of certificates for Google offerings involving hosting of > products and services for customers. This is an interesting situation because it points to an interesting ramification of a requirement which is anything like "issues certs to the public". We can compare large companies who happen to be in the cloud hosting business (e.g. Google, Amazon, Microsoft) with those that are not. The former category can pass a "issuing certs to the public" test and so qualify for inclusion, and can then use that same infra to issue their internal certs, or certs for their own public-facing domains and hostnames. A large company which happens not to be in the cloud hosting business cannot pass that test, and so has to use a 3rd party CA for their cert requirements. One could argue that deciding whether a large tech company gets the convenience of a self-hosted root based on whether they provide a particular service is not very fair. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 17/01/18 15:41, Peter Bowen wrote: > In the interest of transparency, I would like to add one more example > to your list: > > * Amazon Trust Services is a current program member. Amazon applied > independently but then subsequently bought a root from Go Daddy > (obvious disclosure: Wayne was VP at Go Daddy at the time). So far > there is no public path to bring Amazon a public key/CSR you generate > on you own server and have Amazon issue a certificate containing that > public key. The primary path to getting a certificate issued by > Amazon is to use AWS Certificate Manager. That being said, we have > issued certificates to hundreds of thousands of domains and Mozilla > telemetry data shows they are being widely used by users of Mozilla > software products. IOW, you can't bring your CSR to Amazon and get a certificate, but you can bring your _domain_ to Amazon and get a certificate. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 17/01/18 15:13, Jonathan Rudenberg wrote: > I like this concept a lot. Some concrete ideas in this space: > > - Limit the validity period of root certificates to a few years, so that the > criteria can be re-evaluated, updated, and re-applied on a rolling basis. Are you saying we should do this for new entrants only? If so, surely that would give existing CAs a significant competitive advantage? Or, if not, what is the relevance of your point to the question under consideration? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 17/01/18 14:54, Alex Gaynor wrote:> In summary, I think we should focus less on the questions of whether a CA > is "appropriate" or "deserving" of participation in the Mozilla Root > Program, and more on whether they are willing and able to fulfill the > expectations of them as a steward of global trust on the internet. If you ask any applicant "are you willing and able to fulfil what is expected of you as a steward of global trust on the Internet?", and they know they have to say "Yes" to get in, they will say "Yes". So is the upshot of your position that anyone who wants to apply can get in? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On Wed, Jan 17, 2018 at 3:32 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/01/2018 23:03, Jonathan Rudenberg wrote: > > You seem to be stuck inside some kind of ivory tower world where > computers are king and everything is done by robots. > > This is an interesting debate, but I don't think it's getting us any closer to answering the question at hand. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On Wed, Jan 17, 2018 at 7:54 AM, Alex Gaynor wrote: > Hi Wayne, > > After some time thinking about it, I struggled to articulate what the > right rules for inclusion were. > > Yes, that is the challenge. So I decided to approach this from a different perspective: which is that I > think we should design our other policies and requirements for CAs around > what we'd expect for organizations operating towards a goal of securing the > Internet as a global public resource. > > Towards that goal we should continue to focus on things like transparency > (how this list is run, visibility of audit statements, certificate > transparency) and driving technical improvements to the WebPKI (shorter > certificate lifespans, fewer allowances for non-compliant certificates or > use of deprecated formats and cryptography). If organizations wish to hold > themselves to these (presumably higher) standards for what could equally > well be a private PKI, I don't see that as a problem. On the flip side, we > should not delay improvements because CAs with limited impact on the public > internet struggle with compliance. > > Can we separate the ongoing work we need to do to improve the ecosystem from a decision on root inclusion criteria? Or are you saying that we need to set new requirements like these as a condition for changing the root inclusion criteria? In summary, I think we should focus less on the questions of whether a CA > is "appropriate" or "deserving" of participation in the Mozilla Root > Program, and more on whether they are willing and able to fulfill the > expectations of them as a steward of global trust on the internet. This has > the nice benefit of aligning well with Mozilla's mission to ensure the > internet is a global public resource, open and accessible to all. > > With this approach we would welcome any CA that can meet the program's requirements, regardless of the intended use of their certificates. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On Wed, Jan 17, 2018 at 7:46 AM, Tim Hollebeek wrote: > I support "encouraging" those who are currently using the public web PKI > for > internal uses to move to their own private PKIs. The current situation is > an > artifact of the old notion that there should be a global "One CA List to > Rule > Them All" owned by the operating system, and everyone should use that. > That notion is a bit antiquated, in my mind. Applications and components > that need a trust list really need to carefully select (or create!) an > appropriate > one instead of just grabbing the most convenient one. > > I think this is a vote for the status quo, in which we have been accepting CAs that don't meet the guidance provided under 'who may apply' I'm familiar with a few efforts in the financial space to transition away > from > browser trust lists for non-browser TLS, but as you can imagine, that's > not a > trivial effort and will take some time. My only request would be that if > the > rules are going to change, that large companies and entire industries that > may be affected be given enough notice to be able to come up with > reasonable transition plans. > > Point taken. My immediate concern is for new applications, not with existing CAs. -Tim > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria (organizations)
On 17/01/2018 22:51, Peter Bowen wrote: On Wed, Jan 17, 2018 at 11:49 AM, Jakob Bohm via dev-security-policy wrote: 4. Selected company CAs for a handful of too-bit-to-ignore companies that refuse to use a true public CA. This would currently probably be Microsoft, Amazon and Google. These should be admitted only on a temporary basis to pressure such companies to use generally trusted independent CAs. Jakob, Can you please explain how you define "true public CA"? How long should new CAs have to meet this criteria? I don't like carve outs for "too-big-to-ignore". True public CA = #1 to #3 in my list. For the 3 organizations mentioned, this would probably be #1. For #1 they would need to offer certificates to anyone willing to pay the usual fee (possibly 0), passing validation and not barred by special circumstances (Government embargoes, non-functional whois servers, known cybercriminals etc.). They would need to promise doing this as long as they are fully operational, but obviously not during spin-up and stand-down periods (where they would typically only sign internal certificates, test sites etc.) For #2 and #3 they would need to offer certificates to most entities within their scope. So Let's encrypt, Digicert, Globalsign etc. are true global CAs. (#1) CNNIC, Deutche Telekom etc. are national CAs (#2) VISA, ICAO etc. might operate vertical major CAs (#3) The carve outs are there because as web users we have difficulty avoiding websites using those specific organizations, thus needing to trust them subject to as many limitations as the browser can practically enforce. The suggested time limits are there to help sunsetting the carve-outs. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 17/01/2018 23:03, Jonathan Rudenberg wrote: On Jan 17, 2018, at 16:24, Jakob Bohm via dev-security-policy wrote: On 17/01/2018 21:14, Jonathan Rudenberg wrote: On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy wrote: On 17/01/2018 16:13, Jonathan Rudenberg wrote: On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy wrote: Hi Wayne, After some time thinking about it, I struggled to articulate what the right rules for inclusion were. So I decided to approach this from a different perspective: which is that I think we should design our other policies and requirements for CAs around what we'd expect for organizations operating towards a goal of securing the Internet as a global public resource. Towards that goal we should continue to focus on things like transparency (how this list is run, visibility of audit statements, certificate transparency) and driving technical improvements to the WebPKI (shorter certificate lifespans, fewer allowances for non-compliant certificates or use of deprecated formats and cryptography). If organizations wish to hold themselves to these (presumably higher) standards for what could equally well be a private PKI, I don't see that as a problem. On the flip side, we should not delay improvements because CAs with limited impact on the public internet struggle with compliance. I would say, that to limit the danger that such an essentially unused CA operator turns rogue, only CAs that provide certificates for public trust should be admitted in the future, more on that in another post. I like this concept a lot. Some concrete ideas in this space: - Limit the validity period of root certificates to a few years, so that the criteria can be re-evaluated, updated, and re-applied on a rolling basis. This may be fine for TLS root CAs that are distributed in frequently updated browsers (such as Firefox and Chrome). It is absolutely fatal for roots that are also used for any of the following: - Distributed in browsers that don't get frequent updates (due to problems in that distribution channel), such as many browsers distributed in the firmware of mobile devices, TVs etc. Distributing WebPKI roots in infrequently updated software is a bad idea and leads to disasters like the issues around the SHA-1 deprecation. But what should then be done when that infrequently updated software is in fact a general end user web browser (as opposed to the previously discussed special cases of certain payment terminals)? Remove TLS support? Trust all certificates without meaningful checks? Pop up certificate warnings for every valid certificate? Don’t ship browsers that don’t get updates. The surface area is huge and there are many security bugs that are fixed regularly. Shipping browsers in a way that prevents them from being updated frequently is deeply irresponsible. Unfortunately, people do that, in the billions. Nothing we can do to stop them. The way the SHA-1 deprecation was done, with no widely implemented way for TLS clients to signal their ability to support stronger algorithms, has in fact created a situation where unreliable hacks are needed to support older mobile browsers, including feeding unencrypted pages to some of them. The public stigma attached to this makes this something that is rarely discussed in public, but is quietly done by webmasters that need to communicate with those systems. This is false. TLS clients absolutely signal their ability to support specific algorithms, and there are several implementations of serving SHA-1 certificates to insecure clients. Interesting that their is no published support or instructions in the usual guides on TLS configuration best practices, nor much accommodation by this root program for SHA-1-forever CAs. - Used to (indirectly) sign items of long validity, such as e-mails (Thunderbird!), timestamps and software. I don’t know much about S/MIME, but this doesn’t sound right. Of course certificates used to sign emails expire! That’s obviously expected, and I’d hope that the validation takes that into account. The mechanisms vary by recipient software. But a typical technique combines a known-unmodified-since date (such as the date of reception or a date certified by a cryptographic timestamps) to compare the relevant validity dates in certificates against. This obviously needs continued trust in the root certificates that were relevant at that earlier time, including the ability if the corresponding CAs to publish and update revocation information after the end certificates expiry date. (Consider the case where an e-mail sender's personal certificate was compromised 1 day before expiry, but that fact was not reported to the CA until later, thus requiring the CA to publish changed revocation information for an already expired certificate in order to protect relying parties (recipients) from trusting fraudulent signatures made with the compromised key. If
Re: Updating Root Inclusion Criteria
> On Jan 17, 2018, at 16:24, Jakob Bohm via dev-security-policy > wrote: > > On 17/01/2018 21:14, Jonathan Rudenberg wrote: >>> On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy >>> wrote: >>> >>> On 17/01/2018 16:13, Jonathan Rudenberg wrote: > On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy > wrote: > > Hi Wayne, > > After some time thinking about it, I struggled to articulate what the > right > rules for inclusion were. > > So I decided to approach this from a different perspective: which is that > I > think we should design our other policies and requirements for CAs around > what we'd expect for organizations operating towards a goal of securing > the > Internet as a global public resource. > > Towards that goal we should continue to focus on things like transparency > (how this list is run, visibility of audit statements, certificate > transparency) and driving technical improvements to the WebPKI (shorter > certificate lifespans, fewer allowances for non-compliant certificates or > use of deprecated formats and cryptography). If organizations wish to hold > themselves to these (presumably higher) standards for what could equally > well be a private PKI, I don't see that as a problem. On the flip side, we > should not delay improvements because CAs with limited impact on the > public > internet struggle with compliance. >>> >>> I would say, that to limit the danger that such an essentially unused CA >>> operator turns rogue, only CAs that provide certificates for public trust >>> should be admitted in the future, more on that in another post. >>> I like this concept a lot. Some concrete ideas in this space: - Limit the validity period of root certificates to a few years, so that the criteria can be re-evaluated, updated, and re-applied on a rolling basis. >>> >>> This may be fine for TLS root CAs that are distributed in frequently >>> updated browsers (such as Firefox and Chrome). >>> >>> It is absolutely fatal for roots that are also used for any of the >>> following: >>> >>> - Distributed in browsers that don't get frequent updates (due to >>> problems in that distribution channel), such as many browsers >>> distributed in the firmware of mobile devices, TVs etc. >> Distributing WebPKI roots in infrequently updated software is a bad idea and >> leads to disasters like the issues around the SHA-1 deprecation. > > But what should then be done when that infrequently updated software is > in fact a general end user web browser (as opposed to the previously > discussed special cases of certain payment terminals)? Remove TLS > support? Trust all certificates without meaningful checks? Pop up > certificate warnings for every valid certificate? Don’t ship browsers that don’t get updates. The surface area is huge and there are many security bugs that are fixed regularly. Shipping browsers in a way that prevents them from being updated frequently is deeply irresponsible. > The way the SHA-1 deprecation was done, with no widely implemented way > for TLS clients to signal their ability to support stronger algorithms, > has in fact created a situation where unreliable hacks are needed to > support older mobile browsers, including feeding unencrypted pages to > some of them. The public stigma attached to this makes this something > that is rarely discussed in public, but is quietly done by webmasters that > need to communicate with those systems. This is false. TLS clients absolutely signal their ability to support specific algorithms, and there are several implementations of serving SHA-1 certificates to insecure clients. > >>> - Used to (indirectly) sign items of long validity, such as e-mails >>> (Thunderbird!), timestamps and software. >> I don’t know much about S/MIME, but this doesn’t sound right. Of course >> certificates used to sign emails expire! That’s obviously expected, and I’d >> hope that the validation takes that into account. > > The mechanisms vary by recipient software. But a typical technique > combines a known-unmodified-since date (such as the date of reception or > a date certified by a cryptographic timestamps) to compare the relevant > validity dates in certificates against. > > This obviously needs continued trust in the root certificates > that were relevant at that earlier time, including the ability > if the corresponding CAs to publish and update revocation > information after the end certificates expiry date. (Consider the > case where an e-mail sender's personal certificate was > compromised 1 day before expiry, but that fact was not reported > to the CA until later, thus requiring the CA to publish changed > revocation information for an already expired certificate in > order to protect relying parties (recipients) from trusting > fraudulent signatures made with the compromised key
Re: Updating Root Inclusion Criteria (organizations)
On Wed, Jan 17, 2018 at 11:49 AM, Jakob Bohm via dev-security-policy wrote: > 4. Selected company CAs for a handful of too-bit-to-ignore companies > that refuse to use a true public CA. This would currently probably > be Microsoft, Amazon and Google. These should be admitted only on > a temporary basis to pressure such companies to use generally trusted > independent CAs. Jakob, Can you please explain how you define "true public CA"? How long should new CAs have to meet this criteria? I don't like carve outs for "too-big-to-ignore". Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 17/01/2018 21:14, Jonathan Rudenberg wrote: On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy wrote: On 17/01/2018 16:13, Jonathan Rudenberg wrote: On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy wrote: Hi Wayne, After some time thinking about it, I struggled to articulate what the right rules for inclusion were. So I decided to approach this from a different perspective: which is that I think we should design our other policies and requirements for CAs around what we'd expect for organizations operating towards a goal of securing the Internet as a global public resource. Towards that goal we should continue to focus on things like transparency (how this list is run, visibility of audit statements, certificate transparency) and driving technical improvements to the WebPKI (shorter certificate lifespans, fewer allowances for non-compliant certificates or use of deprecated formats and cryptography). If organizations wish to hold themselves to these (presumably higher) standards for what could equally well be a private PKI, I don't see that as a problem. On the flip side, we should not delay improvements because CAs with limited impact on the public internet struggle with compliance. I would say, that to limit the danger that such an essentially unused CA operator turns rogue, only CAs that provide certificates for public trust should be admitted in the future, more on that in another post. I like this concept a lot. Some concrete ideas in this space: - Limit the validity period of root certificates to a few years, so that the criteria can be re-evaluated, updated, and re-applied on a rolling basis. This may be fine for TLS root CAs that are distributed in frequently updated browsers (such as Firefox and Chrome). It is absolutely fatal for roots that are also used for any of the following: - Distributed in browsers that don't get frequent updates (due to problems in that distribution channel), such as many browsers distributed in the firmware of mobile devices, TVs etc. Distributing WebPKI roots in infrequently updated software is a bad idea and leads to disasters like the issues around the SHA-1 deprecation. But what should then be done when that infrequently updated software is in fact a general end user web browser (as opposed to the previously discussed special cases of certain payment terminals)? Remove TLS support? Trust all certificates without meaningful checks? Pop up certificate warnings for every valid certificate? The way the SHA-1 deprecation was done, with no widely implemented way for TLS clients to signal their ability to support stronger algorithms, has in fact created a situation where unreliable hacks are needed to support older mobile browsers, including feeding unencrypted pages to some of them. The public stigma attached to this makes this something that is rarely discussed in public, but is quietly done by webmasters that need to communicate with those systems. - Used to (indirectly) sign items of long validity, such as e-mails (Thunderbird!), timestamps and software. I don’t know much about S/MIME, but this doesn’t sound right. Of course certificates used to sign emails expire! That’s obviously expected, and I’d hope that the validation takes that into account. The mechanisms vary by recipient software. But a typical technique combines a known-unmodified-since date (such as the date of reception or a date certified by a cryptographic timestamps) to compare the relevant validity dates in certificates against. This obviously needs continued trust in the root certificates that were relevant at that earlier time, including the ability if the corresponding CAs to publish and update revocation information after the end certificates expiry date. (Consider the case where an e-mail sender's personal certificate was compromised 1 day before expiry, but that fact was not reported to the CA until later, thus requiring the CA to publish changed revocation information for an already expired certificate in order to protect relying parties (recipients) from trusting fraudulent signatures made with the compromised key. - Apply for inclusion in other root programs with slow/costly/ inefficient distribution of new root certificates (At least one major software vendor has these problems in their root program). This isn’t Mozilla’s problem, and one can come up with a variety of straightforward workarounds. The big problem is that the formats for communicating the certificate chain from the certificate holder to the relying parties are quite limited in how they can accommodate different relying parties trusting different roots from each CA. Requiring CAs to set up extra workarounds just to satisfy an arbitrary policy like yours is an unneeded complication for everybody but Mozilla and Chrome. - Make all certificates issued by CAs under a root that is trusted for TLS in scope for the Baseline Requirements,
Re: Updating Root Inclusion Criteria
> On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy > wrote: > > On 17/01/2018 16:13, Jonathan Rudenberg wrote: >>> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy >>> wrote: >>> >>> Hi Wayne, >>> >>> After some time thinking about it, I struggled to articulate what the right >>> rules for inclusion were. >>> >>> So I decided to approach this from a different perspective: which is that I >>> think we should design our other policies and requirements for CAs around >>> what we'd expect for organizations operating towards a goal of securing the >>> Internet as a global public resource. >>> >>> Towards that goal we should continue to focus on things like transparency >>> (how this list is run, visibility of audit statements, certificate >>> transparency) and driving technical improvements to the WebPKI (shorter >>> certificate lifespans, fewer allowances for non-compliant certificates or >>> use of deprecated formats and cryptography). If organizations wish to hold >>> themselves to these (presumably higher) standards for what could equally >>> well be a private PKI, I don't see that as a problem. On the flip side, we >>> should not delay improvements because CAs with limited impact on the public >>> internet struggle with compliance. > > I would say, that to limit the danger that such an essentially unused CA > operator turns rogue, only CAs that provide certificates for public trust > should be admitted in the future, more on that in another post. > >> I like this concept a lot. Some concrete ideas in this space: >> - Limit the validity period of root certificates to a few years, so that the >> criteria can be re-evaluated, updated, and re-applied on a rolling basis. > > This may be fine for TLS root CAs that are distributed in frequently > updated browsers (such as Firefox and Chrome). > > It is absolutely fatal for roots that are also used for any of the > following: > > - Distributed in browsers that don't get frequent updates (due to > problems in that distribution channel), such as many browsers > distributed in the firmware of mobile devices, TVs etc. Distributing WebPKI roots in infrequently updated software is a bad idea and leads to disasters like the issues around the SHA-1 deprecation. > - Used to (indirectly) sign items of long validity, such as e-mails > (Thunderbird!), timestamps and software. I don’t know much about S/MIME, but this doesn’t sound right. Of course certificates used to sign emails expire! That’s obviously expected, and I’d hope that the validation takes that into account. > - Apply for inclusion in other root programs with slow/costly/ > inefficient distribution of new root certificates (At least one > major software vendor has these problems in their root program). This isn’t Mozilla’s problem, and one can come up with a variety of straightforward workarounds. >> - Make all certificates issued by CAs under a root that is trusted for TLS >> in scope for the Baseline Requirements, and don’t allow issuing things like >> client certificates that have much more relaxed requirements (if any). This >> helps avoid ambiguity around scope. > > Again this would be a major problem for roots that are used outside web > browsers, including roots used for e-mail certificates (Thunderbird). > > The ecosystem already suffers from the need to keep multiple trusted > root certificates per CA organization due to artifacts of existing > rules, no need to make this worse by multiplying this with the number > of certificate end uses. I’m having trouble seeing how sharding roots based on compliance type is a problem. Not doing so complicates reasoning about compliance unnecessarily. >> - Limit the maximum validity period of leaf certificates issued to a sane >> upper bound like 90 days. This will help ensure that we don’t rust old >> crypto and standards in place and makes it less likely that a CA is “too big >> to fail” due to a set of customers that are not expecting to replace their >> certificates regularly. > > This would be a *major* problem for any end users not using Let's > encrypt, and would seemingly seek to destroy a major advantage of using > a real CA over Let's encrypt. Obviously this is completely false. Ridiculous diversions about “real” CAs aside, many other CAs issue certificates to automated management systems and this is obviously the way forward. Humans should not be managing certificate lifecycles. > The only "too big to fail" problem we had recently was when the oldest, > and biggest CA ever was forced out of business by some very loud people > on this list. And the problem was that those people demanded rushed > punishment in the extreme with little or no consideration for who would > be hurt in the process. This is not true. Readers of this list are almost certainly quite familiar with the events that caused Google and Mozilla to protect their users from Symantec’s failures: https://wiki.mozill
Re: Updating Root Inclusion Criteria (organizations)
As for what CA organizations to include in a future iteration of the Mozilla root store, I would say that there are 4 groups that I (as a browser user) would like to get included and 2 which I would not: 1. Global public CAs that provide certificates to subscribers from all over the world subject to appropriate security controls to avoid issuing to people other than what the certificate states and avoid technical compromise of the certificate infrastructure and the relying party software. 2. National public and government CAs that issue certificates only to their own subjects (citizens, organizations, institutions) to similar high standards further enhanced by their authoritative knowledge of the true identities of subscribers. However trust in those should be technically constrained (either in the roots or in extra root store metadata) to only the country identifiers they are actually authoritative for. For example the Taiwan Governmemt roots should only be trusted for the .tw TLD (or perhaps some government subdomain). Similar any new Danish national CA (replacing the dead TDC CA) would only be trusted for the .dk, .fo and .gl TLDs . The C= and jurisdictionOfIncorporation parts of distinguished names should also be restricted. 3. Major vertical CAs for high value business categories that issue publicly trusted certificates at better than EV level integrity. For example if the VISA CA was issuing public certificates for the customer facing secure account web interfaces of most of the participating banks and credit card issuers, worldwide, they would be valuable CA to include. The same would be true if the (now historic) SET payment standard had been included in Firefox and relied on VISA issued certificates for the payment servers. 4. Selected company CAs for a handful of too-bit-to-ignore companies that refuse to use a true public CA. This would currently probably be Microsoft, Amazon and Google. These should be admitted only on a temporary basis to pressure such companies to use generally trusted independent CAs. Root operators not to include: -1. Root programs that engage in actually harmful activities such as MiTM attacks or mandatory key escrow. Seems many "ElDAS" style CAs in the EU do the latter. -2. Root programs that serve only themselves and have not become too-big to ignore. On 17/01/2018 00:45, Wayne Thayer wrote: I would like to open a discussion about the criteria by which Mozilla decides which CAs we should allow to apply for inclusion in our root store. Section 2.1 of Mozilla’s current Root Store Policy states: CAs whose certificates are included in Mozilla's root program MUST: 1.provide some service relevant to typical users of our software products; Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On 17/01/2018 16:13, Jonathan Rudenberg wrote: On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy wrote: Hi Wayne, After some time thinking about it, I struggled to articulate what the right rules for inclusion were. So I decided to approach this from a different perspective: which is that I think we should design our other policies and requirements for CAs around what we'd expect for organizations operating towards a goal of securing the Internet as a global public resource. Towards that goal we should continue to focus on things like transparency (how this list is run, visibility of audit statements, certificate transparency) and driving technical improvements to the WebPKI (shorter certificate lifespans, fewer allowances for non-compliant certificates or use of deprecated formats and cryptography). If organizations wish to hold themselves to these (presumably higher) standards for what could equally well be a private PKI, I don't see that as a problem. On the flip side, we should not delay improvements because CAs with limited impact on the public internet struggle with compliance. I would say, that to limit the danger that such an essentially unused CA operator turns rogue, only CAs that provide certificates for public trust should be admitted in the future, more on that in another post. I like this concept a lot. Some concrete ideas in this space: - Limit the validity period of root certificates to a few years, so that the criteria can be re-evaluated, updated, and re-applied on a rolling basis. This may be fine for TLS root CAs that are distributed in frequently updated browsers (such as Firefox and Chrome). It is absolutely fatal for roots that are also used for any of the following: - Distributed in browsers that don't get frequent updates (due to problems in that distribution channel), such as many browsers distributed in the firmware of mobile devices, TVs etc. - Used to (indirectly) sign items of long validity, such as e-mails (Thunderbird!), timestamps and software. - Apply for inclusion in other root programs with slow/costly/ inefficient distribution of new root certificates (At least one major software vendor has these problems in their root program). - Make all certificates issued by CAs under a root that is trusted for TLS in scope for the Baseline Requirements, and don’t allow issuing things like client certificates that have much more relaxed requirements (if any). This helps avoid ambiguity around scope. Again this would be a major problem for roots that are used outside web browsers, including roots used for e-mail certificates (Thunderbird). The ecosystem already suffers from the need to keep multiple trusted root certificates per CA organization due to artifacts of existing rules, no need to make this worse by multiplying this with the number of certificate end uses. - Limit the maximum validity period of leaf certificates issued to a sane upper bound like 90 days. This will help ensure that we don’t rust old crypto and standards in place and makes it less likely that a CA is “too big to fail” due to a set of customers that are not expecting to replace their certificates regularly. This would be a *major* problem for any end users not using Let's encrypt, and would seemingly seek to destroy a major advantage of using a real CA over Let's encrypt. The only "too big to fail" problem we had recently was when the oldest, and biggest CA ever was forced out of business by some very loud people on this list. And the problem was that those people demanded rushed punishment in the extreme with little or no consideration for who would be hurt in the process. All in all, such a requirement would do nothing but harm. I think with these and other similar requirements, we move closer towards ensuring that the roots accepted are operated with the high level goals described by Alex in mind, and allow more agility at the root store level to respond to issues. Jonathan Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On Tuesday, January 16, 2018 at 3:46:03 PM UTC-8, Wayne Thayer wrote: > I would like to open a discussion about the criteria by which Mozilla > decides which CAs we should allow to apply for inclusion in our root store. > > Section 2.1 of Mozilla’s current Root Store Policy states: > > CAs whose certificates are included in Mozilla's root program MUST: > > 1.provide some service relevant to typical users of our software > > products; > > > > Further non-normative guidance for which organizations may apply to the CA > program is documented in the ‘Who May Apply’ section of the application > process at https://wiki.mozilla.org/CA/Application_Process . The original > intent of this provision in the policy and the guidance was to discourage a > large number of organizations from applying to the program solely for the > purpose of avoiding the difficulties of distributing private roots for > their own internal use. > > Recently, we’ve encountered a number of examples that cause us to question > the usefulness of the currently-vague statement(s) we have that define > which CAs to accept, along a number of different axes: > > * Visa is a current program member that has an open request to add another > root. They only issue a relatively small number of certificates per year to > partners and for internal use. They do not offer certificates to the > general public or to anyone with whom they do not have an existing business > relationship. > > * Google is also a current program member, admitted via the acquisition of > an existing root, but does not currently, to the best of our knowledge, > meet the existing inclusion criteria, even though it is conceivable that > they would issue certificates to the public in the future. > > * There are potential applicants for CA status who deploy a large number of > certificates, but only on their own infrastructure and for their own > domains, albeit that this infrastructure is public-facing rather than > company-internal. > > * We have numerous government CAs in the program or in the inclusion > process that only intend to issue certificates to their own institutions. > > * We have at least one CA applying for the program that (at least, it has > been reported in the press) is controlled by an entity which may wish to > use it for MITM. > > There are many potential options for resolving this issue. Ideally, we > would like to establish some objective criteria that can be measured and > applied fairly. It’s possible that this could require us to define > different categories of CAs, each with different inclusion criteria. Or it > could be that we should remove the existing ‘relevance’ requirement and > inclusion guidelines and accept any applicant who can meet all of our other > requirements. > > With this background, I would like to encourage everyone to provide > constructive input on this topic. > > Thanks, > > Wayne Wayne, I recall facing this topic at Microsoft when I was defining the root policy for them. At the time I failed to effectively come up with language that would capture all of the use cases we felt were important. This is why we ended up with what was at the time a vague statement on broad value to Microsoft consumers. With that said, despite the challenges associated with the tasks, I agree this is an area where clarity is needed. Since Google's PKI was mentioned as an example, I can publicly state that the plan is for Google to utilize the Google Trust Services infrastructure to satisfy its SSL certificate needs. While I can not announce specific product roadmaps I can say that this includes the issuance of certificates for Google offerings involving hosting of products and services for customers. Ryan Hurst Product Manager Google ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
On Tue, Jan 16, 2018 at 3:45 PM, Wayne Thayer via dev-security-policy wrote: > I would like to open a discussion about the criteria by which Mozilla > decides which CAs we should allow to apply for inclusion in our root store. > > Section 2.1 of Mozilla’s current Root Store Policy states: > > CAs whose certificates are included in Mozilla's root program MUST: >> 1.provide some service relevant to typical users of our software >> products; >> > > Further non-normative guidance for which organizations may apply to the CA > program is documented in the ‘Who May Apply’ section of the application > process at https://wiki.mozilla.org/CA/Application_Process . The original > intent of this provision in the policy and the guidance was to discourage a > large number of organizations from applying to the program solely for the > purpose of avoiding the difficulties of distributing private roots for > their own internal use. > > Recently, we’ve encountered a number of examples that cause us to question > the usefulness of the currently-vague statement(s) we have that define > which CAs to accept, along a number of different axes: > [snip] > > There are many potential options for resolving this issue. Ideally, we > would like to establish some objective criteria that can be measured and > applied fairly. It’s possible that this could require us to define > different categories of CAs, each with different inclusion criteria. Or it > could be that we should remove the existing ‘relevance’ requirement and > inclusion guidelines and accept any applicant who can meet all of our other > requirements. > > With this background, I would like to encourage everyone to provide > constructive input on this topic. Wayne, In the interest of transparency, I would like to add one more example to your list: * Amazon Trust Services is a current program member. Amazon applied independently but then subsequently bought a root from Go Daddy (obvious disclosure: Wayne was VP at Go Daddy at the time). So far there is no public path to bring Amazon a public key/CSR you generate on you own server and have Amazon issue a certificate containing that public key. The primary path to getting a certificate issued by Amazon is to use AWS Certificate Manager. That being said, we have issued certificates to hundreds of thousands of domains and Mozilla telemetry data shows they are being widely used by users of Mozilla software products. Thanks, Peter P.S. I'm very much looking forward to the Firefox ESR 60 release, as that will mark Amazon inclusion for EV in all Mozilla products. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy > wrote: > > Hi Wayne, > > After some time thinking about it, I struggled to articulate what the right > rules for inclusion were. > > So I decided to approach this from a different perspective: which is that I > think we should design our other policies and requirements for CAs around > what we'd expect for organizations operating towards a goal of securing the > Internet as a global public resource. > > Towards that goal we should continue to focus on things like transparency > (how this list is run, visibility of audit statements, certificate > transparency) and driving technical improvements to the WebPKI (shorter > certificate lifespans, fewer allowances for non-compliant certificates or > use of deprecated formats and cryptography). If organizations wish to hold > themselves to these (presumably higher) standards for what could equally > well be a private PKI, I don't see that as a problem. On the flip side, we > should not delay improvements because CAs with limited impact on the public > internet struggle with compliance. I like this concept a lot. Some concrete ideas in this space: - Limit the validity period of root certificates to a few years, so that the criteria can be re-evaluated, updated, and re-applied on a rolling basis. - Make all certificates issued by CAs under a root that is trusted for TLS in scope for the Baseline Requirements, and don’t allow issuing things like client certificates that have much more relaxed requirements (if any). This helps avoid ambiguity around scope. - Limit the maximum validity period of leaf certificates issued to a sane upper bound like 90 days. This will help ensure that we don’t rust old crypto and standards in place and makes it less likely that a CA is “too big to fail” due to a set of customers that are not expecting to replace their certificates regularly. I think with these and other similar requirements, we move closer towards ensuring that the roots accepted are operated with the high level goals described by Alex in mind, and allow more agility at the root store level to respond to issues. Jonathan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Updating Root Inclusion Criteria
Hi Wayne, After some time thinking about it, I struggled to articulate what the right rules for inclusion were. So I decided to approach this from a different perspective: which is that I think we should design our other policies and requirements for CAs around what we'd expect for organizations operating towards a goal of securing the Internet as a global public resource. Towards that goal we should continue to focus on things like transparency (how this list is run, visibility of audit statements, certificate transparency) and driving technical improvements to the WebPKI (shorter certificate lifespans, fewer allowances for non-compliant certificates or use of deprecated formats and cryptography). If organizations wish to hold themselves to these (presumably higher) standards for what could equally well be a private PKI, I don't see that as a problem. On the flip side, we should not delay improvements because CAs with limited impact on the public internet struggle with compliance. In summary, I think we should focus less on the questions of whether a CA is "appropriate" or "deserving" of participation in the Mozilla Root Program, and more on whether they are willing and able to fulfill the expectations of them as a steward of global trust on the internet. This has the nice benefit of aligning well with Mozilla's mission to ensure the internet is a global public resource, open and accessible to all. Alex On Tue, Jan 16, 2018 at 6:45 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I would like to open a discussion about the criteria by which Mozilla > decides which CAs we should allow to apply for inclusion in our root store. > > Section 2.1 of Mozilla’s current Root Store Policy states: > > CAs whose certificates are included in Mozilla's root program MUST: > > 1.provide some service relevant to typical users of our software > > products; > > > > Further non-normative guidance for which organizations may apply to the CA > program is documented in the ‘Who May Apply’ section of the application > process at https://wiki.mozilla.org/CA/Application_Process . The original > intent of this provision in the policy and the guidance was to discourage a > large number of organizations from applying to the program solely for the > purpose of avoiding the difficulties of distributing private roots for > their own internal use. > > Recently, we’ve encountered a number of examples that cause us to question > the usefulness of the currently-vague statement(s) we have that define > which CAs to accept, along a number of different axes: > > * Visa is a current program member that has an open request to add another > root. They only issue a relatively small number of certificates per year to > partners and for internal use. They do not offer certificates to the > general public or to anyone with whom they do not have an existing business > relationship. > > * Google is also a current program member, admitted via the acquisition of > an existing root, but does not currently, to the best of our knowledge, > meet the existing inclusion criteria, even though it is conceivable that > they would issue certificates to the public in the future. > > * There are potential applicants for CA status who deploy a large number of > certificates, but only on their own infrastructure and for their own > domains, albeit that this infrastructure is public-facing rather than > company-internal. > > * We have numerous government CAs in the program or in the inclusion > process that only intend to issue certificates to their own institutions. > > * We have at least one CA applying for the program that (at least, it has > been reported in the press) is controlled by an entity which may wish to > use it for MITM. > > There are many potential options for resolving this issue. Ideally, we > would like to establish some objective criteria that can be measured and > applied fairly. It’s possible that this could require us to define > different categories of CAs, each with different inclusion criteria. Or it > could be that we should remove the existing ‘relevance’ requirement and > inclusion guidelines and accept any applicant who can meet all of our other > requirements. > > With this background, I would like to encourage everyone to provide > constructive input on this topic. > > Thanks, > > Wayne > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Updating Root Inclusion Criteria
Wayne, I support "encouraging" those who are currently using the public web PKI for internal uses to move to their own private PKIs. The current situation is an artifact of the old notion that there should be a global "One CA List to Rule Them All" owned by the operating system, and everyone should use that. That notion is a bit antiquated, in my mind. Applications and components that need a trust list really need to carefully select (or create!) an appropriate one instead of just grabbing the most convenient one. I'm familiar with a few efforts in the financial space to transition away from browser trust lists for non-browser TLS, but as you can imagine, that's not a trivial effort and will take some time. My only request would be that if the rules are going to change, that large companies and entire industries that may be affected be given enough notice to be able to come up with reasonable transition plans. -Tim > -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne > Thayer via dev-security-policy > Sent: Tuesday, January 16, 2018 4:46 PM > To: mozilla-dev-security-policy > > Subject: Updating Root Inclusion Criteria > > I would like to open a discussion about the criteria by which Mozilla decides > which CAs we should allow to apply for inclusion in our root store. > > Section 2.1 of Mozilla’s current Root Store Policy states: > > CAs whose certificates are included in Mozilla's root program MUST: > > 1.provide some service relevant to typical users of our software > > products; > > > > Further non-normative guidance for which organizations may apply to the CA > program is documented in the ‘Who May Apply’ section of the application > process at https://wiki.mozilla.org/CA/Application_Process . The original > intent of this provision in the policy and the guidance was to discourage a > large > number of organizations from applying to the program solely for the purpose > of avoiding the difficulties of distributing private roots for their own > internal > use. > > Recently, we’ve encountered a number of examples that cause us to question > the usefulness of the currently-vague statement(s) we have that define which > CAs to accept, along a number of different axes: > > * Visa is a current program member that has an open request to add another > root. They only issue a relatively small number of certificates per year to > partners and for internal use. They do not offer certificates to the general > public or to anyone with whom they do not have an existing business > relationship. > > * Google is also a current program member, admitted via the acquisition of an > existing root, but does not currently, to the best of our knowledge, meet the > existing inclusion criteria, even though it is conceivable that they would > issue > certificates to the public in the future. > > * There are potential applicants for CA status who deploy a large number of > certificates, but only on their own infrastructure and for their own domains, > albeit that this infrastructure is public-facing rather than company-internal. > > * We have numerous government CAs in the program or in the inclusion > process that only intend to issue certificates to their own institutions. > > * We have at least one CA applying for the program that (at least, it has been > reported in the press) is controlled by an entity which may wish to use it for > MITM. > > There are many potential options for resolving this issue. Ideally, we would > like > to establish some objective criteria that can be measured and applied fairly. > It’s > possible that this could require us to define different categories of CAs, > each > with different inclusion criteria. Or it could be that we should remove the > existing ‘relevance’ requirement and inclusion guidelines and accept any > applicant who can meet all of our other requirements. > > With this background, I would like to encourage everyone to provide > constructive input on this topic. > > Thanks, > > Wayne > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy