Re: Updating Root Inclusion Criteria (organizations)

2018-01-22 Thread Jakob Bohm via dev-security-policy 

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)

2018-01-22 Thread Gervase Markham via dev-security-policy 
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)

2018-01-19 Thread Jakob Bohm via dev-security-policy 

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)

2018-01-19 Thread Gervase Markham via dev-security-policy 
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)

2018-01-18 Thread Jakob Bohm via dev-security-policy 

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)

2018-01-18 Thread Gervase Markham via dev-security-policy 
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)

2018-01-17 Thread Jakob Bohm via dev-security-policy 

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 (organizations)

2018-01-17 Thread Peter Bowen via dev-security-policy 
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 (organizations)

2018-01-17 Thread Jakob Bohm via dev-security-policy 
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