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: TLS-SNI-01 and compliance with BRs

2018-01-18 Thread J.C. Jones via dev-security-policy
That would be the right place. At the time there was not universal desire
for these validation mechanisms to be what I'd call 'fully specified'; the
point of having them written this way was to leave room for individuality
in meeting the requirements.

Of course, having a few carefully-specified-and-validated mechanisms
instead of individuality has worked rather well for other security-critical
operations, like the very transport security this whole infrastructure
exists to support. Perhaps that argument could be re-opened.

J.C.


On Thu, Jan 18, 2018 at 3:25 PM, Matthew Hardeman 
wrote:

>
>
> On Thu, Jan 18, 2018 at 4:14 PM, J.C. Jones via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> As one of the authors of 3.2.2.4.10, Alex's logic is exactly how we walked
>> through it in the Validation Working Group. The ADN lookup is DNS, and
>> what
>> you find when you connect there via TLS, within the certificate, should be
>> the random value (somewhere). 3.2.2.4.10 was written to permit ACME's
>> TLS-SNI-01 while being generic enough to permit CAs to accomplish the same
>> general validation structure without following the ACME-specified
>> algorithm.
>>
>> J.C.
>
>
> I would presume that the CABforum would be the place to explore further
> details, but it seems that the specifications for the #10 method should be
> reexamined as to what assurances they actually provide with a view to
> revising those specifications.  At least 1 CA so far has found that the
> real world experience of a (presumably) compliant application of method #10
> as it exists today was deficient in mitigating the provision of
> certificates to incorrect/unauthorized parties.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: TLS-SNI-01 and compliance with BRs

2018-01-18 Thread J.C. Jones via dev-security-policy
As one of the authors of 3.2.2.4.10, Alex's logic is exactly how we walked
through it in the Validation Working Group. The ADN lookup is DNS, and what
you find when you connect there via TLS, within the certificate, should be
the random value (somewhere). 3.2.2.4.10 was written to permit ACME's
TLS-SNI-01 while being generic enough to permit CAs to accomplish the same
general validation structure without following the ACME-specified algorithm.

J.C.

On Thu, Jan 18, 2018 at 1:47 PM, Alex Gaynor via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01
> performs a DNS lookup for the ADN, connects to that IP, and initiatives a
> TLS connection with the .acme.invalid SNI value.
>
> Certificates don't exist on Domain Names if we think really hard about it,
> but servers with IPs that domain names point to can serve certificates, and
> that seems like a reasonable interpretation of the intent of that sentence,
> which TLS-SNI-01 fulfills.
>
> Alex
>
> On Thu, Jan 18, 2018 at 3:43 PM, Doug Beattie via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Now that I'm more familiar with method 9 and 10 domain validation methods
> > and heard a few side discussions about the topic, it's made me (and
> others)
> > wonder if the ACME TLS-SNI-01 is compliant with BR Method 10.
> >
> > The BRs say:
> > 3.2.2.4.10. TLS Using a Random Number
> > Confirming the Applicant's control over the FQDN by confirming the
> > presence of a Random Value within a Certificate on the Authorization
> Domain
> > Name which is accessible by the CA via TLS over an Authorized Port.
> >
> > But it's my understanding that the CA validates the presence of the
> random
> > number on "random.acme.invalid" and not on the ADN specifically.  Is the
> > validation done by confirming the presence of a random number within the
> > certificate on the ADN, or some other location?  I'm probably misreading
> > the ACME spec, but is sure seems like the validation is not being done on
> > the ADN.
> >
> > Doug
> >
> > ___
> > 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: TLS-SNI-01 and compliance with BRs

2018-01-18 Thread Matthew Hardeman via dev-security-policy
The trouble is that the BRs for those methods are really really vague.

I don't know that one can make a stronger case for misissuance versus
properly issued in these cases.

I'm certainly no fan of the mechanism in TLS-SNI-01 and regard it deficient
in the face of real world deployment circumstances.  Clearly Let's Encrypt
does too, for why else would they have disabled the mechanism?

If we assume a world with more complex infrastructure, the case can be made
that they're not attaching to the authorization domain name, because they
failed to submit that name via SNI to the endpoint to which they are
attached, which may cause the validation to be routed incorrectly within
certain more complex hosting architectures.  On the other hand, they did
access the right IP address via DNS lookup to the correct target
authorization domain name, meaning they're talking to the right endpoint at
the IP layer.

Nothing in the BRs makes clear what would be a correct interpretation.
It's hard to imagine that one could not defend that "on the Authorization
Domain Name" via TLS over an Authorized Port means no more than at an IP
address discovered as an A or  record after having dereferenced the
authorization domain name as necessary via typical DNS resolution rules
(allowing for CNAME, etc.) on port 443.

