subject:"Unbelievable\!"


On 12/27/2008 02:16 PM, Ian G:

Indeed, this is the Verisign buyout model; outsource something new,
get huge, get bought out by Verisign.


What has that to do exactly with what Paul agreed to?


It doesn't matter in business principle whether it outsources a function
to a reseller, to its employees or to the government.


Of course it does. Besides that an employee isn't outsourcing, he is 
part of the company. Or one might ask, why are certain functions never 
outsourced to a third party? Or perhaps lets start to outsource the CA 
root key responsibilities as well then...




Is there a criteria anywhere that says or implies The CA has not
outsourced critical function X to an external agent? Can anyone recall
such a statment?


Yes, the some extend Mozilla does that already today with the 
Problematic Practices. For example auditing of intermediate CAs 
shouldn't be outsourced from the auditor to the CA (it's just the other 
way around).


And if there is no such criteria we might still create and adopt it. 
This is no precedence, there are other criterion already.



that a popular incentive is to generate opportunities for business
revenues.


So? Mozilla really shouldn't care about the business revenues of some 
CAs. How is that relevant?



As advice this would remain fine and standard. However trying to create
some sort of restriction on how these things are done is likely to close
of opportunities to do it better another way, in the future.



I think what Paul suggested is exactly what any responsible CA should 
do. I believe most do exactly that today. Specially in light that it's 
a core requirement of the Mozilla CA policy.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 12/27/2008 02:34 PM, Gervase Markham:

One of the points of EV was to allow us to act against a CA without
massive collateral damage. We can remove EV status from a root without
disabling the root entirely.


Which unfortunately isn't really effective for the issue we are facing 
today. Removing EV status would be applicable in case the EV guidelines 
wouldn't be fulfilled by a CA. It's absolutely useless otherwise. Or 
would you suggest that because a CA doesn't perform its duties for 
regular certs to disable EV, even though their EV business practices are 
in complete compliance with the EV guidelines?


I think the opposite should be explored more clearly. Disable a root 
except in case it's an EV cert. Think about it...


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-27 Thread Ian G


On 27/12/08 02:21, Paul C. Bryan wrote:

On Dec 26, 4:40 pm, Ian Gi...@iang.org  wrote:

With respect:


This is a forum for the discussion of technical, crypto, root and general PKI
issues, by either dictat or convention.  It is not a forum for the airing of 
general
business complaints.


Are you characterizing this issue as merely a general business
complaint?



I see two particular complaints.  Firstly is the alleged 
email-soliciting.  This I would characterise as business, and I would 
suggest is completely outside scope.


The second is the alleged failure of verification.  This is more 
particularly of interest to this forum, in principle, as it poses 
questions of policy and practice, which the forum has by custom debated.


But, again, the dispute itself is probably outside scope for the moment, 
although it may be inside scope of the bugzilla filing (an open question).


These are just my views and my readings of the policy and the 
conventions.  Others no doubt will chime in.


(BTW, is it verification or validation?  As far as I know, there are 
specific meanings for these terms, and one is likely wrongly applied.)




I happen to agree that this should not be the forum for such
discussion, but as you point out, there is no other apparent forum for
dispute resolution. Where should such discussions be taken?



For the second dispute, there is a bugzilla filing.  We might take that 
as a place for the dispute before Mozilla, but this is by no means an 
exclusive venue.


The formal forum for complaints is court, and we probably have to 
respect that for both of the complaints, at some level.  Because of the 
nature of court, and because we've probably crossed the rubicon of 
actionable acts and statements, everything said here could be presented. 
 So, in effect, any parties that are named may already be in court 
and will see their statements presented.  Hence my general warning.




That said, I'd say the really pressing question is, where *better* to 
take these complaints, and deal with them in a more appropriate forum 
(court being expensive, inconveniant, and too general).  For that, I 
don't know.  Bugzilla doesn't begin to answer that question, and while 
court will likely conquer the question, it will also likely kill the 
solution and some of the participants.


I've had to work with this question in the past.  However, the solutions 
I have seen only work in certain contexts, and I can't see a way to 
scale it to this situation.  E.g., I can craft paper solutions, but they 
always end up with and then party X must agree which nobody wants.




Having appreciated this point, a more interesting one is whether we as a
community think about opening up the processes for more open governance,
more open scrutiny, more stakeholder checking [1].


My first reaction would be: most definitely, +1.

That said, you have classified this discussion as a public lynching of
a CA, called into question the professionalism of those engaging in
such discussion, and identified potential legal liabilities in doing
so.

My question to you would be: assuming the issues you raised are
legitimate (I happen to disagree) how could such an open governance
model cope with the restrictions that would most certainly be
necessary to address the issues you raised?



Good question!  What we are seeing now:  one side to the complaint feels 
bound by certain stated and unstated restrictions, whereas the other 
side(s) to the complaint feel(s) that they are free of all these stated 
and unstated restrictions.


An open governance model would attempt to address these imbalances.

Firstly, lay out the restrictions of criticism more clearly.  For 
example, we would perhaps encourage open scrutiny of security models on 
an ongoing basis, but we would require that all criticisms be grounded 
in the prevailing practices and policies.


That is, if we say the RA must not be outsourced! we would have to 
ground that as either a comment on the CPS of the CA concerned, 
referring to a statement that indeed says our RA is not outsourced or 
similar ... or as a proposal for a criteria that says RA is not in 
general outsourced which then becomes a criticism of the mozo policy 
and audit criteria, not of any CA.


(Insisting on clear grounding in practices  policies would wipe out 
about 80% of the noise we have seen in this thread.)


Secondly, statements should be primarily non-personal.  That is, if a 
representative of a CA were to call for a report to be delivered on 
X,Y,Z, then it could be taken to mean that the same representative of 
the CA were proposing that this report be standard for all CAs, and 
indeed, we might reasonably ask that representative to provide an example.


Thirdly, if there are to be any penalties then they need to equally 
bind all.  If I decide to claim that a CA is derelict in some duty, and 
this should cause loss of something, then if found not to be true, then 
the statement has to rebound on me

Re: Unbelievable!

Ian G wrote:
 On 26/12/08 00:36, Michael Ströder wrote:
 Paul Hoffman wrote:
 At 7:16 PM +0100 12/25/08, Michael Ströder wrote:
 I'd tend to punish a rogue CA by removing their root CA cert from NSS.
 
 I do not see a rogue CA.  The evidence of the posts here suggests a flaw
 leading to false certs was found and such certs were issued;  and that
 the CA responded when made aware.
 
 What is rogue about that?  Are you saying they didn't respond?

Bear in mind I'm not a native English speaker. After looking up rogue
in a dictionary it seems a little bit strong. So thanks for asking back.

Still I think we have a fundamental problem here which was discussed in
theory before many times here. And the follow-ups by Robin, Comodo and
Patricia, Certstar IMO shows that problem cannot be solved in practice
by just fixing a single mistake.

 Maybe this serves as a good example to other CAs that the Mozilla CA
 policy is really enforced. Otherwise nobody will care.
 This is Firefox we're talking about, not IE. Do you really think that
 this is going to help end users, or just hurt people who bought
 certificates from the lax (not rogue) CA?

 PKI is about security.
 
 Security is risks and costs.  In this case, there is low risk and zero
 costs.  Perhaps because the problem was caught early on, but security is
 about real hard facts not conjecture.

Ian, we had this point many times. Frankly you cannot really estimate
risks and costs in such cases since you don't know what happens out there.

Bear in mind that even though Mozilla products are provided at no cost
to the end user Mozilla could be made accountable and taken to court in
some countries for things going wrong. IIRC here in Germany you cannot
effectively deny warranty for open source products provided at no cost.
To some extent you have to apply generally accepted rules of technology
in every case.

 (If you want real hard costs and losses and grief, check out phishing.
 Where's the lynch mob when we are dealing with phishing, I wonder?)

If you really want to discredit me or my comments as lynch mob we can
simply stop discussing.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

ro...@comodo.com wrote:
 On Dec 24, 2:13 am, Paul C. Bryan em...@pbryan.net wrote:
 2. Are resellers subject to the same audits that Comodo presumably had
 to undergo to get its root certs added to Mozilla? Who performs, and
 who verifies such audits? How often are they performed?
 No, the RAs are not subject to the same audits as Comodo.

And that's a fundamental flaw. If you delegate RA functionality (here
domain validation) to a reseller leading to the reseller being capable
of triggering cert issuance without further validation of the CA the RA
should also be audited just like the CA.

 3. Are you willing to openly, continually disclose your list of
 resellers, the frequency of audits, audit methodology, and actual
 audit reports so that third parties can evaluate whether Comodo is
 trustworthy as a CA?
 That is a question combined with an assertion.
 To the question: on a unilateral basis, no, Comodo wouldn't reveal
 that level of detail of our internal operation.  If all CAs were
 required to provide the information, either to retain Webtrust
 certification or to gain or retain access to the root program of a
 major browser or other platform, then we would reconsider.
 To the assertion that this is a pre-requisite for a CA to be
 trustworthy: I am not aware that it is Mozilla's policy to require
 this information to be disclosed.

Robin, I agree that all CAs should fullfil the same requirements. And I
suspect your case is not the only problematic case.

So basically we're back at the point which was already raised many times
here. In former discussion people were concerned about the power of RAs
and sub-CAs of trusted root CAs and that this relationship is not
published at all. And as this case shows the concerns are valid.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Gervase Markham wrote:
 We (Mozilla) would expect Comodo to be issuing certificates under any
 root it owns, whether the name on the root is its own or another's,
 in compliance with the Mozilla CA policy and the audits it has
 passed.
 [..]
 There are root certificates in the store which bear the names of
 companies which have not existed for quite some time. We know about
 this. Knowing about it is not a function of audit frequency.

Disclaimer: I'm no lawyer. But different national laws might apply here.

Here in Germany we have some obligations for commercial web sites to
really show correct names (of natural or legal persons) and full postal
address so that anybody who wants to take the web site owner to court
can do so. It's called Impressumspflicht and it already caused lots of
litigation cases. In this spirit I'm not sure whether there aren't any
legal problems with root CA certs containing issuer names which are not
a valid name of a natural or legal person anymore. Even though such a
name mismatch is not primarily caused by Mozilla the project could be
taken to court because of publishing this false information as trusted.

Ask your lawyers...

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-27 Thread Gervase Markham

Eddy Nigg wrote:
 On 12/27/2008 02:34 PM, Gervase Markham:
 One of the points of EV was to allow us to act against a CA without
 massive collateral damage. We can remove EV status from a root without
 disabling the root entirely.
 
 Which unfortunately isn't really effective for the issue we are facing
 today. 

No, indeed. My point was just that sayrer said We didn't learn that
lesson for EV, and I am saying that we did.

 Removing EV status would be applicable in case the EV guidelines
 wouldn't be fulfilled by a CA. It's absolutely useless otherwise. Or
 would you suggest that because a CA doesn't perform its duties for
 regular certs to disable EV, even though their EV business practices are
 in complete compliance with the EV guidelines?

No, I'm not suggesting that.

Gerv
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-27 Thread Frank Hecker


John Nagle wrote:

   As a user of SSL certificates in our SiteTruth system, which
attempts to identify and rate the business behind a web site, we're
concerned about CA reliability and trust.  We've been using Mozilla's
approved root cert list for our system, and are considering whether
we should continue to do so.


As a general point, I have never advocated having downstream licensees 
of Mozilla code accept the default NSS root list as is, without doing 
some due diligence on their own. There are lots of roots in that list 
that are there for legacy reasons, and others that are not necessarily 
of general interest (e.g., CAs operating within a single country or 
region). I encourage you and other licensees to trim the root list to 
meet your own needs and your own assessment of CAs.



   1.Comodo must undergo an audit to WebTrust standards, and the audit
report must be published. An in-house self-investigation is not
acceptable. The audit must be conducted by a recognized outside
auditing firm.


Comodo already has undergone WebTrust audits, and presumably will do so 
again; see for example


https://cert.webtrust.org/SealFile?seal=798file=pdf
https://cert.webtrust.org/SealFile?seal=804file=pdf

which I believe are the latest ones. Robin Alden can provide information 
on other past, present, and future WebTrust audits of Comodo.



   2.CertStar must separately undergo an audit to WebTrust standards,
and the audit report must be published.


Certstar isn't a CA, and thus the WebTrust for CAs criteria are not 
necessarily a good fit for it. (Plus the expense of a full WebTrust for 
CAs audit is likely an order of magnitude higher than Certstar's 
probable revenues.) However it's certainly true that future Comodo 
WebTrust audits could and IMO should look at the question of how Comodo 
deals with resellers and affiliates, as part of the task of determining 
whether Comodo is operating in accordance with its CPS.


Frank

--
Frank Hecker
hec...@mozillafoundation.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-27 Thread Ian G


On 27/12/08 13:34, Gervase Markham wrote:

sayrer wrote:

The truth is that we are basically unable to act without a lot of
collateral damage. We should keep this in mind with future security
technology. Relying on companies willing to take money for doing
absolutely nothing (not even the bare minimum they agreed to) is not a
pleasant thing to do to our users. We didn't learn this lesson with
EV--maybe next time! :)


One of the points of EV was to allow us to act against a CA without
massive collateral damage. We can remove EV status from a root without
disabling the root entirely.



