Responses from Comodo
Gervase Markham
recently kind enough to send me the following. One important point to
note is that currently none of Comodo's "RAs" have any RA
responsibility; Comodo has taken over all the checking. This will remain
true until it is decided what the new RA rules are.
Gerv
> 1) Are the details in these "claims of responsibility" accurate?
> > http://pastebin.com/74KXCaEZ
> > http://pastebin.com/DBDqm6Km
Broadly, we believe the claims of responsibility are accurate. We note that
the attackers claim to have compromised the reseller's systems - not
Comodo's
network or systems - and we state categorically that Comodo's CA network and
CA systems have not been compromised.
> > 2) If so, is "trustdll.dll" something Comodo created, or InstantSSL?
It is something created by the reseller. The reseller also ran the site
http://www.InstantSSL.it.
The attackers claim that, once inside the reseller’s server, they
discovered the file named ‘TrustDLL.dll’. ‘TrustDLL.dll’ was not coded
by Comodo, does not run on Comodo servers, and is not maintained by
Comodo. It is solely the property of the reseller.
Comodo did not provide this DLL and we were not aware of its existence
until the attackers' claims were published.
> > 3) If your issuance system implements restrictions in some
> > cases on what domains can be issued for (e.g. for an
> > Enterprise RA issuing certificates just for their particular
> > company), in which part of the system are these
> > restrictions implemented? What checks have been done
> > to ensure they cannot be bypassed?
The restriction of an Enterprise RA to only be able to issue
certificates for
domains that have been validated to be controlled by them is implemented
within our (Comodo's) systems.
As an immediate response to this incident we have removed RA privileges from
all enterprises/partners/resellers. Any validation and checking previously
being implemented by those external partners is now being undertaken by
Comodo
internally.
This will not change until (at least) the new requirements on CAs that
we were
made aware would be forthcoming are digested and implemented by us.
Regards
Robin Alden
Comodo CA Limited
Kyle Hamilton
The scenario that Comodo didn't see coming is so blindingly obvious that I feel they have shown gross ineptitude (or gross negligence, if you prefer) in their ability to design and enforce effective internal controls.
They had their opportunities to recognize that maybe they needed to hire a security consultant to help them design their system to minimize the opportunity to exploit. If this were the first incident, I would be okay with that. After the second, I agreed that Comodo's proposed controls appeared to be solid -- but that we would have to wait and see if they were effective.
It is clear that they were not.
Just how much is your users' peace of mind worth?
-Kyle H
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
Kyle Hamilton
Stephen Schultze
> I must respectfully state my continued opposition to Comodo's continued membership in the root program.
>
> The scenario that Comodo didn't see coming is so blindingly obvious that I feel they have shown gross ineptitude (or gross negligence, if you prefer) in their ability to design and enforce effective internal controls.
I too find Comodo's public response very troubling. Just a few
examples:
1. "This is a new threat model"
They repeatedly state that nobody considered the "lone hacker,"
"government entity," or "non-fraud-oriented attack" as part of the
threat model. This seems absurd. There have been myriad discussions
in all of the relevant communities for quite some time, and papers
published on the topic. In any case, this is beside the point,
because their security practices were equally vulnerable to fraud-
oriented attacks. Nothing about the way that their RA was set up is
specific to this. Someone seeking to attack financial sites could
have just as easily taken advantage of their poor security model.
http://blogs.comodo.com/it-security/data-security/the-changing-threat-model/
2. "Username/password is the problem, but that's not our fault"
The latest Comodo Data Security Blog post says that the real problem
is that "The core weakness in the current Web authentication scheme is
that the Web browser authenticates to a Web server by passing it the
password." and "This is an unnecessary weakness in the Internet
security infrastructure and one that can be solved through some minor
changes to the SSL/HTML authentication mechanism if only we could find
the will to act." Sure, we should move toward a web authentication
system that is not u/p based, but this does indeed require some
significant work in coordination with many players. You know what
doesn't? Structuring your RA system so that a single username and
password grants the keys to the kingdom. If Comodo knew that the u/p
issue was an issue, why didn't they fix it beforehand? In their own
words, "The vulnerability of using usernames and passwords as the
basis for Internet authentication have been known for more than two
decades, as has the fact that the approach adopted in the Web world,
of delivering the password itself to a server for verification is
amongst the worst. What has been lacking until now has been the
incentive to make the necessary changes."
http://blogs.comodo.com/it-security/data-security/fixing-the-problems-1-caa/
3. "It's really a DNS problem"
Immediately following the attack, different folks at Comodo repeatedly
asserted both that this was really a problem with DNS and that the
attacker would have needed control of DNS to make use of the certs.
Neither is true. The vulnerability was clearly with their
authentication process, and a MITM could just have easily used the
certs without any DNS attack at all simply by MITM'ing on the routing
level.
http://www.eweek.com/c/a/Security/Fake-SSL-Certificate-Incident-Highlights-Flaws-in-DNS-Comodo-CEO-440985/
I have a hard time seeing this as anything other than one or all of
the following: embarrassing ignorance, intentional misrepresentation,
and CYA.
Eddy Nigg
> I have continued to seek further info from Comodo. Robin Alden was
> recently kind enough to send me the following.
Is this meant to be sarcastic or...?
> One important point to note is that currently none of Comodo's "RAs"
> have any RA responsibility; Comodo has taken over all the checking.
> This will remain true until it is decided what the new RA rules are.
Well, unfortunately something very similar is what Robin already said
more than year ago too:
https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c68
Quote:
We do still have a subset of our sales partners who are able to act
as RAs, but since this debacle over CertStar we have retrofitted our
own DV process into the RA's ordering process in the vast majority
of cases.
By 'our own DV process', I mean that Comodo performs an automated
check of domain control by sending (and confirming receipt of) an
email to an address which is either on the domain to be validated or
is explicitly mentioned in the WHOIS entry for the domain to be
validated.
So this is surely not sufficient this time.
Now, more than three weeks have past since this incident and all I'm
hearing so far is a lot of talking around all kinds of different issues,
some of them pretty unrelated. For example failures of DNS, failure of
passwords, failures of the political climate, failure of revocations,
failures of policies...
I see a lot of distraction from the core issue and it's hard to remain
focused. But I'd still like to know where Mozilla stands with all this.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Kathleen Wilson
> Well, unfortunately something very similar is what Robin already said
> more than year ago too:
> https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c68
>
> Quote:
>
> We do still have a subset of our sales partners who are able to act
> as RAs, but since this debacle over CertStar we have retrofitted our
> own DV process into the RA's ordering process in the vast majority
> of cases.
> By 'our own DV process', I mean that Comodo performs an automated
> check of domain control by sending (and confirming receipt of) an
> email to an address which is either on the domain to be validated or
> is explicitly mentioned in the WHOIS entry for the domain to be
> validated.
>
>
> So this is surely not sufficient this time.
>
> Now, more than three weeks have past since this incident and all I'm
> hearing so far is a lot of talking around all kinds of different issues,
> some of them pretty unrelated. For example failures of DNS, failure of
> passwords, failures of the political climate, failure of revocations,
> failures of policies...
>
> I see a lot of distraction from the core issue and it's hard to remain
> focused. But I'd still like to know where Mozilla stands with all this.
>
We are not currently going down the path of disabling Comodo's roots.
Our current focus is on identifying the appropriate changes, having
Comodo implement the changes, and requiring an audit of each RA before
it can be re-enabled.
Kathleen
Eddy Nigg
> We are not currently going down the path of disabling Comodo's roots.
> Our current focus is on identifying the appropriate changes, having
> Comodo implement the changes, and requiring an audit of each RA before
> it can be re-enabled.
Kathleen, how about proper action items as we know it from inclusion
requests, tracking of the defined actions and compliance thereof? I
think those items should be at least defined and publicly announced.
How does Mozilla confirm that any of the actions it currently requires
(whatever they are) are kept accordingly? How does Mozilla know that
whatever should be enabled in the future (apparently RAs after receiving
some audit statements) has been disabled in first place?
Kathleen Wilson
> On 04/11/2011 11:27 PM, From Kathleen Wilson:
>> We are not currently going down the path of disabling Comodo's roots.
>> Our current focus is on identifying the appropriate changes, having
>> Comodo implement the changes, and requiring an audit of each RA before
>> it can be re-enabled.
>
> Kathleen, how about proper action items as we know it from inclusion
> requests, tracking of the defined actions and compliance thereof? I
> think those items should be at least defined and publicly announced.
>
Yes, I agree. I will create a bug, and publicly announce it.
> How does Mozilla confirm that any of the actions it currently requires
> (whatever they are) are kept accordingly? How does Mozilla know that
> whatever should be enabled in the future (apparently RAs after receiving
> some audit statements) has been disabled in first place?
>
All good questions, which we're working on.
Kathleen
Kyle Hamilton
>
> We are not currently going down the path of disabling Comodo's roots. Our
> current focus is on identifying the appropriate changes, having Comodo
> implement the changes, and requiring an audit of each RA before it can be
> re-enabled.
>
> Kathleen
Does someone have to file a lawsuit accusing Mozilla of gross negligence and failure to act in accordance with its published policies to get Mozilla to realize that this is completely inappropriate?
You make decisions for inclusion with input from this group. You're not making decisions for exclusion with input from this group, and you're not making decisions regarding repeated, published trust failures by this single entity in accordance with your published policy.
Is this group simply smoke and mirrors to hide racketeering? It sure looks like it.
See, here's the situation: Mozilla's capacity to administer its root program for the public benefit is also on trial. Thus far it's failed to show any reason that the public should continue to be trust it with this responsibility, as evidently *repeated* failures to effectively implement effective access controls -- i.e., even multiple examples of CA incompetence isn't enough to make it wash its hands of the problem.
If Comodo wants to fix it, it needs to hire an external security consultant, completely rewrite its certification policy and certification practice statement, get audited again (by a DIFFERENT auditor, since the current one is obviously not qualified to render an opinion on security-critical operations), and then reapply to the root program.
-Kyle H
Paul van Brouwershaven
> On Mon, Apr 11, 2011 at 1:27 PM, Kathleen Wilson <kathle...@yahoo.com> wrote:
>>
>> We are not currently going down the path of disabling Comodo's roots. Our
>> current focus is on identifying the appropriate changes, having Comodo
>> implement the changes, and requiring an audit of each RA before it can be
>> re-enabled.
>>
>> Kathleen
>
> Does someone have to file a lawsuit accusing Mozilla of gross negligence and failure to act in
> accordance with its published policies to get Mozilla to realize that this is completely inappropriate?
>
> You make decisions for inclusion with input from this group. You're not making decisions for
> exclusion with input from this group, and you're not making decisions regarding repeated, published
> trust failures by this single entity in accordance with your published policy.
I agree with Kyle. For me there is way to much time spend on 'solving the system' instead of taking
responsibility and discuss the real indecent. Not the hack or a failing CA system, but Comodo that
is not doing what they should do (for years).
> Is this group simply smoke and mirrors to hide racketeering? It sure looks like it.
>
> See, here's the situation: Mozilla's capacity to administer its root program for the public benefit
> is also on trial. Thus far it's failed to show any reason that the public should continue to be
> trust it with this responsibility, as evidently *repeated* failures to effectively implement
> effective access controls -- i.e., even multiple examples of CA incompetence isn't enough to make it
> wash its hands of the problem.
>
> If Comodo wants to fix it, it needs to hire an external security consultant, completely rewrite its
> certification policy and certification practice statement, get audited again (by a DIFFERENT
> auditor, since the current one is obviously not qualified to render an opinion on security-critical
> operations), and then reapply to the root program.
And even then we haven't spoke about the possibility that there could be much more false issued
certificates out there. The sites from this and the previous incidents where all high profile sites!
What about a regular site...? Comodo RAs are able to issue certificates on there own for years and
they have been able to issue plenty of false certificates. These less outstanding (regular) websites
won't raise questions as soon as a high profile website as we have seen in the currently known
incidents.
Finally there is only one way to keep the Comodo root included and that would be revalidation every
cert that has been issued by a Comodo RA after the CPS has been rewritten and
Kind regards,
Paul van Brouwershaven
Networking4all B.V.
____________________________________________
Phone: (31) 20 7881042 Fax: (31) 20 7881040
Email: p.vanbrou...@networking4all.com
Internet: https://www.networking4all.com
LinkedIn: https://www.linkedin.com/in/pvanbrouwershaven
Facebook: https://www.facebook.com/p.vanbrouwershaven
Twitter: https://www.twitter.com/vanbroup
Jean-Marc Desperrier
> [...] even then we haven't spoke about the possibility that there could be much more false issued
> certificates out there. [...] Comodo RAs are able to issue certificates on there own for years and
> they have been able to issue plenty of false certificates.
Where is the proof that no other CA has similarly risky RA ? Would an
attacker now attack Comodo that is probably quite on the ball, or search
for another unsuspecting CA, with maybe a slightly different attack vector ?
As Michael says a little above : "One of my customers has a
fully-trusted sub-CA and the root CA with its "trusted" root CA cert did
not even read the CPS I wrote. Not to speak of an audit. They can issue
any cert they want". So does it still looks like Comodo is the one
scapegoat that must be killed to get rid of the problem fully ? Opposite
to the standard scapegoat, Comodo has indeed failed. But I still don't
believe that all evil will go away together with Comodo.
What we need to do is to define what the proper new rule about RA/sub-CA
should be for all CA. And require them all to comply to it.
In the case of such a private sub-CA as described by Michael, I think
there should be a name-constraint that allows it only to issue
certificates for it's own domain.
Moudrick M. Dadashov
I fully agree with you.
M.D.
> Paul van Brouwershaven wrote:
>> [...] even then we haven't spoke about the possibility that there could
>> be much more false issued
>> certificates out there. [...] Comodo RAs are able to issue certificates
>> on there own for years and
>> they have been able to issue plenty of false certificates.
>
> Where is the proof that no other CA has similarly risky RA ? Would an
> attacker now attack Comodo that is probably quite on the ball, or search
> for another unsuspecting CA, with maybe a slightly different attack vector
> ?
>
> As Michael says a little above : "One of my customers has a
> fully-trusted sub-CA and the root CA with its "trusted" root CA cert did
> not even read the CPS I wrote. Not to speak of an audit. They can issue
> any cert they want". So does it still looks like Comodo is the one
> scapegoat that must be killed to get rid of the problem fully ? Opposite
> to the standard scapegoat, Comodo has indeed failed. But I still don't
> believe that all evil will go away together with Comodo.
>
> What we need to do is to define what the proper new rule about RA/sub-CA
> should be for all CA. And require them all to comply to it.
>
> In the case of such a private sub-CA as described by Michael, I think
> there should be a name-constraint that allows it only to issue
> certificates for it's own domain.
Paul van Brouwershaven
> Paul van Brouwershaven wrote:
>> certificates out there. [...] Comodo RAs are able to issue certificates on there own for years and
>> they have been able to issue plenty of false certificates.
>
> that is probably quite on the ball, or search for another unsuspecting CA, with maybe a slightly
> different attack vector ?
I agree that we are not certainly that there are no other CAs that have similarly risky RA(s). By
not taking proper measures now we won't be able to do that for other CAs that misbehave. Why should
any CA now review it's policies if there are no consequences for them if they fail?
> As Michael says a little above : "One of my customers has a
> fully-trusted sub-CA and the root CA with its "trusted" root CA cert did not even read the CPS I
> wrote. Not to speak of an audit. They can issue any cert they want". So does it still looks like
> Comodo is the one scapegoat that must be killed to get rid of the problem fully ? Opposite to the
> standard scapegoat, Comodo has indeed failed. But I still don't believe that all evil will go away
> together with Comodo.
Michael, are you willing to share some more information?
> What we need to do is to define what the proper new rule about RA/sub-CA should be for all CA. And
> require them all to comply to it.
Certainly, but don't forget that Comodo agreed to change there policies the last time... and
obviously they didn't. How do you enforce the CA to comply to this rules if there are no
consequences if they don't?
Gervase Markham
> Well, unfortunately something very similar is what Robin already said
> more than year ago too:
> https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c68
>
> Quote:
>
> We do still have a subset of our sales partners who are able to act
> as RAs, but since this debacle over CertStar we have retrofitted our
> own DV process into the RA's ordering process in the vast majority
> of cases.
> By 'our own DV process', I mean that Comodo performs an automated
> check of domain control by sending (and confirming receipt of) an
> email to an address which is either on the domain to be validated or
> is explicitly mentioned in the WHOIS entry for the domain to be
> validated.
>
> So this is surely not sufficient this time.
That time, they said "the vast majority" - which turned out to be 91%,
which seems like a fair number to call a vast majority. ComodoHacker
himself said he needed to compromise 3 RAs before he found one he could
use to issue certs in the way he did.
Of course, that say something about RA security which is troubling. But
what I am commenting on here is the suggestion that Comodo did not tell
the truth back then; I think that accusation is wrong. And it is also
not right that what they said then is the same as what they are saying now.
Gerv
Gervase Markham
> Does someone have to file a lawsuit accusing Mozilla of gross negligence
> and failure to act in accordance with its published policies to get
> Mozilla to realize that this is completely inappropriate?
Presumably, Kyle, that person will also be filing lawsuits against the
other browser makers who have not taken the action your are promoting?
In fact, why not file against Opera and Safari first, as (AFAIK) they
have taken _no_ action - not even shipped a patch?
Gerv
Rob Stradling
> On 12/04/11 00:32, Kyle Hamilton wrote:
> > and failure to act in accordance with its published policies to get
> > Mozilla to realize that this is completely inappropriate?
>
> other browser makers who have not taken the action your are promoting?
> In fact, why not file against Opera and Safari first, as (AFAIK) they
> have taken _no_ action - not even shipped a patch?
Just FYI, Opera have taken action:
http://my.opera.com/rootstore/blog/2011/03/31/new-cnnic-ev-root-pubsuffix-
update-and-some-blacklisted-certificates
"In this case we have decided to follow the other browsers, and update our
Untrusted list with these certificates..."
> Gerv
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Ian G
>> In the case of such a private sub-CA as described by Michael, I think
>> there should be a name-constraint that allows it only to issue
>> certificates for it's own domain.
Can anybody think of a reason why that would not be a good idea?
iang
Gervase Markham
> http://my.opera.com/rootstore/blog/2011/03/31/new-cnnic-ev-root-pubsuffix-
> update-and-some-blacklisted-certificates
>
> "In this case we have decided to follow the other browsers, and update our
> Untrusted list with these certificates..."
Thank you; I stand corrected.
Gerv
Steve Roylance
Many organisations have multiple domains and acquire new ones related to
products periodically, so a one size fits all is always difficult to
predict up front. SubCAs are hard to change on the fly and therefore
cannot offer a level of flexibility that may be required for policy
constraints at the domain level.
Kind Regards
Steve Roylance
Business Development Director
GlobalSign
Eddy Nigg
> On 09/04/11 20:51, Eddy Nigg wrote:
>> Well, unfortunately something very similar is what Robin already said
>> more than year ago too:
>> https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c68
>>
>> Quote:
>>
>> We do still have a subset of our sales partners who are able to act
>> as RAs, but since this debacle over CertStar we have retrofitted our
>> own DV process into the RA's ordering process in the vast majority
>> of cases.
>> By 'our own DV process', I mean that Comodo performs an automated
>> check of domain control by sending (and confirming receipt of) an
>> email to an address which is either on the domain to be validated or
>> is explicitly mentioned in the WHOIS entry for the domain to be
>> validated.
>>
>> So this is surely not sufficient this time.
>
> That time, they said "the vast majority" - which turned out to be 91%,
> which seems like a fair number to call a vast majority. ComodoHacker
> himself said he needed to compromise 3 RAs before he found one he
> could use to issue certs in the way he did.
And I said that it's surely not sufficient this time. Is there anything
wrong with that?
Erwann Abalea
Because Safari and Opera always validate the certificate via OCSP and/
or CRL?
--
Erwann.
Andy Isaacson
> Many organisations have multiple domains and acquire new ones related to
> products periodically, so a one size fits all is always difficult to
> predict up front. SubCAs are hard to change on the fly and therefore
> cannot offer a level of flexibility that may be required for policy
> constraints at the domain level.
Thanks for joining the conversation, Steve.
Are you saying that issuing a new subCA signature is harder than issuing
a certificate signature? Is there a technical issue there or is it a
business process and validation issue? (Not to say the latter is less
valid, I just want to understand.)
Seems to me if a CA has vetted and approved a subCA for an enterprise
domain, it should be a fairly straightforward process (technically at
least) to issue an additional cert (for the same subCA private key) for
another related domain. It does require some additional configuration
to ensure that the appropriate cert chains are configured for each leaf
certificate, but that's doable.
Have you considered and rejected this scenario (and if so, can you
sketch the reasoning), or is this something the CAs could implement?
Would a more flexible language for encoding subCA capabilities be
helpful? I don't think it's feasible to go all the way to regex parsing
on the DNS names, nor do I think that would address the market need
you're articulating, but perhaps something could be done.
-andy
Steve Roylance
SubCAs that we use for our own product range, SubCAs that we host on
behalf of others and SubCAs that we offer to large organisations who have
the physical and logical infrastructure to meet our policies take up a
huge amount of resource to plan and implement. The offline signing
ceremony itself needs to be planned well in advance and therefore trying
to add specific domain level constraints and a more frequent ceremony to
keep up to date with any policy constraint doesn't seem feasible. In
addition if the public private key pair is used many times to 'update' the
content of a SubCA then this only means that a key compromise situation
demands multiple revocations which again adds to the complexity. Without
going into too much detail on this posting we've found that the best
position to be in is to contractually constrain usage and to mandate a
periodic audit. I've been pushing our WebTrust auditors and others in
the industry for a couple of years now in a bid to ensure maximum coverage
and no weak links so I'm very glad that this is now being discussed (I'm
just sad it's on the back of some negative press for our industry) - My
argument to our auditors has always been that if we are doing the work,
then why should we not be recognised for the work we do?
So bottom line...a higher frequency of issuance of a policy constrained
SubCA doesn't seem to be feasible as it's not scaleable offline. What's
better is the way we have been heading already with the inclusion of
SubCAs into the scope of our annual audit. That's flexible, achievable
and something we are actively pushing.
Steve
Gervase Markham
> Because Safari and Opera always validate the certificate via OCSP and/
> or CRL?
It has been noted that Opera is more strict about this, and that they
have also shipped an update. However, according to
http://www.imperialviolet.org/2011/03/18/revocation.html
Safari shows no difference when revocation fails.
Gerv
Gervase Markham
> So bottom line...a higher frequency of issuance of a policy constrained
> SubCA doesn't seem to be feasible as it's not scaleable offline. What's
> better is the way we have been heading already with the inclusion of
> SubCAs into the scope of our annual audit. That's flexible, achievable
> and something we are actively pushing.
How about a position which said: OK, you have two options for your SubCAs:
1) Name constraints to owned domains, no audit, you can keep their
identity private
2) Inclusion in audit, no name constraints necessary, publication of
identity
And you could pick whichever model suited a given situation best?
Gerv
Steve Schultze
+1
I still see no reason why Mozilla or its users benefit from undisclosed
Sub-CAs, but given that you have shown a willingness to bend to CA
wishes, this seems like a reasonable compromise. The potential damage
due to a non-disclosed domain-constrained Sub-CA seems to be of much
lower magnitude.
Kyle Hamilton
On Tue, Apr 12, 2011 at 2:59 AM, Jean-Marc Desperrier <jmd...@gmail.com> wrote:
>
> As Michael says a little above : "One of my customers has a
> fully-trusted sub-CA and the root CA with its "trusted" root CA cert did not
> even read the CPS I wrote. Not to speak of an audit. They can issue any cert
> they want". So does it still looks like Comodo is the one scapegoat that
> must be killed to get rid of the problem fully ? Opposite to the standard
> scapegoat, Comodo has indeed failed. But I still don't believe that all evil
> will go away together with Comodo.
No, it won't.
But the rest of the CAs would see that Mozilla's actually willing to use its only blunt-force trauma-inducing weapon against the people who don't deserve to be trusted by it or the public.
Can anyone, but particularly Kathleen or Gerv or Rob, explain how keeping Comodo in the root program after its repeated failures to exercise due diligence could even remotely be in the end user's interest?
-Kyle
Ian G
> Can anyone, but particularly Kathleen or Gerv or Rob, explain how
> keeping Comodo in the root program after its repeated failures to
> exercise due diligence could even remotely be in the end user's interest?
Sure. It's standard management calculations. It's common or garden
risk management, if you want to put a sexy label on it. Take the two
options and calculate the costs:
Option 1. Keep Comodo. Cost?
* red faces at Comodo, generally booked as "brand" or "goodwill"
* lots of additional "compliance" work...
* lost time by lots of listmongers, Mozilla, Microsoft, etc,
* The lone Iranian-crypto-jihadist gets a giggle (negative loss)
(There is a possibility that we could calculate in expected future
losses to customers who've been breached... but that's hard because
we've never had a customer loss due to crypto, and this takes us into
Geer's law.)
Option 2. Dump Comodo. Cost?
* X,000 customers lose their certs and accounts. Cost to businesses
of putting in new certs is typically O($1000). Multiply that by number
of businesses that need to switch. Add the premium.
* Loss of business by those businesses as their sites go into "you
don't trust this site" mode. Dunno how to calculate that.
* Loss of Comodo (bankrupcy, think Enron and Arthur Anderson).
* all those Y,000 resellers. calculate & mutiply.
Dumping Comodo is by far the greater cost. No way around that. Even if
they are run by Satan and they eat little children for breakfast,
consigning them to the meatgrinder is not a net benefit.
Remember the old joke about banking? Well, it's like this: if the CA
has 1000 certs on issue, and gets breached, the CA has a problem. If
the CA has a million certs on issue, then we've got a problem.
iang
Eddy Nigg
> Option 1. Keep Comodo. Cost?
>
> * red faces at Comodo, generally booked as "brand" or "goodwill"
> * lots of additional "compliance" work...
> * lost time by lots of listmongers, Mozilla, Microsoft, etc,
> * The lone Iranian-crypto-jihadist gets a giggle (negative loss)
>
Well, we could add some additional costs which are probably hard to
measure. For example damage to the entire industry, possible damage due
to previous and future wrongful issuance, damage to the browser vendors
standing, etc.
> Dumping Comodo is by far the greater cost. No way around that. Even
> if they are run by Satan and they eat little children for breakfast,
> consigning them to the meatgrinder is not a net benefit.
>
Actually this should be a nice spectacle to watch, specially the part
with the meatgrinder sounds interesting ;-)
Gervase Markham
> Can anyone, but particularly Kathleen or Gerv or Rob, explain how
> keeping Comodo in the root program after its repeated failures to
> exercise due diligence could even remotely be in the end user's interest?
One reason is that because "the end-user" probably would not like it if
10% of the SSL web broke overnight. And neither would the businesses who
use their roots. Disabling a CA's root does not just affect that CA.
If we had the ability to disable a root certificate only for end-entity
certificates issued after a certain termination date, then we could
disable a root on an ongoing basis without breaking the entire web. In
other words, disabling that root would affect only the CA, and their
capability to continue to issue. This ability was, you may have noticed,
on the short-term priority list recently posted.
Gerv
Eddy Nigg
> One reason is that because "the end-user" probably would not like it
> if 10% of the SSL web broke overnight. And neither would the
> businesses who use their roots. Disabling a CA's root does not just
> affect that CA.
>
Gerv, that was the lamest response I've heard on this issue. I mean, all
a CA has to do is getting a sufficient market share (how much is enough?
is 6% sufficient too) and just every failure will get through.
I think that there are considerations that can lead to that decision
most likely depending on the severity and added requirements placed upon
the CA if necessary. But market share and braking certs from a CA are
more important than the relying parties who have to rely on it and can't?
Something smells foul here...I think a Mozilla should come up with a
better explanation. Also I think it's time that the action items and
requirements be put in place as Kathleen already note she'll do. The
responses should come forward more swiftly in my opinion.
Ian G
> On 04/14/2011 02:05 PM, From Ian G:
>>
>> * red faces at Comodo, generally booked as "brand" or "goodwill"
>> * lots of additional "compliance" work...
>> * lost time by lots of listmongers, Mozilla, Microsoft, etc,
>> * The lone Iranian-crypto-jihadist gets a giggle (negative loss)
>>
>
> measure. For example damage to the entire industry, possible damage due
> to previous and future wrongful issuance, damage to the browser vendors
> standing, etc.
Yep! As I've frequently said, *reputation* is practically the only
lever that Mozilla has to enforce.
Hence, suggestions to put the name of the CA on the chrome, so that the
end-user sees who the CA is that is causing the problem. Then, CAs have
an incentive to act positively.
Right now, they all have an incentive to act badly. The structure of
the industry is the famous race to the bottom (with occasional but
temporary lift ups by regulation).
Reputation gives them a reason to reverse that.
>> Dumping Comodo is by far the greater cost. No way around that. Even if
>> they are run by Satan and they eat little children for breakfast,
>> consigning them to the meatgrinder is not a net benefit.
>>
>
> Actually this should be a nice spectacle to watch, specially the part
> with the meatgrinder sounds interesting ;-)
:) Perhaps Mozilla should request and hold shares in the CAs. Then it
can buy and sell them to manipulate the reputation on the market ;-)
iang
Kyle Hamilton
On Thu, Apr 14, 2011 at 4:05 AM, Ian G <ia...@iang.org> wrote:
> On 14/04/11 6:13 PM, Kyle Hamilton wrote:
>
>> Can anyone, but particularly Kathleen or Gerv or Rob, explain how
>> keeping Comodo in the root program after its repeated failures to
>> exercise due diligence could even remotely be in the end user's interest?
>
> management, if you want to put a sexy label on it. Take the two options and
> calculate the costs:
The cost is to the businesses which purchased certificates from Comodo. Not the end-user (unless Mozilla takes this action around September, impacting Christmas shopping).
> Remember the old joke about banking? Well, it's like this: if the CA has
> 1000 certs on issue, and gets breached, the CA has a problem. If the CA has
> a million certs on issue, then we've got a problem.
But no, the state identity was all we were ever going to need, so that's all that Netscape's engineers allowed us to have. The IETF all but rubber-stamped their proposals.
This has led to a situation where some CAs have evidently become "too big to fail", with no effective check on their abuses of the system.
-Kyle H
Ian G
>
>
> On Thu, Apr 14, 2011 at 4:05 AM, Ian G <ia...@iang.org> wrote:
>> On 14/04/11 6:13 PM, Kyle Hamilton wrote:
>>
>>> Can anyone, but particularly Kathleen or Gerv or Rob, explain how
>>> keeping Comodo in the root program after its repeated failures to
>>> exercise due diligence could even remotely be in the end user's
>>> interest?
>>
>> Sure. It's standard management calculations. It's common or garden risk
>> management, if you want to put a sexy label on it. Take the two
>> options and
>> calculate the costs:
>
> That's not a statement of "it's in the best interest of the end-user".
> That's an orthogonal argument which doesn't apply to the question.
>
> The cost is to the businesses which purchased certificates from Comodo.
> Not the end-user (unless Mozilla takes this action around September,
> impacting Christmas shopping).
Well, I'm not sure I see your point. Keeping Comodo keeps hundreds of
thousands users in the green -- websites and their users, they are both
there to be considered as important parties. Dropping Comodo drops all
those users in the deep mucky brown stuff.
On the other hand, there is a sort of apocyliptic claim that this one
breach has caused some costs to users. Yes, in that the websites who
got false certs issued might be scratching their heads ... but not a lot
that is measurable.
Nobody's lost money. And even if we see lost money, it will be in the
vicinity of $1000 to $100,000. Far less than the alternative.
It's a clear win.
Which raises very harsh philosophical questions for those that believe
in the perfect security of the CA business. Wnat to do?
>> Remember the old joke about banking? Well, it's like this: if the CA
>> has
>> 1000 certs on issue, and gets breached, the CA has a problem. If the
>> CA has
>> a million certs on issue, then we've got a problem.
>
> If the system had been designed properly for the simultaneous provision
> and assertion of multiple credential chains from the beginning, there
> wouldn't be a problem here. Comodo's customers would have been able to
> purchase verification services from multiple CAs and mitigate the risk.
Yes, could be. Why was it designed to be so dependent on a single point
of failure?
> But no, the state identity was all we were ever going to need, so that's
> all that Netscape's engineers allowed us to have. The IETF all but
> rubber-stamped their proposals.
Yeah, "whatever"... there were a dozen interests at the time competing
to design what they wanted. End-users weren't among them, as always.
> This has led to a situation where some CAs have evidently become "too
> big to fail", with no effective check on their abuses of the system.
Yes. The term of art is "brittle."
A race to 2B2F as they say these days in the finance world, and a race
to bad behaviour. Bad mix. What to do?
iang
Kyle Hamilton
On Thu, Apr 14, 2011 at 8:05 PM, Ian G <ia...@iang.org> wrote:
>> The cost is to the businesses which purchased certificates from Comodo.
>> Not the end-user (unless Mozilla takes this action around September,
>> impacting Christmas shopping).
>
> Well, I'm not sure I see your point. Keeping Comodo keeps hundreds of
> thousands users in the green -- websites and their users, they are both
> there to be considered as important parties. Dropping Comodo drops all
> those users in the deep mucky brown stuff.
> On the other hand, there is a sort of apocyliptic claim that this one breach
> has caused some costs to users. Yes, in that the websites who got false
> certs issued might be scratching their heads ... but not a lot that is
> measurable.
>
> Nobody's lost money. And even if we see lost money, it will be in the
> vicinity of $1000 to $100,000. Far less than the alternative.
>
> It's a clear win.
> Which raises very harsh philosophical questions for those that believe in
> the perfect security of the CA business. Wnat to do?
However, there's a difference between "imperfectly secure" and "grossly incompetent".
I do not trust Comodo. It's that simple.
>
>>> Remember the old joke about banking? Well, it's like this: if the CA
>>> has
>>> 1000 certs on issue, and gets breached, the CA has a problem. If the
>>> CA has
>>> a million certs on issue, then we've got a problem.
>>
>> If the system had been designed properly for the simultaneous provision
>> and assertion of multiple credential chains from the beginning, there
>> wouldn't be a problem here. Comodo's customers would have been able to
>> purchase verification services from multiple CAs and mitigate the risk.
>
> Yes, could be. Why was it designed to be so dependent on a single point of
> failure?
X.509 (and X.500) are -perfectly- designed, for their precise sphere: treaty-mandated interactions between sovereign states. The sovereign state doesn't care if you're a banker or a rockstar, it cares that it knows exactly whose problem you are.
The overarching design seems to have been built with the idea "If we can't let the state read it, we at the very least must let the state know who one side of the conversation is.
>> This has led to a situation where some CAs have evidently become "too
>> big to fail", with no effective check on their abuses of the system.
>
>
> Yes. The term of art is "brittle."
>
> A race to 2B2F as they say these days in the finance world, and a race to
> bad behaviour. Bad mix. What to do?
There is no security in the current system.
-Kyle H
Kyle Hamilton
On Thu, Apr 14, 2011 at 8:50 AM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 04/14/2011 04:39 PM, From Gervase Markham:
>>
>> One reason is that because "the end-user" probably would not like it if
>> 10% of the SSL web broke overnight. And neither would the businesses who use
>> their roots. Disabling a CA's root does not just affect that CA.
>>
>
> Gerv, that was the lamest response I've heard on this issue. I mean, all a
> CA has to do is getting a sufficient market share (how much is enough? is 6%
> sufficient too) and just every failure will get through.
+1
> I think that there are considerations that can lead to that decision most
> likely depending on the severity and added requirements placed upon the CA
> if necessary. But market share and braking certs from a CA are more
> important than the relying parties who have to rely on it and can't?
>
> Something smells foul here...I think a Mozilla should come up with a better
> explanation. Also I think it's time that the action items and requirements
> be put in place as Kathleen already note she'll do. The responses should
> come forward more swiftly in my opinion.
So, what's the contact information for the Mozilla Foundation? Maybe physical letters to the board will get more response.
-Kyle H
Kyle Hamilton
On Thu, Apr 14, 2011 at 6:39 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 14/04/11 09:13, Kyle Hamilton wrote:
>>
>> Can anyone, but particularly Kathleen or Gerv or Rob, explain how
>> keeping Comodo in the root program after its repeated failures to
>> exercise due diligence could even remotely be in the end user's interest?
>
> of the SSL web broke overnight. And neither would the businesses who use
> their roots. Disabling a CA's root does not just affect that CA.
In other words, "usability trumps security".
> If we had the ability to disable a root certificate only for end-entity
> certificates issued after a certain termination date, then we could disable
> a root on an ongoing basis without breaking the entire web.
No. If Firefox had the ability to interpret multiple certificate chains, the site owners would be able to manage their risks with multiple CAs' services.
> In other words,
> disabling that root would affect only the CA, and their capability to
> continue to issue. This ability was, you may have noticed, on the short-term
> priority list recently posted.
The short-term priority list needs to be:
Implement a cross-certifying CA, and let it put UserNotice text in its certification chains that the browser actually displays to the user, describing that the root is pending deactivation and that the owner of the site needs to find a different CA.
You're the PKI experts, so you would have us in this group believe -- you created the first ubiquitously-available PKI implementation on the Internet (since PGP didn't gain ubiquitous traction). You know what PKI has historically been able to do, and you know what your software hasn't ever been able to guarantee to the sovereign citizen.
Seriously, has Mozilla ever even -tried- to understand the impedance mismatch between what Mozilla claims to provide and what the individual citizen actually needs?
-Kyle H
Ian G
> On 04/14/2011 04:39 PM, From Gervase Markham:
>> if 10% of the SSL web broke overnight. And neither would the
>> businesses who use their roots. Disabling a CA's root does not just
>> affect that CA.
>>
>
> a CA has to do is getting a sufficient market share (how much is enough?
> is 6% sufficient too) and just every failure will get through.
Exactly.
> I think that there are considerations that can lead to that decision
> most likely depending on the severity and added requirements placed upon
> the CA if necessary. But market share and braking certs from a CA are
> more important than the relying parties who have to rely on it and can't?
*Market share is the parties* ... right? The problem is whether we can
separate out the interests of some RPs and ignore the interests of
others. Not easy, expecially with no evidence of losses.
> Something smells foul here...
Not a new comment ...
iang
Ian G
>
>
> On Thu, Apr 14, 2011 at 8:05 PM, Ian G <ia...@iang.org> wrote:
>>> The cost is to the businesses which purchased certificates from Comodo.
>>> Not the end-user (unless Mozilla takes this action around September,
>>> impacting Christmas shopping).
>>
>> Well, I'm not sure I see your point. Keeping Comodo keeps hundreds of
>> thousands users in the green -- websites and their users, they are both
>> there to be considered as important parties. Dropping Comodo drops all
>> those users in the deep mucky brown stuff.
>
> Yes, it does. The blame lies on the IETF (nee Netscape) for not allowing
> multiple credential chains to be asserted in the handshake.
Blame!
Well, here's a list, and the IETF doesn't even make the top 10 :)
http://financialcryptography.com/mt/archives/000609.html
>> On the other hand, there is a sort of apocyliptic claim that this one
>> breach
>> has caused some costs to users. Yes, in that the websites who got false
>> certs issued might be scratching their heads ... but not a lot that is
>> measurable.
>>
>> Nobody's lost money. And even if we see lost money, it will be in the
>> vicinity of $1000 to $100,000. Far less than the alternative.
>>
>> It's a clear win.
>
> The real losers are the people who are scared off of online shopping,
> and the shops they'd normally buy from.
Yes, it's also possible to look at the fear in the users as to shopping
at all.
But's very hard to isolate the factors. Is it that CA? Is it phishing?
Is it the media, which feeds them constant scare stories? The USG
which wants its budget for cyberwar? Is it identity fraud in the large,
which is 10 times larger than Internet based fraud? Or?
>> Which raises very harsh philosophical questions for those that believe in
>> the perfect security of the CA business. Wnat to do?
>
> I'm perfectly willing to accept that the CA business isn't completely
> secure. As Verisign showed in the incorrect TLD instance, even the
> people who do it well make mistakes.
>
> However, there's a difference between "imperfectly secure" and "grossly
> incompetent".
>
> I do not trust Comodo. It's that simple.
Sure, and opinions like that will happen. Lots here agree with you.
But opinions don't change the buck.
>>>> Remember the old joke about banking? Well, it's like this: if the CA
>>>> has
>>>> 1000 certs on issue, and gets breached, the CA has a problem. If the
>>>> CA has
>>>> a million certs on issue, then we've got a problem.
>>>
>>> If the system had been designed properly for the simultaneous provision
>>> and assertion of multiple credential chains from the beginning, there
>>> wouldn't be a problem here. Comodo's customers would have been able to
>>> purchase verification services from multiple CAs and mitigate the risk.
>>
>> Yes, could be. Why was it designed to be so dependent on a single
>> point of
>> failure?
>
> Because the IETF's cryptography groups were staffed with people who were
> so used to having to live under ITAR and EAR that they unconsciously
> ducked their heads even though the roof had been blown off? I truly
> could not say.
Yes, there was a desire in the old days in the IETF for designing in
every mode and algorithm and choice and freedom they could think of.
This resulted in woefully bad engineering; the funny example of this is
MD5. For all the apparent algorithm agility that SSL was designed to
cope with, it got caught out by a 1990s algorithm that we'd all given up
on by around 1995 when SHA1 came out.
It was out of this mess -- crypto-agility as a religion -- that I
started the counter-cause: there is only one mode, and it is secure.
And, the One True CipherSuite. Design for the one. Replace the lot.
> X.509 (and X.500) are -perfectly- designed, for their precise sphere:
> treaty-mandated interactions between sovereign states. The sovereign
> state doesn't care if you're a banker or a rockstar, it cares that it
> knows exactly whose problem you are.
>
> The overarching design seems to have been built with the idea "If we
> can't let the state read it, we at the very least must let the state
> know who one side of the conversation is.
That's a fair characterisation. I wouldn't go so far as to say that the
state intended it ... but it was pretty clear that the reason that the
PKI design was brittle was because the telcos imagined themselves as
perfectly competent deliverers of product (remember, the phone market in
the 1980s was characterised by perfect quality and 100% reliability.
Switches were designed to cope with 36 hour power outages, etc).
So brittleness wasn't a problem for them, in fact it was a boon (cf.
Porter's 5 forces).
Meanwhile, the Internet was designed to break. That's why it was so
successful. The retries were pushed up to layer 9, the mind, and
permission was explicitly written out because to include
permission-to-connect would have immediately bought the telcos &
regulation in...
And this can also be seen in VoIP which broke the quality goal of the
telcos. The telcos couldn't reconfigure to face VoIP because that meant
they'd also have to break their own quality goal. So they slowly lost
revenue to people who wanted to pay less for a poorer quality service.
Now Skype is the biggest deliverer of mobile minutes in the world...
Unreliable minutes :)
Anyway, enough of history :)
>>> This has led to a situation where some CAs have evidently become "too
>>> big to fail", with no effective check on their abuses of the system.
>>
>>
>> Yes. The term of art is "brittle."
>>
>> A race to 2B2F as they say these days in the finance world, and a race to
>> bad behaviour. Bad mix. What to do?
>
> Show that as sovereign individuals, we expect a certain amount of
> competence and diligence from the people we trust?
Right. But it's the net. No such polite expectation works. Telcos
didn't have to deal with lone iranian crypto-jihadists or poor-quality
upstarts. An expectation of perfect delivery ("competence and
diligence") simply doesn't work.
It's more like open competition, where companies fight and joust for
advantage. Companies go broke. Mistakes happen all the time.
Competition leads us to the better practices.
> There is no security in the current system.
There is no security in a system that cannot evolve.
Enuf preaching to the choir :)
iang
Gervase Markham
> Gerv, that was the lamest response I've heard on this issue. I mean, all
> a CA has to do is getting a sufficient market share (how much is enough?
> is 6% sufficient too) and just every failure will get through.
No, that's not true. But it's being wilfully blind to deny that the
ubiquity of the root affects the cost-benefit analysis.
It's very easy for people in this group to shout "pull the root, pull
the root" - they don't have to deal with the enormous ramifications. The
tens of thousands of customers of the CA (as in, website owners) do.
We want to get to a place where we can make that decision in a way that
affects only the CA. And soon, we will be there.
Gerv
Gervase Markham
> So, what's the contact information for the Mozilla Foundation? Maybe
> physical letters to the board will get more response.
You can write to the Foundation at the address on this page given for
DMCA notices:
http://www.mozilla.com/en-US/about/legal.html
I suggest addressing the envelope to "The Board of the Mozilla
Foundation, 650 ...".
Gerv
Gervase Markham
>> One reason is that because "the end-user" probably would not like it
>> if 10%
>> of the SSL web broke overnight. And neither would the businesses who use
>> their roots. Disabling a CA's root does not just affect that CA.
>
> In other words, "usability trumps security".
This is not a game of cards. There is a cost-benefit analysis. The way
you make a course of action more possible is by reducing its costs
and/or increasing its benefits.
It's ironic, really - people argue for systems which alert a user when
the site's certificate changes, and the same people argue for an action
which would cause hundreds of thousands of certificates to change very
rapidly, and they claim that users would still be able to make sane
trust decisions in a TOFU/SSH model.
> No. If Firefox had the ability to interpret multiple certificate chains,
> the site owners would be able to manage their risks with multiple CAs'
> services.
You, and the people who argue that the CAs are all a cartel, and
certificates are too expensive, need to get together and work a story
out, because I'm not sure that group would be particularly happy if we
suggested that site owners had to pay two or more CAs, instead of one,
in order to have a cert which was safe from the risk of suddenly not
working.
Gerv
Eddy Nigg
> On 14/04/11 16:50, Eddy Nigg wrote:
>> Gerv, that was the lamest response I've heard on this issue. I mean, all
>> a CA has to do is getting a sufficient market share (how much is enough?
>> is 6% sufficient too) and just every failure will get through.
>
> No, that's not true. But it's being wilfully blind to deny that the
> ubiquity of the root affects the cost-benefit analysis.
Well, there is also compliance to policies and requirements. If I'd rate
everything on this basis, I guess I'd have to do a lot of things
different. But here we have CAs that are exactly doing that cost-benefit
analysis. Not security first, compliance second, business last...
>
> It's very easy for people in this group to shout "pull the root, pull
> the root" - they don't have to deal with the enormous ramifications.
I'm not one of those - but I would like to see clear responses about the
considerations (beyond market share) to justify not doing exactly that,
action items placed upon the party, confirmation of implementation of
those items and a stick if anything with that should go wrong.
Apparently whatever was required before the last incident and whatever
requirements Mozilla placed upon the affected party wasn't sufficient. I
believe there can't be a repeating of the same issues over and over
again without such ramifications.
> The tens of thousands of customers of the CA (as in, website owners) do.
Well obviously. But isn't that the stick after all? It would be the CAs
responsibility to deal with that.
>
> We want to get to a place where we can make that decision in a way
> that affects only the CA. And soon, we will be there.
How exactly? I might not have seen all comments or missing something.
Gervase Markham
> Well, there is also compliance to policies and requirements. If I'd rate
> everything on this basis, I guess I'd have to do a lot of things
> different. But here we have CAs that are exactly doing that cost-benefit
> analysis. Not security first, compliance second, business last...
Everyone does it. So the fix is not to try and make water run uphill,
but change things to make it so the incentives are correctly aligned.
> Apparently whatever was required before the last incident and whatever
> requirements Mozilla placed upon the affected party wasn't sufficient. I
> believe there can't be a repeating of the same issues over and over
> again without such ramifications.
I don't think that Mozilla's response to Comodo, or Comodo's reaction to
the incident, are even in the same ballpark as last time.
>> The tens of thousands of customers of the CA (as in, website owners) do.
>
> Well obviously. But isn't that the stick after all? It would be the CAs
> responsibility to deal with that.
Except in practice, it's not. It's "my site doesn't work in Firefox!".
>> We want to get to a place where we can make that decision in a way
>> that affects only the CA. And soon, we will be there.
>
> How exactly? I might not have seen all comments or missing something.
By having the ability to deactivate a root beginning at a certain date.
Gerv
Eddy Nigg
> I don't think that Mozilla's response to Comodo, or Comodo's reaction
> to the incident, are even in the same ballpark as last time.
I understand. But those involved and interested here don't know really
about it, that's my point. Perhaps we would like to see some
transparency to set the expectations right. That is, we know that the CA
root will not removed. Great, but what else.
> By having the ability to deactivate a root beginning at a certain date.
>
Thanks for the clarification - this is indeed smart and I wasn't aware
of such an effort. Again, I might have not heard it in the noise.
Kyle Hamilton
On Fri, Apr 15, 2011 at 3:01 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 15/04/11 05:10, Kyle Hamilton wrote:
>> In other words, "usability trumps security".
>
> This is not a game of cards. There is a cost-benefit analysis. The way you
> make a course of action more possible is by reducing its costs and/or
> increasing its benefits.
Here's the problem: I do not trust -any- assertions -ever- made by Comodo. If their security model didn't include "total compromise of the RA", what other utterly obvious things have they screwed up?
In good conscience, I cannot allow anyone to force anyone else to trust them and rely on them either. In good conscience, you are failing to uphold your own users' security.
The cost of keeping Comodo in the root program should be seen to FAR outweigh (for Mozilla's corporate reputation) the cost of removing it.
> It's ironic, really - people argue for systems which alert a user when the
> site's certificate changes, and the same people argue for an action which
> would cause hundreds of thousands of certificates to change very rapidly,
> and they claim that users would still be able to make sane trust decisions
> in a TOFU/SSH model.
Well, yes. However, if there were something like, oh, I dunno...
1) Working revocation,
2) A UserNotice extension that Firefox and/or Thunderbird actually honored,
3) A cross-certifying CA under the control of Mozilla, and
4) a will to actually fix the problem instead of merely spackle it over
then this entire problem wouldn't be a problem at all. Mozilla's CCCA would revoke the prior certificate to Comodo, would issue a new one with a UserNotice stating that the CA who certified it was no longer trusted and that it would no longer be supported by Mozilla after the UserNotice certificate's expiration, and give every site owner a sporting chance to fix things before said expiration.
>> No. If Firefox had the ability to interpret multiple certificate chains,
>> the site owners would be able to manage their risks with multiple CAs'
>> services.
>
> You, and the people who argue that the CAs are all a cartel, and
> certificates are too expensive, need to get together and work a story out,
> because I'm not sure that group would be particularly happy if we suggested
> that site owners had to pay two or more CAs, instead of one, in order to
> have a cert which was safe from the risk of suddenly not working.
This doesn't change the fact that there is currently a single point of failure in the system which has failed. Under Netscape's draconian and antiquated but inherited and still-in-effect model, there is no means for risk managers to affect the fact that they are currently forced to rely upon the actions on not merely one, but multiple external entities for the PRIVILEGE of being able to whisper in someone else's ear. They cannot manage this risk by relying solely upon the single pillar of "permission to display to end-user conflated with knowing someone's state identity" to enable their e-commerce!
This isn't a cartel, it is a criminal protection racket. I'm not the only one to call it such (c.f. Peter Gutmann's godzilla crypto presentation).
Mozilla's defense against this charge is not helped by the fact that the wording in the untrusted-issuer path says, in bold, "Legitimate sites will not ask you to do this." I believe that this is libel, as it's a decision-based tangible representation-as-fact-because-the-site-didn't-follow-your-rules-and-pay-the-protection-value about the site that the user is attempting to reach. It is even INTENDED in a manner which is designed to reduce the probability that the user will continue the action. This is intended to affect the interactions between the "illegitimate" site and its user, and since "illegitimate" is defined by a private entity it thus operates as illegal coercion.
Ask the Foundation's corporate counsel about this particular view. I don't think anyone wants to go to prison, but they will if they keep this up.
(and if anyone says "there are CAs which are free", I'm just going to say that they all -- ALL -- require the entry of correct personal information as a prerequisite. Personal information is valuable -- if it wasn't, identity theft wouldn't be a positive value proposition. This makes the "no-cost" CA quite a pricey proposition indeed.)
-Kyle H
Ian G
>
> On Fri, Apr 15, 2011 at 3:01 AM, Gervase Markham <ge...@mozilla.org> wrote:
>> On 15/04/11 05:10, Kyle Hamilton wrote:
>>> In other words, "usability trumps security".
>>
>> This is not a game of cards. There is a cost-benefit analysis. The way
>> you
>> make a course of action more possible is by reducing its costs and/or
>> increasing its benefits.
>
> Here's the problem: I do not trust -any- assertions -ever- made by
> Comodo. If their security model didn't include "total compromise of the
> RA", what other utterly obvious things have they screwed up?
Right. Now you (Kyle) are truly appreciating the race to the bottom
that is built into the CA model. There is no way out of this trap
without changing the model. And, the browsers can't do that without
causing a furore, like that which happened last time.
Curiously, I didn't think it likely that anyone would appreciate the
2B2F flaw in CAs, but it's doing the rounds:
http://www.theregister.co.uk/2011/04/11/state_of_ssl_analysis/page3.html
......................
Although SSL's vulnerabilities are worrying, critics have reserved their
most biting assessments for the business practices of Comodo, VeriSign,
GoDaddy and the other so-called certificate authorities, known as CAs
for short. Once their root certificates are included in Internet
Explorer, Firefox and other major browsers, they can't be removed
without creating disruptions on huge swaths of the internet.
In that sense, they are like Citigroup, American International Group and
other investment companies that received billion-dollar bailouts from
tax payers because the US government deemed them “too big to fail.”
“The current security of SSL depends on these external entities and
there's no reason for us to trust them,” Marlinspike said. “They don't
have a strong incentive to behave well because they're not accountable.”
Mike Zusman, a senior consultant at security firm Intrepidus Group, agreed.
“In terms of what the CAs do, it seems like it's a bit of the old west,”
he said. “It doesn't seem like anyone is holding them accountable, even
when something as severe as the Comodo incident happens.”
......................
> In good conscience, I cannot allow anyone to force anyone else to trust
> them and rely on them either. In good conscience, you are failing to
> uphold your own users' security.
No choice, the Mozilla uber-CA makes that decision for you :)
> The cost of keeping Comodo in the root program should be seen to FAR
> outweigh (for Mozilla's corporate reputation) the cost of removing it.
The cost to you. Unfortunately your cost doesn't come anywhere near the
cost of to the users of losing some significant proportion of the SSL infra.
>> It's ironic, really - people argue for systems which alert a user when
>> the
>> site's certificate changes, and the same people argue for an action which
>> would cause hundreds of thousands of certificates to change very rapidly,
>> and they claim that users would still be able to make sane trust
>> decisions
>> in a TOFU/SSH model.
Well, if Mozilla tells some people that there is a feature for
individual control of roots, and tells other people that they can drop
the roots if there is any misdealings, and other people that the browser
can be adjusted because it is open source and anyone can contribute and
just dive in ...
Then... don't complain when they come back and hold you to those claims!
> Well, yes. However, if there were something like, oh, I dunno...
>
> 1) Working revocation,
> 2) A UserNotice extension that Firefox and/or Thunderbird actually honored,
> 3) A cross-certifying CA under the control of Mozilla, and
> 4) a will to actually fix the problem instead of merely spackle it over
>
> then this entire problem wouldn't be a problem at all. Mozilla's CCCA
> would revoke the prior certificate to Comodo, would issue a new one with
> a UserNotice stating that the CA who certified it was no longer trusted
> and that it would no longer be supported by Mozilla after the UserNotice
> certificate's expiration, and give every site owner a sporting chance to
> fix things before said expiration.
>
>>> No. If Firefox had the ability to interpret multiple certificate chains,
>>> the site owners would be able to manage their risks with multiple CAs'
>>> services.
>>
>> You, and the people who argue that the CAs are all a cartel,
That's me, but misquoted. CAB/Forum is a cartel. It is
closed-membership, and includes only a certain group which are agreed on
preserving their current business model. In economics terms, it's
almost a case study in the definition of a cartel.
CAs aren't a cartel, they are more like business operators in a
franchise model operated by the browsers.
>> and
>> certificates are too expensive, need to get together and work a story
>> out,
What's your story? Is the model open? Can we change it? Can we adjust
the source to add in the SSH/TOFU model? Can the user expect to be able
to control at the CA level? Can we get a nice interface to trust the
sites that we users know are trusted?
>> because I'm not sure that group would be particularly happy if we
>> suggested
>> that site owners had to pay two or more CAs, instead of one,
Actually, this isn't really sustainable, although it sounds nice!
Site owners are not particularly happy to pay *one CA* , and they've
never really bought into the whole "identity" argument because they
already know how to do that better.
It doesn't make a difference to pay for two CAs, because they are
already accustomed to buying two of many things. Two licences, two
certifications, two independent trust agencies, two this, two that.
E.g., we're currently asking CAs to buy into multiple practices from
CAB/Forum, Mozilla, ETSI, etc. Bureaucracy and red tape from princes
(aka stationary bandits) is something that business is very very adept at.
For them, they are already at the point where they have little choice,
and they'll simply take it as another cost of business / tax / no
choice. Indeed, if you can show that there are improvements in
delivery, they'll be happy to pay.
(This follows because the cost of certs is well in excess of the price
paid to the CA. Due to many and various factors ... if you can show
those other factors coming down, selling 2 certs will be a snap, it's a
saving for them.)
>> in order to
>> have a cert which was safe from the risk of suddenly not working.
>
> This doesn't change the fact that there is currently a single point of
> failure in the system which has failed. Under Netscape's draconian and
> antiquated but inherited and still-in-effect model,
:) I don't think it is possible to blame Netscape. I suspect no other
company would have done better...
> there is no means
> for risk managers to affect the fact that they are currently forced to
> rely upon the actions on not merely one, but multiple external entities
> for the PRIVILEGE of being able to whisper in someone else's ear. They
> cannot manage this risk by relying solely upon the single pillar of
> "permission to display to end-user conflated with knowing someone's
> state identity" to enable their e-commerce!
>
> This isn't a cartel, it is a criminal protection racket. I'm not the
> only one to call it such (c.f. Peter Gutmann's godzilla crypto
> presentation).
>
> Mozilla's defense against this charge is not helped by the fact that the
> wording in the untrusted-issuer path says, in bold, "Legitimate sites
> will not ask you to do this." I believe that this is libel, as it's a
> decision-based tangible
> representation-as-fact-because-the-site-didn't-follow-your-rules-and-pay-the-protection-value
> about the site that the user is attempting to reach. It is even INTENDED
> in a manner which is designed to reduce the probability that the user
> will continue the action. This is intended to affect the interactions
> between the "illegitimate" site and its user, and since "illegitimate"
> is defined by a private entity it thus operates as illegal coercion.
It's certainly a defamation, because the browser has no evidence of
maldoing. Same as the infamous "You do not trust this site" which
contradicts the model espoused by Gervase, where the root controls all,
so "Mozilla does not trust this site" is the accurate label. But
presumably this makes the defamation clearer.
I doubt it would go beyond defamation though. It can't be fraud because
there is no money involved for the browser. Conspiracy possibly but
that's notoriously difficult to prove. Coercion is hard because the
product is free and there is competition in browsers, and users blast
through the false messages with aplomb.
> Ask the Foundation's corporate counsel about this particular view. I
> don't think anyone wants to go to prison, but they will if they keep
> this up.
Have you noticed ... as soon as anyone mentions the law, everybody shuts
up? That's because any comment by anyone related to anything can be
used in a lawsuit at a later time.
So instead of facing up to the problems in open discussion, as we
imagine it to be in an open source organisation, everything is done
under the covers.
I know, I tried for years to talk to people at Mozilla about the
liability issue. They rarely if ever responded, but occasionally, fixes
I was yammering for turned up. There is an element of this in the
Baseline Document; but I'll bet there is no recorded discussion about
it :) There will only be very muted and careful responses to any posts
on it, if any at all.
Fixes like in the browser licence agreement are very welcome (even if
nobody knew they happened). But doing them in secret carries the cost
of slowness -- exposure times measured up to a decade -- and the missed
opportunities of putting in a more enlightened regime.
All because nobody could talk about it.
> (and if anyone says "there are CAs which are free", I'm just going to
> say that they all -- ALL -- require the entry of correct personal
> information as a prerequisite. Personal information is valuable -- if it
> wasn't, identity theft wouldn't be a positive value proposition. This
> makes the "no-cost" CA quite a pricey proposition indeed.)
I'll comment offlist on that. But you're point is clear: CAs (and
Mozilla and others) need to justify why they collect the privacy
information, and what use they make of it. So far, the justification
does not survive scrutiny. If you want more, look at my paper on "An
Open Audit" and search for "What's in a name?"
iang
Kyle Hamilton
On Fri, Apr 15, 2011 at 8:35 AM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 04/15/2011 01:42 PM, From Gervase Markham:
>
> Thanks for the clarification - this is indeed smart and I wasn't aware of
> such an effort. Again, I might have not heard it in the noise.
Unless you require reliable timestamps from another provider, it isn't going to matter. Comodo can just set the start date before that cutoff.
Am I the only one who's thinking of obvious attacks against these security-related proposals?
-Kyle H
Ian G
> On 04/15/2011 12:55 PM, From Gervase Markham:
>>> Gerv, that was the lamest response I've heard on this issue. I mean, all
>>> a CA has to do is getting a sufficient market share (how much is enough?
>>> is 6% sufficient too) and just every failure will get through.
>>
>> No, that's not true. But it's being wilfully blind to deny that the
>> ubiquity of the root affects the cost-benefit analysis.
>
> everything on this basis, I guess I'd have to do a lot of things
> different. But here we have CAs that are exactly doing that cost-benefit
> analysis. Not security first, compliance second, business last...
Business always comes first. If the business didn't come first, there
would be no business. Which means that cost-benefit is inevitable.
>> It's very easy for people in this group to shout "pull the root, pull
>> the root" - they don't have to deal with the enormous ramifications.
>
> I'm not one of those - but I would like to see clear responses about the
> considerations (beyond market share) to justify not doing exactly that,
> action items placed upon the party, confirmation of implementation of
> those items and a stick if anything with that should go wrong.
And above, there is talk of compliance, more compliance, better
compliance! All this clarity comes from where? Look at the problems in
this:
a. Who makes these decisions? Mozilla because they are in the middle?
No. Mozilla has typically taken its guidance from elsewhere, and no
authority is presenting the conditions with which it should comply with
in order to drop the root, or take other actions. So that's not going
to work.
b. 12.2.4 of the baseline lists three responses --
(i) "internal",
(ii) forward to law enforcement authorities, and
(iii) revocation. With a reason, see the very impressive 12.2.5 :)
So according to the CABForum, this is sufficient to deal with a problem.
c. which leads to the next issue: who wrote this up? Well, the CAs of
course. And how did they write it up? So as to *ensure that they
themselves were able to carry on* ... The recent CA incident will
achieve this high standard of response with aplomb. Why are you
criticising them? They presumably have met their new standard which
they are all agreed to.... As underscored by rushing the document out
at the current time, because of the current criticism. They believe it
works, it's good, it addresses the issue.
All of which says: Let's hear less of these strident demands that
Mozilla has to do something, anything, yank the root, show some cojones.
It isn't going to happen.
Every time this erupts, "you're the government, you must do
something..." it takes valuable attention and time from dealing with the
real underlying issues.
> Apparently whatever was required before the last incident and whatever
> requirements Mozilla placed upon the affected party wasn't sufficient. I
> believe there can't be a repeating of the same issues over and over
> again without such ramifications.
Calling for more compliance is not only not a solution to the problem,
it is a large part of the problem. Here we are, still tightening the
screws, and trouble keeps popping out. The more you call for higher
barriers and more compliance, the more problems will occur.
Or, if you don't buy that, let's talk about CDOs and bank pay and so
forth. Same problem, same solution, same mess. Enron and AA caused
more compliance, which provided cover for more rorts.
>> The tens of thousands of customers of the CA (as in, website owners) do.
>
> Well obviously. But isn't that the stick after all? It would be the CAs
> responsibility to deal with that.
Ahhh... bankrupcy is a stick that hurts more than it helps.
Have a look at the global financial crisis. Did Enron and Arthur
Anderson achieve *anything at all* in the sense of improved governance?
Or were they just the sacrifices we needed so the herd could get on
with the real feeding frenzy?
>> We want to get to a place where we can make that decision in a way
>> that affects only the CA. And soon, we will be there.
>
> How exactly? I might not have seen all comments or missing something.
Reputation! You want the CA to want to do it themselves, to have a
competitive advantage in their actions. Reverse the race to the bottom
and make it a race to the top.
iang
Ian G
I don't think we necessarily understand it. Gerv, can you describe what
you mean?
iang
Eddy Nigg
> Business always comes first. If the business didn't come first, there
> would be no business. Which means that cost-benefit is inevitable.
Well, we can reverse it, if no security and no compliance means no
business. It's easy :-)
> They presumably have met their new standard which they are all agreed
> to.... As underscored by rushing the document out at the current
> time, because of the current criticism.
You are entirely wrong on that - The CAB Forum worked on it for quite
some time and the publication was scheduled to go out. There were some
that were concerned that it might be not a good timing shortly after the
Comodo incident.
Some of us including myself and Sid (from Mozilla) pushed to go ahead
with it, because and despite the most recent incidents. And we are
entirely aware the most recent incidents could have been addressed
better in the current version, but we prefer to have a basic guidelines
instead of none. Whatever changes have to be considered will go into the
next version.
> Calling for more compliance is not only not a solution to the problem,
> it is a large part of the problem. Here we are, still tightening the
> screws, and trouble keeps popping out. The more you call for higher
> barriers and more compliance, the more problems will occur.
I don't agree, the requirements weren't enforced and nobody had the
balls to set those. The Basic Guidelines actually helps to overcome some
of the issues one browser vendor alone has more difficulty to enforce.
> Reputation! You want the CA to want to do it themselves, to have a
> competitive advantage in their actions. Reverse the race to the
> bottom and make it a race to the top.
Even if Comodo's reputation was hurt, this affects only a small group of
potential customers, the rest go after the advertisements and buy. So
they get a few nasty emails, and...? It's not a stick strong enough,
it's more like straw. With damaged reputation we don't higher the
requirements and enforce compliance.
Eddy Nigg
> That's me, but misquoted. CAB/Forum is a cartel. It is
> closed-membership, and includes only a certain group which are agreed
> on preserving their current business model. In economics terms, it's
> almost a case study in the definition of a cartel.
>
The CAB Forum is certainly not a cartel (because I wouldn't participate
at a cartel). According to Wikipedia (whatever that's worth):
A *cartel* is a formal (explicit) agreement among /competing/ firms. It
is a formal organization of producers and manufacturers that agree to
*fix prices, marketing, *and*production*.
The CAB Forum isn't involved with anything of that. Additionally there
are various representatives including browser vendors (non-CAs) and CAs
from 4 different continents. So all your claims about US orientated and
such might be perceived as such (including myself in the past), it is in
fact however incorrect. Any non-US representative can pull into a
different direction if they wish to do so.
BTW, there are also parties that have observer status and non-voting
members. It's not open to the public, but it's also not entirely closed.
Ian G
> On 04/16/2011 05:33 AM, From Ian G:
>> closed-membership, and includes only a certain group which are agreed
>> on preserving their current business model. In economics terms, it's
>> almost a case study in the definition of a cartel.
>>
>
> at a cartel).
lol... participating in a cartel is *always good for the participants*.
Don't cut yourself short.
> According to Wikipedia (whatever that's worth):
>
> A *cartel* is a formal (explicit) agreement among /competing/ firms.
OK, that's approximately correct. Better put,
A *cartel* is a formal (explicit) agreement among
/competing/ firms to arrange the market in a way
of mutual benefit.
Let's also be clear on another point: a cartel is an economics
observation. It is not necessarily a bad thing or an illegal thing.
For example, OPEC and deBeers are both cartels in their way, and they've
not been seen as bad.
> It
> is a formal organization of producers and manufacturers that agree to
> *fix prices, marketing, *and*production*.
OK. Let's be careful about wikipedia as an aid to economics, because
when you get into serious business, wikipedia is a bit light.
A cartel forms to control the market in some way for benefit of members.
Typically it will do so in order to maintain or increase prices. It
will do so using a variety of tools, whatever is to hand. E.g., de
Beers with advertising, OPEC with production numbers.
> The CAB Forum isn't involved with anything of that.
Wrong. It is involved in marketing and production. It has released in
the past EV Guidelines, and it has just released Baseline Requirements.
For example, and I quote, BR1 says:
"The Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates describe
a subset of the requirements that a Certification
Authority must meet in order for its Certificates to
be Publicly Trusted."
That's fixing production, right there. It's a requirements document
that is aimed at every business calling itself a CA.
(For marketing, that follows from the above. The trick is to think of
marketing more as strategy and product design, and less as advertising
and PR.)
> Additionally there
> are various representatives including browser vendors (non-CAs) and CAs
Yes, so it would be a cartel with 3 different factor firms: CAs,
auditors and vendors. There's no rule in cartels that say that only one
factor is allowed. De Beers has 2 different factors: mines and
cutters/polishers.
> from 4 different continents. So all your claims about US orientated and
> such might be perceived as such (including myself in the past), it is in
> fact however incorrect. Any non-US representative can pull into a
> different direction if they wish to do so.
The North American Orientation is simply an observation, it doesn't
necessarily speak to the issue of cartel. I make that observation
frequently because there are many from the European Orientation who
don't see why it is that CABForum concentrates on SSL. (And v.v.) It's
just an aid to help people here understand the different submarkets ...
same can be said of the Government Orientation; you will recall heated
debates about why governments audit differently, and you can see in
Baseline Requirements a hack to try and fit governments into the
mindset. You don't have to believe in these observations, but (I claim)
they help to explain the arguments.
Geographical diversification is good to see, but doesn't change the
economics story much.
> BTW, there are also parties that have observer status and non-voting
> members. It's not open to the public, but it's also not entirely closed.
Of course. Who choses that and how is it chosen? It will be done in
order to keep certain interests out, and to keep certain interests in,
right?
http://www.cabforum.org/forum.html
Is that the story?
iang
Eddy Nigg
> lol... participating in a cartel is *always good for the
> participants*. Don't cut yourself short.
Not sure about that, it removes competition obviously, which is bad. If
you want to compete, you can't participate in a cartel.
> That's fixing production, right there.
Right, but so does any standards committee in some form, any RFC, ISO,
w3c, EITF, ITU, even ETSI and the various European work groups that put
out standards. They are not cartels, they are standards bodies that are
developing specifications and this is what the CAB Forum mostly does in
my opinion.
> It's a requirements document that is aimed at every business calling
> itself a CA.
Right, that's the goal, however the adopters are potentially the
software vendors (and to some extend maybe auditing standards and
bodies) which have the overall say in any case what they consider their
requirements. The fact that they'd adopt a document or standard in order
to make their life's easier and have the ability to steer certain
requirements across the entire industry isn't a cartel, it's
standardizing certain aspects.
Specially myself has seen fixing the bottom far more important than
fixing the top. There is no problem for high-quality verifications,
there was always a problem at the bottom. EV is nice, but I believe the
basic requirements guidelines will have a much bigger impact.
Kyle Hamilton
On Sat, Apr 16, 2011 at 5:00 PM, Eddy Nigg <eddy...@startcom.org> wrote:
> On 04/17/2011 02:34 AM, From Ian G:
>>
>> lol... participating in a cartel is *always good for the participants*.
>> Don't cut yourself short.
>
> Not sure about that, it removes competition obviously, which is bad. If you
> want to compete, you can't participate in a cartel.
>> That's fixing production, right there.
>
> Right, but so does any standards committee in some form, any RFC, ISO, w3c,
> EITF, ITU, even ETSI and the various European work groups that put out
> standards. They are not cartels, they are standards bodies that are
> developing specifications and this is what the CAB Forum mostly does in my
> opinion.
A standards organization doesn't have anything negative that it can do to anyone who doesn't want to use them. The CABF can force the untrusted certificate path on anyone who doesn't want to pay its protection.
>> It's a requirements document that is aimed at every business calling
>> itself a CA.
>
> Right, that's the goal, however the adopters are potentially the software
> vendors (and to some extend maybe auditing standards and bodies) which have
> the overall say in any case what they consider their requirements. The fact
> that they'd adopt a document or standard in order to make their life's
> easier and have the ability to steer certain requirements across the entire
> industry isn't a cartel, it's standardizing certain aspects.
That's collusion (membership in a professional organization of many parties, fixing the standards and prices) to commit extortion (private tolls that cannot be avoided without defamation).
> Specially myself has seen fixing the bottom far more important than fixing
> the top. There is no problem for high-quality verifications, there was
> always a problem at the bottom. EV is nice, but I believe the basic
> requirements guidelines will have a much bigger impact.
Bring Authority into the Certifying Authority. Use publicly-filed and publicly-sworn documents.
-Kyle H
Ian G
> On 04/17/2011 02:34 AM, From Ian G:
>> participants*. Don't cut yourself short.
>
Not sure what is meant by "want" here ... but let me resort to the
economists perspective, again.
Typically what happens in an industry is that new entrants come in and
start competing. (Because they want to?) They discover the incumbents
make things hard for them, and it's hard to make a profit. So they
innovate around the incumbents. And that allows them to take the better
margin.
Then, the incumbents get annoyed at the cherry picking and organise
things to stop it. One popular technique is to buy out the more
successful innovators (c.f., Thawte & Geotrust). Another is to organise
a club of incumbents, and set compatibility and quality standards so as
to raise the entry cost and knock out the lightweight players.
(Term of art: barriers to entry.)
If you want something to read on a lazy sunday, try this beautifully
written introduction to competition in banking:
http://iang.org/free_banking/dowd_lfb_intro.html
This is almost the "economics of cartels in one easy lesson" !
>> That's fixing production, right there.
>
> Right, but so does any standards committee in some form, any RFC, ISO,
> w3c, EITF, ITU, even ETSI and the various European work groups that put
> out standards. They are not cartels, they are standards bodies that are
> developing specifications and this is what the CAB Forum mostly does in
> my opinion.
Right. But standards can be looked at both ways. They can be used to
improve matters for consumers, and/or they can be used to raise costs
and set barriers to entry against innovators. Things like electrical
standards are widely seen as both: as quality of safety appliances
increases, so all the incumbent manufacturers cheer! Cheap foreign
imports are controlled by quality standards, keeping everyone in work.
So, it's no wonder that the standards are written by the incumbent
manufacturers, and incumbents are always trying to increase the quality
and safety .... and cost.
It's an unfortunate consequence: standards are opposing to competition,
because competition is just as valid in new ways as the same way done
better.
And, in this particular industry, this is precisely the point. The
various standards bodies (your list above) have bogged the security down
to the point where it is all compliance and marketing, and security
itself is questionable. For the particular perspective on why the
standards bodies cannot do security particularly well, google on Boyd's
OODA loop, and measure the rollout time for renegotiation fix (as I am
doing).
>> It's a requirements document that is aimed at every business calling
>> itself a CA.
>
> Right, that's the goal, however the adopters are potentially the
> software vendors (and to some extend maybe auditing standards and
> bodies) which have the overall say in any case what they consider their
> requirements. The fact that they'd adopt a document or standard in order
> to make their life's easier and have the ability to steer certain
> requirements across the entire industry isn't a cartel, it's
> standardizing certain aspects.
Right, you're saying the same things. In order to get the browser
vendors to follow a consistent message, the CAs had to form a group and
come to an agreement on what that consistent message was. Hence the two
documents. From this, plus a lot of pressure, the industry was able to
contain the vendors to follow this path.
So it's entirely clear that the purpose of CABForum is to get the
vendors to follow a certain path. That's part and parcel of the goals.
E.g., OPEC don't set production targets so as to make things easier.
They set production targets knowing that the laws of supply & demand
will push the prices up. So the incumbents benefit.
(Now, an important part of cartel theory is that that cartels don't work
very well because there is always an incentive to cheat. Consider that
and apply it to the current situation, and you'll see the theory
explains *a lot* ...)
> Specially myself has seen fixing the bottom far more important than
> fixing the top. There is no problem for high-quality verifications,
> there was always a problem at the bottom. EV is nice, but I believe the
> basic requirements guidelines will have a much bigger impact.
Sure, there are all these opinions and wide divergence amongst them.
You think from a CA perspective, so you look for the holes in
implementation. Others think from other perspectives....
If you thought from a business perspective (as I do) EV coming first is
a no-brainer. I've even written a rant about it somewhere, many years
ago, more or less proposing EV before it had that name.
http://iang.org/ssl/dr_self_signed.html
You will hate it, but it's all bog-standard marketing and sales,
straight from the book.
iang
Ian G
> On 04/16/2011 06:46 AM, From Ian G:
>> would be no business. Which means that cost-benefit is inevitable.
>
> business. It's easy :-)
Great advertising copy :)
>> They presumably have met their new standard which they are all agreed
>> to.... As underscored by rushing the document out at the current time,
>> because of the current criticism.
>
> You are entirely wrong on that - The CAB Forum worked on it for quite
> some time and the publication was scheduled to go out. There were some
> that were concerned that it might be not a good timing shortly after the
> Comodo incident.
OK, I stand corrected. So it wasn't rushed out. But presumably it is
still the CABForum's best shot at the overall problem?
(This is where those who are "in" have an advantage over those who are
"out" ... we lack information, we'll always be defeated on that basis.)
> Some of us including myself and Sid (from Mozilla) pushed to go ahead
> with it, because and despite the most recent incidents. And we are
> entirely aware the most recent incidents could have been addressed
> better in the current version, but we prefer to have a basic guidelines
> instead of none.
Hence the philosophy "a bird in the hand is better than two in the
bush." By which I assume that CABForum have thought about this, and
decided this document is better out now, even with the new learning.
Which would suggest that the industry has bigger problems than the
current incident. So, CABForum might be suggesting, it would be better
to take a measured approach, carefully and thoughtfully, to the current
lessons & experience, rather than demanding heads, roots, media
attention and other knee-jerk reactions. OK.
> Whatever changes have to be considered will go into the
> next version.
Timeframe?
>> Calling for more compliance is not only not a solution to the problem,
>> it is a large part of the problem. Here we are, still tightening the
>> screws, and trouble keeps popping out. The more you call for higher
>> barriers and more compliance, the more problems will occur.
>
> I don't agree, the requirements weren't enforced and nobody had the
> balls to set those.
Of course. Calling for more compliance always leads to that comment, as
regular as clockwork. More compliance they yell, then shortly after,
more enforcement!!!! And that doesn't work so we start again.
Unfortunately, as soon as we start looking at "enforcement" everyone
runs for the hills. That is in part what is wrong with compliance: it
requires enforcement, which is an unsolved problem.
> The Basic Guidelines actually helps to overcome some
> of the issues one browser vendor alone has more difficulty to enforce.
Sure, I agree in principle. All things being equal, having a document
of this nature is probably a good thing. But, not all things are equal.
>> Reputation! You want the CA to want to do it themselves, to have a
>> competitive advantage in their actions. Reverse the race to the bottom
>> and make it a race to the top.
>
> Even if Comodo's reputation was hurt, this affects only a small group of
> potential customers, the rest go after the advertisements and buy. So
> they get a few nasty emails, and...? It's not a stick strong enough,
> it's more like straw. With damaged reputation we don't higher the
> requirements and enforce compliance.
You are assuming that Comodo's reputation is what I'm calling for. No
such; Comodo doesn't have a reputation. Nor does anyone else to a
useful degree of approximation. There's nothing to say, nothing to
hurt. Even this group doesn't have a reputation.
The surrounding context is important here. Verisign have a slight
reputation, but it is mushy and indistinguishable, not something the
consumer really knows about. That's as best as it gets, and it's
woeful. They can do whatever they like, and their reputation won't be
touched.
Unlike, for example, Arthur Anderson. Their reputation was slightly
damaged by an email... Such a small piece straw, and such a very large
camel. Or Intel, who's reputation was damaged by a floating point number.
The structure of this industry is that way. So when we talk about
reputation, we mean, giving the CAs a reputation at an industry level.
As a first, necessary step. Then, when they've got it, they'll defend it.
Now, they've got nothing to defend. So they don't. Hence, your piece
of straw, yes, it's straw, nothing worth talking about.
iang
Eddy Nigg
> OK, I stand corrected. So it wasn't rushed out.
Nope.
> But presumably it is still the CABForum's best shot at the overall
> problem?
I think it's a very good start and it took a while to gather consensus
for it.
> Hence the philosophy "a bird in the hand is better than two in the bush."
Absolutely - I think most of us feel like this.
> By which I assume that CABForum have thought about this, and decided
> this document is better out now, even with the new learning.
Yes, another round might have cost us another few month.
>> Whatever changes have to be considered will go into the
>> next version.
>
> Timeframe?
I don't want to answer for the CAB Forum, but it's my understanding that
there is the intention for a reasonable effort to process another
version fairly quickly. Or errata to the existing version.
> Unfortunately, as soon as we start looking at "enforcement" everyone
> runs for the hills. That is in part what is wrong with compliance:
> it requires enforcement, which is an unsolved problem.
But I assume it will be easier when there is an agreed standard.
Eddy Nigg
> Another is to organise a club of incumbents, and set compatibility and
> quality standards so as to raise the entry cost and knock out the
> lightweight players.
Yeah, but not in this case, actually I believe the big ones have to
adjust more than the smaller ones interestingly. That's probably a good
thing over time.
Peter Gutmann
>The CAB Forum is certainly not a cartel (because I wouldn't participate at a
>cartel). According to Wikipedia (whatever that's worth):
>
>A *cartel* is a formal (explicit) agreement among /competing/ firms. It is a
>formal organization of producers and manufacturers that agree to *fix prices,
>marketing, *and*production*.
The magic term here is "formal agreement", which, as you point out, the CAB
Forum doesn't have. This makes it an oligopoly, not a cartel.
Peter.
Kyle Hamilton
On Fri, Apr 15, 2011 at 8:46 PM, Ian G <ia...@iang.org> wrote:
>>> We want to get to a place where we can make that decision in a way
>>> that affects only the CA. And soon, we will be there.
>>
>> How exactly? I might not have seen all comments or missing something.
>
> competitive advantage in their actions. Reverse the race to the bottom and
> make it a race to the top.
-Kyle H
Ian G
As with any relationship, the contract is found in a bunch of events and
actions, including document(s) of agreement, and it might not
necessarily carry the title you're expecting.
Check out BR sections 7,8.
What is not clear is what are the conditions on joining. Can anyone
fill us in? I have it on good authority that Achmed is interested in
applying ...
https://bugzilla.mozilla.org/show_bug.cgi?id=647959
iang
Jan Schejbal
>
> Option 2. Dump Comodo. Cost?
> * Loss of Comodo (bankrupcy, think Enron and Arthur Anderson).
that's a plus.
* All other CAs becoming much more careful because they do not want to
follow Comodo (negative cost)
Kind regards,
Jan
--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...
Jan Schejbal
> On 12/04/11 8:11 PM, Moudrick M. Dadashov wrote:
>> In the case of such a private sub-CA as described by Michael, I
>> think there should be a name-constraint that allows it only to
>> issue certificates for it's own domain.
>
> Can anybody think of a reason why that would not be a good idea?
Maybe there is one in the archives, I remember that I wanted to have
this long time ago.
IMHO there should be the rule that a root CA must not issue CA certs to
third parties unless restricted to a real second-level domain (i.e.
example.com, google.co.uk, not co.uk) by name constraint.
Existing ones should be replaced within 1 year and the old ones revoked.
Failure to follow these rules should result in removal of the root, with
no further questions asked.
Jan Schejbal
>
> Unless you require reliable timestamps from another provider, it isn't
> going to matter. Comodo can just set the start date before that cutoff.
>
> Am I the only one who's thinking of obvious attacks against these
> security-related proposals?
If they did it on honestly-issued certs, they would be removed
immediately. If serial numbers are sequential, those may be used too
(with similar problems applying). This still seems as a useful
compromise between do-nothing and kill-it-now for cases of CAs who need
to be removed due to policy violations but not full compromise and seems
like a good way out of the to-big-to-fail problem. I support this idea.
The effects on mozilla users (10% of SSL web not working) seems to be
the main argument against removing CAs. This way, we can give the web
site owners a grace period (maybe 6 months? I would not make it too
long) to safely replace their certs, the users won't get 10% of the SSL
web broken, and we have a way to get rid of CAs.
I am very sure that the CAs willingly use the to-big-to-fail effect. For
this reason, I suggest this to be implemented even if we do not want to
use it now, as it would stop the CAs to rely on being safe due to size.
And if something happens again, we can finally make the decision about
removing the CA free from the to-big-to-fail effect.
Peter Gutmann
>Another is to organise a club of incumbents, and set compatibility and
>quality standards so as to raise the entry cost and knock out the lightweight
>players.
Slightly off-topic, but a good example of this is FIPS 140. Look at what the
incumbents did to OpenSSL to delay the admission of a free certified
implementation onto the gravy train for as long they possibly could.
Peter.
Peter Gutmann
>Gerv, that was the lamest response I've heard on this issue. I mean, all a CA
>has to do is getting a sufficient market share (how much is enough? is 6%
>sufficient too) and just every failure will get through.
I've just noticed, via Luther Martin's always-interesting blog:
http://superconductor.voltage.com/2011/04/honest-achmed-not-honest-enough.html
that there is a CA that actually has this as their business model:
https://bugzilla.mozilla.org/show_bug.cgi?id=647959
I can't understand why the request was turned down, I guess he should have
disguised his actual business plan like other CAs do and no-one would have
noticed :-).
Peter.
Eddy Nigg
> Slightly off-topic, but a good example of this is FIPS 140. Look at what the
> incumbents did to OpenSSL to delay the admission of a free certified
> implementation onto the gravy train for as long they possibly could.
I don't buy this really, NSS is also open source and free and gets
certified I believe on an almost yearly basis. Could it be that OpenSSL
had some real issues?
Jean-Marc Desperrier
> On 15/04/11 05:10, Kyle Hamilton wrote:
>> In other words, "usability trumps security".
>
> This is not a game of cards
However, usability does trump security.
If it's not usable, it can't be secure : If your efforts to make it more
secure make it less usable, then users will disable the security
mechanism to get the usability back, and if you make that impossible,
they will switch to something else that's easier to use and a lot less
secure.
You can never implement security without putting usability first.
Varga Viktor
I think, the users first need security, comfort is only the second.
If a CA does not do the things good, shousl be dropped.
This is not the first case.
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customer Service Executive
Netlock Kft.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
> _______________________________________________________________________
> Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail
> MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
>
> This email has been scanned for viruses and SPAM by the filter:mail
> MessageLabs System. More information: http://www.filtermax.hu
> _______________________________________________________________________
> _
_______________________________________________________________________
Ezt az e-mailt virus- es SPAM-szuresnek vetettuk ala a filter:mail MessageLabs rendszerrel. Tovabbi informacio: http://www.filtermax.hu
This email has been scanned for viruses and SPAM by the filter:mail MessageLabs System. More information: http://www.filtermax.hu ________________________________________________________________________________________
Gervase Markham
> That's me, but misquoted. CAB/Forum is a cartel. It is
> closed-membership, and includes only a certain group which are agreed on
> preserving their current business model. In economics terms, it's almost
> a case study in the definition of a cartel.
CABForum's membership is open to anyone who meets the criteria. Surely
if it were a cartel, membership would need to be by invitation?
In addition, no document issued by CABForum is, in itself, binding on
anyone.
Gerv
Ian G
> On 16/04/11 03:33, Ian G wrote:
>> closed-membership, and includes only a certain group which are agreed on
>> preserving their current business model. In economics terms, it's almost
>> a case study in the definition of a cartel.
>
Well of course :)
> Surely
> if it were a cartel, membership would need to be by invitation?
No. One simply defines the criteria.
For example,
"OPEC is a permanent intergovernmental organization
of 12 oil-exporting developing nations that coordinates
and unifies the petroleum policies of its Member Countries".
If you're an oil-consuming nation, you're out of luck. Read more:
http://www.opec.org/opec_web/en/about_us/25.htm
> In addition, no document issued by CABForum is, in itself, binding on
> anyone.
BR1 disagrees with you.
======
The Baseline Requirements for the Issuance and Management of
Publicly-Trusted Certificates describe a subset of the requirements that
a Certification Authority must meet in order for its Certificates to be
Publicly Trusted.
======
Mozilla intends to adopt, which makes it binding. Presumably all other
CAs are in agreement. This makes it a CABforum binding document.
iang
Michael Ströder
> Op 12-4-2011 1:32, Kyle Hamilton schreef:
>> On Mon, Apr 11, 2011 at 1:27 PM, Kathleen Wilson <kathle...@yahoo.com> wrote:
>>>
>>> We are not currently going down the path of disabling Comodo's roots. Our
>>> current focus is on identifying the appropriate changes, having Comodo
>>> implement the changes, and requiring an audit of each RA before it can be
>>> re-enabled.
>>
>> Does someone have to file a lawsuit accusing Mozilla of gross negligence and failure to act in
>> accordance with its published policies to get Mozilla to realize that this is completely inappropriate?
>>
>> You make decisions for inclusion with input from this group. You're not making decisions for
>> exclusion with input from this group, and you're not making decisions regarding repeated, published
>> trust failures by this single entity in accordance with your published policy.
>
> I agree with Kyle. For me there is way to much time spend on 'solving the system' instead of taking
> responsibility and discuss the real indecent. Not the hack or a failing CA system, but Comodo that
> is not doing what they should do (for years).
I wholeheartly agree. I find it totally useless to discuss policy aspects if
nothing will happen if CAs fail to be trustworthy. In case of Comodo the
policy is simply not enforced.
>> If Comodo wants to fix it, it needs to hire an external security consultant, completely rewrite its
>> certification policy and certification practice statement, get audited again (by a DIFFERENT
>> auditor, since the current one is obviously not qualified to render an opinion on security-critical
>> operations), and then reapply to the root program.
>
> And even then we haven't spoke about the possibility that there could be much more false issued
> certificates out there. The sites from this and the previous incidents where all high profile sites!
> What about a regular site...?
Yupp!
And how to make CAs to put good practices in place? Especially Comodo who
failed several times? They won't improve anything because that costs money. So
kick rogue CAs like Comodo out of business so that improving security will be
a real business case for CAs.
Ciao, Michael.
Michael Ströder
> Paul van Brouwershaven wrote:
>> [...] even then we haven't spoke about the possibility that there
>> could be much more false issued
>> certificates on there own for years and
>> they have been able to issue plenty of false certificates.
>
> Where is the proof that no other CA has similarly risky RA ?
There is no such proof. But that does not mean that a CA shouldn't get
punished for having failed.
> As Michael says a little above : "One of my customers has a
> fully-trusted sub-CA and the root CA with its "trusted" root CA cert did
> not even read the CPS I wrote. Not to speak of an audit. They can issue
> any cert they want". So does it still looks like Comodo is the one
> scapegoat that must be killed to get rid of the problem fully ? Opposite
> to the standard scapegoat, Comodo has indeed failed. But I still don't
> believe that all evil will go away together with Comodo.
Obviously one cannot fully solve the issue by removing Comodo's root CA certs.
But without any consequences everybody feels like it's ok to misbehave.
> What we need to do is to define what the proper new rule about RA/sub-CA
> should be for all CA. And require them all to comply to it.
And what happens if the don't obey to this new rule?
> In the case of such a private sub-CA as described by Michael, I think
> there should be a name-constraint that allows it only to issue
> certificates for it's own domain.
To tell you all something about the real world:
After the last merger the company running this sub-CA has approx. 50000
registered domains. How do you want to put these in a name constraint? For
business reasons the CA is interested to establish a sub-CA constraint in
contracts but there's no real chance to keep up with the list of registered
domains. So this is blurry.
To make matters worse the business units are free to choose any domain hoster
they want (the out-sourcing religion rules here). So the guy approving the
CSRs has to do conduct domain validation just like any other public CA.
Actually he's doing a good job and I personally trust him much more than any
other pre-installed CA. But in general this sub-CA has the power to issue any
cert it wants.
Ciao, Michael.
Brian Smith
> To tell you all something about the real world:
>
> After the last merger the company running this sub-CA has approx.
> 50000 registered domains. How do you want to put these in a name
> constraint? For business reasons the CA is interested to
> establish a sub-CA constraint in contracts but there's no real
> chance to keep up with the list of registered domains. So this
> is blurry.
>
> To make matters worse the business units are free to choose
> any domain hoster they want (the out-sourcing religion rules
> here). So the guy approving the CSRs has to do conduct domain
> validation just like any other public CA. Actually he's doing
> a good job and I personally trust him much more than any other
> pre-installed CA. But in general this sub-CA has the power to
> issue any cert it wants.
AFAICT, this is a great example of why sub-CAs cannot be allowed.
- Brian
David E. Ross
To me, a sub-CA is a subterfuge that allows a CA to operate outside of
the constraints of WebTrust and outside of the Mozilla policies, both of
which apparently apply only to the primary CA.
In fact, the WebTrust criteria for CAs makes no mention of third-party,
external sub-CAs or allowing any signing of subscriber certificates
except by the audited CA. This alone should guide the updating of the
Mozilla policies into prohibiting the root certificate of any CA that
allows an external, third-party organization to sign subscriber
certificates.
This was the primary point of my review comments in this newsgroup under
the subject "More Review Comments -- Phase 2 of Policy Update: RAs and
Subordinate CAs".
--
David E. Ross
<http://www.rossde.com/>
On occasion, I might filter and ignore all newsgroup messages
posted through GoogleGroups via Google's G2/1.0 user agent
because of spam from that source.
Peter Gutmann
>After the last merger the company running this sub-CA has approx. 50000
>registered domains. How do you want to put these in a name constraint? For
>business reasons the CA is interested to establish a sub-CA constraint in
>contracts but there's no real chance to keep up with the list of registered
>domains. So this is blurry.
Ah, so others have run into this one as well :-). I was once involved with
some cert deployment (not sure if I could dignify it with the name "PKI") for
an organisation that operated across a number of countries and with various
subsidiaries and affiliates. Their grand master plan, prepared by conslutants
from a large PKI vendor, called for the use of name constraints. A quick bit
of SQL on their who's-who database later and we demonstrated that (a) if they
were serious about this they were going to have to attach trailers
("anhaenger") to their certs to carry the list of constraints around, (b) they
would have to re-issue the certs several times a week because of name churn,
and (c) in order to allow all the names they were working with, the
constraints couldn't be much more restrictive than '*'.
Name constraints are another one of these nice theoretical things that work if
your PKI is the global X.500 directory, but don't survive any exposure to the
real world.
Peter.
Jean-Marc Desperrier
> After the last merger the company running this sub-CA has approx. 50000
> registered domains. How do you want to put these in a name constraint? For
> business reasons the CA is interested to establish a sub-CA constraint in
> contracts but there's no real chance to keep up with the list of registered
> domains. So this is blurry.
>
> To make matters worse the business units are free to choose any domain hoster
> they want (the out-sourcing religion rules here). So the guy approving the
> CSRs has to do conduct domain validation just like any other public CA.
Well, providing this compagny the ability to approve SSL certificate for
50 000+ different domain without going through a full audit simply isn't
compatible with PKI.
Either they buy them individually from external entities, or they go the
procedure to become a full CA.
I'm quite convinced however that the main reason why they have 50 000+
different domain is that it cost them basically nothing (or at least
nothing visible. Or just not enough to take the decision to drop those
that aren't actually in no way useful).
And that they're not doing sensitive business using 50 000 different
names because nobody can remember that many different names, so it's
perfectly equivalent to having no security.
Because a part of meaningful use of SSL is lowering the number of
different domain name you use, so that what users need to check is
simple. Or then, they don't check anything when connecting. And then
it's easy for the attacker to get a certificate for some random name
that won't be checked anyway.
Gervase Markham
> No. One simply defines the criteria.
>
> For example,
> "OPEC is a permanent intergovernmental organization
> of 12 oil-exporting developing nations that coordinates
> and unifies the petroleum policies of its Member Countries".
That's a statement of fact, not a set of membership criteria.
> If you're an oil-consuming nation, you're out of luck.
http://cabforum.org/forum.html has the membership criteria at the bottom
of the page.
In what way does an organization avoid your charge of being a cartel,
without having membership open to anyone and everyone with no criteria
whatsoever?
>> In addition, no document issued by CABForum is, in itself, binding on
>> anyone.
>
> BR1 disagrees with you.
>
> ======
> The Baseline Requirements for the Issuance and Management of
> Publicly-Trusted Certificates describe a subset of the requirements that
> a Certification Authority must meet in order for its Certificates to be
> Publicly Trusted.
> ======
>
> Mozilla intends to adopt, which makes it binding.
Right. But whether Mozilla adopts it or not is not in the CAB Forum's
control.
> Presumably all other
> CAs are in agreement. This makes it a CABforum binding document.
The language in BR1 is loose; what it should probably say is:
"The Baseline Requirements for the Issuance and Management of
Publicly-Trusted Certificates describe a subset of the requirements that
a Certification Authority complying with it must meet in order for its
Certificates to be Publicly Trusted by an entity requiring compliance."
Gerv
Michael Ströder
> It's ironic, really - people argue for systems which alert a user when
> the site's certificate changes, and the same people argue for an action
> which would cause hundreds of thousands of certificates to change very
> rapidly, and they claim that users would still be able to make sane
> trust decisions in a TOFU/SSH model.
While possibly hundred thousands of certs might be affected the single user
will only be affected by a few cert changes. I personally use cert patrol and
I also turned off the trust bits from Comodo CAs and the affiliated CAs
(UserTrust and Addtrust). There are not so many problems in my daily usage. I
can handle that.
Ciao, Michael.
Michael Ströder
> The cost of keeping Comodo in the root program should be seen to FAR
> outweigh (for Mozilla's corporate reputation) the cost of removing it.
+1
Ciao, Michael.
Ian G
> On 21/04/11 02:11, Ian G wrote:
>>
>> For example,
>> "OPEC is a permanent intergovernmental organization
>> of 12 oil-exporting developing nations that coordinates
>> and unifies the petroleum policies of its Member Countries".
>
I can rewrite it to make it clearer:
To join OPEC you have to be an oil-exporting developing nation.
(And whatever else they don't tell you about :) Please note that
typically organisations that operate as cartels do not put out big
flashing banners advertising CARTEL!!! JOIN HERE!!!! ... so it is up to
the public to decide this question.)
>> If you're an oil-consuming nation, you're out of luck.
--------------------^^^^^^^^^----------------^^^^^^^^^^^
carets and sticks :D
> http://cabforum.org/forum.html has the membership criteria at the bottom
> of the page.
>
> In what way does an organization avoid your charge of being a cartel,
Let's look at the definition on wikipedia (fwiw):
=====================
A cartel is a formal (explicit) agreement among competing firms. It is a
formal organization of producers and manufacturers that agree to fix
prices, marketing, and production.[1]
=====================
Are the members all supply-side firms? Yes.
=====================
Cartels usually occur in an oligopolistic industry, where there is a
small number of sellers and usually involve homogeneous products.
=====================
Do we have a homogoneous product? Yes, certs are homogoneous.
Is there a small number of sellers? Yes, around 6 or so firms dominate
the market, and 3 are in the leading group of firms.
(It's also possible to have buy-side cartels, consider supermarket chains.)
=====================
Cartel members may agree on such matters as price fixing, total industry
output, market shares, allocation of customers, allocation of
territories, bid rigging, establishment of common sales agencies, and
the division of profits or combination of these.
=====================
What is the method by which production is controlled? By means of the
two documents EVG and BR which are binding compliant, which includes
further stipulations within.
=====================
The aim of such collusion (also called the cartel agreement) is to
increase individual members' profits by reducing competition.
=====================
(Which leads to a speculative case, which isn't really germane.)
So how to avoid any suspicion of cartel? Well, the first way this is
done is to have buyer representation and power in decision making.
(But you've ruled that out:)
> without having membership open to anyone and everyone with no criteria
> whatsoever?
A second way would be to have recommendations not requirements. Right
now, everything is structured for binding compliance (save for a few
marketing comments that it isn't binding, but the written word, actions
and structure speak louder than marketing).
Thirdly, once you have recommentations, establish a brand to support the
recommendations, not a blanket insistence that all follow this. E.g.,
EV Guidelines is like a brand, nobody need follow it, and browser remain
at liberty in theory to add a "blue brand" and a "purple brand". (BR is
not a brand, because it's binding.)
But, frankly, it is *very difficult* to avoid the suspicion of cartel if
there is no open membership, and one side of the buy-sell divide wields
full power. This is why the IETF established their open forums and
their concept of rough consensus; so that buyer groups could mob the
forums and shift it when sellers were getting too powerful.
Even if every member of CABForum were to actually *want to offer
something of interest to users* this would not sustain in the long term.
This is why we look at the incentives of organisations. Without the
user representation, there is no way to stop the inevitable slide into
CA-oriented behaviour.
>>> In addition, no document issued by CABForum is, in itself, binding on
>>> anyone.
>>
>> BR1 disagrees with you.
>>
>> ======
>> The Baseline Requirements for the Issuance and Management of
>> Publicly-Trusted Certificates describe a subset of the requirements that
>> a Certification Authority must meet in order for its Certificates to be
>> Publicly Trusted.
>> ======
>>
>> Mozilla intends to adopt, which makes it binding.
>
> Right. But whether Mozilla adopts it or not is not in the CAB Forum's
> control.
Mozilla has entered into CABForum. Mozilla is a member of CABForum.
From the outside, all we see is CABForum. At a minimum, if Mozilla
agrees to the binding, then it will always carry the conflict of
interest. At a maximum, it's all the same, Mozilla is operating as
CABForum, it was all agreed beforehand.
This is the problem with entering into a cartel. Closed door
discussions, no public scrutiny ... decisions foistered on a public
buyer group.
(To be fair, I see a claim that Mozilla representatives insisted that
the document must be presented to this group. Ok, so maybe your heart
is in the right place. But, that doesn't stop the actions of the
cartel, if such is really what is happening. That just means Mozilla is
a drempel, a little barrier on the way to success.)
>> Presumably all other
>> CAs are in agreement. This makes it a CABforum binding document.
>
> The language in BR1 is loose; what it should probably say is:
>
> "The Baseline Requirements for the Issuance and Management of
> Publicly-Trusted Certificates describe a subset of the requirements that
> a Certification Authority complying with it must meet in order for its
> Certificates to be Publicly Trusted by an entity requiring compliance."
So we're agreed the intention is a binding document.
And we're agreed that Mozilla and other vendors intend to endow the
CABForum with the ability to define what means "Publicly Trusted."
iang
Ian G
> Jean-Marc Desperrier wrote:
>> In the case of such a private sub-CA as described by Michael, I think
>> there should be a name-constraint that allows it only to issue
>> certificates for it's own domain.
>
> To tell you all something about the real world:
>
> After the last merger the company running this sub-CA has approx. 50000
> registered domains. How do you want to put these in a name constraint? For
> business reasons the CA is interested to establish a sub-CA constraint in
> contracts but there's no real chance to keep up with the list of registered
> domains. So this is blurry.
Right, one of the CAs made this point too, some private sub-CAs won't be
able to deal with name contstraints.
> To make matters worse the business units are free to choose any domain hoster
> they want (the out-sourcing religion rules here). So the guy approving the
> CSRs has to do conduct domain validation just like any other public CA.
> Actually he's doing a good job and I personally trust him much more than any
> other pre-installed CA. But in general this sub-CA has the power to issue any
> cert it wants.
According to a compromise that was posted earlier, audit & policy and
CPSs and so forth cover his sub-CA as if he was a CA. And we get to
read all about how it is done.
So, either name-constraints, or full audit & policy coverage. Until we
come up with some other way to fill that gap.
As you know this guy, can you ask him to identify the documentation, the
audits, the opinions, etc?
(It's a very useful data point, something that could well inform us.)
iang
Gervase Markham
> =====================
> A cartel is a formal (explicit) agreement among competing firms. It is a
> formal organization of producers and manufacturers that agree to fix
> prices, marketing, and production.[1]
> =====================
>
> Are the members all supply-side firms? Yes.
But there are no agreements to fix prices, marketing or production.
Heck, an agreement to fix marketing might have helped us to squash some
of the more unhelpful "green bar" messages surrounding EV. But we don't
have one, so we can't.
> =====================
> Cartels usually occur in an oligopolistic industry, where there is a
> small number of sellers and usually involve homogeneous products.
> =====================
>
> Do we have a homogoneous product? Yes, certs are homogoneous.
>
> Is there a small number of sellers? Yes, around 6 or so firms dominate
> the market, and 3 are in the leading group of firms.
There are not a small number of sellers. My impression is that a
reasonable number of companies have sufficient root ubiquity to compete
with the large ones. Am I mistaken? If not, let me propose an
alternative straw-man theory for you to refute: "those companies are
dominating because they serve their customers better".
> =====================
> Cartel members may agree on such matters as price fixing, total industry
> output, market shares, allocation of customers, allocation of
> territories, bid rigging, establishment of common sales agencies, and
> the division of profits or combination of these.
None of these things are controlled by CAB Forum.
> =====================
>
> What is the method by which production is controlled? By means of the
> two documents EVG and BR which are binding compliant, which includes
> further stipulations within.
These documents do not control levels or amounts of production. They
control methods of production, but only insofar as the relying parties
("customers"?) require it.
>> without having membership open to anyone and everyone with no criteria
>> whatsoever?
>
> A second way would be to have recommendations not requirements. Right
> now, everything is structured for binding compliance (save for a few
> marketing comments that it isn't binding, but the written word, actions
> and structure speak louder than marketing).
They are recommendations. They only become requirements if the browsers
or other relying parties choose to make them so. We could choose to not
adopt the BR - but given that they contain a load of stuff we want, that
would be a somewhat odd thing to do IMO.
> Thirdly, once you have recommentations, establish a brand to support the
> recommendations, not a blanket insistence that all follow this. E.g., EV
> Guidelines is like a brand, nobody need follow it, and browser remain at
> liberty in theory to add a "blue brand" and a "purple brand". (BR is not
> a brand, because it's binding.)
They are at such a liberty, in theory.
>> Right. But whether Mozilla adopts it or not is not in the CAB Forum's
>> control.
>
> Mozilla has entered into CABForum. Mozilla is a member of CABForum. From
> the outside, all we see is CABForum. At a minimum, if Mozilla agrees to
> the binding, then it will always carry the conflict of interest. At a
> maximum, it's all the same, Mozilla is operating as CABForum, it was all
> agreed beforehand.
I don't follow your argument here at all.
> So we're agreed the intention is a binding document.
>
> And we're agreed that Mozilla and other vendors intend to endow the
> CABForum with the ability to define what means "Publicly Trusted."
No. Mozilla defines what Mozilla trusts; we do that in a shared document
because having different documents for each relying party, all saying
the same thing, would be pointless.
Mozilla reserves the right both to waive requirements in the BR, and to
add additional requirements.
Gerv
Kyle Hamilton
> On 25/04/11 02:29, Ian G wrote:
>>
>> A cartel is a formal (explicit) agreement among competing firms. It is a
>> formal organization of producers and manufacturers that agree to fix
>> prices, marketing, and production.[1]
>> =====================
>>
>> Are the members all supply-side firms? Yes.
>
Er, EV is a marketing tactic. There's a formal agreement for it.
(Don't believe me? What are the "EV Guidelines"? What is the "green
bar" concept at all? They are nothing more than agreed-upon ways to
market products that the buyers are forced to purchase to get the
high-trust certificate presentation.)
There's also a mandate to fix production to be -precisely compliant-.
That's "fixing", and it's also in a formal agreement -- the EV
Guidelines and the Basic Requirements are both formal agreements.
And, with a very small number of CAs, the fixed supply is going to be
tiny while the demand is fixed by Mozilla/Microsoft/Opera/whoever else
as a prerequisite to being privileged with the capacity to encrypt
their traffic without being the target of a denigrating, blanket
statement by Mozilla that they are not legitimate because they're not
playing by Mozilla's rules.
You're fixing the content of what can be said, by mandating that
production adhere to your fiat. You're fixing the format of how it's
said. You're fixing the idea of "green bar" -- no matter how it was
interpreted by the various vendors -- as a marketing tactic ostensibly
to the end users, but really to the businesses and sites.
Get off your high horse, Gerv. Or climb down out of the ivory tower
you're in. Or whatever metaphor you want to use. Your management of
this program as an exclusive club with a close friend you don't want
to kick out is severely, overtly conflicted. It is also not in the
least interests of the individual, the business that deals with the
individual, or the CA business that actually wants to be associated
with a noble profession instead of a money-grubbing cesspool of crabs.
Remember the adage: "One bad apple spoils the entire barrel." Are you
the bad apple in Mozilla?
-Kyle H
Eddy Nigg
> Er, EV is a marketing tactic. There's a formal agreement for it.
> (Don't believe me? What are the "EV Guidelines"? What is the "green
> bar" concept at all? They are nothing more than agreed-upon ways to
> market products that the buyers are forced to purchase to get the
> high-trust certificate presentation.)
Well, you can't have it both ways - on one hand shout about the lax
requirements and weak controls at the CAs and on other hand not setting
them in first place. The EV guidelines as the Basic Requirements today
try to regulate and improve exactly that. Some CAs maybe don't need it,
some others certainly do :-)
> You're fixing the idea of "green bar" -- no matter how it was
> interpreted by the various vendors -- as a marketing tactic ostensibly
> to the end users, but really to the businesses and sites.
I want even more than that, for example differentiation between DV and
IV/OV (for non-EV certs). I want to be able to signal to the relying
parties what kind of validation the certificate holder underwent. And I
guess we'll get there eventually.
You can look at it as marketing, I look at it from a different angle.
> Remember the adage: "One bad apple spoils the entire barrel." Are you
> the bad apple in Mozilla?
Is this necessary?
Kyle Hamilton
> On 04/27/2011 05:43 AM, From Kyle Hamilton:
>
> requirements and weak controls at the CAs and on other hand not setting them
> in first place. The EV guidelines as the Basic Requirements today try to
> regulate and improve exactly that. Some CAs maybe don't need it, some others
> certainly do :-)
I certainly can.
There is no effective regulation. There is no central authority which
can grant or revoke authority to operate. As you and other CA
representatives, as well as Gerv, have pointed out, if an entity wants
to be audited to CABF's standards it can have a seat at the table.
Mozilla is in the position of regulator, but it's not acting like one
-- it's bending over backwards to bend its rules as far as possible to
make sure that someone can stay in the club after proving that they're
too incompetent to be allowed to stay in the club.
And the individual consumer, the one who actually uses Firefox as a
platform upon which to make purchases, is the one who loses.
Considering that SSL and TLS were designed for a regulatory regime for
merchants a la the VISA and MasterCard payment networks, the lack of a
strong central organization willing to revoke an entity's
authorization to operate in the network is nothing more than
attempting to maintain the wild west with the according "pseudo-state"
which has grown up around it. It's illegal racketeering.
> I want even more than that, for example differentiation between DV and IV/OV
> (for non-EV certs). I want to be able to signal to the relying parties what
> kind of validation the certificate holder underwent. And I guess we'll get
> there eventually.
I would of course like something like that as well.
Of course, I'd also like CAs to start asserting that they have
key-binding statements sworn under penalty of perjury. I'd also like
CAs to come up with a single, deterministic way to express what
statements the enrollee wanted to be able to have said about them by
the CA.
I don't hold any hope of any of these happening before the next ice age.
> You can look at it as marketing, I look at it from a different angle.
Wow, you are really, truly not seeing that this is an artificial
market. Green-bar standards came about because there was a hue and
cry over >100 CA certificates being trusted for all purposes by
Mozilla.
Mozilla created this mess, and I honestly don't think that Mozilla is
competent to fix it.
>> Remember the adage: "One bad apple spoils the entire barrel." Are you
>> the bad apple in Mozilla?
>
> Is this necessary?
Yes, actually, it is.
Gervase is the one who seems to be running the CA policy and program
nowadays. Kathleen makes recommendations, but I haven't seen Frank
Hecker here in a long time.
Gervase is also the one who is completely ignoring every piece of
sarcasm in Honest Achmed's bug application. NOBODY believes that
Mozilla can be trusted to run its root program in accordance with its
published policies. It all but states that it will remove roots from
the repository when it impacts the user's security -- and this falls
square into that category -- but it's not following through.
Let's tally this up:
1) The decision to keep the third bug (about Comodo's
completely-compromised RA) private was made in meetings in which Gerv
was undoubtedly a member.
2) The decisions in the first, second, and third instances were all
essentially delivered by him.
3) Gerv suggests that "certificates issued after a certain date will
be invalid". I would like to understand how he thinks this can be
technically enforced -- there is no trusted timestamp as to the
certification date, there exist only the notBefore and notAfter
fields. This would end up giving Comodo an extra 39 months to operate
before anything really came down the pike. To restate this, that's
three years and three months that Comodo can still extort money from
its current customers. (I derive that date from the EV certification
length, the one which can be technically checked by the SSL
Observatory.)
These are all major, MAJOR issues. And all of them, not
coincidentally, related to Comodo. Gerv is, baldly, protecting Comodo
and its business.
Just how much does he chum around with the boys from Comodo? He's
certainly protecting them like he's got... oh, an investment or
something.
Once is happenstance. Twice is coincidence. Three times is conspiracy.
-Kyle H
Moudrick M. Dadashov
isn't it time to have a minimal set of rules not only for organizations
(CAs), certificates but also for people participating on this list? The
list supposed to focus on ideas and principles and not on personal
accusations.
I'm in no way for censorship but at least a couple of words on preventing
personal attacks like this would be in the interests of everyone on the
list.
Thanks,
M.D.
>>> Remember the adage: "One bad apple spoils the entire barrel." Are you
>>> the bad apple in Mozilla?
>>
Rob Stradling
> Hi Kathleen,
>
> isn't it time to have a minimal set of rules not only for organizations
> (CAs), certificates but also for people participating on this list?
Moudrick, Mozilla have already done this:
https://www.mozilla.org/about/forums/etiquette.html
> The list supposed to focus on ideas and principles and not on personal
> accusations.
Agreed.
> I'm in no way for censorship but at least a couple of words on preventing
> personal attacks like this would be in the interests of everyone on the
> list.
Two of the Mozilla etiquette rules seem particularly relevant here...
"Be civil.
No personal attacks. Do not feel compelled to defend your honor in public.
Posts containing personal attacks may be removed from the news server."
"Let sleeping dogs lie.
It's tempting to revisit controversial decisions you disagree with, but
it's rarely productive to do so, since it almost always results in the same
heated, lengthy, and time/energy draining discussions leading to the same
conclusion that was reached in the last round.
Therefore, for issues already raised, discussed, and decided upon, reopen
the discussion only if you have significant new information that would
reasonably prompt reconsideration of the original decision."
<snip>
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Moudrick M. Dadashov
M.D.
Ian G
On 26/04/11 9:39 PM, Gervase Markham wrote:
> On 25/04/11 02:29, Ian G wrote:
>> =====================
>> A cartel is a formal (explicit) agreement among competing firms. It is a
>> formal organization of producers and manufacturers that agree to fix
>> prices, marketing, and production.[1]
>> =====================
>>
>> Are the members all supply-side firms? Yes.
>
> But there are no agreements to fix prices, marketing or production.
Yes there are: I suggest that BR + EVG do indeed "fix" the "production"
of certs.
> Heck, an agreement to fix marketing might have helped us to squash some
> of the more unhelpful "green bar" messages surrounding EV. But we don't
> have one, so we can't.
:)
>> =====================
>> Cartels usually occur in an oligopolistic industry, where there is a
>> small number of sellers and usually involve homogeneous products.
>> =====================
>>
>> Do we have a homogoneous product? Yes, certs are homogoneous.
>>
>> Is there a small number of sellers? Yes, around 6 or so firms dominate
>> the market, and 3 are in the leading group of firms.
>
> There are not a small number of sellers. My impression is that a
> reasonable number of companies have sufficient root ubiquity to compete
> with the large ones. Am I mistaken?
Sorry, ok, to be more precise. Do we have a small number of sellers
*that control a majority of sales in the market* ?
Yes of course there are a 100 CAs. But according to published
statistics, one group (with 3 brands) ships between half to three
quarters of the product. 6 brands probably control close to 90%.
http://en.wikipedia.org/wiki/Oligopoly
(Please, can someone post current stats?)
> If not, let me propose an
> alternative straw-man theory for you to refute: "those companies are
> dominating because they serve their customers better".
Cute, but not supported by the facts: The lead firm was the 1st mover,
indeed the lead firm was created by the people who were there at the
table forcing Netscape to add in certs and break it out of Netscape
control. One could suggest that the lead firm created the market.
That firm managed to grab and hold on and then made out like bandits on
the stock exchange (I wish I was there...). It then bought out two of
the other leading brands.
So, market events & facts suggests oligopoly behaviour.
So, ask yourself another question: who started CAB Forum?
(I feel a James Bond moment, "I could tell you, but then I'd have to
shoot you..." :P )
>> =====================
>> Cartel members may agree on such matters as price fixing, total industry
>> output, market shares, allocation of customers, allocation of
>> territories, bid rigging, establishment of common sales agencies, and
>> the division of profits or combination of these.
>
> None of these things are controlled by CAB Forum.
"may agree on such matters..." Apparently CAB Forum have agreed on BR
and EVG.
>> =====================
>>
>> What is the method by which production is controlled? By means of the
>> two documents EVG and BR which are binding compliant, which includes
>> further stipulations within.
>
> These documents do not control levels or amounts of production. They
> control methods of production,
Yes. This is where "legal" views of cartels separates from "economics"
views of cartels. The latter is far more subtle and descriptive, the
former is more prescriptive and measurable. Because it needs to be.
I'm talking about the economics. Because that's what matters to the
end-users that are served by this forum.
> but only insofar as the relying parties
> ("customers"?) require it.
You said earlier that the 8 (?) vendors would need to require it. They
are all members of CAB Forum. So, CAB Forum controls it, insofar as CAB
Forum controls it.
I'm curious: do the vendors get the same weight of voting as the CAs?
(Another 007 moment :)
>>> without having membership open to anyone and everyone with no criteria
>>> whatsoever?
>>
>> A second way would be to have recommendations not requirements. Right
>> now, everything is structured for binding compliance (save for a few
>> marketing comments that it isn't binding, but the written word, actions
>> and structure speak louder than marketing).
>
> They are recommendations. They only become requirements if the browsers
Yes, CAB FOrum members. Recommendations that CAB Forum members follow
their own documents ... which say that CAB Forum members *must* follow.
> or other relying parties choose to make them so.
Curious #3: who would that be?
> We could choose to not
> adopt the BR - but given that they contain a load of stuff we want, that
> would be a somewhat odd thing to do IMO.
:)
>> Thirdly, once you have recommentations, establish a brand to support the
>> recommendations, not a blanket insistence that all follow this. E.g., EV
>> Guidelines is like a brand, nobody need follow it, and browser remain at
>> liberty in theory to add a "blue brand" and a "purple brand". (BR is not
>> a brand, because it's binding.)
>
> They are at such a liberty, in theory.
Yeah, in theory :(
>>> Right. But whether Mozilla adopts it or not is not in the CAB Forum's
>>> control.
>>
>> Mozilla has entered into CABForum. Mozilla is a member of CABForum. From
>> the outside, all we see is CABForum. At a minimum, if Mozilla agrees to
>> the binding, then it will always carry the conflict of interest. At a
>> maximum, it's all the same, Mozilla is operating as CABForum, it was all
>> agreed beforehand.
>
> I don't follow your argument here at all.
Anything Mozilla does to support the document is subject to the claim
that it was already agreed and Mozilla is a puppet of CABForum.
>> So we're agreed the intention is a binding document.
>>
>> And we're agreed that Mozilla and other vendors intend to endow the
>> CABForum with the ability to define what means "Publicly Trusted."
>
> No. Mozilla defines what Mozilla trusts;
The onus is on Mozilla to prove that.
> we do that in a shared document
> because having different documents for each relying party, all saying
> the same thing, would be pointless.
Except, the policy disagrees. It includes several audit criteria, and
it has recently added EVG.
It might be *controversial* and *unpleasant* that Mozilla's policy
supports a choice in audit criteria, but it's hardly pointless.
It is the case that every document that has ever hit the table has been
flawed. From WebTrust (which has held JUNK status since 2003) all the
way through the Prussian ETSI invasion, via the quixotic-but-perceptive
DRC to the party-like-it's-1999 EVG.
In such a world, for end-users at least, there is every point in
competition for guidelines, criteria, processes, procedures, claims,
contracts, ... indeed all of browsing security.
(Something that CAB Forum will fight to the death over.)
> Mozilla reserves the right both to waive requirements in the BR, and to
> add additional requirements.
AH! Well, we're not privy to Mozilla's "position" nor any of CAB
Forum's debates... Please say more :)
iang
Ian G
> There is no effective regulation.....
> Mozilla is in the position of regulator, but it's not acting like one
> -- it's bending over backwards to bend its rules as far as possible to
> make sure that someone can stay in the club after proving that they're
> too incompetent to be allowed to stay in the club.
There are two schools of thought as to what a regulator does. The more
popularist view has it that a regulator serves some defined end-user
body public. The more cynical view is that the regulator serves the
defined seller industry. I think it might have been Stiglitz who made
this observation first, but I suppose it isn't a surprise.
> And the individual consumer, the one who actually uses Firefox as a
> platform upon which to make purchases, is the one who loses.
Who are they? I frequently point out they aren't here, only to be told
"I'm here!" by about 2 people :)
> Of course, I'd also like CAs to start asserting that they have
> key-binding statements sworn under penalty of perjury. I'd also like
> CAs to come up with a single, deterministic way to express what
> statements the enrollee wanted to be able to have said about them by
> the CA.
I just want competition in models. But that's been consistently blocked
by Mozilla and all other vendors.
> I don't hold any hope of any of these happening before the next ice age.
Nope. And, it's coming.
>> You can look at it as marketing, I look at it from a different angle.
>
> Wow, you are really, truly not seeing that this is an artificial
> market. Green-bar standards came about because there was a hue and
> cry over>100 CA certificates being trusted for all purposes by
> Mozilla.
Au contraire! Green-bar standards came about because Gerv introduced
the yellow bar. Which was to do with phishing, addressing the *user
interface* questions. Oh what a tangled web we weave...
> Yes, actually, it is.
Sigh. I understand the sentiment, but it won't get you anywhere. It
matters no matter how right it might be, being rude will just distract,
and it will turn everyone against you.
> Gervase is the one who seems to be running the CA policy and program
> nowadays. Kathleen makes recommendations, but I haven't seen Frank
> Hecker here in a long time.
Frank's retired. Kathleen holds the chair.
But yes, it seems that Gerv champions the cause of CAB Forum. OK, whatever.
But it also seems that CAB Forum is *not popular* in Mozilla. I wish
more people would speak up. What to do? We can't do much more than
insist on public open access to this debate, and a voice.
> These are all major, MAJOR issues. And all of them, not
> coincidentally, related to Comodo. Gerv is, baldly, protecting Comodo
> and its business.
Sheesh.... and I thought I was the one protecting Comodo :P
iang
Eddy Nigg
> Mozilla is in the position of regulator, but it's not acting like one
Mozilla probably tries to, but it's not alone. Breaking 10% of the
secured sites needs a lot of justification apparently. Especially if
others opted not to do that either.
However I also noted that the browser vendors including Mozilla haven't
set specific requirements on RAs (again, some don't need to be told what
to do). Now that the heat is on them, they did. Also the basic
requirements came unfortunately a half year too late, it could have been
prevented.
> Wow, you are really, truly not seeing that this is an artificial
> market. Green-bar standards came about because there was a hue and
> cry over>100 CA certificates being trusted for all purposes by
> Mozilla.
Here again - one can't complain that there aren't enough alternatives
and the CAs are acting as a Monopoly and on the other hand complain that
there are too many CAs. Make up your mind, but I believe today's world
is better than that of pre-2005.
> Mozilla created this mess, and I honestly don't think that Mozilla is
> competent to fix it.
And even though there is an effort to fix a lot of it, pre-2005 has seen
so much more crap out there. Today we have advanced here at Mozilla
quite a bit thanks to the effort of many participating. Besides that, I
believe that another software vendor has even a bigger list of trusted
CAs. So this isn't Mozilla's problem only.
> Gervase is also the one who is completely ignoring every piece of
> sarcasm in Honest Achmed's bug application.
So did I mostly. Nelson's bug was much more original and we have past
that stage a long time ago.
> NOBODY believes that
> Mozilla can be trusted to run its root program in accordance with its
> published policies. It all but states that it will remove roots from
> the repository when it impacts the user's security -- and this falls
> square into that category -- but it's not following through.
But is removing a root the only defense? True, I'd have set the
requirements on RAs crystal clear a while ago with the previous
incidents. I tried to have them set, but failed to have them included in
the policy and most of the issues that were raised landed in the
"Problematic Practices". And the folks from Comodo and other CAs pointed
out that the "Problematic Practices" are not policy. So crying foul
today doesn't work.
> (I derive that date from the EV certification
> length, the one which can be technically checked by the SSL
> Observatory.)
If you found EV certificates that are valid for more than 27 month,
please forward them to me. Thanks.
> Gerv is, baldly, protecting Comodo and its business.
Might be, but for such accusations you probably have some evidence for it?
> Once is happenstance. Twice is coincidence. Three times is conspiracy.
:-)
Kyle Hamilton
>
> Two of the Mozilla etiquette rules seem particularly relevant here...
>
> "Be civil.
> No personal attacks. Do not feel compelled to defend your honor in public.
> Posts containing personal attacks may be removed from the news server."
>
> "Let sleeping dogs lie.
> It's tempting to revisit controversial decisions you disagree with, but
> it's rarely productive to do so, since it almost always results in the same
> heated, lengthy, and time/energy draining discussions leading to the same
> conclusion that was reached in the last round.
> Therefore, for issues already raised, discussed, and decided upon, reopen
> the discussion only if you have significant new information that would
> reasonably prompt reconsideration of the original decision."
Rob,
Here's the problem: we, the people of this mailing list, can't decide
anything, have only the barest of input into into the decisions which
are made, and most importantly can't veto decisions which have been
made by the employees of MoFo and MoCo. There is only the barest
veneer of legitimacy over a corrupt process run by people and an
organization which have over the past several years repeatedly been
asked "What kind of failure does it take to get a CA de-listed?" and
have never answered.
Evidently, even gross negligence and baldly evident incompetence on
the part of Comodo's threat modelers/risk assessors isn't enough. (It
is a well-known security adage that it's not enough to trust the link
and expect that the only things that are going to come down it are the
things legitimately expected -- the link's subversion must always be
accounted for.)
Every security flaw exists because of untested, unproven assumptions.
Comodo assumed that the only signing requests that were going to come
in under those credentials were legitimate, and so it didn't test
their content. It didn't even implement Eddy Nigg's (eminently
reasonable) suggestion to simply blacklist requests for high-profile
domains that it didn't already have a contract with -- and it also
didn't implement even the barest of checks that the name requested was
useful or even valid.
In other words, it issued certificates which did not comply with
Mozilla's technical requirements, in addition to the breach of trust.
I still have yet to see Comodo, or even Mozilla for that matter,
answer the question I asked on March 30: Did you, and if you did when
did you, contact the CIA and/or MI-6 when you thought it was a
state-level attacker? If you didn't, did you (and when did you) call
the police to report an intrusion into a trusted computer system and
forged high-value certificates?
Did you even -think- to bring the state into an action by another
suspected state-level attacker? Or was that announcement simply an
attempt to distract us from our legitimate inquest? (You claim to act
in a quasi-fiduciary role, and we have the responsibility to know what
our fidicuiaries are doing on our behalf.)
There's far too much stink here for it to be just Febreezed away, and
I'm starting to think that it's the people involved who have made the
situation so thoroughly rotten.
Thus, to reiterate my question to the other party involved: what
relationship does Gerv have with Comodo? What relationship does
Comodo -- and/or its management -- have with Gerv?
I suspect that Gerv has independently contracted his expertise in
trust management issues to Comodo, and is thus independently assured
of its continued legitimacy. If this is the case, I would be willing
to accept that. (If it isn't the case, I certainly suggest that.)
But the reason for the decision needs to be disclosed, and needs to be
better than "it's too big to fail and removing it would inconvenience
the user too much" as follows from the brittle nature of Mozilla's
model). Otherwise, we the individual users are never going to be able
to have faith in Mozilla's trust management system again.
As an aside: There were exactly two completely serious comments on the
Honest Achmed bug. One was from Eddy Nigg, and the other was from
Gerv. Everything else was complete snark. Especially the one which
suggested it was a duplicate of Comodo's inclusion request. (Hi B!)
-Kyle H
Rob Stradling
You addressed me personally, but I don't believe any of your criticisms were
directed at me personally. (Although you did accuse me of "much excellent
thinking" in another thread recently ;-) ).
If my employer's "threat modelers/risk assessors" or Management Team wish to
"defend their honour in public" and/or answer any of your questions, then that
is up to them.
I am not aware of any special relationship between Comodo and Gerv.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@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.
Kyle Hamilton
I addressed you personally because you are the point of contact for
your company in this forum, no other reason.
If it needs to be expressed: I do not believe that you (personally)
are doing anything other than your very best job for the company by
which you are employed. I do not believe that you (personally) are
incompetent, and I do not believe that you (personally) are doing
anything to answer for. You're doing nothing but an exemplary job in
the face of a completely undesirable position, and I truly wish that I
did not have to take the position I must in opposition.
Your employer has, unfortunately, exhibited itself as a state which
has grown up around core principles which have caused the security and
validity of its assertions to be brought into question; your employer
has also shown itself to have been completely blind to a
well-understood threat, and has thus unfortunately besmirched its own
reputation and trustworthiness beyond short-term repair.
The only benefit to the individual user of Mozilla's software of
having many, many CAs in the program is redundancy, in case any one of
them shows itself to be untrustworthy. That argument only holds if
the action taken when a member CA exhibits untrustworthiness is to
remove the trust.
The only benefit to any individual user of Mozilla's software of
leaving Comodo in the program is convenience, and Mozilla's
certificate policy does not mention convenience as any portion of its
core mission.
This is why "2B2F" leaves such a poor taste -- Mozilla is run by the
people who inherited the legacy of Netscape, and Netscape's reasons
for moving things in the path they did was for the benefit of a single
industry (payments) without really examining any of the security
threats that its individual users actually face, and also without
really addressing any of the security threats that its individual
users actually face.
To bring things into perspective, "malware" is a term which was
developed after the year 2000, but Netscape's risk assessment and
design was created several years before then. The idea of "if you
know from whence a particular software came you know if you can trust
it" is nothing more than an implementation of the principle "trust the
channel, thus the message".
This is why I have the issues that I do with this situation. Netscape
created a known-brittle model, the flaws were repeatedly discussed
both before and after Netscape was eaten by AOL, and then Mozilla spun
out. No change was ever made to the model.
Now, in the face of a situation worthy of bringing out the Big Stick,
Mozilla's saying that it's not bringing out the Stick because it would
be too inconvenient for its users. This inconvenience was caused by
Mozilla, and now Mozilla is punishing its users for its own lack of
foresight.
This is why I perceive this situation as criminal: Mozilla was made
aware of the problems, it failed to act; it was made aware of the
problems again the first time Comodo suffered an RA-related failure,
it failed to act; it was made aware of another Comodo RA-related
failure, and failed to act; and it is now not failing to act because
of any argument which can be made for "security", it's failing to act
because it failed to create a state which is durable in case of
failure to meet expectations and assumptions.
Mozilla's own past negligence is preventing current effective and
correct action from being taken.
-Kyle H
Kyle Hamilton
I note also that you ignored the question AGAIN.
Here it is, quoted AGAIN:
>> I still have yet to see Comodo, or even Mozilla for that matter,
>> answer the question I asked on March 30: Did you, and if you did when
>> did you, contact the CIA and/or MI-6 when you thought it was a
>> state-level attacker? If you didn't, did you (and when did you) call
>> the police to report an intrusion into a trusted computer system and
>> forged high-value certificates?
>>
>> Did you even -think- to bring the state into an action by another
>> suspected state-level attacker? Or was that announcement simply an
>> attempt to distract us from our legitimate inquest? (You claim to act
>> in a quasi-fiduciary role, and we have the responsibility to know what
>> our fidicuiaries are doing on our behalf.)
Answer, or Comodo and Mozilla are going to be the subject of records
act requests to MI-6 and the CIA.
If you answer "no, Comodo and Mozilla didn't" now, you will at least
show that you've got a core that might be worth trusting. If you
answer "yes they did" and you are found out not to have, you'll have
destroyed your own trustworthiness through a public lie.
If you don't answer at all, and you are found to have not, you will
have destroyed your own trustworthiness through a public failure to
disclose material information regarding your competence and
trustworthiness.
Frankly? I don't believe you did. I expect that when I make my
request to the CIA and MI-6, they'll give me a "no, we were never
contacted" answer.
And if you did, and aren't disclosing it, then you're still failing to
disclose material information regarding your competence and
trustworthiness, and are proving yourself to be untrustworthy.
For the user, Comodo's untrustworthiness is a lot easier to recover
from than Mozilla's.
Ian G
On 29/04/11 7:29 AM, Kyle Hamilton wrote:
...
> The only benefit to the individual user of Mozilla's software of
> having many, many CAs in the program is redundancy, in case any one of
> them shows itself to be untrustworthy. That argument only holds if
> the action taken when a member CA exhibits untrustworthiness is to
> remove the trust.
I don't think so. It only holds if the individual user can choose.
Shutting the barn door after the horse has bolted will lead to all sorts
of wierd effects, such as developing self-slamming doors, redundant
ganged doors, moving horses to other barns without doors, and teaching
horses to slam doors as they bolt.
All of these things can work. The problem is as usual elsewhere.
> The only benefit to any individual user of Mozilla's software of
> leaving Comodo in the program is convenience, and Mozilla's
> certificate policy does not mention convenience as any portion of its
> core mission.
>
> This is why "2B2F" leaves such a poor taste -- Mozilla is run by the
> people who inherited the legacy of Netscape, and Netscape's reasons
> for moving things in the path they did was for the benefit of a single
> industry (payments) without really examining any of the security
> threats that its individual users actually face, and also without
> really addressing any of the security threats that its individual
> users actually face.
>
> To bring things into perspective, "malware" is a term which was
> developed after the year 2000, but Netscape's risk assessment and
> design was created several years before then. The idea of "if you
> know from whence a particular software came you know if you can trust
> it" is nothing more than an implementation of the principle "trust the
> channel, thus the message".
>
> This is why I have the issues that I do with this situation. Netscape
> created a known-brittle model, the flaws were repeatedly discussed
> both before and after Netscape was eaten by AOL, and then Mozilla spun
> out. No change was ever made to the model.
Netscape adopted the model, they didn't create it. I've written
elsewhere that it is unlikely they could have avoided adopting the model.
In my researches in the mid 00's I came across several reasons why
Mozilla could not change the model. Firstly, Netscape got very beaten
up in the Microsoft wars, and one of the defences it adopted was a
slavish adoption of open standards. Which in effect meant a wholesale
outsourcing of architecture. As a result and secondly, they employed or
attracted no security architects at that level; all the security people
were builders and maintenance-side engineers. Which is a different
mindset, it's more about understanding and implementing than tearing
things apart and starting again. A third issue is that the CA/PKI desk
in Mozilla is a quite small part of the entire security makeup. It's
not significant, you won't ever get the heavy hitters in Mozilla
involved in it.
(One of the things I suggested was that they create a position for a
Security Officer (like a CISO). Apparently that was taken up at some
point, but I never saw how it went. I speculate (with no info at all)
that it hit the third effect above.)
> Now, in the face of a situation worthy of bringing out the Big Stick,
> Mozilla's saying that it's not bringing out the Stick because it would
> be too inconvenient for its users. This inconvenience was caused by
> Mozilla, and now Mozilla is punishing its users for its own lack of
> foresight.
>
> This is why I perceive this situation as criminal: Mozilla was made
> aware of the problems, it failed to act; it was made aware of the
> problems again the first time Comodo suffered an RA-related failure,
> it failed to act; it was made aware of another Comodo RA-related
> failure, and failed to act; and it is now not failing to act because
> of any argument which can be made for "security", it's failing to act
> because it failed to create a state which is durable in case of
> failure to meet expectations and assumptions.
>
> Mozilla's own past negligence is preventing current effective and
> correct action from being taken.
Well, maybe. That's for a court to decide. And you are reaching too
far because Mozilla has not accepted certain or all of the premises.
However, where there's smoke there's fire. What has been the case is
that the CAs have run a certain legal and contractual regime which was
designed to favour their situation. Slowly, Mozilla has got to grasp
with that legal arrangement. Especially, the common claim is that the
vendor is the relying party in effect. This is now more or less
accepted wisdom (I claim).
2-3 years ago they rolled out a user agreement that limited their liability.
Now, you will notice in BR that there is a new contractual clause 17.2
that the CAs indemnify the vendors. This is a direct unwinding of the
"relying party" farce that emerged when the real-estate wars changed the
user model from choice to no-choice. Now, the vendors are more formally
the relying party as per their choice of the root, and they have the
legal protection to do that on behalf of their user public.
However, as far as I've seen it, this work has taken 5 years. The CAs
have fought it every step of the way, because it makes their position
more costly. (E.g., now, the CAs are not comfortable revealing their
contracts.) Quite how the clause 17.2 got through CAB Forum is an open
question that we in the open governance world will not know, but it is
one of the few bright spots in BR, and for that is welcome. Albeit in
the wrong place.
Unfortunately, there is more to do. And the reason that it will be hard
is that nobody in Mozilla will take on a fight where they have to lay
out the evidence of their own negligence before the world. They are
registered in California, after all.
So it's slow work.
Also, you don't want to go hitting on Comodo. They have done us a great
service by putting on the table real data about the weakness of the
model. We are best served by keeping them in business, and by
developing real data. Perverse as it is ... the only way we will ever
drag the model from the 1980s to now is if we break it so much that
people will start to accept it's out of the times.
Instead, say "this is the house you built, now live in it..."
iang
>> 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.
>>
Eddy Nigg
> Rob (and Gerv),
>
> I note also that you ignored the question AGAIN.
In the meantime, maybe this helps
https://bugzilla.mozilla.org/show_bug.cgi?id=653543
Gervase Markham
> So, ask yourself another question: who started CAB Forum?
CABForum participants occasionally argue about that :-). Melih of Comodo
likes to take the credit, but I'm not certain that's correct. I could
look back at my very old email and see who convened the first meeting.
But TBH, I don't think it's particularly important.
> You said earlier that the 8 (?) vendors would need to require it. They
> are all members of CAB Forum. So, CAB Forum controls it, insofar as CAB
> Forum controls it.
>
> I'm curious: do the vendors get the same weight of voting as the CAs?
>
> (Another 007 moment :)
No; the voting rules of CAB Forum are not a secret (as far as I know).
The wording is a bit more complex to deal with abstentions, and people
who are members but not active participants, but AIUI proposals need a
majority of active voting CA members and a majority of active voting
browser members voting in favour to pass. (I've recently asked for a
summary of them from Tim Moses of Entrust, who's the chairman, so if
this turns out to be wrong I'll let you know.)
Gerv