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 (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 (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 (organizations)
On 17/01/2018 22:51, Peter Bowen wrote: On Wed, Jan 17, 2018 at 11:49 AM, Jakob Bohm via dev-security-policywrote: 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 (organizations)
On Wed, Jan 17, 2018 at 11:49 AM, Jakob Bohm via dev-security-policywrote: > 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 (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