Where is this documented?  I do not recall a mention of this in the 
guidelines.  It would seem to be a fairly important point!



iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-27 Thread Ian G


On 27/12/08 13:43, Eddy Nigg wrote:

On 12/27/2008 02:16 PM, Ian G:

Indeed, this is the Verisign buyout model; outsource something new,
get huge, get bought out by Verisign.


What has that to do exactly with what Paul agreed to?


It doesn't matter in business principle whether it outsources a function
to a reseller, to its employees or to the government.


Of course it does. Besides that an employee isn't outsourcing, he is
part of the company. Or one might ask, why are certain functions never
outsourced to a third party?



E.g., employees are sometimes subject to various criteria such as 
background checking.



Or perhaps lets start to outsource the CA
root key responsibilities as well then...



This is already done.  It is common practice to outsource the security 
model of the root key to something called a HSM which is supplied by a 
manufacturer, which again likely outsources its security criteria to 
another party, for example CC.




Is there a criteria anywhere that says or implies The CA has not
outsourced critical function X to an external agent? Can anyone recall
such a statment?


Yes, the some extend Mozilla does that already today with the
Problematic Practices. For example auditing of intermediate CAs
shouldn't be outsourced from the auditor to the CA (it's just the other
way around).



They are not criteria nor policy.  If in the future they are to become 
criteria or policy, let's propose them?




And if there is no such criteria we might still create and adopt it.
This is no precedence, there are other criterion already.



Yes, that was the question, to restate it:  what criteria or policy exist?


that a popular incentive is to generate opportunities for business
revenues.


So? Mozilla really shouldn't care about the business revenues of some
CAs. How is that relevant?



Well, a normal lesson of business is that we can't get business people 
to agree to something if their revenues go down...  PKI is business only 
(a frequent complaint, who speaks for the user?), and Mozilla has to 
live in this business world.


Either way, when you get serious and propose a chance to a criteria or 
policy, we have to expect that all will consider the revenues question.


Hence, I predict there are very few restrictions on outsourcing.



...  Specially in light that it's a
core requirement of the Mozilla CA policy.



Well, with respect to desires and so forth, the words that matter are 
the ones that are in the policy.  It says:


13.  In addition to the requirements outlined above,
*we also recommend that* ...

If there is a move to make that recommendation into a requirement, let's 
hear it.




iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Ian G wrote:
 On 27/12/08 13:43, Eddy Nigg wrote:
 So? Mozilla really shouldn't care about the business revenues of some
 CAs. How is that relevant?
 
 Well, a normal lesson of business is that we can't get business people
 to agree to something if their revenues go down...  PKI is business only
 (a frequent complaint, who speaks for the user?), and Mozilla has to
 live in this business world.

Please bear in mind the CAs want to be added to the trusted root CA cert
store to make business. AFAIK they don't pay for that. So Mozilla's
customers are the end users of Firefox etc. not the CAs.

 Either way, when you get serious and propose a chance to a criteria or
 policy, we have to expect that all will consider the revenues question.

It's definitely not Mozilla's task to think about the CAs' business and
whether they have revenues when being added to trusted root CA cert
store or not!

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Frank Hecker wrote:
 John Nagle wrote:
2.CertStar must separately undergo an audit to WebTrust standards,
 and the audit report must be published.
 
 Certstar isn't a CA, and thus the WebTrust for CAs criteria are not
 necessarily a good fit for it.

If a CA delegates some tasks to a RA the RA, probably a department and
not the whole company, should be certainly part of the CA audit as well.

 (Plus the expense of a full WebTrust for
 CAs audit is likely an order of magnitude higher than Certstar's
 probable revenues.)

It's Comodo's business decision whether they delegate some tasks to an
external RA or not and whether the revenues are worth it. That's IMO out
of scope for Mozilla and its policy regarding trusted root CA certs.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-27 Thread Florian Weimer

* Hendrik Weimer:

 Frank Hecker hec...@mozillafoundation.org writes:

 My intent is to balance the disruption that would be caused by pulling
 a root vs. the actual security threat to users. Right now we have no
 real idea as to the extent of the problem (e.g., how many certs might
 have been issued without proper validation, how many of those were
 issued to malicious actors, etc.).

 Isn't that, by itself, a very good reason to take immediate action?
 Security should be default-fail rather than default-pass.

This is not about security, this is about the presence or absence of
an obscure browser warning.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-27 Thread David E. Ross

On 12/27/2008 5:07 AM, Gervase Markham wrote [in part]:
 Hi John,
 
 You raise some important questions, but it's worth having clarity on a
 few matters of fact.
 
 John Nagle wrote [also in part]:
1.AddTrust, a company which apparently no longer exists, has an
 approved
 root CA certificate.  This in itself is troublesome. 
 
 This is extremely common. Certificates change hands. Failing to honour
 root certificates which are no longer owned by the companies which
 created them would break a significant proportion of the web. Microsoft
 does not have a policy preventing this.

I would sometimes encounter a secure site with a certificate from a root
not in the Mozilla database.  The root would be from a CA that no longer
existed.  Using the WebTrust list of certified CAs (a list that no
longer appears on the Web), I would be able to trace the changes in
ownership of such CAs and determine for myself whether the root was
indeed certified by WebTrust.  It the root were certified by WebTrust,
WebTrust's list would even have a link to the current CA's Web site,
from where I could download and install the root.

This process is no longer available to users, now that WebTrust no
longer maintains a public list of certified CAs.

-- 
David E. Ross
http://www.rossde.com/

Go to Mozdev at http://www.mozdev.org/ for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications.  You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-27 Thread David E. Ross

On 12/27/2008 5:48 AM, Michael Ströder wrote [in part]:
 ro...@comodo.com wrote [in part]:
 On Dec 24, 2:13 am, Paul C. Bryan em...@pbryan.net wrote:
 2. Are resellers subject to the same audits that Comodo presumably had
 to undergo to get its root certs added to Mozilla? Who performs, and
 who verifies such audits? How often are they performed?
 No, the RAs are not subject to the same audits as Comodo.
 
 And that's a fundamental flaw. If you delegate RA functionality (here
 domain validation) to a reseller leading to the reseller being capable
 of triggering cert issuance without further validation of the CA the RA
 should also be audited just like the CA.
 

Instead of auditing RAs and resellers, audit the root CA's process for
ensuring that RAs and resellers comply with the CA's policies (e.g., the
CP).  This is what I proposed in a different (but related) thread in
this newsgroup.

The CA approves its RAs and resellers.  Thus, the CA should be held
accountable for the actions of its RAs and resellers.  If the CA's CP
addresses how accountability is handled (or denies the existence of RAs
or resellers), the CA's outside audit is supposed to review the
implementation of this (along with the implementation of the all rest of
the CP).  If this accountability is not addressed in the CP or the way
it is addressed is weak, the CA's root does not belong in the Mozilla
database.

I ask Hecker, Wilson, and any others doing the initial reviews of root
certificates proposed for inclusion in the Mozilla database to give some
attention to this.

-- 
David E. Ross
http://www.rossde.com/

Go to Mozdev at http://www.mozdev.org/ for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications.  You can access Mozdev much
more quickly than you can Mozilla Add-Ons.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Ian G wrote:
 That earlier story has no real place here, IMHO.  This is a forum for
 the discussion of technical, crypto, root and general PKI issues, by
 either dictat or convention.  It is not a forum for the airing of
 general business complaints.

I agree that the effects of this whole story on Startcom's business is
out of scope for this forum and Eddy has to clarify that with his
lawyers. I'm certain Eddy knows that. (And I personally am not
affiliated with Eddy or Startcom.)

But the fact is that Certstar used misleading DNS names for their web
site to trick Starcom's customers to re-new certs at their web site.
These server naming tricks are pretty close to what phishers are doing.
Also look at From: google@ in one of Patricia's postings. So I take this
as a strong indication that Certstar has a rather rogue attitude (and in
case of Certstar I mean like this). And discussing the conclusions for
trustworthiness of Comodo is perfectly within the scope of this forum.

 E.g., where Comodo or any CA completes an internal audit and creates a
 report to document that audit action, could we expect the CA or the
 internal auditor to publish this as a routine action?

Personally I have some doubts about auditing reports anyway.

But I believe that bad press and removing the trust flags from a root CA
cert as a result of a CA misbehaving is an appropriate negative
enforcement leading to better results in the long run. Again: If Mozilla
fails to enforce its own policy the Mozilla foundation should better
drop this whole root CA cert store completely.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 12/27/2008 05:10 PM, Michael Ströder:

Frank Hecker wrote:

(Plus the expense of a full WebTrust for
CAs audit is likely an order of magnitude higher than Certstar's
probable revenues.)


It's Comodo's business decision whether they delegate some tasks to an
external RA or not and whether the revenues are worth it. That's IMO out
of scope for Mozilla and its policy regarding trusted root CA certs.



Certainly! I don't think Frank implied that (if he would, I'd have some 
suggestions to make ;-) ), but simply stated the fact that RAs are not 
CAs and hence can't perform themselves a WebTrust for CAs audit. They 
could be audited nevertheless by an audit firm to a different set of 
criterion of course.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 12/27/2008 05:38 PM, Florian Weimer:

Isn't that, by itself, a very good reason to take immediate action?
Security should be default-fail rather than default-pass.


This is not about security, this is about the presence or absence of
an obscure browser warning.


Huuu? Have you understood the issue at all? I'm not sure...however it's 
not about browser warnings. This is about security proper. Or how else 
would you explain an MITM attack?



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 12/27/2008 03:07 PM, Gervase Markham:

This is extremely common. Certificates change hands. Failing to honour
root certificates which are no longer owned by the companies which
created them would break a significant proportion of the web. Microsoft
does not have a policy preventing this.



In itself I've raised concern about it previously. If Microsoft is 
preventing it or not it isn't really relevant. If we look at the issue 
more closely, than we will realize (maybe) that companies can change 
hands, but not root certificates. If common policies are applied to 
roots as they are applied to end-user (and even intermediate CA) 
certificates, than roots which change any of the listed parameters must 
be revoked and a new certificate created with the corrected and updated 
information. This is a common requirement of digital certificates at large.


In this case, I knew to whom the affected root belonged, even though it 
listed an unrelated company from Sweden or Utah. Others would simply not 
know. If a user must start researches in a field not familiar to him 
and/or has to contact the browser vendor in order to know who the issuer 
is, I think we have a problem.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Florian Weimer wrote:
 Even if you've got the certificate, you need to attack IP routing or
 DNS.  If you can do that, chances are that you can mount this attack
 against one of the domain-validating RAs, and still receive a
 certificate.  So the browser PKI is currently irrelevant for practical
 purposes (beyond CA revenues and giving users a warm, fuzzy feeling),
 even if everybody follows established RA procedures.

Oh Florian, come on! You know the MITM techniques within a LAN very
well. So I take your comment simply as a provocation saying that
maintaining a cert store with pre-trusted root CA certs are not worth
the effort at all. But that's also not entirely true.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 12/27/2008 11:07 PM, Michael Ströder:


I meant the RA should also be audited during the CA audit.



This in turn would be similar to this 
https://wiki.mozilla.org/CA:Problematic_Practices#Allowing_external_entities_to_operate_unconstrained_subordinate_CAs


At this stage I'm not proposing to make the same requirements as for 
externally operated intermediate CAs, however I'd maybe suggest to have 
critical aspects performed at the CA itself than have it outsourced. 
This in order to guaranty adherence to the Mozilla CA Policy section 7.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 12/27/2008 10:36 PM, Florian Weimer:

As a downstream distributor of Mozilla code,


StartCom is also a downstream distributor of Mozilla code...


I'd hate to roll out updates (especially security updates)


...which happens every two month anyway...


just because CAs start to play games with each other.


I really hope that nobody sincerely believes that this is a game. 
However any other party - and not only competing CAs - are invited to 
verify the the implementations of the StartCom CA at any time, heck I'd 
even thank you for finding a bug: http://www.startssl.com/


(For every wrongfully issued certificate I'll return to you ten times 
the amount you paid for it ;-) )



This is not about security proper.  You're
trying to pull us into a PR attack on one of your competitors, thereby
willingly reducing confidence in ecommerce.  (I'm exaggerating a bit,
of course.)


Exactly the opposite is true. If at all, I'm trying to encourage 
responsible competition on *equal* footing without compromising the 
security of the relying parties. It needs just *one* CA to devalue the 
collective work of browser vendors, certification authorities and 
cryptography specialist. Only one! Unfortunately some CAs take their 
responsibilities less serious than others - which in turn gives them a 
competitive advantage.
Besides that, I'm known to work towards improving the practices of 
public certification authorities in order to provide better security on 
the Internet.



If users edit /etc/hosts to complete the attack, it's their fault.


Nobody will do that and this is not how those attacks work. That's only 
to easily demonstrate it.



Even if you've got the certificate, you need to attack IP routing or
DNS.


This is one way, there are others [1].


If you can do that, chances are that you can mount this attack
against one of the domain-validating RAs, and still receive a
certificate.


CAs (should) have controls in place to prevent that from happening. But 
since you mentioned RAs, than yes, it's fairly bad that an RA hosted at 
a hosting provider should perform those validations. This is exactly why 
we think that this functionally should not be outsourced but performed 
at the CA.