Nowhere within the BRs is it formally specified that the TLS session over
which this validation is taking place need to even implement SNI (an
optional feature) much less that there should be regard for the value.

Having said all that, and having read the very limited specifications of
the 10 blessed methods, I have, as an outsider looking in, arrived at the
conclusion that each and every of these methods is ridiculously
underspecified.  I'm convinced that each of the 10 should be scrutinized
thoroughly before being discarded or in the alternative formally specified
in egregious detail, such that questions such as this one may not be
raised.

On Thu, Jan 18, 2018 at 3:46 PM, Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> The point is, you don’t really connect to the Certificate on the
> Authorization Domain Name, you connect to a certificate on the same IP
> address as the ADN, but you actually intentionally ask for a different
> server name, which has no relationship to the ADN (except they happen to
> share the same IP address).  It seems like misissuance to me.
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: TLS-SNI-01 and compliance with BRs

2018-01-18 Thread Alex Gaynor via dev-security-policy
I guess it depends how you define "Certificate on the ADN" -- TLS-SNI-01
performs a DNS lookup for the ADN, connects to that IP, and initiatives a
TLS connection with the .acme.invalid SNI value.

Certificates don't exist on Domain Names if we think really hard about it,
but servers with IPs that domain names point to can serve certificates, and
that seems like a reasonable interpretation of the intent of that sentence,
which TLS-SNI-01 fulfills.

Alex

On Thu, Jan 18, 2018 at 3:43 PM, Doug Beattie via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Now that I'm more familiar with method 9 and 10 domain validation methods
> and heard a few side discussions about the topic, it's made me (and others)
> wonder if the ACME TLS-SNI-01 is compliant with BR Method 10.
>
> The BRs say:
> 3.2.2.4.10. TLS Using a Random Number
> Confirming the Applicant's control over the FQDN by confirming the
> presence of a Random Value within a Certificate on the Authorization Domain
> Name which is accessible by the CA via TLS over an Authorized Port.
>
> But it's my understanding that the CA validates the presence of the random
> number on "random.acme.invalid" and not on the ADN specifically.  Is the
> validation done by confirming the presence of a random number within the
> certificate on the ADN, or some other location?  I'm probably misreading
> the ACME spec, but is sure seems like the validation is not being done on
> the ADN.
>
> Doug
>
> ___
> 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


TLS-SNI-01 and compliance with BRs

2018-01-18 Thread Doug Beattie via dev-security-policy
Now that I'm more familiar with method 9 and 10 domain validation methods and 
heard a few side discussions about the topic, it's made me (and others) wonder 
if the ACME TLS-SNI-01 is compliant with BR Method 10.

The BRs say:
3.2.2.4.10. TLS Using a Random Number
Confirming the Applicant's control over the FQDN by confirming the presence of 
a Random Value within a Certificate on the Authorization Domain Name which is 
accessible by the CA via TLS over an Authorized Port.

But it's my understanding that the CA validates the presence of the random 
number on "random.acme.invalid" and not on the ADN specifically.  Is the 
validation done by confirming the presence of a random number within the 
certificate on the ADN, or some other location?  I'm probably misreading the 
ACME spec, but is sure seems like the validation is not being done on the ADN.

Doug

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


Re: Updating Root Inclusion Criteria

2018-01-18 Thread Alex Gaynor via dev-security-policy
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

2018-01-18 Thread Ryan Sleevi via dev-security-policy
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 

RE: Updating Root Inclusion Criteria

2018-01-18 Thread Tim Hollebeek via dev-security-policy
> 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

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

2018-01-18 Thread Jonathan Rudenberg via dev-security-policy

> 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

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

2018-01-18 Thread Ryan Sleevi via dev-security-policy
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

2018-01-18 Thread Ryan Sleevi via dev-security-policy
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: Camerfirma's misissued certificate

2018-01-18 Thread Juan Angel Martin (AC Camerfirma) via dev-security-policy
Hi Rob,

We've some costumers that really appreciates that we include them.

But I can also tell you that you are absolutely right and now we're studying to 
modify this parameter in our OCSP.

Thanks a lot
Juan Angel

-Mensaje original-
De: Rob Stradling [mailto:rob.stradl...@comodo.com] 
Enviado el: jueves, 18 de enero de 2018 12:21
Para: Juan Angel Martin (AC Camerfirma) 
CC: 'Wayne Thayer' ; 'mozilla-dev-security-policy' 

Asunto: Re: Camerfirma's misissued certificate

Hi Juan.  Is there a particular technical reason why you feel the need to 
include "all the certs chaining up to the roots" in your OCSP responses?

When an OCSP response is signed directly by the CA that issued the 
corresponding certificate, the OCSP response does not need to contain any 
certificates at all.

