Web Browsers and Comodo Announce A Successful Certificate Authority Attack, Perhaps From Iran
Steve Schultze
current roundup:
http://freedom-to-tinker.com/blog/sjs/web-browsers-and-comodo-announce-successful-certificate-authority-attack-perhaps-iran
Eddy Nigg
> Many of you are probably already following this story.
....and we are waiting patiently for a posting by a Mozilla
representative here.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Kathleen Wilson
> On 03/23/2011 09:16 PM, From Steve Schultze:
>> Many of you are probably already following this story.
>
> ....and we are waiting patiently for a posting by a Mozilla
> representative here.
>
I appreciate your patience...
(I've been ill, so not online much the past couple of days.)
A good description about what happened has been posted here:
https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-fraudulent-https
Comodo has provided their summary of the events here:
http://blogs.comodo.com/category/it-security/
http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
We were informed by Comodo promptly, and they followed the Security Bugs
process: http://www.mozilla.org/projects/security/security-bugs-policy.html
The Security Bug is here:
https://bugzilla.mozilla.org/show_bug.cgi?id=642395
The bad certs were all revoked promptly, but blacklisting allows us to
cope with the possibility that an attacker might block OCSP if they
control the victim's network. OCSP failures aren't fatal by default
(though they do downgrade EV to DV) so we wanted to make sure these
certs never worked.
Mozilla requested that Comodo take the following actions.
1) Revoke the RA rights of the RA concerned. (Done)
2) Monitor their OCSP logs for evidence of use of these certificates, or
evidence that access to their OCSP responders is being blocked from
certain geographical locations
3) Publish a full account of exactly what happened. (See comodo.com
links above)
4) Provide compelling public evidence that:
- the root private key was not compromised
- the channel of mis-issuance is now shut
- all mis-issued certs have been found and listed
- the list of other certs to come through that channel recently has been
carefully audited, and representatives of each organization are
being/have been contacted to confirm correct issuance.
(partially complete, Comodo plans to engage WebTrust auditors)
5) Move, in a short time-frame (small number of months) towards a model
where each RA issues from a separate subordinate CA certificate.
(started)
We are still evaluating the situation, and may request further action
from Comodo.
Additionally, this issue has brought several concerns about
implementation of CRL and OCSP to the forefront, and some new bugs have
been filed. Also, it turned out that an NSS-based fix for this instance
was not as simple as we would like. A new bug has been created for
improving NSS to allow us to add certs to the store which are
specifically untrusted:
https://bugzilla.mozilla.org/show_bug.cgi?id=642503
Comodo responded appropriately to this incident by revoking the
certificates immediately, and notifying the major browser vendors so
that more proactive actions could be taken.
This incident alone is concerning enough, but as we are all aware, there
are previous incidents that have been logged in Bugzilla regarding certs
issued within Comodo’s hierarchy, for example:
https://bugzilla.mozilla.org/show_bug.cgi?id=470897
https://bugzilla.mozilla.org/show_bug.cgi?id=526560
https://bugzilla.mozilla.org/show_bug.cgi?id=599856
Of particular note is the comment in
https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c68
"… 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."
We have asked Comodo to explain why this mechanism was not active (or
did not work) for this RA.
I am extremely concerned about the history of questionable certs being
issued within the Comodo hierarchy. One possible result is for Mozilla
to turn off all of the trust bits for the Comodo root certificates that
are included by default in NSS. However, I think that the CAs actions
in response to the most recent situation should also be taken under
consideration. It would have been much easier for the CA to not say
anything to browser vendors about their mistake – they had caught it
quickly and revoked the certs already. Comodo was very much aware of the
previous issues that had been logged in Bugzilla, and of the possible
outcome of making this mistake public. Regardless, Comodo chose to do
the right thing and disclose this situation to the browser vendors so
that they could also take action.
We could focus on punishment, but I think it would be more beneficial
for us to focus on actions that will prevent such mistakes in the
future. As well as sharing the lessons-learned, to help prevent other
CAs from making the same mistakes.
I ask the representatives of Comodo to contribute actively to this
discussion group. In particular, please described the actions Comodo is
taking now (e.g. the list of requested actions above), as well as the
actions that Comodo plans to take to prevent such a mistake from
happening again.
I have added a few items to
https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase
Under the heading “RAs and Subordinate CAs”
There are some practices, such as some roots signing end-entity certs
directly, that this incident has demonstrated should no longer be
allowed, and need to be corrected soon.
I am also following the CAB Forum and EFF SSL Observatory discussions on
this topic. So no need to copy info from them, unless there are specific
action items that pertain to Mozilla.
Kathleen
Steingruebl, Andy
> From: Kathleen Wilson
>
> 5) Move, in a short time-frame (small number of months) towards a model
> where each RA issues from a separate subordinate CA certificate.
> (started)
> https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase
> Under the heading “RAs and Subordinate CAs”
> There are some practices, such as some roots signing end-entity certs
> directly, that this incident has demonstrated should no longer be allowed,
> and need to be corrected soon.
Is your stipulation that the "parent" CA should still be in full control of those subordinates and able to audit/control all activities of the subordinates? Maybe that is implicit in your requirements, but I don't see it specifically called out. Comodo's current model allowed them to see these certs, had they used a "fully delegated" subordinate with their RAs this activity wouldn't have had the same visibility.
- Andy
Steve Schultze
> 1) Revoke the RA rights of the RA concerned. (Done)
What is the definition of "revoke"? Does it have a cryptographic or
operational implication?
> 3) Publish a full account of exactly what happened. (See comodo.com
> links above)
I do not believe that the account is yet "full," as Jake observed:
https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion#Update
As Andy noted, this point...
> 5) Move, in a short time-frame (small number of months) towards a model
> where each RA issues from a separate subordinate CA certificate.
> (started)
....seems mutually exclusive with this point...
> Of particular note is the comment in
> https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c68
> "… 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."
>
> We have asked Comodo to explain why this mechanism was not active (or
> did not work) for this RA.
....and the latter seems preferable. The combination, in which the
"parent" does validation and issuance, but uses a different sub-CA for
each RA seems ideal.
> I am extremely concerned about the history of questionable certs being
> issued within the Comodo hierarchy. One possible result is for Mozilla
> to turn off all of the trust bits for the Comodo root certificates that
> are included by default in NSS.
This episode raises concerns not just about Comodo's practices, but
about Mozilla's. How is it that a well-understood problem from 3 years
ago (Comodo's unsafe RA practices) was not confirmed to be resolved by
now? I'll ask again...
....will Mozilla mandate public disclosure of all RAs, and the CA's
precise practices with respect to delegating authority
(cryptographically or operationally) to them?
> However, I think that the CAs actions in
> response to the most recent situation should also be taken under
> consideration. It would have been much easier for the CA to not say
> anything to browser vendors about their mistake – they had caught it
> quickly and revoked the certs already. Comodo was very much aware of the
> previous issues that had been logged in Bugzilla, and of the possible
> outcome of making this mistake public. Regardless, Comodo chose to do
> the right thing and disclose this situation to the browser vendors so
> that they could also take action.
This logic only incentivizes CAs to not perform due diligence under the
assumption that as long as they admit their mistakes publicly they will
not be held accountable. You're right, Comodo was very much aware of
the previous issues that had been logged in Bugzilla... and they even
knew what they had to do to mitigate their harm, and claimed that they
were doing so, but evidently did not.
> We could focus on punishment, but I think it would be more beneficial
> for us to focus on actions that will prevent such mistakes in the
> future. As well as sharing the lessons-learned, to help prevent other
> CAs from making the same mistakes.
How is this time different from last time?
Kathleen Wilson
wrote:
Hmmm. I'm not seeing this posting in Thunderbird, only in Google
Groups.
Yes, for the case where an intermediate CA corresponds to an RA, I was
assuming that the "parent" CA would be in full control of the
intermediate CAs.
I add this clarification to the related bullet point in the wiki page:
https://wiki.mozilla.org/CA:CertPolicyUpdates#RAs_and_Subordinate_CAs
Thanks,
Kathleen
Kathleen Wilson
> On 3/24/11 5:24 PM, Kathleen Wilson wrote:
>> 1) Revoke the RA rights of the RA concerned. (Done)
>
> What is the definition of "revoke"? Does it have a cryptographic or
> operational implication?
>
Operational.
>> 3) Publish a full account of exactly what happened. (See comodo.com
>> links above)
>
> I do not believe that the account is yet "full," as Jake observed:
> https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion#Update
>
Fair enough.
>
> As Andy noted, this point...
>
>> 5) Move, in a short time-frame (small number of months) towards a model
>> where each RA issues from a separate subordinate CA certificate.
>> (started)
>
> ....seems mutually exclusive with this point...
>
The intent is that Comodo operates these intermediate CAs and maintains
full control/auditing of them. The point is that if an RA does make a
mistake, Comodo can revoke that particular intermediate CA.
>> Of particular note is the comment in
>> https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c68
>> "… 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."
>>
>> We have asked Comodo to explain why this mechanism was not active (or
>> did not work) for this RA.
>
> ....and the latter seems preferable. The combination, in which the
> "parent" does validation and issuance, but uses a different sub-CA for
> each RA seems ideal.
>
I think these practices should be incorporated by any CA who uses
external RAs. I've added points about both of these to
https://wiki.mozilla.org/CA:CertPolicyUpdates#RAs_and_Subordinate_CAs
>> I am extremely concerned about the history of questionable certs being
>> issued within the Comodo hierarchy. One possible result is for Mozilla
>> to turn off all of the trust bits for the Comodo root certificates that
>> are included by default in NSS.
>
> This episode raises concerns not just about Comodo's practices, but
> about Mozilla's. How is it that a well-understood problem from 3 years
> ago (Comodo's unsafe RA practices) was not confirmed to be resolved by
> now? I'll ask again...
>
> http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/381acf2eca0c011f/f57b56dd111ba48b?q=comodo#f57b56dd111ba48b
>
Fair enough. At this point I think we should ask Comodo to do a full
audit of all of their RAs. It appears that their updated practices
haven't been adopted by all of their RAs.
>
> ....will Mozilla mandate public disclosure of all RAs, and the CA's
> precise practices with respect to delegating authority
> (cryptographically or operationally) to them?
>
I don't know about publicly disclosing the list of their RAs.
But I do agree that Comodo should publicly disclose their practices with
respect to delegating authority to their RAs. They should also provide a
description of the changes that they are going to make, have new
training for all of their RAs, and audit all of their RAs.
>> However, I think that the CAs actions in
>> response to the most recent situation should also be taken under
>> consideration. It would have been much easier for the CA to not say
>> anything to browser vendors about their mistake – they had caught it
>> quickly and revoked the certs already. Comodo was very much aware of the
>> previous issues that had been logged in Bugzilla, and of the possible
>> outcome of making this mistake public. Regardless, Comodo chose to do
>> the right thing and disclose this situation to the browser vendors so
>> that they could also take action.
>
> This logic only incentivizes CAs to not perform due diligence under the
> assumption that as long as they admit their mistakes publicly they will
> not be held accountable. You're right, Comodo was very much aware of the
> previous issues that had been logged in Bugzilla... and they even knew
> what they had to do to mitigate their harm, and claimed that they were
> doing so, but evidently did not.
>
It's a shame if CAs view it that way.
I'll wait for Comodo's answers to pass judgment, but I agree that it's
concerning that practices that were said to be put into place don't
appear to have been enforced with all of their RAs
>> We could focus on punishment, but I think it would be more beneficial
>> for us to focus on actions that will prevent such mistakes in the
>> future. As well as sharing the lessons-learned, to help prevent other
>> CAs from making the same mistakes.
>
> How is this time different from last time?
Well, the way it happened is different. Also, Comodo caught it
immediately, and took action immediately -- it didn't take someone else
to notice. So apparently they do have a practice of monitoring their RAs
in place that did work. Some of that monitoring should be automated, and
should happen before the cert gets issued...
Kathleen
Steve Schultze
> On 3/24/11 4:19 PM, Steve Schultze wrote:
>> On 3/24/11 5:24 PM, Kathleen Wilson wrote:
>>> I am extremely concerned about the history of questionable certs being
>>> issued within the Comodo hierarchy. One possible result is for Mozilla
>>> to turn off all of the trust bits for the Comodo root certificates that
>>> are included by default in NSS.
>>
>> This episode raises concerns not just about Comodo's practices, but
>> about Mozilla's. How is it that a well-understood problem from 3 years
>> ago (Comodo's unsafe RA practices) was not confirmed to be resolved by
>> now? I'll ask again...
>>
>> http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/381acf2eca0c011f/f57b56dd111ba48b?q=comodo#f57b56dd111ba48b
>>
>>
>
> Fair enough. At this point I think we should ask Comodo to do a full
> audit of all of their RAs. It appears that their updated practices
> haven't been adopted by all of their RAs.
>
>>
>> ....will Mozilla mandate public disclosure of all RAs, and the CA's
>> precise practices with respect to delegating authority
>> (cryptographically or operationally) to them?
>>
>
> I don't know about publicly disclosing the list of their RAs.
>
> But I do agree that Comodo should publicly disclose their practices with
> respect to delegating authority to their RAs. They should also provide a
> description of the changes that they are going to make, have new
> training for all of their RAs, and audit all of their RAs.
How do you plan to ensure that they are doing what they are claiming to
do without requiring disclosure? Disclosure and the resulting
accountability is a fundamental part of Mozilla's cert management
process. *Public* disclosure is essential because Mozilla relies on
*this* public community for due diligence.
> I'll wait for Comodo's answers to pass judgment, but I agree that it's
> concerning that practices that were said to be put into place don't
> appear to have been enforced with all of their RAs
>
>>> We could focus on punishment, but I think it would be more beneficial
>>> for us to focus on actions that will prevent such mistakes in the
>>> future. As well as sharing the lessons-learned, to help prevent other
>>> CAs from making the same mistakes.
>>
>> How is this time different from last time?
>
> Well, the way it happened is different. Also, Comodo caught it
> immediately, and took action immediately -- it didn't take someone else
> to notice. So apparently they do have a practice of monitoring their RAs
> in place that did work. Some of that monitoring should be automated, and
> should happen before the cert gets issued...
How is the accountability for their claims or Mozilla's wishes different
from last time? Mozilla was evidently operating under the assumption
that Comodo was doing something that they were not doing. You do not
propose any more disclosure than last time, so in that respect I don't
see how it is different this time.
Kathleen Wilson
Even if they do give us the full list, how are we to know that they've
updated the processes and monitoring for all of their RAs?
I think the only feasible way is to rely on an audit. Perhaps we should
require Comodo to go through a comprehensive independent audit of all of
their RAs to prove that the updated practices and monitoring is in place
across all of their RAs.
>> I'll wait for Comodo's answers to pass judgment, but I agree that it's
>> concerning that practices that were said to be put into place don't
>> appear to have been enforced with all of their RAs
>>
>>>> We could focus on punishment, but I think it would be more beneficial
>>>> for us to focus on actions that will prevent such mistakes in the
>>>> future. As well as sharing the lessons-learned, to help prevent other
>>>> CAs from making the same mistakes.
>>>
>>> How is this time different from last time?
>>
>> Well, the way it happened is different. Also, Comodo caught it
>> immediately, and took action immediately -- it didn't take someone else
>> to notice. So apparently they do have a practice of monitoring their RAs
>> in place that did work. Some of that monitoring should be automated, and
>> should happen before the cert gets issued...
>
> How is the accountability for their claims or Mozilla's wishes different
> from last time? Mozilla was evidently operating under the assumption
> that Comodo was doing something that they were not doing. You do not
> propose any more disclosure than last time, so in that respect I don't
> see how it is different this time.
Yes, I agree. What do you think of the idea of requiring an independent
audit of all of their RAs?
Kathleen
Steve Schultze
Well, you'd have to require them to disclose the audit... thereby
disclosing the list. Or did you envision an audit where the result was
just some auditor's attestation that all of the RAs were complying?
But what possible legitimate reason, from the perspective of users that
rely on these entities, could there be for not requiring disclosure? At
times, there seems to be a posture on the part of the Moz cert team
against things that are thought to inconvenience the CAs.
I can imagine a variety of ways that public disclosure would help with
policing. It would mean that people could conduct tests against the
full list to verify actual validation. People could report RAs that do
not have disclosed audits. Etc...
>>> I'll wait for Comodo's answers to pass judgment, but I agree that it's
>>> concerning that practices that were said to be put into place don't
>>> appear to have been enforced with all of their RAs
>>>
>>>>> We could focus on punishment, but I think it would be more beneficial
>>>>> for us to focus on actions that will prevent such mistakes in the
>>>>> future. As well as sharing the lessons-learned, to help prevent other
>>>>> CAs from making the same mistakes.
>>>>
>>>> How is this time different from last time?
>>>
>>> Well, the way it happened is different. Also, Comodo caught it
>>> immediately, and took action immediately -- it didn't take someone else
>>> to notice. So apparently they do have a practice of monitoring their RAs
>>> in place that did work. Some of that monitoring should be automated, and
>>> should happen before the cert gets issued...
>>
>> How is the accountability for their claims or Mozilla's wishes different
>> from last time? Mozilla was evidently operating under the assumption
>> that Comodo was doing something that they were not doing. You do not
>> propose any more disclosure than last time, so in that respect I don't
>> see how it is different this time.
>
> Yes, I agree. What do you think of the idea of requiring an independent
> audit of all of their RAs?
Obviously from the above, I think that disclosure is necessary. Audits
are probably also necessary. How often would you propose that they
happen? Must an audit be done of every RA before they begin operations?
However, I'm not sure that applying these policies against "RAs" is the
right approach. Or maybe it is, depending on what the definition of
"RA" is. According to WebTrust (http://www.webtrust.org/item27804.pdf):
"The CA or RA verifies the identity of the subscriber in accordance with
the CA’s established business practices (that may be contained in a
certification practice statement), and then issues a digital certificate."
and
"An RA is an entity that is responsible for the identification and
authentication of subscribers, but does not sign or issue certificates."
So perhaps even WebTrust isn't consistent... does an RA issue certs?
Does it verify identity? I think that any entity that has the
operational and/or cryptographic ability to issue certs (directly, or by
asserting identity to an entity that issues the certs) should be audited
and publicly disclosed. Is that unreasonable?
Peter Gutmann
>>> We could focus on punishment, but I think it would be more beneficial
>>> for us to focus on actions that will prevent such mistakes in the
>>> future. As well as sharing the lessons-learned, to help prevent other
>>> CAs from making the same mistakes.
>>
>> How is this time different from last time?
>
>Well, the way it happened is different. Also, Comodo caught it immediately,
>and took action immediately -- it didn't take someone else to notice.
How do we know that there haven't been dozens of similar compromises that
weren't caught? This seems to be saying "lax practice are OK, we'll pretend
that they're not happening until forced by public disclosure to do something,
and even then it'll be nothing more than a slap on the wrist with a wet bus
ticket". Even before the various public failures, Comodo had a bit of a
reputation in the PKI community for lax practices, to the extent that I'd
heard it referred to privately as "Commode-o" by other PKI people (a name that
I may have accidentally let slip into a public post in the past :-). So there
appears to have been some unease about them for a long time, predating any of
the public disclosures of problems, but it was just ignored.
What we have is an industry that claims to be selling trust, but that has
repeatedly demonstrated its untrustworthiness in a very public manner. And
while other trust-based industries rely on "trust but verify", the browsers
just give us "trust and hope". When the PKI fails, as it has repeatedly,
there's nothing else there to fall back on. If you read the discussion on
various web forums (admittedly not a representative survey, but the best we
have to go on at the moment), most people have pretty much zero confidence in
browser PKI, and very low confidence in browser vendors' seriousness about
protecting users from harm. This is the real problem that browsers should be
looking at, not "how wet shall we make the bus ticket before we slap the CA's
wrist with it" but "how do we deal with the fact that our chosen (and only)
web security mechanism is repeatedly, and publicly, failing, and our only
response to date has been PKI-me-harder".
Peter.
Eddy Nigg
> Comodo responded appropriately to this incident by revoking the
> certificates immediately, and notifying the major browser vendors so
> that more proactive actions could be taken.
Luckily they detected it before more damage could be done. Unfortunately
disclosure to the public has not been prompt by any party involved and
this should not have happened in this way. The reasons are obvious.
> We have asked Comodo to explain why this mechanism was not active (or
> did not work) for this RA.
I believe that this is a major issue which clearly shows a failure
across the band. If Comodo would have implemented their domain control
validation process as claimed in that bug, this attempt would have been
most likely successfully foiled.
It gets me that this wasn't the case, that this hasn't been made the
declared policy and that this hasn't been audited accordingly! More than
that, if we can't rely on what a CA claims, we have a far bigger issue
than nine fraudulent certs, seriously.
It is very clear to me that no system is 100% secure all the time -
obviously an RA somewhere out there is more likely to fail than the CA
with its resources. It's however not understandable to me that no
sincere best effort has been made since the many issues preceding this one.
It's not understandable that the API for RAs hasn't been requiring the
DV process at the CA side as promised.
It's not understandable that no better measures for authentication
against the API have been implemented.
It's not understandable that Comodo wasn't able to implement a lousy
flagging system for the top 100 targets which would be most likely
requested in such an event.
There are CAs that by choice do NOT work with such RAs - with the
expected result of lesser revenues. There are CAs that have strict
access controls to the CA systems, to those parts that can issue a
certificate - with the expected inconvenience and added costs. There are
CAs that have multiple controls in place in order to detect fraudulent
attempts should a particular lawyer fail in the chain of events and
infrastructure - with the expected result of higher development costs
and operating resources and man-power required.
But what is it worth all that, if there are those that simple don't care
or are incapable to care?!?! And Comodo might be not alone with that.
>
> I am extremely concerned about the history of questionable certs being
> issued within the Comodo hierarchy. One possible result is for Mozilla
> to turn off all of the trust bits for the Comodo root certificates
> that are included by default in NSS.
Even though this should be really the last defense of Mozilla, some
action must happen that clearly makes a point. It will be probably not
an easy decision on your part and most likely you won't make everybody
happy. But something got to happen.
> Regardless, Comodo chose to do the right thing and disclose this
> situation to the browser vendors so that they could also take action.
It might be that those certificates would have surfaced at some point
anyway, so better this.
>
> We could focus on punishment, but I think it would be more beneficial
> for us to focus on actions that will prevent such mistakes in the
> future. As well as sharing the lessons-learned, to help prevent other
> CAs from making the same mistakes.
Nope, this works for some CAs, for others it simply doesn't, period. The
screws must be tightened here and now.
> There are some practices, such as some roots signing end-entity certs
> directly, that this incident has demonstrated should no longer be
> allowed, and need to be corrected soon.
I have been saying this for years, back at the time preceding EV already
(probably arguing with Frank).
The same goes for outsourcing domain control validation.
The same goes for unrestricted externally operated intermediate CAs.
Requiring RAs to be channeled through dedicated intermediate CAs is in
my opinion only partly helpful in case of a compromise - the issuance
processes must be improved, strictly, without mercy and conflicting
business interest.
Erwann Abalea
[...]
> What we have is an industry that claims to be selling trust, but that has
> repeatedly demonstrated its untrustworthiness in a very public manner. And
> while other trust-based industries rely on "trust but verify", the browsers
> just give us "trust and hope". When the PKI fails, as it has repeatedly,
> there's nothing else there to fall back on. If you read the discussion on
> various web forums (admittedly not a representative survey, but the best we
> have to go on at the moment), most people have pretty much zero confidence in
> browser PKI, and very low confidence in browser vendors' seriousness about
> protecting users from harm. This is the real problem that browsers should be
> looking at, not "how wet shall we make the bus ticket before we slap the CA's
> wrist with it" but "how do we deal with the fact that our chosen (and only)
> web security mechanism is repeatedly, and publicly, failing, and our only
> response to date has been PKI-me-harder".
I agree that measures MUST be taken against recidivist liars, instead
of continuing to trust them.
Comodo clearly lied when they wrote that technical countermeasures had
been installed to prevent such problems.
I personally won't trust such a lier anymore.
On the other hand, I've heard arguments against the trust revocation
for some browsers (but not all), in the sense that such a situation
could cause loss of market share for those browsers. I can understand
this. But this means that the power relationship changes completely as
soon as a CA is included in a browser; before acceptance, a CA needs
its root to be deployed in order to sell certificates; after
acceptance, the browser needs to keep the biggest number of roots to
keep their users happy. That's insane.
Could it be possible to temporarily disable all trust in Comodo
certificates, wait for them to be positively audited on the technical
modifications they might implement to prevent other human failures to
happen so easily (with a public disclosure of the audit report, of
course), and re-enable them after a public discussion?
About the "anti-X.509" buzz, I've also read a lot of such things,
comparing "evil money-based CA (X.509)" and "good PGP-like users", but
honestly (and sadly, yes), they haven't understood what the real
problem was. This has nothing to do with the chosen trust model, it
could have happened with a web-of-trust (and it still does happen,
today).
--
Erwann.
Steingruebl, Andy
> From: Erwann Abalea
>
> On the other hand, I've heard arguments against the trust revocation for
> some browsers (but not all), in the sense that such a situation could cause
> loss of market share for those browsers.
Maybe we just need to think of it differently from a UI perspective. When you visit a suspected malware site, Firefox, Chrome, etc. popup up a nice nasty warning saying that the site probably has something awfully wrong with it, and you shouldn't visit it.
Maybe in the cases of a site that has a certificate issued by a CA that is being de-listed, or has been de-listed, the browser shouldn't show normal certificate warnings, it should advertise something more about *why* it has made this decision. In this case it is quite straightforward and a lot easier to explain than signature expiry, mismatch of CN/Hostname, etc. It is that we don't trust a given CA that has been de-certified.
BTW, this isn't a statement saying what ought to be done with the current CA under discussion, just suggesting an approach UI-wise that might make browses more nimble.
Just a thought.
- Andy
Ben Bucksch
> I think the only feasible way is to rely on an audit. Perhaps we
> should require Comodo to go through a comprehensive independent audit
> of all of their RAs to prove that the updated practices and monitoring
> is in place across all of their RAs.
Yes! All RAs are effectively a CA, because they can issue certs, and
must be subject to the same scrutiny as CAs.
It's not acceptable that we all trust on a bunch of companies, and
Comodo refuses to even say who they are. (Even in an event like this,
they still refuse to say who is the offender.)
I understand their business model relies on hundreds of resellers.
There's no problem with resellers. There's a problem with RAs, third
party entities which perform verification, i.e. a core function of the
CA. That must stop. IMHO, the whole concept of RAs is directly against
our policy, because they are notpart of the audit (as you say), neither
are they are not approved by us (which is what would still be missing).
A policy which says "I can let anyone in the world do the verification
for me" is obviously not very useful, but that's preciselywhat their
policy is.
Again, I have no problem with resellers, as long as Comodo does all the
CA functions, including all verifications, itself.
Ben
Ben Bucksch
> I think that any entity that has the operational and/or cryptographic
> ability to issue certs (directly, or by asserting identity to an
> entity that issues the certs) should be audited and publicly
> disclosed. Is that unreasonable?
Exactly.
No, it's not unreasonable, but the idea of the Mozilla CA policy. It was
just circumvented here. I don't think we should retrospectively
legitimize it.
Ben
Ben Bucksch
> I add this clarification to the related bullet point in the wiki page:
> https://wiki.mozilla.org/CA:CertPolicyUpdates#RAs_and_Subordinate_CAs
I would like to replace this entire section with:
"RAs and sub-CAs must not exist. All verifications and issuance happen
by the CA itself and cannot be delegated or outsourced. All persons and
machinery that is able to issue certs in any way must be subject to and
part of the audit, physically."
In view of the current section, this change may sound extreme, but I
believe it is justified for the reasons above, and anything else would
simply circumvent the whole policy.
Otherwise I can make a Über-CA, write in my policy that I delegate RAs
as I wish, and then every new CA doesn't have to go through our policy
and approval, but just pays me $$.
Exactly that seems to be the business model of Comodo, and I claim it's
in direct contradiction of the idea of our policy.
Ben
Eddy Nigg
> But this means that the power relationship changes completely as
> soon as a CA is included in a browser; before acceptance, a CA needs
> its root to be deployed in order to sell certificates; after
> acceptance, the browser needs to keep the biggest number of roots to
> keep their users happy. That's insane.
Thanks for bringing this up in this way. I believe too that it's
unacceptable that we have CAs of new root inclusion requests jump
through extensive scrutiny, modifications of policies, re-auditing and
so forth - whereas there are some CA roots included that have repeating
failures without any review of the relevant policies, public discussions
and attestations of requested corrective measures.
> Could it be possible to temporarily disable all trust in Comodo
> certificates, wait for them to be positively audited on the technical
> modifications they might implement to prevent other human failures to
> happen so easily (with a public disclosure of the audit report, of
> course), and re-enable them after a public discussion?
If the same equation for existing roots is applied as for new ones, this
should be the correct action at this time. But Mozilla would not be able
to do it on its own without risking a degradation of its own product.
Robin Alden
I apologize for not responding more quickly to your questions.
I will dedicate some time at the start of next week to respond properly.
Best regards
Robin Alden
Comodo
> -----Original Message-----
> From: dev-security-policy-
> bounces+robin=comod...@lists.mozilla.org [mailto:dev-
> security-policy-bounces+robin=comod...@lists.mozilla.org] On
> Behalf Of Kathleen Wilson
> Sent: 24 March 2011 21:24
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Web Browsers and Comodo Announce A Successful
> Certificate Authority Attack, Perhaps From Iran
>
> On 3/23/11 6:07 PM, Eddy Nigg wrote:
> > On 03/23/2011 09:16 PM, From Steve Schultze:
> >> Many of you are probably already following this story.
> >
> > ....and we are waiting patiently for a posting by a Mozilla
> > representative here.
> >
>
> I appreciate your patience...
> (I've been ill, so not online much the past couple of days.)
>
> A good description about what happened has been posted here:
> https://www.eff.org/deeplinks/2011/03/iranian-hackers-obtain-
> fraudulent-https
>
> Comodo has provided their summary of the events here:
> http://blogs.comodo.com/category/it-security/
> http://www.comodo.com/Comodo-Fraud-Incident-2011-03-
> 23.html
>
> We were informed by Comodo promptly, and they followed the
> Security Bugs
> process: http://www.mozilla.org/projects/security/security-bugs-
> policy.html
>
> The Security Bug is here:
> https://bugzilla.mozilla.org/show_bug.cgi?id=642395
>
> The bad certs were all revoked promptly, but blacklisting allows us
> to cope with the possibility that an attacker might block OCSP if
> they control the victim's network. OCSP failures aren't fatal by
> default (though they do downgrade EV to DV) so we wanted to
> make sure these certs never worked.
>
> Mozilla requested that Comodo take the following actions.
>
> 1) Revoke the RA rights of the RA concerned. (Done)
>
> 2) Monitor their OCSP logs for evidence of use of these
> certificates, or evidence that access to their OCSP responders is
> being blocked from certain geographical locations
>
> 3) Publish a full account of exactly what happened. (See
> comodo.com links above)
>
> 4) Provide compelling public evidence that:
> - the root private key was not compromised
> - the channel of mis-issuance is now shut
> - all mis-issued certs have been found and listed
> - the list of other certs to come through that channel recently has
> been carefully audited, and representatives of each organization
> are being/have been contacted to confirm correct issuance.
> (partially complete, Comodo plans to engage WebTrust auditors)
>
> 5) Move, in a short time-frame (small number of months) towards
> a model where each RA issues from a separate subordinate CA
> certificate.
> (started)
>
> We are still evaluating the situation, and may request further
> action from Comodo.
>
> Additionally, this issue has brought several concerns about
> implementation of CRL and OCSP to the forefront, and some new
> bugs have been filed. Also, it turned out that an NSS-based fix for
> this instance was not as simple as we would like. A new bug has
> been created for improving NSS to allow us to add certs to the
> store which are specifically untrusted:
> https://bugzilla.mozilla.org/show_bug.cgi?id=642503
>
> Comodo responded appropriately to this incident by revoking the
> certificates immediately, and notifying the major browser vendors
> so that more proactive actions could be taken.
>
> This incident alone is concerning enough, but as we are all aware,
> there are previous incidents that have been logged in Bugzilla
> regarding certs issued within Comodo’s hierarchy, for example:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=470897
> https://bugzilla.mozilla.org/show_bug.cgi?id=526560
> https://bugzilla.mozilla.org/show_bug.cgi?id=599856
>
> Of particular note is the comment in
> https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c68
> "… 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."
>
> We have asked Comodo to explain why this mechanism was not
> active (or did not work) for this RA.
>
> I am extremely concerned about the history of questionable certs
> being issued within the Comodo hierarchy. One possible result is
> for Mozilla to turn off all of the trust bits for the Comodo root
> certificates that are included by default in NSS. However, I think
> that the CAs actions in response to the most recent situation
> should also be taken under consideration. It would have been
> much easier for the CA to not say anything to browser vendors
> about their mistake – they had caught it quickly and revoked the
> certs already. Comodo was very much aware of the previous
> issues that had been logged in Bugzilla, and of the possible
> outcome of making this mistake public. Regardless, Comodo chose
> to do the right thing and disclose this situation to the browser
> vendors so that they could also take action.
>
> We could focus on punishment, but I think it would be more
> beneficial for us to focus on actions that will prevent such mistakes
> in the future. As well as sharing the lessons-learned, to help
> prevent other CAs from making the same mistakes.
>
> I ask the representatives of Comodo to contribute actively to this
> discussion group. In particular, please described the actions
> Comodo is taking now (e.g. the list of requested actions above), as
> well as the actions that Comodo plans to take to prevent such a
> mistake from happening again.
>
> I have added a few items to
> https://wiki.mozilla.org/CA:CertPolicyUpdates#Second_Phase
> Under the heading “RAs and Subordinate CAs”
> There are some practices, such as some roots signing end-entity
> certs directly, that this incident has demonstrated should no longer
> be allowed, and need to be corrected soon.
>
> I am also following the CAB Forum and EFF SSL Observatory
> discussions on this topic. So no need to copy info from them,
> unless there are specific action items that pertain to Mozilla.
>
> Kathleen
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
David E. Ross
> On 03/25/2011 03:55 PM, From Erwann Abalea [also in part]:
>> But this means that the power relationship changes completely as
>> soon as a CA is included in a browser; before acceptance, a CA needs
>> its root to be deployed in order to sell certificates; after
>> acceptance, the browser needs to keep the biggest number of roots to
>> keep their users happy. That's insane.
>
> Thanks for bringing this up in this way. I believe too that it's
> unacceptable that we have CAs of new root inclusion requests jump
> through extensive scrutiny, modifications of policies, re-auditing and
> so forth - whereas there are some CA roots included that have repeating
> failures without any review of the relevant policies, public discussions
> and attestations of requested corrective measures.
However, the Mozilla policy has been updated to require periodic audits.
I assume someone in Mozilla will be looking at the audit reports.
--
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.
Steve Schultze
> On 3/25/11 11:11 AM, Eddy Nigg wrote [in part]:
>> On 03/25/2011 03:55 PM, From Erwann Abalea [also in part]:
>>> But this means that the power relationship changes completely as
>>> soon as a CA is included in a browser; before acceptance, a CA needs
>>> its root to be deployed in order to sell certificates; after
>>> acceptance, the browser needs to keep the biggest number of roots to
>>> keep their users happy. That's insane.
>>
>> Thanks for bringing this up in this way. I believe too that it's
>> unacceptable that we have CAs of new root inclusion requests jump
>> through extensive scrutiny, modifications of policies, re-auditing and
>> so forth - whereas there are some CA roots included that have repeating
>> failures without any review of the relevant policies, public discussions
>> and attestations of requested corrective measures.
>
> However, the Mozilla policy has been updated to require periodic audits.
> I assume someone in Mozilla will be looking at the audit reports.
It doesn't appear that this is done comprehensively, or that not
providing an updated audit is grounds for removal. For example, the
spreadsheet shows the most recent CNNIC audit as being August 2009:
http://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html
https://cert.webtrust.org/SealFile?seal=935&file=pdf
The Moz Cert Policy 2.0 says that "CAs are expected to maintain the
level of service that was established in the Inclusion Section of the
Mozilla CA Certificate Policy."
http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html
However, there doesn't seem to be any mechanism for active policing of
this expectation, other than yearly audit updates. Of course, the only
output of the audit updates is the two-page attestation from an auditor
that a new audit was done... none of the details from the actual report.
And of course, the audit requirement is only one of many requirements
for acceptance.
http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
In addition, Kathleen has said:
"We don't usually go back and retroactively apply root inclusion process
changes to roots. The exception being that we have started to require
regularly updated audit documents for all included root certificate
authorities."
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/eea04805fbd98045#c9c1c678497fae86
So I believe that the original critique stands -- there is a de-facto
difference between the requirements (and the incentives on CAs) for
acceptance vs maintenance. There is even more difference between
recently approved roots and less recently approved roots.
Steve
Eddy Nigg
> However, there doesn't seem to be any mechanism for active policing of
> this expectation, other than yearly audit updates. Of course, the only
> output of the audit updates is the two-page attestation from an
> auditor that a new audit was done... none of the details from the
> actual report.
That would be fine if we'd have the ability to monitor the accompanying
CA policies (and changes thereof). I believe it would be impossible for
this group here to maintain that - however it will become easier for us
(and Kathleen) to handle once the Basic Guidelines have been adopted and
incorporated into the Mozilla CA Policy requirements.
This will require to look at two place - compliance to the basic
guidelines and attestation by audit. Possible improvements to the
guidelines will be maintained by the CAB Forum, a process that has
already kind of started. I believe this tool will become very important
for all of us.
Steve Schultze
> On 03/26/2011 03:35 AM, From Steve Schultze:
>> However, there doesn't seem to be any mechanism for active policing of
>> this expectation, other than yearly audit updates. Of course, the only
>> output of the audit updates is the two-page attestation from an
>> auditor that a new audit was done... none of the details from the
>> actual report.
>
> That would be fine if we'd have the ability to monitor the accompanying
> CA policies (and changes thereof). I believe it would be impossible for
> this group here to maintain that - however it will become easier for us
> (and Kathleen) to handle once the Basic Guidelines have been adopted and
> incorporated into the Mozilla CA Policy requirements.
So in summary, "we can't actually enforce the expectations we just wrote
into the new guidelines."
It's also not just a matter of CA policies... it's a matter of
practices. However, without disclosure of things like SubCA's and RA's,
it's impossible for anyone to even try in a comprehensive way.
> This will require to look at two place - compliance to the basic
> guidelines and attestation by audit. Possible improvements to the
> guidelines will be maintained by the CAB Forum, a process that has
> already kind of started. I believe this tool will become very important
> for all of us.
The CAB Forum doesn't own the requirements on CA's. The browsers and OS
vendors do. If they wish to adopt the CAB Forum guidelines, they can.
If the CAB Forum would like to begin conducting its business in a more
public way, this outcome might be more likely.
=JeffH
>
> On 3/23/11 6:07 PM, Eddy Nigg wrote:
>> On 03/23/2011 09:16 PM, From Steve Schultze:
>>> Many of you are probably already following this story.
>>
>> ....and we are waiting patiently for a posting by a Mozilla
>> representative here.
>>
> Mozilla requested that Comodo take the following actions.
>
The legitimate certs of two of the targeted webapps are apparently EV certs:
<https://login.live.com/> and <https://addons.mozilla.org/>.
The generated impostor certs were not EV -- but /could/ they have been? I.e. is
Comodo (and other CAs) facilitating their RAs to issue EV certs? Could the
compromised RA user account have actually issued an EV certs for login.live.com
and addons.mozilla.org ?
If Comodo is facilitating EV issuance by any of their RAs, are they following
(where their RAs are concerned) the procedures in Sections 12.2 (and section 12
in general) and section 10.12 of <http://cabforum.org/Guidelines_v1_3.pdf> ?
Perhaps these are questions to add to the list for them to answer.
thanks,
=JeffH
Eddy Nigg
> It's also not just a matter of CA policies... it's a matter of practices.
Of course this auditors have to confirm - failing that, they fail too.
> However, without disclosure of things like SubCA's and RA's, it's
> impossible for anyone to even try in a comprehensive way.
One doesn't exclude the other obviously. Luckily we are free to add our
own requirements :-)
> The CAB Forum doesn't own the requirements on CA's.
No, it's a group that can (and does) propose the guidelines.
> The browsers and OS vendors do. If they wish to adopt the CAB Forum
> guidelines, they can.
Obviously. And of course I'd urge exactly that to do once it becomes
relevant.
Kathleen Wilson
> On 3/25/11 8:23 PM, David E. Ross wrote:
>> On 3/25/11 11:11 AM, Eddy Nigg wrote [in part]:
>>> On 03/25/2011 03:55 PM, From Erwann Abalea [also in part]:
>>>> But this means that the power relationship changes completely as
>>>> soon as a CA is included in a browser; before acceptance, a CA needs
>>>> its root to be deployed in order to sell certificates; after
>>>> acceptance, the browser needs to keep the biggest number of roots to
>>>> keep their users happy. That's insane.
>>>
>>> Thanks for bringing this up in this way. I believe too that it's
>>> unacceptable that we have CAs of new root inclusion requests jump
>>> through extensive scrutiny, modifications of policies, re-auditing and
>>> so forth - whereas there are some CA roots included that have repeating
>>> failures without any review of the relevant policies, public discussions
>>> and attestations of requested corrective measures.
>>
>> However, the Mozilla policy has been updated to require periodic audits.
>> I assume someone in Mozilla will be looking at the audit reports.
>
> It doesn't appear that this is done comprehensively, or that not
> providing an updated audit is grounds for removal. For example, the
> spreadsheet shows the most recent CNNIC audit as being August 2009:
>
> http://spreadsheets.google.com/pub?key=ttwCVzDVuWzZYaDosdU6e3w&single=true&gid=0&output=html
>
Actually, CNNIC did provide the updated audit in Bug #607208. I just
hadn't added that update to the spreadsheet yet. It's there now.
> The Moz Cert Policy 2.0 says that "CAs are expected to maintain the
> level of service that was established in the Inclusion Section of the
> Mozilla CA Certificate Policy."
>
> http://www.mozilla.org/projects/security/certs/policy/MaintenancePolicy.html
>
>
> However, there doesn't seem to be any mechanism for active policing of
> this expectation, other than yearly audit updates. Of course, the only
> output of the audit updates is the two-page attestation from an auditor
> that a new audit was done... none of the details from the actual report.
> And of course, the audit requirement is only one of many requirements
> for acceptance.
> http://www.mozilla.org/projects/security/certs/policy/InclusionPolicy.html
>
Yes, I rely on the audits. About every 6 months I go through my
spreadsheet to find audits that are out of date, and contact the
relevant CAs.
The nice thing (for me) is that since we updated the Mozilla CA Cert
Policy, CAs have started to proactively send me their updated audits
before I ask.
> In addition, Kathleen has said:
> "We don't usually go back and retroactively apply root inclusion process
> changes to roots. The exception being that we have started to require
> regularly updated audit documents for all included root certificate
> authorities."
>
> http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/eea04805fbd98045#c9c1c678497fae86
>
>
> So I believe that the original critique stands -- there is a de-facto
> difference between the requirements (and the incentives on CAs) for
> acceptance vs maintenance. There is even more difference between
> recently approved roots and less recently approved roots.
>
However, we do expect all CAs to comply with Version 2.0 of the Mozilla
CA Cert Policy by August 8, 2011. This was communicated to CAs via
email, and I have been keeping an internal spreadsheet of the responses
and progress.
https://wiki.mozilla.org/CA:CertPolicyUpdates#Transitioning_to_the_Updated_Policy
Likewise, we will give all CAs a certain amount of time to comply with
the next update of the Mozilla CA Cert Policy.
Compliance means that the CA policy documentation has been updated as
needed, and the new practices put into place. Then the next regular
audit should included these updates, since they are part of the policy
documentation.
Kathleen
Steve Schultze
> On 03/26/2011 04:23 AM, From Steve Schultze:
>> It's also not just a matter of CA policies... it's a matter of practices.
>
> Of course this auditors have to confirm - failing that, they fail too.
The auditors do not confirm everything in the Mozilla requirements...
including some of the required practices. That is the point.
Steve Schultze
> Yes, I rely on the audits. About every 6 months I go through my
> spreadsheet to find audits that are out of date, and contact the
> relevant CAs.
A column in the spreadsheet listing the date of the last audits might
make it easier for you and for outsiders to do this.
At what point does an overdue audit update trigger removal?
> Compliance means that the CA policy documentation has been updated as
> needed, and the new practices put into place. Then the next regular
> audit should included these updates, since they are part of the policy
> documentation.
Ah, I see how this works with InclusionPolicy #14.
It seems that a great deal rises and falls on the auditors. It seems
like anything that can be done to allow the public to more easily verify
compliance would be good.
Eddy Nigg
Maybe you got me wrong - it's the basic guidelines to which the CA will
have to commit in the policy. Whatever is beyond is obviously not
covered, but that already should be a significant improvement.
David E. Ross
> On 3/25/11 8:23 PM, David E. Ross wrote:
>> On 3/25/11 11:11 AM, Eddy Nigg wrote [in part]:
>>> On 03/25/2011 03:55 PM, From Erwann Abalea [also in part]:
>>>> But this means that the power relationship changes completely as
>>>> soon as a CA is included in a browser; before acceptance, a CA needs
>>>> its root to be deployed in order to sell certificates; after
>>>> acceptance, the browser needs to keep the biggest number of roots to
>>>> keep their users happy. That's insane.
>>>
>>> Thanks for bringing this up in this way. I believe too that it's
>>> unacceptable that we have CAs of new root inclusion requests jump
>>> through extensive scrutiny, modifications of policies, re-auditing and
>>> so forth - whereas there are some CA roots included that have repeating
>>> failures without any review of the relevant policies, public discussions
>>> and attestations of requested corrective measures.
>>
>> However, the Mozilla policy has been updated to require periodic audits.
>> I assume someone in Mozilla will be looking at the audit reports.
>
> It doesn't appear that this is done comprehensively, or that not
> providing an updated audit is grounds for removal. For example, the
> spreadsheet shows the most recent CNNIC audit as being August 2009:
>
This is a new policy. Thus, it has not been required in the past.
>From the wording of the policy -- "This section of the Mozilla CA
Certificate Policy describes the obligations of Certification
Authorities for maintaining confidence in their root certificates that
are included in Mozilla Products." and "This is the official Mozilla
policy for Certification Authorities to maintain their CA Certificates
that are distributed in Mozilla products" -- I would assume that a
failure to provide an annual auditor's attestation would result in the
removal of a root certificate.
Kathleen: Would a root certificate indeed be removed for any
certificate authority for which Mozilla does not receive an annual
auditor's attestation? Or would this merely be grounds for removal? I
hope it is the former. We have seen repeated grounds for removing
Comodo roots, yet none have been actually removed.
Eddy Nigg
> How do we know that there haven't been dozens of similar compromises that
> weren't caught? This seems to be saying "lax practice are OK, we'll pretend
> that they're not happening until forced by public disclosure to do something,
> and even then it'll be nothing more than a slap on the wrist with a wet bus
> ticket".
Some more possible information here:
Just got it from https://bugzilla.mozilla.org/show_bug.cgi?id=642395
Peter Gutmann
>...so this person, if I understand it correctly, is claiming that Comodo is
>using a username/password authentication system for its RAs.
Which I find at least as amusing as the fact that, every year, the PKI experts
who attend the PKI workshop authenticate themselves with username and password
(and the fact that browser vendors dealt with the Comodo fiasco using updated
binaries, not CRLs and OCSP, and ...). Does anyone involved in PKI actually
believe in it sufficiently to secure their infrastructure with it?
Peter.
Paul van Brouwershaven
> On 03/25/2011 05:44 AM, From Peter Gutmann:
>> weren't caught? This seems to be saying "lax practice are OK, we'll pretend
>> that they're not happening until forced by public disclosure to do something,
>> and even then it'll be nothing more than a slap on the wrist with a wet bus
>> ticket".
>
>
> http://pastebin.com/74KXCaEZ
>
> Just got it from https://bugzilla.mozilla.org/show_bug.cgi?id=642395
I would like to continue on the question from Peter Gutmann, *"How do we know that there haven't
been dozens of similar compromises that weren't caught?"*
The last years there have been various incident's with Comodo that all came back on the fact that
there partners are able to tick the box. (*“I have sufficiently validated this application”*)
A Comodo representative gave me a few key points last month to "convince" me that we now could trust
there system. They would have learned from there mistakes :-).
COMODO: *"All new partners from a few years ago cannot validate certificate orders."*
... what about the 'old' partners?
COMODO: *"Mandatory that for the first 5-10 orders they send in documentation (Training)"*
... wow that is a huge training! (so you can issue a false certificate after I issued the first 10)
COMODO: *"Upon approval and only a case by case basis do e approve a partner to be an RA."*
... but it's still offered to me :-)
COMODO: *"Even as an RA we still enforce that All partners use DCV on all orders. (OV, DV, EV), See
attached Domain Control Integration guide."*
... yes this would give me a lot of trust in the quality of there OV and EV validations!
And finally some information from there Web Hosts Partner Network program, that is enough
information for me that this CA has no right to issue trust at all!
"
*Appendix 1: Validation Guidelines for Web Hosts*
In order to ensure the integrity of the trust infrastructure provided by Comodo through InstantSSL
it is essential that members of the Web Host Programme operate under the following guidelines when
issuing Certificates.
*You must address two core areas prior to issuing a Certificate to a customer:*
1. The customer has the right to use the domain name to be included in the Certificate
2. The customer exists as a responsible legal entity or individual
In most cases you will have a pre-established relationship with the applicant. This may include
existing business relations established through the sale of products / services such as web hosting
services or domain name registration. In this event, the right of a customer to the domain name
contained within the application will have been established you will be hosting the domain name on
behalf of the customer. It is therefore only necessary for to validate the existence of the customer
as a responsible commercial entity or individual.
If you have an existing business relationship with customer, this requirement may already have been
fulfilled in the guise of payments / invoices paid by the end entity. In the event that an existing
business relationship does not exist, or you are not fully confident that the customer is
sufficiently known to you, it is your responsibility to sufficiently determine their organisational
/ individual status. To complete this validation, we recommend you request any of the following
documentation from the customer:
*If the Certificate is for a commercial entity:*
• Articles of Incorporation
• Business License
• DUNS details (e.g. your Dun & Bradstreet company number)
• Trading License
*If the Certificate is for a non-commercial entity:*
• Copy of your drivers license or passport
Upon receipt of the relevant documentation, you should verify the information received correctly
matches the information provided during application.
It is deemed that the above validation will have taken place when you check the *“I have
sufficiently validated this application”* checkbox when applying for a Certificate.
"
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
Peter Gutmann
>Some more possible information here:
He's now also posted an update containing the complete decompiled Comodo RA
DLL, you can find it at http://pastebin.com/DBDqm6Km. Incidentally, here's a
message I posted to the cypherpunks list a few days ago:
-- Snip --
Subject: Iranian state-sponsored cyberwarfare is indistinguishable from script kiddies
Pretty much every news report I've seen so far that mentions any kind of
Iranian connection is claiming that it's Iranian state-sponsored hacking. If
what's happened with the certs so far (someone grabbed a few sample certs for
high-profile domains, and there was a report of one of them briefly appearing
on a test server in Iran) is an indication of their competence then we really
have nothing to fear from them.
Let's look at what would have happened if *I'd* figured out a way to
compromise a CA. First, I'd get a few test certs issued for high-profile
domains, Microsoft, Google, Yahoo, and perhaps a CA cert just for giggles.
Then I'd set up a server somewhere and install one of the sample certs to see
whether any web browser noticed a problem.
Gosh, this sounds awfully like what actually happened. New Zealand must have
a state-sponsored cyberwar program! The only difference in my case is that
after a day or so of inviting security people to have a giggle at the test
server with my "genuine" cert, I'd notify the CA about the problem. If I was
an Iranian script kiddie I probably wouldn't have much motivation to do that.
So what we have here is either (a) the world's most incompetent state-
sponsored cyberwar program, who get the keys to the kingdom and then have no
idea what to do with them, or (b) a bunch of script kiddies having fun.
What do you reckon the odds are?
(And in all this I haven't seen any mention of the Al Kai-yee-da angle. What
happened, is everyone asleep?).
-- Snip --
(OK, I get to do the I-toldja-so dance now).
Peter.
Peter Gutmann
http://www.heise.de/security/news/foren/S-Kenne-ich-von-Comodo-nicht-anders-ich-kann-selber-solche-Zertifikate-ausstellen/forum-196553/msg-20015933/read/
Translation: "I have a reseller account with Comodo, I can get certs issued
for any domain as long as I use their API and not the web GUI".
I've frequently referred to CAs as "certificate vending machines" to get
across to people how they work, but it looks like Comodo really *is* just a
certificate vending machine.
Peter.
Gervase Markham
> I do not believe that the account is yet "full," as Jake observed:
> https://blog.torproject.org/blog/detecting-certificate-authority-compromises-and-web-browser-collusion#Update
Mozilla has now published more details about what happened:
http://blog.mozilla.com/security/2011/03/25/comodo-certificate-issue-follow-up/
I am ready to answer any other questions I can about the incident.
> ....will Mozilla mandate public disclosure of all RAs, and the CA's
> precise practices with respect to delegating authority
> (cryptographically or operationally) to them?
I was about to add this to
https://wiki.mozilla.org/CA:Comodo_Misissuance_Response , but it seems
you beat me to it :-)
Gerv
Gervase Markham
> Perhaps these are questions to add to the list for them to answer.
Noted.
Gerv
Varga Viktor
> http://blogs.comodo.com/category/it-security/
> http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html
"The perpetrator can only make use of these certificates if it had control of the DNS infrastructure."
It's ideal for government. :) They control the infrastructure, and now they have the certficates too. :)
I think the CA should be dropped.
Üdvözlettel/Regards,
Varga Viktor
Üzemeltetési és Vevőszolgálati Vezető
IT Service and Customer Service Executive
Netlock Kft.
_______________________________________________________________________
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 ________________________________________________________________________________________
Eddy Nigg
> Even though this should be really the last defense of Mozilla, some
> action must happen that clearly makes a point. It will be probably not
> an easy decision on your part and most likely you won't make everybody
> happy. But something got to happen.
>
A few days and a few thoughts later, I thought it would be beneficial if
I'd share what my expectations would be in resolving this issue. In case
Mozilla doesn't already plans to remove or disable the Comodo roots,
then the following minimum set of actions must be taken in order to
ensure some reasonable reliance and trust into the certificates issued
by Comodo from now on.
Hopefully this gives some ideas and some of the basics in order to
continue with a resolution. I'd propose the following requirements and
commitments:
Comodo disables immediately all RAs and Sub CAs (the later share the
same problem as RAs according to the information I have).
Comodo implements a domain control validation procedures into their API
and web based control panels for RAs with the following sequences:
* A query option for RAs to obtain a list of authoritative email
addresses according to the Mozilla CA Policy.
* A request for domain control validation by the RA by submitting
which domain and email address from the above list shall be used
for domain control. Comodo must check if the email address is
permitted for this purpose. If correct, Comodo sends a
verification code to that email address (the email may be branded
to reflect the RA).
* A post response of the verification code by the RA to Comodo which
includes the domain, the email address used and the verification
code. This response should be within a time frame sufficient to
receive an email and reply the code (this may be as low as 15
minutes, but should not exceed more than a couple of hours the most).
* If the response was successful, the domain or domain space may be
used for a certificate for the specific applicant.
* Comodo implements a flagging system for the top target domains and
high profile brands that might be targeted including well known
banks, so-called social sites etc.
* Comodo implements better authentication mechanisms for their API
and web based control panels of their RAs, probably based on
client certificates or similar solutions.
Further Comodo modifies its policies to reflect the above changes and
commitment for validating all domains through their own processes.
Comodo engages with its auditor and performs an extra-ordinary audit
confirming above implementations.
After publishing of the audit report and acceptance by Mozilla, Comodo
may enable the API for RAs and Sub CAs. I expect the action items to be
resolved within 30 - 90 days. During this time Comodo will accept and
process certificate requests only through its own web sites and systems.
Mozilla confirms at the policy newsgroup that it received the audit
report and accepted its wording and confirms the changes to the policy.
No further discussion would be necessary, provided that this would be
the accepted resolution.
Eddy Nigg
Some more: http://pastebin.com/X8znzPWH
Paul van Brouwershaven
> A few days and a few thoughts later, I thought it would be beneficial if I'd share what my
> expectations would be in resolving this issue. In case Mozilla doesn't already plans to remove or
> disable the Comodo roots, then the following minimum set of actions must be taken in order to ensure
> some reasonable reliance and trust into the certificates issued by Comodo from now on.
It's definitely time that Mozilla (and Microsoft and..) take there responsibility and pull the root
from the browsers.
Comodo had several opportunities to show that they are willing to change, in the past years they
have showed over and over again that they are not willing to take the responsibility that a CA
should have. You can give a CA the benefit of the doubts but in the case of Comodo they have enough
incidents to prove they are not able to run a proper CA and bring the whole internet community in
danger.
An issue like would not be practical for any kind of product but if there is a potential safety
problem with your car you would be happy if there was a product recall just like with any faulty
commodity. Customers must be offered refunds for any certificates purchased through Comodo and the
browser vendors like Mozilla should force a product recall!
To recover the end user trust all affected parties (Google, Mozilla, Microsoft, Skype, Yahoo etc)
should seek the full warranty to be paid on this mis-issued Comodo certificates.
Who will trust the CA model in general if we do not pull the root from all the browsers from a CA
that is clearly not able to do the job. Wasn't this the idea of the whole CA model, have the
pressure of removing the root if you do not do a proper job?
> Comodo disables immediately all RAs and Sub CAs (the later share the same problem as RAs according
> to the information I have).
Is this not the same as that they said they did after the last flaws?
Kai Engert
>
> Comodo implements a domain control validation procedures into their API
> and web based control panels for RAs with the following sequences:
>
> which domain and email address from the above list shall be used
> for domain control. Comodo must check if the email address is
> permitted for this purpose. If correct, Comodo sends a
> verification code to that email address (the email may be branded
> to reflect the RA).
> * A post response of the verification code by the RA to Comodo which
> includes the domain, the email address used and the verification
> code.
You're moving to implementation details, changing subject.
You say:
- CA generates secret transaction code
- CA sends email to customer
- customer clicks link which points to *RA* system
- RA sends request to CA and includes secret transaction code
I don't like the idea to empower the RA to
"have a secret code and RA can produce a cert".
I'd prefer if the DV is done between customer and CA,
not involving the RA at all.
If the verifiation link goes to the RA,
external parties are unable to confirm that it's really the CA who
performs the verification.
It should be clear to everyone that you're NOT buying "certs from RA",
but really you're buying "certs from CA".
I'd say, let's make it obvious that the CA performs the verification:
- RA submits CSR to CA
- CA assigns job ID and returns job ID to RA
- RA perdiodically pulls for news from CA
- CA generates transaction code
- CA sends email with requested cert subject and transaction code
to the customer
- customer clicks link which points to *CA* system
- CA remembers in "job database" that domain ownership
and subject name authorization has been verified for job ID
- next time RA pulls for news, CA says "ready", RA can proceed
In my opinion, just to be clear, it should NOT be sufficient to verify
domain ownership just once.
If you allowed domain ownership once, and allowed the RA to remember a
domain verification code, then a hacker could look through an RA's
database, and find domains with confirmed ownership, and could produce
hacked certificates for those.
I think domain ownership (and confirmation to allow purchase for
hostname XYZ) must be separately confirmed for each purchased certificate.
Kai
Eddy Nigg
> You say:
> - CA generates secret transaction code
> - CA sends email to customer
> - customer clicks link which points to *RA* system
> - RA sends request to CA and includes secret transaction code
Yes.
> I don't like the idea to empower the RA to
> "have a secret code and RA can produce a cert".
If the RA doesn't receive the code, it obviously can't request a
certificate on behalf of the applicant. So I'm not overly concerned
about that.
> I'd prefer if the DV is done between customer and CA,
> not involving the RA at all.
I believe there are other situations like intermediate CAs as well, and
the way APIs are usually drawn up, it may or may not involve such a
third party. I'm looking at it from the angle how such things are set up
- but if you want, we can just remove RAs at all (BTW, I've been on
record to warn about that for years).
>
> If the verifiation link goes to the RA,
> external parties are unable to confirm that it's really the CA who
> performs the verification.
Since the CA is sending the verification code and such implementation
can be audited, I'm not sure why it can't be confirmed.
> It should be clear to everyone that you're NOT buying "certs from RA",
> but really you're buying "certs from CA".
Well, I'm fine with that too - it probably will kill the current
"business model" of those using such reseller "RAs".
> In my opinion, just to be clear, it should NOT be sufficient to verify
> domain ownership just once.
Of course not - domain control validation may be valid for a certain
period. The CAB Forum suggests 13 month IIRC, other CAs are using way
shorter expiration periods. Maybe requests coming from such RAs should
have to prove domain control every time.
>
> If you allowed domain ownership once, and allowed the RA to remember a
> domain verification code,
Well, that verification should expire in any case within a short period.
I assume you meant the successful domain control validation for the
applicant.
> then a hacker could look through an RA's database, and find domains
> with confirmed ownership, and could produce hacked certificates for
> those.
Yes, this is likely. But it's less likely that those will be for
high-profile targets.
> I think domain ownership (and confirmation to allow purchase for
> hostname XYZ) must be separately confirmed for each purchased
> certificate.
If this would be a requirement for any external entity, I'm fine with
that. I wouldn't want that for applicants that are enrolling at the CA.
Some grace period should be allowed (I prefer 30 days).
Robin Alden
I've tried to pull together a number of the details asked.
> Of particular note is the comment in
> https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c68
> "… 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."
>
> We have asked Comodo to explain why this mechanism was not
> active (or did not work) for this RA.
>
At the time of this recent incident just under 9% of our RAs were able to
place orders that didn't use that DV process.
This RA (and others) implemented their own domain control checks
according to our CPS.
We checked their work to verify that they were actually correctly
checking domain control.
The rationale for this RA doing the DCV was that the RA did a
(verified by Comodo) good job of validating domain control and had a good and
close relationship with his small number of customers. Also he spoke the same Language as his customers.
We were dealing with the threat model that the RA could be
Underperforming with, or trying to avoid doing, their validation duty
(neither of which were the case for this RA), but what we had not
done was adequately consider the new (to us) threat model of the RA
being the subject of a targeted attack and entirely compromised.
As of shortly after this incident, all (100%) of our RAs must either
use this (Comodo-driven) DCV process - or otherwise have their validation checked by Comodo. This applies to all orders placed.
[RA compromised]
The RA that was the subject of this attack appears to have been
thoroughly compromised.
The RA account is de-activated.
Comodo RAs do/did not have access to any Comodo private key
material.
We are rolling out improved authentication for all RA accounts.
We are implementing both IP address restriction and hardware based
two-factor authentication. The rollout of two-factor tokens is in
progress but will take another couple of weeks to complete. Until
that process is complete Comodo will review 100% of all RA
validation work before issuing any certificate.
Two further RA accounts have since been compromised and had RA
privileges withdrawn. No further mis-issued certificates have
resulted from those compromises.
[CA not compromised]
Our CA systems have not been compromised.
Our HSMs and key material have not been compromised.
[sub-CA per RA]
We understand Mozilla's request that we move to having a separate
sub_CA certificate per RA.
Currently many of our end entity certificates are issued from
RA-specific sub-CAs but some (like this incident) are not.
As a short-term measure we will move towards issuing all
certificates from sub-CAs. Initially some of these will be
Comodo-branded and there will not be a 1:1 match between RAs and
sub-CAs, but we think this will give Mozilla the flexibility they
seek in this regard. In the slightly longer term we will move to a
sub-CA per RA.
[Move away from issuing from root]
The above section (having a sub-CA per RA) will achieve this in an
accelerated timescale.
[High value target check]
This facility has been re-instated on all orders (RA or otherwise).
Regrettably it had been disabled for a small number of RA accounts.
We are removing the aspects of our back-end system that allow this
check to be optional - ensuring that it remains in place on all
certificates going forward.
[EV certificates]
Comodo RAs do not act as RAs in the issuance of EV certificates.
Comodo RAs cannot (and previously could not) cause EV certificates
to be issued without the mandated checks and validation from Comodo.
[External oversight]
We are engaging with our WebTrust auditors to ensure they are aware
of the issues we have experienced and it is our intention to further
engage them to produce a statement that we may publish with regard
to the effects and remedies of the original RA compromise.
Regards
Robin Alden
Comodo
Paul C. Bryan
> It's definitely time that Mozilla (and Microsoft and..) take there responsibility and pull the root
> from the browsers.
I agree 100%, since the first Comodo incident was reported. Here's why
I'm not holding my breath:
1. Pulling a root affects users. Breaking thousands of so-called secure
web sites is unattractive to browser vendors, who have consistently
avoided adversely affecting the experience of their users. One browser
vendor will not create a worse user experience if other browsers do not
do the same.
2. There's no liability (yet), so there's little incentive to act. The
effects of bad security so far are an externality to browser vendors,
who are proxying for their users in making decisions on which CAs to
trust. Assurance without liability (financial, reputation, other) is
worthless. As long as browser vendors can CYA with third-party CPSes and
passably-credible audits, they have little motivation to take steps that
would adversely affect them on other fronts, namely user experience.
If there were a consortium of browser vendors who could work
collectively to make such decisions, at least such a decision to pull a
root would have more weight, and all browser vendors would "break" with
affected sites simultaneously.
Paul
Eddy Nigg
> It's definitely time that Mozilla (and Microsoft and..) take there responsibility and pull the root from the browsers.
Even though there are many really pissed off - I'm not sure if this is
the right action at this time. I mean, there hasn't been gross
negligence and no CA key compromise (some negligence yes, improper
disclosure of the current implementations too).
Instead I believe some serious actions are on the agenda. I heard some
suggestions from other corners that disallowing RAs would be the
solution. Why not...
Now, Comodo has acted upon learning of the breach mostly responsible
(even though disclosure by all parties involved might have been
earlier), but Comodo did their duty under the circumstances. They took
responsibility for it and acted as I'd expect under such circumstances.
Comodo tries to perform their job for the higher validated certificates
as expected as far as I can tell. So the action to remove their root(s)
might be not the right solution. I made one proposal, there could be
others including disallowing of external "RAs" or disallowing DV for Comodo.
>> Comodo disables immediately all RAs and Sub CAs (the later share the same problem as RAs according to the information I have).
> Is this not the same as that they said they did after the last flaws?
I'm not aware that Mozilla made any conditions whatsoever.
Paul C. Bryan
> Even though there are many really pissed off - I'm not sure if this is
> the right action at this time. I mean, there hasn't been gross
> negligence and no CA key compromise (some negligence yes, improper
> disclosure of the current implementations too).
Comodo (and Mozilla) have had over two years to work out a solution
since the first breach in 2008, where the same issues were known and
documented. I'm at a loss to see how one can justify calling what
happened anything but gross negligence.
Paul
Eddy Nigg
> Comodo (and Mozilla) have had over two years to work out a solution
> since the first breach in 2008, where the same issues were known and
> documented.
Right - I'd say Mozilla too has probably some responsibility here. It
does certainly now.
> I'm at a loss to see how one can justify calling what
> happened anything but gross negligence.
That most likely depends how one defines gross negligence. I'm not
going to argue about it strongly in any case.
Eddy Nigg
> Two further RA accounts have since been compromised and had RA
> privileges withdrawn. No further mis-issued certificates have
> resulted from those compromises.
Thanks Robin for disclosing it. I believe that current action should be
to disable all external entities until the scope and possible resolution
to this incident(s) have been decided by the relevant parties involved.
I suggested it at a previous mail for a possible solution and steps I
expect should happen. But there is some sense of urgency right now to
prevent any further damage and in order to examine the situation and in
order to allow each party perform their own due diligence and
considerations.
Eddy Nigg
> On 03/29/2011 06:54 PM, From Robin Alden:
>> Two further RA accounts have since been compromised and had RA
>> privileges withdrawn. No further mis-issued certificates have
>> resulted from those compromises.
>
> Thanks Robin for disclosing it.
Well, apparently somebody else did that already earlier today:
http://pastebin.com/kkPzzGKW
Eddy Nigg
>> Two further RA accounts have since been compromised and had RA
>> privileges withdrawn. No further mis-issued certificates have
>> resulted from those compromises.
>
> Thanks Robin for disclosing it.
Well, apparently somebody else did that already earlier today:
http://pastebin.com/kkPzzGKW
--
Peter Gutmann
>no CA key compromise
That's a bogus argument, as long as you use an HSM you can always claim this.
A CA can set up a public web server fronting an HSM that signs anything anyone
submits in any name, but still claim "no CA key compromise".
The issue here is "have fraudulent certs been issued?", and in that the CA has
a proven track record.
Peter.
Eddy Nigg
> That's a bogus argument, as long as you use an HSM you can always claim this.
> A CA can set up a public web server fronting an HSM that signs anything anyone
> submits in any name, but still claim "no CA key compromise".
Correct. One of the main tasks of a CA is obviously taking care of its
keys, audit log and all the rest. Failing that, we'd have no discussion
here at all...
....of course whoever takes the risks for the above implementation has to
take responsibility, I'm not denying it. I have a very clear picture
what should have been there and done and that wasn't.
> The issue here is "have fraudulent certs been issued?", and in that the CA has
> a proven track record.
....that's unfortunately the case. And I believe Comodo has to come clean
on this. And I expect that the fallout from this event will have some
consequences, not sure which. And what would be most beneficial for all
parties involved.
Eddy Nigg
> A CA can set up a public web server fronting an HSM that signs anything anyone
> submits in any name, but still claim "no CA key compromise".
In continuation to this, there have been many articles published about
the Comodo incident and now about the additional compromised resellers.
In interesting comment I found at
https://threatpost.com/en_us/blogs/comodo-says-two-more-registration-authorities-compromised-033011
which really brings it to the point (and is what Peter has been saying
here in other words):
[Quote:]
Pretty amazing they basically trusted RAs with access to their private
key, even if through some API or other. Why do entities like mozilla and
microsoft (who amazingly forces all their users to consent to their
trustability decisions) even allow root certificates in their
certificate stores without checking that the people with the matching
private key have any clue what they're on about?
Michael Ströder
> On the other hand, I've heard arguments against the trust revocation
> for some browsers (but not all), in the sense that such a situation
> could cause loss of market share for those browsers.
Or it could be a gain in market share.
Or there could be a coordinated trust revocation by all browser vendors.
Ciao, Michael.