So the browser PKI is currently irrelevant for practical
purposes (beyond CA revenues and giving users a warm, fuzzy feeling),
even if everybody follows established RA procedures.


This however is unrelated FUD!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=460374

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-27 Thread Kyle Hamilton

I am a user.  I am worried about MITM attacks.

Unlike most users, I'm technically and legally savvy enough to know:
1) Why to perform my due diligence
2) How to perform my due diligence
3) How to add the root into my store

However,  I have additional problems that I can't deal with through
the standard Mozilla user interface (or any browser that I have access
to's interface, realistically).

For example, I cannot easily see who issued a given certificate, or
what root it chains up to.  I cannot apply an attribute to a root
certificate saying not a financial-services certification authority.
 I cannot see details about the chain without having to go through
multiple difficult-to-get-to windows.

If it wasn't already obvious from the past five years that I've been
on this list, I resent the way that Mozilla's developers have chosen
to make it continually more difficult for me to do what I need to do
to ensure my own security, by concealing more and more information
(there was the blue site name bar, which was disabled by default in
FF3, which provides one-click access to the information I need --
whereas the lock icon at the bottom requires a double-click).

Further, I resent the fact that there's a this web site does not
supply identity information line.  THAT IS WHERE I NEED THE SUBJECT
TO BE PRINTED.  I honestly don't care one whit that it's not an EV
certificate.  I need the Subject, because I need to see at one glance
if it's a Domain Control Verified certificate, not have to
double-click the lock and then click View Certificate.  If you want
to point out that this is not extended-validation, that's fine -- but
for the sake of the users, don't try to protect them from
unverified information.

It is my unshakable belief that if a user EVER has to examine the
certificate itself, or go into the interface to do so, the goal of the
user interface (which is to provide information) has failed.  This is
NOT, however, a statement that the ability to view the certificate
should be removed!  (Especially given Mozilla's track record at
creating useful user interfaces for certificate data presentation --
every time they've done something right, they've gone back two
revisions later, declared it useless, removed it, and put in
something even more wrong.)

I believe that CA branding on the UI is necessary, so that the user
can do the due diligence which Mozilla is arguably NOT doing on the
user's behalf, no matter that Mozilla appears to claim that they are
by requiring audits to WebTrust criteria as a prerequisite to joining
the big CAs club of Mozilla's trust list.

-Kyle H

On Sat, Dec 27, 2008 at 11:26 AM, Ian G i...@iang.org wrote:
 On 27/12/08 20:01, Eddy Nigg wrote:

 On 12/27/2008 05:38 PM, Florian Weimer:

 Isn't that, by itself, a very good reason to take immediate action?
 Security should be default-fail rather than default-pass.

 This is not about security, this is about the presence or absence of
 an obscure browser warning.

 Huuu? Have you understood the issue at all? I'm not sure...however it's
 not about browser warnings. This is about security proper. Or how else
 would you explain an MITM attack?


 Security proper is about risks and threats and costs for end-users.  Ask
 them whether they are worried about an MITM attack :)

 Anyway, old debate, not going to be solved today.

 iang
 ___
 dev-tech-crypto mailing list
 dev-tech-crypto@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-tech-crypto

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

https://bugzilla.mozilla.org/show_bug.cgi?id=426575

UTN-UserFIRST-Hardware is enabled for EV per that bug.

-Kyle H