When a CA uses an Authorized Responder, the OCSP response needs to contain 1 
certificate (i.e., the leaf cert, issued directly by the CA, that contains the 
id-kp-ocspSigning EKU OID).

I don't see any circumstance in which including >1 certificate in an OCSP 
response provides any benefit.  All it does is bloat the OCSP response 
unnecessarily.

The TLS client's certificate path validation algorithm validates the issuing 
CA.  Therefore, the OCSP response validation algorithm only needs to validate 
the OCSP response up to that issuing CA, not all the way up to the root.

On 18/01/18 07:34, Juan Angel Martin (AC Camerfirma) via dev-security-policy 
wrote:
> Hello Wayne,
> 
>   
> 
> I’ve investigated the OCSP’s issue time ago, I can tell you that it’s related 
> with https://github.com/golang/go/issues/21527 cause we send all the certs 
> chaining up to the roots.
> 
>   
> 
> BR
> 
> Juan Angel
> 
>   
> 
> De: Wayne Thayer [mailto:wtha...@mozilla.com] Enviado el: miércoles, 
> 17 de enero de 2018 19:14
> Para: martin...@camerfirma.com
> CC: mozilla-dev-security-policy 
> 
> Asunto: Re: Camerfirma's misissued certificate
> 
>   
> 
> Thank you for reporting this misissuance. Since this is a different issue 
> than described in bug 1390977, I have created a new bug to track this problem 
> and your response: https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 
> Please also post your incident report here.
> 
>   
> 
> Also, the crt.sh link above is reporting the following OCSP error for this 
> certificate: "OCSP response contains bad number of certificates" Please 
> investigate.
> 
>   
> 
> - Wayne
> 
>   
> 
>   
> 
> On Wed, Jan 17, 2018 at 9:27 AM, Juan Angel Martin via dev-security-policy 
>   > wrote:
> 
> Hello,
> 
> I have to inform you about a SSL certificate misissued. OU contains 
> non-printable control characters.
> 
> https://crt.sh/?id=305441195
> 
> It has already been revoked.
> 
> Regards
> 
> Juan Angel Martin Gomez
> AC Camerfirma
> ___
> 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
> 

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690 Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed.  If 
you have received this email in error please notify the sender by replying to 
the e-mail containing this attachment. Replies to this email may be monitored 
by COMODO for operational or business reasons. Whilst every endeavour is taken 
to ensure that e-mails are free from viruses, no liability can be accepted and 
the recipient is requested to use their own virus checking software.


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: Camerfirma's misissued certificate

2018-01-18 Thread Rob Stradling via dev-security-policy
Hi Juan.  Is there a particular technical reason why you feel the need 
to include "all the certs chaining up to the roots" in your OCSP responses?


When an OCSP response is signed directly by the CA that issued the 
corresponding certificate, the OCSP response does not need to contain 
any certificates at all.


When a CA uses an Authorized Responder, the OCSP response needs to 
contain 1 certificate (i.e., the leaf cert, issued directly by the CA, 
that contains the id-kp-ocspSigning EKU OID).


I don't see any circumstance in which including >1 certificate in an 
OCSP response provides any benefit.  All it does is bloat the OCSP 
response unnecessarily.


The TLS client's certificate path validation algorithm validates the 
issuing CA.  Therefore, the OCSP response validation algorithm only 
needs to validate the OCSP response up to that issuing CA, not all the 
way up to the root.


On 18/01/18 07:34, Juan Angel Martin (AC Camerfirma) via 
dev-security-policy wrote:

Hello Wayne,

  


I’ve investigated the OCSP’s issue time ago, I can tell you that it’s related 
with https://github.com/golang/go/issues/21527 cause we send all the certs 
chaining up to the roots.

  


BR

Juan Angel

  


De: Wayne Thayer [mailto:wtha...@mozilla.com]
Enviado el: miércoles, 17 de enero de 2018 19:14
Para: martin...@camerfirma.com
CC: mozilla-dev-security-policy 
Asunto: Re: Camerfirma's misissued certificate

  


Thank you for reporting this misissuance. Since this is a different issue than 
described in bug 1390977, I have created a new bug to track this problem and 
your response: https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 Please also 
post your incident report here.

  


Also, the crt.sh link above is reporting the following OCSP error for this certificate: 
"OCSP response contains bad number of certificates" Please investigate.

  


- Wayne

  

  


On Wed, Jan 17, 2018 at 9:27 AM, Juan Angel Martin via dev-security-policy 
 > wrote:

Hello,

I have to inform you about a SSL certificate misissued. OU contains 
non-printable control characters.

https://crt.sh/?id=305441195

It has already been revoked.

Regards

Juan Angel Martin Gomez
AC Camerfirma
___
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



--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

___
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

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

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

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

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