On Thu, Dec 25, 2008 at 9:59 AM, Frank Hecker
hec...@mozillafoundation.org wrote:
 Kyle Hamilton wrote:

 What is the effect of this problem on the request to enable the
 UTN-UserFirst-Hardware root for EV,
 https://bugzilla.mozilla.org/show_bug.cgi?id=401587 ?

 I think (but don't have time to confirm right at the moment) that that
 request is moot. As far as I know, Comodo EV certificates are working fine
 right now even in the absence of the UTN-UserFirst-Hardware root being
 enabled for EV. This is due to EV-enabling of the new Comodo EV root and
 also IIRC due to code that was added to PSM (?) to specially handle cases
 like this where the EV root was cross-signed by a non-EV legacy root.

 (AFAIK this scenario was/is not unique to Comodo. I believe all the VeriSign
 EV CAs work this way as well: a newly added and EV-enabled EV root
 cross-signed by a non-EV legacy root.)

 Frank

 --
 Frank Hecker
 hec...@mozillafoundation.org
 ___
 dev-tech-crypto mailing list
 dev-tech-crypto@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-tech-crypto

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-26 Thread robin

On Dec 24, 2:13 am, Paul C. Bryan em...@pbryan.net wrote:
 On Dec 23, 5:56 pm, ro...@comodo.com wrote:
 Some questions:

 1. Does Comodo take full responsibility for the actions of its
 resellers? If so, how should the repercussions of such failures be to
 Comodo?
Comodo accepts responsibility for the work of its RAs in the
validation that they do leading to the issuance of certificates under
our root certificates.


 2. Are resellers subject to the same audits that Comodo presumably had
 to undergo to get its root certs added to Mozilla? Who performs, and
 who verifies such audits? How often are they performed?
No, the RAs are not subject to the same audits as Comodo.  Comodo
undergoes an annual external audit to maintain our Webtrust
certification for CAs.
http://www.cica.ca/download.cfm?ci_id=45239la_id=1re_id=0
https://cert.webtrust.org/ViewSeal?id=804


 3. Are you willing to openly, continually disclose your list of
 resellers, the frequency of audits, audit methodology, and actual
 audit reports so that third parties can evaluate whether Comodo is
 trustworthy as a CA?
That is a question combined with an assertion.
To the question: on a unilateral basis, no, Comodo wouldn't reveal
that level of detail of our internal operation.  If all CAs were
required to provide the information, either to retain Webtrust
certification or to gain or retain access to the root program of a
major browser or other platform, then we would reconsider.
To the assertion that this is a pre-requisite for a CA to be
trustworthy: I am not aware that it is Mozilla's policy to require
this information to be disclosed.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

See, Robin, my thought is this:

You've already shown that it's possible for the RA function to bypass
all controls.  At this point, because they're not subject to the same
audits that Comodo is, and because the last WebTrust audit that anyone
here can find any record of is in 2007, I find it difficult to believe
that you have the annual external audit.

The internal controls are supposed to prevent this kind of
mis-issuance.  Because they didn't, they throw all the audits that you
have provided into doubt.  Because of this, there is no trust that I
have in Comodo's operation.

Further, this is a problematic practice (delegation of Registration
Authority function, as opposed to simple reseller role) that has
been shown to cast doubt on the entire domain.

The Registration Authority function is terribly security-sensitive.
If the whistle had not been blown by someone who knew where to post to
kick the beehive, would this have been detected?  Since the RAs aren't
audited (which is, by the way, a TERRIBLY dangerous practice, as
you're seeing), and your statements about a representative sample of
certificate requests are reviewed suggesting that they're not even
properly audited by your internal controls...

It is not necessarily a requirement for reseller information to be
disclosed.  However, we're trying to evaluate your company's continued
trustworthiness, and (at least at the moment) I can't find anything
there to trust.  I'm willing to allow your eleven roots to stay in the
root store with trust bits removed until you provide documentation and
an update to your agreement with your RAs to require on-site audits at
least annually (even if done by your internal auditors) -- the only
alternative at this point is to completely remove your roots from the
program.

I would like to know how you're going about ensuring that none of your
other RAs are subject to the same 'glitch' in their signup processes.
I'd like to hear that you're being proactive about this issue.

Unfortunately, I'm not hearing such.

-Kyle H

On Fri, Dec 26, 2008 at 1:10 PM,  ro...@comodo.com wrote:
 On Dec 24, 2:13 am, Paul C. Bryan em...@pbryan.net wrote:
 On Dec 23, 5:56 pm, ro...@comodo.com wrote:
 Some questions:

 1. Does Comodo take full responsibility for the actions of its
 resellers? If so, how should the repercussions of such failures be to
 Comodo?
 Comodo accepts responsibility for the work of its RAs in the
 validation that they do leading to the issuance of certificates under
 our root certificates.


 2. Are resellers subject to the same audits that Comodo presumably had
 to undergo to get its root certs added to Mozilla? Who performs, and
 who verifies such audits? How often are they performed?
 No, the RAs are not subject to the same audits as Comodo.  Comodo
 undergoes an annual external audit to maintain our Webtrust
 certification for CAs.
 http://www.cica.ca/download.cfm?ci_id=45239la_id=1re_id=0
 https://cert.webtrust.org/ViewSeal?id=804


 3. Are you willing to openly, continually disclose your list of
 resellers, the frequency of audits, audit methodology, and actual
 audit reports so that third parties can evaluate whether Comodo is
 trustworthy as a CA?
 That is a question combined with an assertion.
 To the question: on a unilateral basis, no, Comodo wouldn't reveal
 that level of detail of our internal operation.  If all CAs were
 required to provide the information, either to retain Webtrust
 certification or to gain or retain access to the root program of a
 major browser or other platform, then we would reconsider.
 To the assertion that this is a pre-requisite for a CA to be
 trustworthy: I am not aware that it is Mozilla's policy to require
 this information to be disclosed.
 ___
 dev-tech-crypto mailing list
 dev-tech-crypto@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-tech-crypto

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-26 Thread Eddy Nigg


On 12/26/2008 11:38 PM, Kyle Hamilton:

You've already shown that it's possible for the RA function to bypass
all controls.  At this point, because they're not subject to the same
audits that Comodo is, and because the last WebTrust audit that anyone
here can find any record of is in 2007, I find it difficult to believe
that you have the annual external audit.


Robin just gave us the link for the current WebTrust report. As I 
mentioned previously Comodo does perform a yearly audit. However, since 
no directory exists at WebTrust, the last audit I could find was the one 
published at the Pending page.


Here the new link: https://cert.webtrust.org/SealFile?seal=804file=pdf


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Thanks for your response Robin.

On Dec 26, 1:10 pm, ro...@comodo.com wrote:

Comodo accepts responsibility for the work of its RAs in the
validation that they do leading to the issuance of certificates under
our root certificates.

You failed to answer the other half of this question. What should the
repercussions of such failures as this be for Comodo? Simply hoping
you follow-up with your resellers (as has so far been the case with
Certstar) is not an acceptable remedy in my opinion.

No, the RAs are not subject to the same audits as Comodo. Comodo
undergoes an annual external audit to maintain our Webtrust
certification for CAs.

How can the results of the Comodo audits be considered valid if Comodo
outsources portions of its functions to third parties, that are not
subject to the same audits?

http://www.cica.ca/download.cfm?ci_id=45239la_id=1re_id=0https://cert.webtrust.org/ViewSeal?id=804

This link responds with an error result.

That is a question combined with an assertion.

Indeed, which I'll address below.

To the question: on a unilateral basis, no, Comodo wouldn't reveal
that level of detail of our internal operation. If all CAs were
required to provide the information, either to retain Webtrust
certification or to gain or retain access to the root program of a
major browser or other platform, then we would reconsider.

As I have mentioned in previous postings, a trust chain is only as
strong as its weakest link. Comodo has added extra links in its chain,
in the form of resellers whom it trusts to peform DV. If those links
in the chain are not disclosed, and not subject to the same audits as
the party applying for trust certification, then the integrity of the
chain cannot be established. I expect that no other CAs are delegating
their RA/DV functionality to third parties. If they are, then they're
in the same boat as Comodo.

To the assertion that this is a pre-requisite for a CA to be
trustworthy: I am not aware that it is Mozilla's policy to require
this information to be disclosed.

I can't see how a CA can be considered trustworthy by anyone if it
outsources portions of its core operations to undisclosed parties, and
those parties are not subject to the same criteria, inspection and
audits as the CA itself.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

On Dec 26, 2:18 pm, Paul C. Bryan em...@pbryan.net wrote:

 This link responds with an error result.

Apologies. Disregard my statement about the link error. I realized
it's two links. I will now go drink some more coffee to increase my
alertness level.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 26/12/08 22:38, Kyle Hamilton wrote:

See, Robin, my thought is this:

You've already shown that it's possible for the RA function to bypass
all controls.  At this point, because they're not subject to the same
audits that Comodo is, and because the last WebTrust audit that anyone
here can find any record of is in 2007, I find it difficult to believe
that you have the annual external audit.

The internal controls are supposed to prevent this kind of
mis-issuance.  Because they didn't, they throw all the audits that you
have provided into doubt.  Because of this, there is no trust that I
have in Comodo's operation.




The internal controls are not supposed to prevent mis-issuance.  This 
is a gross consumer simplification, and has no place here.  The controls 
are meant to reduce the likelihood of them, make them discoverable, and 
deal with them when they happen.


We can no more prevent bad certs than we can stop the winter from 
coming.  The point is to put in place economically reasonable policies 
and practices that meet an appropriate balance of security versus cost.


If there has been a case where a particular instance has swayed and 
delivered too much convenience, for too high a security risk, then the 
systems will deal with it.


So far the systems are dealing with it.  Check the facts:  CA was 
notified.  Reseller frozen.  Certs revoked.  Internal audits are 
checking.  External audit might get involved.  This is what the systems 
are supposed to do.




To all:  Although we might in other contexts promote the use of open 
forums for open governance purposes -- analysis and discussion of the 
properties of providers by open parties -- *this public lynching is not 
that*.


It is neither informed, nor professional.

Mozilla runs a process where there is a one week period of public 
scrutiny of a CA.  During that time, we could reasonably argue that 
people here are invited to state their fears.  We might consider 
discussions to be more priviledged such as in parliament.


However, outside that week, there is no such protection.  Where people 
in this group have crossed the line, and made actionable statements, 
and/or done actionable harm to a business or individual, they should 
note:  it is unlikely that Mozilla, or the community, or the businesses 
as a whole will, can or should protect them.  And where corporates are 
forced to be quiet for fear of reputational damage, then it is up to the 
rest of us to seek professionalism and self-governance.




The process of recovery from this hack is not an open nor public 
process.  CAs, as businesses, and audits, as governance are not 
generally public affairs.


If you wish to advance these into the open, by all means do, but first, 
establish a policy and a practice.  Let's establish guidelines on 
reasonable behaviour so that criticism can be seen in a narrow context, 
and can be protected and informed.


Elsewise, it is unbalanced.  You can talk unprofessionally, but others 
are forced to remain silent.  Any comments are wasted, discussion is 
fruitless at best, and at worst, the mob will have their way.




iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 26/12/08 02:28, Gen Kanai wrote:


On Dec 26, 2008, at 1:49 AM, Frank Hecker wrote:


Beyond that? It's somewhat of an open question.

Frank


Mozilla needs to have a concrete policy and procedures in place so that
there is no question as to what the penalties would be for future
actions of this kind.



Penalties ... tough talk, but what does it really mean?

Basically, all that a vendor can do is to drop the root.  (Ok, we can 
fiddle with the trust bits, but it seems a little but like fiddling to me.)


In short, it is DROP or NIX.  Can we say, blunt weapon ?  Either the 
vendor is small, so it matters not, or the vendor is huge, and it 
matters a great deal.  (In that latter case, it then matters a great 
deal to the CA.  It could be a deal killer.  E.g., bankrupcy.  Which 
means, Mozilla has to get that *right* or it faces another issue, 
further downstream.  Deep pockets plus aggressive liquidator equals 
not-nice maths.)


How does Mozo make the right decision here ?  Part of the problem in 
making it right whatever that means is that according to classical 
browser PKI it is not the responsibility of Mozo or any other vendor to 
do anything, let alone deciding what right is.


Classically, this is the policy, in a nutshell:

CA sets up.
CA gets audited.
some technical things are checked...
root is added.

It is that second part that is the clue:  the audit.  It is the audit's 
area to check whether the CA is following some sort of policy or 
practice or compliance.


So, if there is a failure, the first question to ask is whether this the 
failure is in the Audit's responsibility, or whether it is a vendor 
issue?  It might be one, or the other, or BOTH.  Certainly, in the 
current case, the vendor does not have the information to make a 
decision, whereas the Auditor might reasonably, having been in there and 
kicked the tires?



(Although I think, it is a singular observation:  there is no effective 
dispute resolution for this case or any other.  What does that say?)




iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

On Fri, Dec 26, 2008 at 3:12 PM, Ian G i...@iang.org wrote:
 (Although I think, it is a singular observation:  there is no effective
 dispute resolution for this case or any other.  What does that say?)

That there is no reason to trust a system without dispute resolution procedures.

-Kyle H
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 27/12/08 00:15, Kyle Hamilton wrote:

On Fri, Dec 26, 2008 at 3:12 PM, Ian Gi...@iang.org  wrote:

(Although I think, it is a singular observation:  there is no effective
dispute resolution for this case or any other.  What does that say?)


That there is no reason to trust a system without dispute resolution procedures.



I would be somewhat sympathetic to this  but it is kind of damning 
to the entire system.


Question is, is there a way of creating a dispute resolution system that 
would deal with the entire problem space?


Let's say you and I are in dispute, and the damages are N bucks.  We 
need someone to tell us who did what, and who does what, and who pays what.


We could envisage a forum of dispute resolution where we both agree to 
enter because we are inside this space already.  And agree to those 
liabilities.  That might work between us, but it doesn't scale.


E.g., it can't apply easily to a Firefox end-user who hasn't agreed to 
this forum.  So, if a Firefox user was ripped off because of a cert, 
then she would be shut out.  Alternatively, if she libelled a CA by 
claiming insecurities in a public blog, the CA would not be able to get 
satisfaction because she wouldn't recognise the forum.


However, maybe a partial solution is better than none?  Anything might 
be better than what we've got now...


iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-26 Thread Eddy Nigg


On 12/27/2008 12:54 AM, Ian G:


We can no more prevent bad certs than we can stop the winter from
coming. The point is to put in place economically reasonable policies
and practices that meet an appropriate balance of security versus cost.



Yeah right! It really depends what the right balance is, ehhh?!


So far the systems are dealing with it. Check the facts: CA was
notified. Reseller frozen. Certs revoked. Internal audits are checking.
External audit might get involved. This is what the systems are supposed
to do.



The story starts before that. You are just seeing the tail, I'm seeing 
what preceded to that - or better, what did not happen and should have.


That's not up to an internal audit as if it were a well hidden bug in 
one of Comodo's system that somebody succeeded to crack. But maybe Robin 
can explain to us which failures happened at their side as they are 
taking supervision of RAs and resellers very seriously. But that's most 
likely something which we'll never know.



However, outside that week, there is no such protection. Where people in
this group have crossed the line, and made actionable statements, and/or
done actionable harm to a business or individual, they should note: it
is unlikely that Mozilla, or the community, or the businesses as a whole
will, can or should protect them.


Are you speaking in the name of Mozilla? Or in the name of the 
community? Or in the name of which business exactly?


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 27/12/08 00:53, Eddy Nigg wrote:

On 12/27/2008 12:54 AM, Ian G:


We can no more prevent bad certs than we can stop the winter from
coming. The point is to put in place economically reasonable policies
and practices that meet an appropriate balance of security versus cost.



Yeah right! It really depends what the right balance is, ehhh?!



There is no right balance just like there is no world peace.  Security 
is an economic phenomena, not a beauty pageant.




So far the systems are dealing with it. Check the facts: CA was
notified. Reseller frozen. Certs revoked. Internal audits are checking.
External audit might get involved. This is what the systems are supposed
to do.



The story starts before that. You are just seeing the tail, I'm seeing
what preceded to that - or better, what did not happen and should have.



That earlier story has no real place here, IMHO.  This is a forum for 
the discussion of technical, crypto, root and general PKI issues, by 
either dictat or convention.  It is not a forum for the airing of 
general business complaints.


https://lists.mozilla.org/listinfo/dev-tech-crypto

I elsewhere mentioned there is no general mechanism for dispute 
resolution, your earlier story might be a case in point.  Or might 
not.  Either way, here is not the place to grumble about practices of 
other businesses.




However, outside that week, there is no such protection. Where people in
this group have crossed the line, and made actionable statements, and/or
done actionable harm to a business or individual, they should note: it
is unlikely that Mozilla, or the community, or the businesses as a whole
will, can or should protect them.


Are you speaking in the name of Mozilla? Or in the name of the
community? Or in the name of which business exactly?



Having appreciated this point, a more interesting one is whether we as a 
community think about opening up the processes for more open governance, 
more open scrutiny, more stakeholder checking [1].


There seems to be an emerging consensus that more open is more better, 
in general at least.


Would we be in a position to explore a general opening of all auditing 
investigations and controls [2] ?


E.g., where Comodo or any CA completes an internal audit and creates a 
report to document that audit action, could we expect the CA or the 
internal auditor to publish this as a routine action?




iang



[1]  My thanks to Robin for underscoring that observation!  I had to 
kick myself for failing to see it.


[2]  Plausibly, such a proposal will not be accepted in time for the 
current case to be effected, but that's fine as this is a forum of 
improving processes, not dispute resolution.

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

On Dec 26, 4:40 pm, Ian G i...@iang.org wrote:

With respect:

 This is a forum for the discussion of technical, crypto, root and general PKI
 issues, by either dictat or convention.  It is not a forum for the airing of 
 general
 business complaints.

Are you characterizing this issue as merely a general business
complaint?

I happen to agree that this should not be the forum for such
discussion, but as you point out, there is no other apparent forum for
dispute resolution. Where should such discussions be taken?

 Having appreciated this point, a more interesting one is whether we as a
 community think about opening up the processes for more open governance,
 more open scrutiny, more stakeholder checking [1].

My first reaction would be: most definitely, +1.

That said, you have classified this discussion as a public lynching of
a CA, called into question the professionalism of those engaging in
such discussion, and identified potential legal liabilities in doing
so.

My question to you would be: assuming the issues you raised are
legitimate (I happen to disagree) how could such an open governance
model cope with the restrictions that would most certainly be
necessary to address the issues you raised?

 Would we be in a position to explore a general opening of all auditing
 investigations and controls [2] ?

+1
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-26 Thread Eddy Nigg


On 12/27/2008 02:40 AM, Ian G:

On 27/12/08 00:53, Eddy Nigg wrote:


Yeah right! It really depends what the right balance is, ehhh?!



There is no right balance just like there is no world peace. Security
is an economic phenomena, not a beauty pageant.



No, security is an inconvenience, but I've said that earlier already.



The story starts before that. You are just seeing the tail, I'm seeing
what preceded to that - or better, what did not happen and should have.



That earlier story has no real place here, IMHO. This is a forum for
the discussion of technical, crypto, root and general PKI issues, by
either dictat or convention. It is not a forum for the airing of general
business complaints.


You don't seem to get it, do you? The story starts before your stating 
of the facts you would like us to believe. The story starts with putting 
resellers and so-called RAs in charge of validation procedures they have 
no clue about and with failing to audit, approving and controlling them, 
it's called due diligence. The story continues with failing to prevent 
issuance of high-profile target certificates such as Mozilla certainly 
is and the story continues with failing to detect them once issued. As I 
said, you are only seeing the tail...




There seems to be an emerging consensus that more open is more better,
in general at least.



This might be correct. However generally speaking CP and CP statements, 
other documents publicly available in addition to general questioning 
(at least during our review procedures at Mozilla) are fairly sufficient.


In relation to Comodo, the writing has been on the wall.


E.g., where Comodo or any CA completes an internal audit and creates a
report to document that audit action, could we expect the CA or the
internal auditor to publish this as a routine action?



I don't think we can expect that as a general role.

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-26 Thread Nelson B Bolyard

ro...@comodo.com wrote, On 2008-12-26 03:28:

We have finished our initial investigation on the certificates
 issued by Certstar.
 
 Of the 111 orders that had been placed through Certstar there remain
 13 orders for which we have still not been able to gather adequate
 evidence of the applicant having domain control.  We have therefore,
 regrettably, revoked the certificates on those orders.
 
 Of those 13 orders, 2 were placed by Eddy, for startcom.org and
 www.mozilla.com, as he has already described.  As we previously
 stated, the certificate for www.mozilla.com was revoked shortly after
 it was issued.
 
 Of the remaining 11 orders we do not have any reason to believe that
 any were placed fraudulently and had we not set such a short timescale
 to effect the (re-)validation and had it not been over this Holiday
 season we believe that we would have been able to achieve validation
 of domain control for all 11.
 
 Certstar have passed to us all of their records for these customers
 and we will ensure that they are contacted for 2 purposes:
 a) to check if it would have been possible to complete the re-validation
 b) to offer a replacement certificate.
 Some of the orders have either been charged-back or refunded.  We have
 to accept the possibility that some of those customers will not assist
 us in re-validation.
 
 Regards
 Robin Alden
 Comodo

Robin,  Thanks for that report.

Speaking for myself only, I think that the speed with which you and Comodo
dealt with this issue, once it became publicly known, and the integrity
you  Comodo showed by revoking 11 certs (~10%) whose veracity simply could
not be determined in a timely fashion, is commendable.

Issues remain, and will continue to be discussed about how this situation
came to be, and what new measures should be taken, and by whom, to minimize
the probability of it ever happening again.  But one clear conclusion from
this episode is that there is not a single clear line of separation of
responsibilities between CAs and RAs that applies to all CAs.  Clearly
several participants in this discussion were surprised that a CA would
delegate the duty of validating domain control to an RA, and some opined
that a CA ought to perform that duty itself.  I'm not convinced that's
necessary, but it certainly does seem that a CA firm ought to be prepared
to deal with the possibility that an RA makes a (potentially big) mistake
without sacrificing the CA firm's entire business.  The challenge, in the
event of an RA error, is to restore/maintain confidence in the integrity
of the CA's PKI overall, while mitigating the potential damage from dubious
enrollments.

In this case, it was feasible to examine the data for ~90% of the RA's 111
enrollments in a reasonably short time.  If the RA had enrolled 10 or 100
times as many, a much larger number (and probably a larger percentage) of
the enrollments might not have been verifiable in such a short time.
I wonder if it would have been perceived as feasible to revoke all the
unverified certs in such a case, and still remain in business.

I personally received numerous requests (mostly privately) asking for ways
for browser users to effectively disable the trust for the certs issued
under the auspices of this particular RA, at least until the veracity of
those certs could be sorted out.  As you and I discussed in bug 470897, the
only options available to users, which would effectively distrust the entire
PositiveSSL CA cert (or the entire root with all its subordinate CAs), would
have also effectively distrusted the certs issued under the auspices of
numerous other RAs.  Hence that solution would not have been a good fit for
the scope of the problem.  Nevertheless, a number of people
expressed to me the view that disabling trust in the subordinate CA that
issued certs for that RA, while too broad of a measure, was nonetheless
preferable to leaving themselves vulnerable to the possibility of false
certificates.  I sensed that they wanted the ability to take action that fit
the scope of the potential problem well, and also was potentially
reversible if and when things were finally sorted out (as it now seems they
are).  Had there been a separate CA issuing certs for this RA, the ability
to disable trust for that CA cert and the ability to restore that trust
at a later time (such as now) would have been much more satisfying to many,
I believe.

So, I would like to suggest that Comodo consider modifying its practices
somewhat, to reduce the mismatch of scope between subordinate CAs and RAs.
I suggest that Comodo operate a separate subordinate CA for each RA to
whom Comodo has delegated validation duties.  I suggest that a new
subordinate CA be created for each such RA, and that all new certs issued
for those RAs be issued from those new single-RA CAs.  I am aware of at
least one other commercial CA that operates that way, operating a separate
subordinate CA for each RA to whom they have delegated validation duties.
I

Re: Unbelievable!

I am minded of the CRL entry reason remove from CRL.  Does NSS
properly handle that reason-code?

If so, a temporary revocation of all unknown certificates might be a
sound practice, removing them from the CRL as they're found and
verified.

We are running up against problems that are caused by absolute
adherence to inflexible standards, and we're proposing mechanisms
inside of the inflexible standards to deal with them.

If there were a way to, say, have the CA include a unique, opaque code
for the RA that submitted a CSR in the issued certificate, AND if
there were a way to filter based on the content of an extension
(rather than simply leaving it completely opaque, which leads to the
current problem), then there would be no need for a separate CA for
each RA.

-Kyle H

On Fri, Dec 26, 2008 at 5:38 PM, Nelson B Bolyard nel...@bolyard.me wrote:
 ro...@comodo.com wrote, On 2008-12-26 03:28:

We have finished our initial investigation on the certificates
 issued by Certstar.

 Of the 111 orders that had been placed through Certstar there remain
 13 orders for which we have still not been able to gather adequate
 evidence of the applicant having domain control.  We have therefore,
 regrettably, revoked the certificates on those orders.

 Of those 13 orders, 2 were placed by Eddy, for startcom.org and
 www.mozilla.com, as he has already described.  As we previously
 stated, the certificate for www.mozilla.com was revoked shortly after
 it was issued.

 Of the remaining 11 orders we do not have any reason to believe that
 any were placed fraudulently and had we not set such a short timescale
 to effect the (re-)validation and had it not been over this Holiday
 season we believe that we would have been able to achieve validation
 of domain control for all 11.

 Certstar have passed to us all of their records for these customers
 and we will ensure that they are contacted for 2 purposes:
 a) to check if it would have been possible to complete the re-validation
 b) to offer a replacement certificate.
 Some of the orders have either been charged-back or refunded.  We have
 to accept the possibility that some of those customers will not assist
 us in re-validation.

 Regards
 Robin Alden
 Comodo

 Robin,  Thanks for that report.

 Speaking for myself only, I think that the speed with which you and Comodo
 dealt with this issue, once it became publicly known, and the integrity
 you  Comodo showed by revoking 11 certs (~10%) whose veracity simply could
 not be determined in a timely fashion, is commendable.

 Issues remain, and will continue to be discussed about how this situation
 came to be, and what new measures should be taken, and by whom, to minimize
 the probability of it ever happening again.  But one clear conclusion from
 this episode is that there is not a single clear line of separation of
 responsibilities between CAs and RAs that applies to all CAs.  Clearly
 several participants in this discussion were surprised that a CA would
 delegate the duty of validating domain control to an RA, and some opined
 that a CA ought to perform that duty itself.  I'm not convinced that's
 necessary, but it certainly does seem that a CA firm ought to be prepared
 to deal with the possibility that an RA makes a (potentially big) mistake
 without sacrificing the CA firm's entire business.  The challenge, in the
 event of an RA error, is to restore/maintain confidence in the integrity
 of the CA's PKI overall, while mitigating the potential damage from dubious
 enrollments.

 In this case, it was feasible to examine the data for ~90% of the RA's 111
 enrollments in a reasonably short time.  If the RA had enrolled 10 or 100
 times as many, a much larger number (and probably a larger percentage) of
 the enrollments might not have been verifiable in such a short time.
 I wonder if it would have been perceived as feasible to revoke all the
 unverified certs in such a case, and still remain in business.

 I personally received numerous requests (mostly privately) asking for ways
 for browser users to effectively disable the trust for the certs issued
 under the auspices of this particular RA, at least until the veracity of
 those certs could be sorted out.  As you and I discussed in bug 470897, the
 only options available to users, which would effectively distrust the entire
 PositiveSSL CA cert (or the entire root with all its subordinate CAs), would
 have also effectively distrusted the certs issued under the auspices of
 numerous other RAs.  Hence that solution would not have been a good fit for
 the scope of the problem.  Nevertheless, a number of people
 expressed to me the view that disabling trust in the subordinate CA that
 issued certs for that RA, while too broad of a measure, was nonetheless
 preferable to leaving themselves vulnerable to the possibility of false
 certificates.  I sensed that they wanted the ability to take action that fit
 the scope of the potential problem well, and also was potentially

Re: Unbelievable!

On Dec 26, 5:38 pm, Nelson B Bolyard nel...@bolyard.me wrote:

 Clearly several participants in this discussion were surprised that a CA would
 delegate the duty of validating domain control to an RA, and some opined
 that a CA ought to perform that duty itself.

I certainly fall in that category.

 I'm not convinced that's necessary, but it certainly does seem that a CA firm
 ought to be prepared to deal with the possibility that an RA makes a 
 (potentially
 big) mistake without sacrificing the CA firm's entire business. The 
 challenge, in
 the event of an RA error, is to restore/maintain confidence in the integrity
 of the CA's PKI overall, while mitigating the potential damage from dubious
 enrollments.

I think I can boil down my concern in this statement:

When trust is being established in a certification authority, trust is
explicitly being placed in its operational practices. It is not being
trusted in its ability to place trust in turn in whomever it may
decide to outsource its operations. By allowing arbitrary parties to
perform critical RA activities (such as DV) the CA is attempting to
extend its operations beyond that which was originally judged.

 So, I would like to suggest that Comodo consider modifying its practices
 somewhat, to reduce the mismatch of scope between subordinate CAs and RAs.
 I suggest that Comodo operate a separate subordinate CA for each RA to
 whom Comodo has delegated validation duties.  I suggest that a new
 subordinate CA be created for each such RA, and that all new certs issued
 for those RAs be issued from those new single-RA CAs.  I am aware of at
 least one other commercial CA that operates that way, operating a separate
 subordinate CA for each RA to whom they have delegated validation duties.
 I believe that is a sound way to minimize the collateral damage that
 might need to be inflicted, even temporarily, to restore/maintain PKI
 integrity in the event of a breach.

I believe your suggestion is valid. This seems to fit s. 13 of the
Mozilla CA Certificate policy: ... we recommend that CAs consider
using separate root CA certificates with separate public keys (or
separate intermediate CA certificates with separate public keys under
a single root) when issuing certificates according to different
Certificate Policies, so that we or others may selectively enable or
disable acceptance of certificates issued according to a particular
policy, or may otherwise treat such certificates differently ...

I believe another valid option would be for the CA to incorporate key
RA duties, namely domain verification. The CA can still have resellers
that initiate registration and collect information. Verification would
remain within the operations of that which is judged in the CA's
conformance to policy.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-25 Thread Daniel Veditz

Kyle Hamilton wrote:
 I then have to click at least six
 times to try to figure out what's going on, and then when I do find a
 site that's protected by an unknown CA certificate (OR that I've
 removed the trust bits on), I have to do the following:
 
 1) Click 'add an exception'
 2) click 'get certificate' (why I should have to do this is beyond me,
 since firefox obviously already has the certificate downloaded since
 it told me 'sec_error_untrusted_issuer', which it couldn't have known
 without the certificate in its possession ANYWAY)

Not that it changes your point any, but if you set the pref
browser.ssl_override_behavior to 2 then you won't need to get
Certificate. Firefox 3.1 will have this behavior by default.

If you set browser.xul.error_pages.expert_bad_cert to true then you
won't have to click a link to reveal the add exception button, saving
a click at that step, too. Firefox 3.1 won't be adopting that default
though.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Kyle Hamilton wrote:
 (Especially if Comodo delegates full Registration Authority capability
 without verification, which seems to be the case -- though they could
 have simply issued a sub-CA certificate.)

Delegating the RA's tasks is still different from issuing a sub-CA cert
since with a delegated RA the CA can look at all issued EE certs and
revoke some of them if needed. A sub-CA typically runs completely on its
own so the CA could only revoke the sub-CA cert and not certain EE certs.

 It occurs to me that there is no facility in Firefox or other Mozilla
 products to provide an explanatory dialog that there's an issue, and
 such a facility would be extremely useful at this point.  Being able
 to print a message to the user like The Mozilla Foundation has
 identified issues with the trusted root that issued this certificate
 which prevent Firefox from being able to guarantee that this is truly
 the site to which you intended to go.  While it is unlikely that this
 is a widespread problem, and an attack would rely on more technical
 intrusions into the network, the nature of these issues requires that
 you be warned of this circumstance so that you can exercise
 appropriate levels of caution.  The Mozilla Foundation is working with
 the trusted root to resolve these issues. would help a lot.

Either the trust bits are removed or not. Such a dialogue wouldn't help
at all. It's too complicated.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Suspend trust bit (was Unbelievable!)

Eddy Nigg wrote:
 On 12/23/2008 09:09 AM, Kyle Hamilton:
 Of course, this would be an NSS change (the addition of a 'trust
 suspended' bit,
 
 I think this to be an interesting idea and should be considered.

I really wonder why there should be one state more. And how is it going
to be set (updated)? A cert is either trusted or not. Period.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Frank Hecker wrote:
 From my point of view I'd wait on more
 information regarding items 2 and 3 above before making a recommendation.

Could you please define a time-frame within Comodo MUST react?

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Kyle Hamilton wrote:
 I hate to say this, but this IS The Worst-Case Scenario.  A CA has
 gone rogue and issued certificates that violate its standards, and the
 standards of the root programs that it's a part of -- it is true that
 Comodo didn't /intend/ to go rogue, but it has, and we can't afford to
 let it damage the greater PKI.  Since every CA in the root store is
 treated the same, there is no differentiation between them -- and this
 means that Verisign and Comodo and Thawte and *every* CA share the
 same reputation.  If one goes rogue, it's exactly the same as if all
 of them have gone rogue, in the eye of the end-user.

I fully agree here. That's why I support to remove the trust bit from
the Comodo root CA cert immediately and make them go through the whole
process of applying to be a trusted root CA.

 THIS is why I want to see greater differentiation in the browser
 chrome between CAs, so that one bad apple doesn't spoil the whole root
 barrel.

I don't think that's feasible. Nobody will be able to deal with that
differentiation. That's also the reason why I think that EV certs does
not help. The problem is the lack of auditing CAs and then punishing
rogue CAs.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Justin Dolske wrote:
 ...I think there's some risk that if a Firefox update suddenly breaks a
 large swath of legitimate SSL sites, that could end up training users to
 ignore the problem.

Given the large amount of self-generated server certs this problem
already exists. Ultimately you cannot hold a user back from shooting
himself in the foot.

 I'm not even sure how you'd present this condition
 to Joe The User in a comprehensible way.

I'm pretty sure that if this case is taken to popular news ticker sites
or other publications many users will be aware of this.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

doug...@theros.info wrote:
 I, for example, have a ssl cert from comodo reseller, and they DO have
 made all the validation steps.
 
 My site, a legitimate one, would be in trouble with this. Are you all
 sure that it is a good measure to just knock off the root cert or
 security bit?
 
 please, think twice

Douglas, I understand that this would be a problem for you. But after
thinking twice the larger issue with bad operational practice at
Comodo's CA and their resellers outweigh your personal damage.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Kyle Hamilton wrote:
 [..many good observations snipped..]
 Because of this, my recommendation that Comodo's trust bits be removed
 until a full audit of their practices (and a full audit of all issued
 certificates) stands, and I am that much more resolute in my belief.

Full ack!

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 12/25/2008 02:39 PM, Michael Ströder:

doug...@theros.info wrote:

I, for example, have a ssl cert from comodo reseller, and they DO have
made all the validation steps.

My site, a legitimate one, would be in trouble with this. Are you all
sure that it is a good measure to just knock off the root cert or
security bit?

please, think twice


Douglas, I understand that this would be a problem for you. But after
thinking twice the larger issue with bad operational practice at
Comodo's CA and their resellers outweigh your personal damage.



If the operations of certstar would have been a glitch and bug in their 
validation system and a very isolated event, I would not suggest to take 
any actions beyond requesting to have it fixed properly, reviewed and 
approved by the Comodo management.


The very fact that there was no validation in place *at all* suggests 
however that Comodo hasn't done any review, testing and approval of 
their systems. This is beyond the acceptable norm of failures which 
certainly can happen - it suggests gross negligence by Comodo.


Secondly, I believe that such crucial parts shouldn't be outsourced to a 
third party - an issue we'll have to look at very closely soon here at 
Mozilla. More than that, Comodo hasn't any controls in place to prevent 
fraudulent or mistaken issuance of certificates of high profile targets. 
This is another failure.


Third and as noted, resellers don't have to undergo any or only some 
validations - insufficient and not adhering to the Mozilla CA Policy. 
The policy is very clear in this respect and Comodo has failed to 
disclose this properly during their review this spring.


Douglas, if and when any actions will be taken, you'll be eligible for 
compensation by Comodo. You would have to look elsewhere to get a new 
certificates maybe. This would be perhaps annoying, however the risk of 
real damage to a third party would be much more severe.



--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-25 Thread Ian G


On 24/12/08 15:17, Frank Hecker wrote:

Gen Kanai wrote:

More discussion on this topic over at Programming Reddit:

http://www.reddit.com/r/programming/comments/7lb96/ssl_certificate_for_mozillacom_issued_without/



Unfortunately the discussion devolved (as it always does :-) into the
merits of self-signed certificates. Oh well.


And the merits of mineral water versus municipal water...  There are a 
lot of people happy with municipal water, and a lot of people happy with 
mineral water, and they aren't likely to sit down and share a social 
drink :)


iang
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-25 Thread Frank Hecker


Michael Ströder wrote:

Frank Hecker wrote:

From my point of view I'd wait on more
information regarding items 2 and 3 above before making a recommendation.


Could you please define a time-frame within Comodo MUST react?


Comodo (in the person of Robin Alden) has already made a reply:

http://groups.google.com/group/mozilla.dev.tech.crypto/msg/b24e70ea2c396bb5

The question is, what else do what want Comodo to do in this case? They 
still have some certificates unaccounted for in terms of verifying the 
validation, and certainly I'd like to hear the status of that as soon as 
possible. Beyond that? It's somewhat of an open question.


Frank

--
Frank Hecker
hec...@mozillafoundation.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-25 Thread Frank Hecker


Kyle Hamilton wrote:

What is the effect of this problem on the request to enable the
UTN-UserFirst-Hardware root for EV,
https://bugzilla.mozilla.org/show_bug.cgi?id=401587 ?


I think (but don't have time to confirm right at the moment) that that 
request is moot. As far as I know, Comodo EV certificates are working 
fine right now even in the absence of the UTN-UserFirst-Hardware root 
being enabled for EV. This is due to EV-enabling of the new Comodo EV 
root and also IIRC due to code that was added to PSM (?) to specially 
handle cases like this where the EV root was cross-signed by a non-EV 
legacy root.


(AFAIK this scenario was/is not unique to Comodo. I believe all the 
VeriSign EV CAs work this way as well: a newly added and EV-enabled EV 
root cross-signed by a non-EV legacy root.)


Frank

--
Frank Hecker
hec...@mozillafoundation.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Frank Hecker wrote:
 Michael Ströder wrote:
 Frank Hecker wrote:
 From my point of view I'd wait on more
 information regarding items 2 and 3 above before making a
 recommendation.

 Could you please define a time-frame within Comodo MUST react?
 
 Comodo (in the person of Robin Alden) has already made a reply:
 
 http://groups.google.com/group/mozilla.dev.tech.crypto/msg/b24e70ea2c396bb5

Yes, already saw that in the meantime. But it does not really say much.

 The question is, what else do what want Comodo to do in this case?

I'd like to know whether there are more contractors serving as RA for
Comodo. A list should provided who they are and which measures are taken
for domain validation. What really strikes me is that this case was only
detected by Eddy because of Certstar's spam e-mails.

 They still have some certificates unaccounted for in terms of
 verifying the validation, and certainly I'd like to hear the status
 of that as soon as possible. Beyond that? It's somewhat of an open
 question.

I'd tend to punish a rogue CA by removing their root CA cert from NSS.
Maybe this serves as a good example to other CAs that the Mozilla CA
policy is really enforced. Otherwise nobody will care.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-25 Thread Kyle Hamilton

I've already stated my preference.

To reiterate:

Actually, I think it's very important that the accounting include this:

for each name (not just certificate, but name in
subjectAlternativeNames) that has been certified, a connection to the
TLS ports should be made, and the certificate presented by the site
compared against the certificate that Comodo issued.  This obviously
won't be a complete verification, but it should give a start to see
how widespread the problem is.

A script to do this could probably be written fairly easily, but
depending on the number of certificates Comodo has issued that are
currently valid (and I'd like to see some hard numbers on that, as
well) it could take a while to run.

From the script, the numbers I'd like to see are: the number of
unreachable/not-answering names/hosts, the number of matching
certificates, and the number of mismatched certificates.  From that
output plus Comodo's records, I would also like to see how many
resellers there are and how many of them have sold mismatched
certificates.

(The 'resellers' I refer to here are 'contracted registration
authorities', not those who make money by funnelling users into
Comodo's pages.  I'd also like to know how Robin/Comodo performed the
audit on certificates for proper domain validation -- if they're
relying on the presence or absence of that check-box I have verified
the domain control in accordance with..., I think the entire audit is
useless and that they should be removed from the root store out of
spite -- for making a mockery of the entire process.)

I do think that Comodo should be required to suspend their
Registration Authority processing until they in-source their
domain-control verification as a condition of staying in Mozilla's
trust list.  I also have not heard word 1 about if they use
registration authorites for higher-assurance certificates.

-Kyle H

On Thu, Dec 25, 2008 at 8:49 AM, Frank Hecker
hec...@mozillafoundation.org wrote:
 Michael Ströder wrote:

 Frank Hecker wrote:

 From my point of view I'd wait on more
 information regarding items 2 and 3 above before making a recommendation.

 Could you please define a time-frame within Comodo MUST react?

 Comodo (in the person of Robin Alden) has already made a reply:

 http://groups.google.com/group/mozilla.dev.tech.crypto/msg/b24e70ea2c396bb5

 The question is, what else do what want Comodo to do in this case? They
 still have some certificates unaccounted for in terms of verifying the
 validation, and certainly I'd like to hear the status of that as soon as
 possible. Beyond that? It's somewhat of an open question.

 Frank

 --
 Frank Hecker
 hec...@mozillafoundation.org
 ___
 dev-tech-crypto mailing list
 dev-tech-crypto@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-tech-crypto

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Suspend trust bit (was Unbelievable!)

2008-12-25 Thread Kyle Hamilton

If Frank's desire to balance user benefit from keeping the root in
with user security by taking the root out is to be upheld, then there
needs to be a way to notify the software user that there is a valid
complaint against the operator of the CA in question.

If it drives business away from the CA in question (because the owner
of the site doesn't want to have to deal with the warning every time
she browses to it using Firefox), well, that's the CA's own fault.
The setting of that bit should encompass the following:

1) A complaint has been made,
2) Mozilla has examined the complaint, and
3) Mozilla has found good cause for believing that the conduct of the
CA has violated its root CA policy.

Thus, such a statement would not (and could not) be made until Mozilla
has done its own due diligence, and thus such a statement would not be
libelous.  (I wish that Mozilla's general counsel was on this list.)

-Kyle H

On Thu, Dec 25, 2008 at 3:21 AM, Michael Ströder mich...@stroeder.com wrote:
 Eddy Nigg wrote:
 On 12/23/2008 09:09 AM, Kyle Hamilton:
 Of course, this would be an NSS change (the addition of a 'trust
 suspended' bit,

 I think this to be an interesting idea and should be considered.

 I really wonder why there should be one state more. And how is it going
 to be set (updated)? A cert is either trusted or not. Period.

 Ciao, Michael.
 ___
 dev-tech-crypto mailing list
 dev-tech-crypto@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-tech-crypto

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-25 Thread Paul Hoffman

At 11:13 PM -0800 12/24/08, Daniel Veditz wrote:
Paul Hoffman wrote:
 At 1:16 AM +0200 12/24/08, Eddy Nigg wrote:
 Select Preferences - Advanced - View Certificates - Authorities.
  Search for AddTrust AB - AddTrust External CA Root and click
 Edit. Remove all Flags.

 Doesn't this seem like a better solution than sue Mozilla for
 theoretical future damages incurred by using their free software?
 Put more rudely, why do you expect Daddy to fix it for you when you
 can fix it yourself, more easily and more quickly, if you want to?

Isn't that a bit like an auto maker issuing a notice If you don't want
your car to explode in a fender bender you can crawl under the right
rear and remove the screw marked 34A on the following diagram.

It depends on what you mean by a bit.

I don't remember paying for Firefox. Nor do I remember anything in the software 
that made any strong assertion of the validity of all the certs that might be 
issued by any of the CAs in the root pile. Maybe you had a different experience.

--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-25 Thread Paul Hoffman

At 7:16 PM +0100 12/25/08, Michael Ströder wrote:
I'd tend to punish a rogue CA by removing their root CA cert from NSS.
Maybe this serves as a good example to other CAs that the Mozilla CA
policy is really enforced. Otherwise nobody will care.

This is Firefox we're talking about, not IE. Do you really think that this is 
going to help end users, or just hurt people who bought certificates from the 
lax (not rogue) CA?

Like most punishment, the origin is more often the desire of the punisher to 
feel powerful. In this case, it is also for financial gain by the first one to 
propose the punishment, of course, but the base desire is the same.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 12/25/2008 08:16 PM, Michael Ströder:

The question is, what else do what want Comodo to do in this case?


What really strikes me is that this case was only
detected by Eddy because of Certstar's spam e-mails.



Even though I believe that Robin and his crew are really angry with me 
right now for disclosing it publicly, this was really the least price 
they could pay and best case scenario for this situation. None of the 
109 other cert holders suspected that anything might be wrong. I'm 
certain that this would not have remained undetected for long and 
somebody could have brought some real damage upon all parties involved.


Speaking about Robin, I wouldn't want to be in his shoes right now - 
it's more or less one of the nightmares of a CA. On the other hand, if 
this is case (it would be for me) than I really anticipate and hope that 
some real changes are going to happen. Additionally, whatever actions 
are taken against Comodo and whatever lessons they learned, one thing is 
clear, that the company which spammed and mislead other CAs customers so 
shamelessly has nothing lost in this industry.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 12/26/2008 12:24 AM, Paul Hoffman:

At 7:16 PM +0100 12/25/08, Michael Ströder wrote:

I'd tend to punish a rogue CA by removing their root CA cert from NSS.
Maybe this serves as a good example to other CAs that the Mozilla CA
policy is really enforced. Otherwise nobody will care.


This is Firefox we're talking about, not IE.


Depending on country and audience, Internet Explorer has even less 
market share than Firefox. We are in 2009, not 2003 if you forgot.



Do you really think that this is going to help end users,


In the longer term it might. And it really depends on other factors like 
how many potentially other certs could have been issued this way.



or just hurt people who bought certificates from the lax (not rogue) CA?


So? They may claim damage from Comodo. Comodo even lists the compatible 
browsers in their CPS [1] under section 2.1.5 CA Root Public Key 
Delivery to Subscribers. A CA shouldn't guaranty browser support at any 
time (and I doubt if Comodo really did).




In this case, it is also for financial gain by the first one to propose the 
punishment, of course, but the base desire is the same.


Do you mean me? Go back and read what I really proposed: 
http://groups.google.com/group/mozilla.dev.tech.crypto/msg/fb8c1fbd0c219eb4

But perhaps you'd disclose how many Comodo shares you've got? ;-)

[1] 
http://www.comodo.com/repository/09_22_2006_Certification_Practice_Statement_v.3.0.pdf


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

Paul Hoffman wrote:
 At 7:16 PM +0100 12/25/08, Michael Ströder wrote:
 I'd tend to punish a rogue CA by removing their root CA cert from NSS.
 Maybe this serves as a good example to other CAs that the Mozilla CA
 policy is really enforced. Otherwise nobody will care.
 
 This is Firefox we're talking about, not IE. Do you really think that
 this is going to help end users, or just hurt people who bought
 certificates from the lax (not rogue) CA?

PKI is about security. Strange I have to remind you about that. There is
a Mozilla CA policy which was violated possibly causing a risk for
end-users. Mozilla has to give some evidence to the community and CAs
that the policy is enforced.

 Like most punishment, the origin is more often the desire of the
 punisher to feel powerful. In this case, it is also for financial
 gain by the first one to propose the punishment, of course, but the
 base desire is the same.

Personally I have absolutely no benefit from withdrawing the trust flags
from Comodo's root CA cert. So it seems strange to me that you're
accusing me in such an arrogant way. This does not contribute anything
to this discussion.

Ciao, Michael.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-25 Thread Gen Kanai



On Dec 26, 2008, at 1:49 AM, Frank Hecker wrote:


Beyond that? It's somewhat of an open question.

Frank


Mozilla needs to have a concrete policy and procedures in place so  
that there is no question as to what the penalties would be for future  
actions of this kind.


I personally like John Nagle's proposal from earlier in this thread:

http://groups.google.com/group/mozilla.dev.tech.crypto/msg/9443ba781a669879

I think there are other actions that need to be taken beyond John  
Nagle's proposal, but it is a good start.


In addition to John Nagle's propsosal, I believe Mozilla needs to act  
early in 2009, and not let weeks or months go by without resolution.   
We can discuss the details of what happened and why endlessly to no  
benefit of our users.


Gen
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 12/26/2008 03:28 AM, Gen Kanai:

I personally like John Nagle's proposal from earlier in this thread:

http://groups.google.com/group/mozilla.dev.tech.crypto/msg/9443ba781a669879



Gen, one thing to note, that Comodo most likely performs a yearly 
WebTrust audit, though the last one I can see currently is from the 
tenth of July 2007.


Also important to note that the audit itself isn't enough - that's why 
there is the Mozilla CA Policy which clearly defines the minimal 
requirements. (A CAs can pass a WebTrust audit without conforming to 
those requirements set up by Mozilla).


As a matter of fact, we are still missing a procedure to make sure that 
CAs issuing EV certificates indeed perform the yearly audit as required 
by the EV guidelines. Those which don't, have to have EV status removed 
as they wouldn't be in compliance with the EV guidelines.


Additionally, Mozilla has no control directly over certificates issued 
through certstar, since the certificates are issued from an intermediate 
CA certificate of Comodo. It's however possible and relatively easy to 
ADD this intermediate to NSS and deliberately mark it untrusted. It 
could be a good solution to prevent damage in case there should be more 
certificates in the wild (and assuming that resellers certs are issued 
through this intermediate).


Incidentally I've brought up the issue of AddTrust and UserSomething CAs 
during the review discussion this year. It isn't exactly surprising that 
now all those questionable practices come up again, isn't it?! There 
were many more concerns brought up, which had no effect whatsoever on 
the status of Comodo and their request to upgrade to EV was eventually 
approved.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-25 Thread Ian G


On 26/12/08 00:36, Michael Ströder wrote:

Paul Hoffman wrote:

At 7:16 PM +0100 12/25/08, Michael Ströder wrote:

I'd tend to punish a rogue CA by removing their root CA cert from NSS.



I do not see a rogue CA.  The evidence of the posts here suggests a flaw 
leading to false certs was found and such certs were issued;  and that 
the CA responded when made aware.


What is rogue about that?  Are you saying they didn't respond?



Maybe this serves as a good example to other CAs that the Mozilla CA
policy is really enforced. Otherwise nobody will care.

This is Firefox we're talking about, not IE. Do you really think that
this is going to help end users, or just hurt people who bought
certificates from the lax (not rogue) CA?


PKI is about security.



Security is risks and costs.  In this case, there is low risk and zero 
costs.  Perhaps because the problem was caught early on, but security is 
about real hard facts not conjecture.


(If you want real hard costs and losses and grief, check out phishing. 
Where's the lynch mob when we are dealing with phishing, I wonder?)




Strange I have to remind you about that. There is
a Mozilla CA policy which was violated possibly causing a risk for
end-users. Mozilla has to give some evidence to the community and CAs
that the policy is enforced.



But it has!  Mozilla talked to the CA.  The CA is dealing with it. 
There are emails to that extent, posted here.


What else is necessary?  And more importantly, why?



iang, curiosity mode switched to hard-ON.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-24 Thread Frank Hecker


Eddy Nigg wrote:
My blog article and exposure has provoked somebody to come forward with 
additional evidences concerning the reseller activities of Comodo. In 
order to protect the innocent I decided to provide this information 
confidentially to Frank Hecker for now. Stay tuned.


To expand on what I wrote to Eddy via email, I really don't want to be 
dealing with information sent to me in confidence. I'm skeptical about 
dealing with reports where the originators of the reports aren't willing 
to go on public record with their complaints, especially when there are 
possibly mixed motives on the part of the person or organization 
reporting the problem. (For example, CAs reporting on either CAs, or 
resellers reporting on other resellers.)


Frank

--
Frank Hecker
hec...@mozillafoundation.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

On Wed, Dec 24, 2008 at 6:17 AM, Frank Hecker
hec...@mozillafoundation.org wrote:
 Gen Kanai wrote:

 More discussion on this topic over at Programming Reddit:


 http://www.reddit.com/r/programming/comments/7lb96/ssl_certificate_for_mozillacom_issued_without/

 Unfortunately the discussion devolved (as it always does :-) into the merits
 of self-signed certificates. Oh well.

 Frank

Honestly, I get more mileage out of doing my own diligence.  This is
why I want to have my own root certificate that I can cross-sign the
various commercial CA certificates with, so that I can revoke those
cross-signatures if they turn out to have a problem.

I'd like to see an extension that allows other certificates (for the
same public key) to be included in a certificate (self-signed or not).
 This would protect against one of the threats against the OpenPGP
model, would create a means for certifications to be cherry-picked for
any given application, and would allow other identities for that
public key to be added by the identity collector -- but would also
create a linkage back to the identity collector's public key.
(realistically, the only reason for the signature on an external
certificate that contains an extension like this would be because no
X.509 software handles the TBSCertificate structure without the
signature.)

-Kyle H
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-24 Thread Paul Hoffman

At 9:14 AM -0800 12/24/08, Kyle Hamilton wrote:
I'd like to see an extension that allows other certificates (for the
same public key) to be included in a certificate (self-signed or not).

Are you asking for a Mozilla extension or a PKIX extension? If the latter, none 
is needed: it is already inherent in PKIX. In fact, I am not sure that anything 
needs to be done by Mozilla. The following should theoretically work:

- Remove all trust anchors one-by-one
- Add your single trust anchor
- Sign the certs of any CA you want
- Add those signed certs to the pre-loaded validation path (not root) cert list

I haven't tried this myself, but it should work. I have been told that 
something very similar to it works fine in XP/Vista for IE.

--Paul Hoffman
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

In the terminology of ASN.1 and PKIX, I want a standardized PKIX
extension that allows for a SEQUENCE OF Certificate within the
tbsCertificate structure.

I'm trying to figure out how I'm supposed to extract all the
certificates from my database without any version of keytool that I
can find available for OSX 10.5 (Leopard).

-Kyle H

On Wed, Dec 24, 2008 at 9:55 AM, Paul Hoffman phoff...@proper.com wrote:
 At 9:14 AM -0800 12/24/08, Kyle Hamilton wrote:
I'd like to see an extension that allows other certificates (for the
same public key) to be included in a certificate (self-signed or not).

 Are you asking for a Mozilla extension or a PKIX extension? If the latter, 
 none is needed: it is already inherent in PKIX. In fact, I am not sure that 
 anything needs to be done by Mozilla. The following should theoretically work:

 - Remove all trust anchors one-by-one
 - Add your single trust anchor
 - Sign the certs of any CA you want
 - Add those signed certs to the pre-loaded validation path (not root) cert 
 list

 I haven't tried this myself, but it should work. I have been told that 
 something very similar to it works fine in XP/Vista for IE.

 --Paul Hoffman
 ___
 dev-tech-crypto mailing list
 dev-tech-crypto@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-tech-crypto

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-24 Thread John Nagle


   As a user of SSL certificates in our SiteTruth system, which
attempts to identify and rate the business behind a web site, we're
concerned about CA reliability and trust.  We've been using Mozilla's
approved root cert list for our system, and are considering whether
we should continue to do so.  Given the situation described in

http://markmail.org/message/rje3lssql55l2rev?q=unbelievable;

the use of Mozila's root CA list is now questionable.

   There seem to be several problems here.

   1.   AddTrust, a company which apparently no longer exists, has an approved
root CA certificate.  This in itself is troublesome.  Comodo does
not seem to have taken on the obligations of AddTrust; see
http://markmail.org/message/3zr4e5hxwmxjbgnp?q=Comodo+AddTrust;.
Yet Comodo is still issuing certificates under the root CA of
this dead company.

   2.   Comodo is apparently not only allowing resellers like CertStar,
but is allowing them to do their own validation of the legitimacy
of the certificate requestor.  Who takes financial responsibility
for such errors?  CertStar itself disclaims financial responsibility
at http://www.certstar.com/terms.html;.

   3.   Microsoft requires an annual audit for root CAs:
http://technet.microsoft.com/en-us/library/cc751157.aspx;.
Mozilla seems willing to accept a one-time audit.  That seems
to be why the disappearance of AddTrust wasn't noticed.
Microsoft's audit requirements extend all the way down the
chain of trust.  Their policy is:
The CA must complete an audit and submit audit results to Microsoft
every twelve (12) months. The Audit must cover the full PKI hierarchy
that will be enabled by Microsoft through the assignment of Extended
Key Usages (EKUs). All certificate usages that we enable must be
audited periodically. The audit report must document the full scope
of the PKI hierarchy including any sub-CA that issues a specific type
of certificate covered by an audit.  Microsoft uses the standards of
the WebTrust Program for Certification Authorities
(http://www.cica.ca/download.cfm?ci_id=45239la_id=1re_id=0;)
managed by the Canadian Society of Chartered Accountants.  That's
a good guideline for Mozilla to follow.

At this point, I would suggest that the following actions are appropriate
to bring Comodo and Mozilla into compliance with the WebTrust standards:

   1.   Comodo must undergo an audit to WebTrust standards, and the audit
report must be published. An in-house self-investigation is not
acceptable. The audit must be conducted by a recognized outside
auditing firm.
   2.   CertStar must separately undergo an audit to WebTrust standards,
and the audit report must be published.  An in-house
self-investigation is not acceptable. The audit must be conducted
by a recognized outside auditing firm.  CertStar should not be
permitted to issue any new certificates until this process is
complete and the audit results are satisfactory.  If this process
is not complete within 3 months, all CertStar-issued certificates
should be revoked.
   3.   Comodo must disclose the identities of all resellers to which
it has outsourced any validation functions.
   4.   All AddTrust root CA certificates must be phased out.  An
expiration date in Q1 or Q2 2009 is suggested.  Since no company
stands behind the AddTrust name, it's necessary to force expiration
of that root.
   5.   The Mozilla Foundation should contact Microsoft's CA Root Certificate
group to coordinate their actions.

John Nagle
SiteTruth
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-24 Thread Nelson B Bolyard

Paul Hoffman wrote, On 2008-12-24 09:55:
 At 9:14 AM -0800 12/24/08, Kyle Hamilton wrote:
 I'd like to see an extension that allows other certificates (for the
 same public key) to be included in a certificate (self-signed or not).
 
 Are you asking for a Mozilla extension or a PKIX extension? If the
 latter, none is needed: it is already inherent in PKIX. In fact, I am not
 sure that anything needs to be done by Mozilla. The following should
 theoretically work:
 
 - Remove all trust anchors one-by-one
 - Add your single trust anchor
 - Sign the certs of any CA you want
 - Add those signed certs to the pre-loaded validation path (not root)
 cert list
 
 I haven't tried this myself, but it should work. I have been told that
 something very similar to it works fine in XP/Vista for IE.

Of course, that is COMPLETELY equivalent to simply setting trust flags on
the CA certs you want to trust, and removing those flags from the ones you
don't want to trust, which is already a part of Mozilla browsers (and
Netscape browsers, before them) for over 14 years.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

On Wed, Dec 24, 2008 at 1:46 PM, Nelson B Bolyard nel...@bolyard.me wrote:
 Paul Hoffman wrote, On 2008-12-24 09:55:
 At 9:14 AM -0800 12/24/08, Kyle Hamilton wrote:
 I'd like to see an extension that allows other certificates (for the
 same public key) to be included in a certificate (self-signed or not).

 Are you asking for a Mozilla extension or a PKIX extension? If the
 latter, none is needed: it is already inherent in PKIX. In fact, I am not
 sure that anything needs to be done by Mozilla. The following should
 theoretically work:

 - Remove all trust anchors one-by-one
 - Add your single trust anchor
 - Sign the certs of any CA you want
 - Add those signed certs to the pre-loaded validation path (not root)
 cert list

 I haven't tried this myself, but it should work. I have been told that
 something very similar to it works fine in XP/Vista for IE.

 Of course, that is COMPLETELY equivalent to simply setting trust flags on
 the CA certs you want to trust, and removing those flags from the ones you
 don't want to trust, which is already a part of Mozilla browsers (and
 Netscape browsers, before them) for over 14 years.

To be honest, Mozilla doesn't distribute keytool with Firefox, which
means that I have to try to go into the (unbatchable) interface and
remove the flags one. by. one. by. one. and then select the next
certificate and remove those trust flags, and the next, and the next,
and the next...

...for all hundred or so certs that Firefox includes.

And then, once I DO manage to do that, then with the new and
improved user interface updates, I then have to click at least six
times to try to figure out what's going on, and then when I do find a
site that's protected by an unknown CA certificate (OR that I've
removed the trust bits on), I have to do the following:

1) Click 'add an exception'
2) click 'get certificate' (why I should have to do this is beyond me,
since firefox obviously already has the certificate downloaded since
it told me 'sec_error_untrusted_issuer', which it couldn't have known
without the certificate in its possession ANYWAY)
3) click 'view'
4) get the name of the Issuer
5) hope to all the gods that there's enough information in the chain
to figure out what root it's supposed to be going to
6) close the window
7) go into Preferences
8) click Advanced
9) click Encryption
10) click 'View Certificates'
11) Scroll through the list, with each click giving me approximately
0.6 useful results (given the preponderance of 'section headings by
root owner', which by the way doesn't work at all with the Addtrust AB
stuff since those are Comodo roots)
12) find the appropriate root and re-enable it for identification of websites
13) refresh the page.

How 'bout this, Nelson (and I invite Frank and the entire security UI
team to do this, as well): YOU do it.  Create a new profile and
manually remove the trust on every CA.  Then, browse around, and see
which CAs are actually used by you in your day-to-day browsing,
reenabling them manually (since you're trying to emulate not having
keytool around).

Furthermore, even when keytool IS available, it's entirely likely that
its name conflicts with Java's keytool.  (especially on Mac OSX.)

This is completely unworkable, and discourages users that want to from
taking their security into their own hands.

-Kyle H
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

I'm also going to state that yes, I know this, because I HAVE DONE IT.
 And I wouldn't wish that hell on anyone who didn't have a DETAILED
knowledge of how the X.509 model operates, and I wouldn't wish the
user-interface hell on ANYONE.

-Kyle H

On Wed, Dec 24, 2008 at 2:36 PM, Kyle Hamilton aerow...@gmail.com wrote:
 On Wed, Dec 24, 2008 at 1:46 PM, Nelson B Bolyard nel...@bolyard.me wrote:
 Of course, that is COMPLETELY equivalent to simply setting trust flags on
 the CA certs you want to trust, and removing those flags from the ones you
 don't want to trust, which is already a part of Mozilla browsers (and
 Netscape browsers, before them) for over 14 years.

 To be honest, Mozilla doesn't distribute keytool with Firefox, which
 means that I have to try to go into the (unbatchable) interface and
 remove the flags one. by. one. by. one. and then select the next
 certificate and remove those trust flags, and the next, and the next,
 and the next...

 ...for all hundred or so certs that Firefox includes.

 And then, once I DO manage to do that, then with the new and
 improved user interface updates, I then have to click at least six
 times to try to figure out what's going on, and then when I do find a
 site that's protected by an unknown CA certificate (OR that I've
 removed the trust bits on), I have to do the following:

 1) Click 'add an exception'
 2) click 'get certificate' (why I should have to do this is beyond me,
 since firefox obviously already has the certificate downloaded since
 it told me 'sec_error_untrusted_issuer', which it couldn't have known
 without the certificate in its possession ANYWAY)
 3) click 'view'
 4) get the name of the Issuer
 5) hope to all the gods that there's enough information in the chain
 to figure out what root it's supposed to be going to
 6) close the window
 7) go into Preferences
 8) click Advanced
 9) click Encryption
 10) click 'View Certificates'
 11) Scroll through the list, with each click giving me approximately
 0.6 useful results (given the preponderance of 'section headings by
 root owner', which by the way doesn't work at all with the Addtrust AB
 stuff since those are Comodo roots)
 12) find the appropriate root and re-enable it for identification of websites
 13) refresh the page.

 How 'bout this, Nelson (and I invite Frank and the entire security UI
 team to do this, as well): YOU do it.  Create a new profile and
 manually remove the trust on every CA.  Then, browse around, and see
 which CAs are actually used by you in your day-to-day browsing,
 reenabling them manually (since you're trying to emulate not having
 keytool around).

 Furthermore, even when keytool IS available, it's entirely likely that
 its name conflicts with Java's keytool.  (especially on Mac OSX.)

 This is completely unworkable, and discourages users that want to from
 taking their security into their own hands.

 -Kyle H

___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-24 Thread Eddy Nigg


On 12/25/2008 12:36 AM, Kyle Hamilton:

To be honest, Mozilla doesn't distribute keytool with Firefox, which
means that I have to try to go into the (unbatchable) interface and
remove the flags one. by. one. by. one. and then select the next
certificate and remove those trust flags, and the next, and the next,
and the next...


Kyle, why don't you blow that libnssckbi away from your Firefox 
installation? Would make it easier I think. (Hope I picked the right one 
;-) )


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

On Wed, Dec 24, 2008 at 2:46 PM, Eddy Nigg eddy_n...@startcom.org wrote:
 On 12/25/2008 12:36 AM, Kyle Hamilton:

 To be honest, Mozilla doesn't distribute keytool with Firefox, which
 means that I have to try to go into the (unbatchable) interface and
 remove the flags one. by. one. by. one. and then select the next
 certificate and remove those trust flags, and the next, and the next,
 and the next...

 Kyle, why don't you blow that libnssckbi away from your Firefox
 installation? Would make it easier I think. (Hope I picked the right one ;-)
 )

Primarily because I want those certs on one profile, but not another,
and disk space is kind of at a premium right now. :)

(Oh yeah, if one person who uses a computer doesn't want the built-in
roots, but another does, they have to have separate Firefox
installations.)

-Kyle H
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-24 Thread Nelson B Bolyard

Kyle Hamilton wrote, On 2008-12-24 14:53:
 On Wed, Dec 24, 2008 at 2:46 PM, Eddy Nigg eddy_n...@startcom.org wrote:
 On 12/25/2008 12:36 AM, Kyle Hamilton:
 To be honest, Mozilla doesn't distribute keytool with Firefox, which
 means that I have to try to go into the (unbatchable) interface and
 remove the flags one. by. one. by. one. and then select the next
 certificate and remove those trust flags, and the next, and the next,
 and the next...

What is the relevance of keytool here?
The tool relevant to NSS is certutil.  It is scriptable.
It's quite possible to write scripts to use certutil to do mass trust
modification.  I've done it.  But there's probably a much easier way
than that.

 Kyle, why don't you blow that libnssckbi away from your Firefox
 installation? Would make it easier I think. (Hope I picked the right one ;-)
 )
 
 Primarily because I want those certs on one profile, but not another,
 and disk space is kind of at a premium right now. :)
 
 (Oh yeah, if one person who uses a computer doesn't want the built-in
 roots, but another does, they have to have separate Firefox
 installations.)

No, it is possible to accommodate both with a single installation.
There are several ways to do it.  Here's one.
Move the nssckbi file from the Firefox code directory where it normally
lives to the profile directory (where the cert8.db file lives) for the
user profile that wants to use it.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-24 Thread sayrer

On Dec 23, 10:33 pm, Paul Hoffman phoff...@proper.com wrote:
 At 1:16 AM +0200 12/24/08, Eddy Nigg wrote:

 Select Preferences - Advanced - View Certificates - Authorities. Search 
 for AddTrust AB - AddTrust External CA Root and click Edit. Remove all 
 Flags.

 Put more rudely, why do you expect Daddy to fix it for you when you can fix 
 it yourself, more easily and more quickly, if you want to?

Mozilla is in the business of protecting all users, not just those
with sysadmin levels of skill. I'm not advocating drastic action with
the Comodo roots, but a workarounds of this sort are probably not
distinguishable from total failure when the entire user base is taken
into account.

The truth is that we are basically unable to act without a lot of
collateral damage. We should keep this in mind with future security
technology. Relying on companies willing to take money for doing
absolutely nothing (not even the bare minimum they agreed to) is not a
pleasant thing to do to our users. We didn't learn this lesson with
EV--maybe next time! :)

- Rob
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-24 Thread Paul Hoffman

At 11:35 AM -0800 12/24/08, Kyle Hamilton wrote:
In the terminology of ASN.1 and PKIX, I want a standardized PKIX
extension that allows for a SEQUENCE OF Certificate within the
tbsCertificate structure.

That makes no sense to me, but I would have to see a complete proposal to 
understand why you would want that.

I'm trying to figure out how I'm supposed to extract all the
certificates from my database without any version of keytool that I
can find available for OSX 10.5 (Leopard).

That's a completely different problem, of course.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-24 Thread Paul Hoffman

At 1:46 PM -0800 12/24/08, Nelson B Bolyard wrote:
Paul Hoffman wrote, On 2008-12-24 09:55:
  - Remove all trust anchors one-by-one
 - Add your single trust anchor
 - Sign the certs of any CA you want
 - Add those signed certs to the pre-loaded validation path (not root)
  cert list

Of course, that is COMPLETELY equivalent to simply setting trust flags on
the CA certs you want to trust, and removing those flags from the ones you
don't want to trust, which is already a part of Mozilla browsers (and
Netscape browsers, before them) for over 14 years.

Not COMPLETELY, but close. What I proposed has a signature at the top of the 
hierarchy, which is what I thought that Kyle was asking for. The result is 
completely equivalent, but the format is slightly different.

Of course, it is much easier for the people on this list to Insist With 
Exclamation Marks! that Mozilla fix this for them instead of them doing it 
themselves, but that problem is at different layer.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-24 Thread Daniel Veditz

Paul Hoffman wrote:
 At 1:16 AM +0200 12/24/08, Eddy Nigg wrote:
 Select Preferences - Advanced - View Certificates - Authorities.
  Search for AddTrust AB - AddTrust External CA Root and click 
 Edit. Remove all Flags.
 
 Doesn't this seem like a better solution than sue Mozilla for
 theoretical future damages incurred by using their free software?
 Put more rudely, why do you expect Daddy to fix it for you when you
 can fix it yourself, more easily and more quickly, if you want to?

Isn't that a bit like an auto maker issuing a notice If you don't want
your car to explode in a fender bender you can crawl under the right
rear and remove the screw marked 34A on the following diagram.

Everyone should be able to do that so I'm sure that gets the auto maker
off the hook, right? Assuming all 200 million Firefox users even hear
about the problem.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-23 Thread patricia

Hi all,

A glitch in our validation system has today caused a certificate to be
issued to a person who successfully abused our system.

We have now strengthened our domain validation system so that such
abuse cannot happen again. Comodo has handled this issue in a
professional way by invoking the certificate immediately after issuing
and contacting Certstar.

Again, I cannot stress enough how seriously we take this issue and I
would like to apologize to the Mozilla organization for the mis-issue.

--
kind regards,
Patricia, Certstar ApS
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

2008-12-23 Thread Thorsten Becker


Hi Patricia,

patri...@certstar.com schrieb:


We have now strengthened our domain validation system so that such
abuse cannot happen again. 


just curious: How do you normally validate domain ownership?

TIA,

Thorsten
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 12/23/2008 10:48 AM, patri...@certstar.com:

Hi all,

A glitch in our validation system has today caused a certificate to be
issued to a person who successfully abused our system.


It's not me who abused your system, it's your company which sent out 
illegal, misleading emails to our customers. Since I couldn't find out 
who stands behind your site I had to get a certificate. There was no 
abuse, there was only use-and-get.


- No affiliation published, the fact that you are a reseller for Comodo 
is nowhere noted.

- No subscriber agreement or notice presented to subscribers.
- No control validation of the domain name. Just pay-and-go.

I didn't had to do anything to overcome any validation whatsoever. There 
was no abuse!



We have now strengthened our domain validation system so that such
abuse cannot happen again. Comodo has handled this issue in a
professional way by invoking the certificate immediately after issuing
and contacting Certstar.


Yes, after I posted my article here at the mailing list.


Again, I cannot stress enough how seriously we take this issue and I
would like to apologize to the Mozilla organization for the mis-issue.




--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


For those interested, Frank opened a bug to investigate this incident:

https://bugzilla.mozilla.org/show_bug.cgi?id=470897

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!


On 12/23/2008 07:09 AM, Frank Hecker:

There are two general reasons for pulling a root, to address a clear and
present danger to Mozilla users, and to punish a CA and deter others. My
concern right now is with the former. I see at least three issues in
relation to that:

1. Issuance of further non-validated certs by this reseller. Comodo
seems to have addressed this by suspending the reseller's ability to get
certs issued. (I can testify that this is the case, as I tried to
duplicate Eddy's feat earlier today and got my uploaded CSR rejected.)


As long as this site keeps operating, our customers are still being let 
to believe that they have to renew their certificate with them. This is 
only a reminder about how it started at all. CAs and their customers are 
still taking damage from the previously sent messages.




2. Potential problems with certs already sold through this reseller.
Comodo should investigate this and take action if needed. (This need not
necessarily require revoking all certificates associated with the
reseller; for example, the existing certs and their associated domains
could be re-validated, the registered domain owners could be notified of
the potential for bogus certs floating around, etc.)


You shouldn't notify the subscribers or domain name owners, but the 
relying parties. How to do that is up to you and Comodo I guess.


Comodo not only shouldn't just investigate and take action, Comodo needs 
to report publicly about their findings and full report about the 
actions taken. This isn't a suggestion of resolution about this 
incident, it's the transparency I expect from them at this hour.



Pulling a Comodo root will knock out Firefox, etc., access to thousands
of SSL sites, maybe tens of thousands.


I'm not advocating removing their root, however we must assess the risk 
which is potentially caused to the relying parties. There may be 
thousands of sites which received certificates without validating them.



Given the disruption that would
cause, the final decision on this IMO should be made in conjunction with
the Firefox security folks.


Disabling the trust bits of AddTrust External CA Root could be a 
temporary measure to prevent damage to relying parties until Mozilla 
receives full report and disclosure from Comodo about its resellers and 
conclusion of their investigation.


Additionally instead of just yanking a root as a deterrent and 
punishment, as you mentioned above, I'd prefer to receive a commitment 
from Comodo to address other issues noted during the last discussion - 
mainly those listed in the Problematic Practices document. Considering 
that OCSP in Firefox is set to soft-fail, an issue with their OCSP 
server could still circumvent bogus sites for potentially the next five 
years. A full review of their current status in NSS and their practices 
might be advocated too.


--
Regards

Signer: Eddy Nigg, StartCom Ltd.
Jabber: start...@startcom.org
Blog:   https://blog.startcom.org
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Suspend trust bit (was Unbelievable!)