Re: Unbelievable!

[Jean-Marc Desperrier]

Eddy Nigg wrote:

[...] We
received already calls from people confusing us with them.

- *certstar.com* as opposed to *cert.startcom*.org


Then sue them really. A concurrent that use a company name that brings 
confusion for ordinary people is a typical case in which you can sue.


Call your lawyer, you'll need to build a proper juridic case, and those 
calls that prove that ordinary people get confused will be very useful 
for that.


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

Re: Unbelievable!

[timeless]

On Dec 31 2008, 12:28 am, "Kyle Hamilton"  wrote:
> (note: "unknown_issuer" without talking at all about who the issuer
> claims to be

you're missing a critical point:

the issuer is something about which we know nothing.

someone could claim "issuer: GOD" or "issuer: POTUS" or "issuer:
VeriSign". Without verifying the issuer, we can't and should neither
attest to nor show it.

And sadly, that's why it isn't shown.

Now, we could perhaps show a fingerprint (minus the fact that MD5 is
at risk), but I tried searching for some fingerprints and haven't
gotten good hits.

http://eklhad.net/linux/app/ssl-certs turns up for MD5 fingerprint
searches, but nothing shows up for the sha1 fingerprint i checked.

- the nss certutil code appears to be able to print sha1s too

> -- and being able to download a certificate and then accept it

it's true we don't do particularly well with chains, however i've
rarely seen a useful misconfigured server with a partial chain and a
missing root. if someone provides me with such a service, i'll see
about trying to improve the user experience -- note that i'd prefer to
start with an instance of a real broken server, since otherwise it's
fairly pointless, however i could do the work from an example.

> without having to see who it's issued by -- is a "WTF WAS
> THE SECURITY TEAM THINK--WAIT, WAS THE SECURITY TEAM
> THINKING??" situation.

they were thinking about it more than you were. calmer heads with more
thought prevailed. and what's important is that when our users get
angry or panic, we don't want them accidentally doing something
they'll regret later. (hopefully you regret shouting in a public
forum. personally i tend to regret each time i post anywhere.)

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

Re: Unbelievable!

[timeless]

On Dec 25 2008, 12:36 am, "Kyle Hamilton"  wrote:
> To be honest, Mozilla doesn't distribute keytool with Firefox, which
> means that I have to try to go into the
> (unbatchable) interface

this is false.

the ui is built as xul with js bindings to c++ objects which use idl
to expose methods. the js *script* which controls the user interface
itself is essentially batching orders.

you're free to batch this as much as you please.

> 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.

i've done this something like half a dozen times using a nokia n800
(or was it a nokia 770) with the built in certificate manager. Which
is worse by far than the one mozilla ships. You almost have my
sympathy.

Except for a few details:
1. i've been working w/ the nokia ui people + engineers to improve
their mess (i thought I had succeeded in burying their ui, but it
seems rumors of its demise were greatly exagerated).
2. i've been working to improve the mozilla ui (by writing patches)

what have you done?

> 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),

again, i've filed bugs and am working to improve this.
what have you done?

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

i believe this is partly to force users (not you, real normal people)
to think before they blindly add issuers.

There's a public bug evidencing that normal users might actually add
trust to every site they encounter (because they're on an evil hot
spot which is spoofing everything).

You're a (professed) expert, our target audience is the average person
(described above), they experience for that person must be safe and
slow. thinking is good. blindly clicking through is bad.

if you're an expert, you can script pieces of this (heck, there's a
pref to speed up the steps you're describing).


> 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

if there isn't, then you shouldn't be trusting it.

heck. if there isn't, go try to find a phone number and get the web
server operator to fix their server.

-- and yes, i've done this, iirc it was last month, i got sun to fix
one of their servers.

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

i've written a patch to improve this ui (with an eye to making the
n800 user experience better).

> 12) find the appropriate root and re-enable it for identification of websites

this seems useless. w/ my patch you could search by any criteria.

> 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).

been there, done this.

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

it's called certutil.

> This is completely unworkable, and discourages users that want to from
> taking their security into their own hands.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Julien R Pierre - Sun Microsystems]

Kyle,

Kyle Hamilton wrote:

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


The reason code "remove from CRL" is only applicable to delta CRLs. In 
addition, this is only allowed if the certificate had the status of "on 
hold" in the base CRL. You cannot otherwise unrevoke other certificates 
according to RFC3280 and its replacements.


Currently, NSS does not support delta CRLs. Neither does libpkix.
So, the answer is no, this particular reason code is not handled by NSS 
at this time.


But a temporary revocation can still be dealt with without the use of 
delta CRLs. libpkix can fetch a full CRL where a certificate entry has 
the reason code of "on hold", and will be treated as revoked. And if the 
CA unrevokes it later, libpkix can pick up the next full CRL from the CA 
that no longer lists that certificate.

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

Re: Unbelievable!

[Julien R Pierre - Sun Microsystems]

Kyle,

Kyle Hamilton wrote:

On Wed, Dec 24, 2008 at 2:46 PM, Eddy Nigg  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.)


No. You can just move the libnssckbi.so to a location that won't 
automatically be picked up by firefox in all profiles.


Then load libnssckbi.so explicitly only in the one profile in which you 
want it, using "Manage security devices" / "Load" . It is just a PKCS#11 
module, after all.


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

Re: Unbelievable!

[Eddy Nigg]

On 01/03/2009 06:41 PM, Florian Weimer:


I can understand that point of view.  But what you seem to be asking
is that browser vendors take the role of judges, regulating CA
behavior.  Shouldn't that be better left to the court system, keeping
Mozilla out of the loop?  What advantage does Mozilla gain by acting
as a judge on day-to-day operations of CAs?


The same criteria should be applied to all CAs. With less definition 
there is also more of room to undercut in every respect. Definitions and 
agreed upon standards are nothing for the courts really, they need to be 
defined first.



CAs (should) have controls in place to prevent that from
happening.


Could you explain what you're doing in this area?  (A "no" is
perfectly acceptable because nothing you can do is totally secure, so
keeping the mechanisms secret actually buys you something.)


Yes, I think I don't want to elaborate on that really. But CAs usually 
have more experience and know-how to set up preventive measures than an RA.


--
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!

[Nelson B Bolyard]

Gervase Markham wrote, On 2008-12-27 05:07:
> Hi John,
> 
> You raise some important questions, but it's worth having clarity on a
> few matters of fact.
> 
> John Nagle wrote:
>>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. 

One must admit that there is more than a little irony at play when the
system that claims to offer sign assurances, binding keys to identity,
and which (in the case of EV) claims to offer an identity that is strong
enough that a relying party could take the party thus identified to court,
fails to similarly identify the party making the signed assertion.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Florian Weimer]

* Eddy Nigg:

>> just because CAs start to play games with each other.  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.

I can understand that point of view.  But what you seem to be asking
is that browser vendors take the role of judges, regulating CA
behavior.  Shouldn't that be better left to the court system, keeping
Mozilla out of the loop?  What advantage does Mozilla gain by acting
as a judge on day-to-day operations of CAs?

It might make sense to demand additional elements in the CPS for
future root additions, and re-audit existing roots.

> CAs (should) have controls in place to prevent that from
> happening.

Could you explain what you're doing in this area?  (A "no" is
perfectly acceptable because nothing you can do is totally secure, so
keeping the mechanisms secret actually buys you something.)

Anyway, one thing that comes to my mind is domain control verification
over multiple communication channels, perhaps by injecting multiple
email messages at different points of the Internet, to make at least
sure that any hijacking is rather close to the subject.  But I don't
think you have to answer to multiple mail challenges for DV
certificates.

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

There might be a legitimate business reason to do this form of
interception (doing this to get "free AV" is quite common, I suppose).
But I agree it's interesting.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Kyle Hamilton]

On Tue, Dec 30, 2008 at 1:04 PM, Florian Weimer  wrote:
> BCP 38 requires that active MITM attacks don't work on LANs. LANs
> which violate that and are under attack are typically not very usable:
> Search engines blocks you due to automated queries, DHCP and DNS
> delivers data which is not 100% accurate (with unknown consequences),
> you receive even more web ads than usual, rogue PPPoE servers sniff
> your credentials, and so on.

I'll point out that at least one of the cases which Mozilla is using
as its standard for the security UI involved a user who was subject to
an active MITM attack while connected to a public wireless hotspot.

BCPs do NOT mandate anything.  They are "best current practices", and
it's a fact that they can be ignored by anyone for any time for any
reason (they are advisory, but local policy can and will often
override them).

> In short, I don't think this is the use case to optimize for.

I think this is important to realize: security is not an
all-or-nothing thing.  Anyone who puts all of their eggs in one basket
(a single thick wall, or a moat -- or, as was found in the late 90s, a
firewall) is going to be unpleasantly surprised when the security of
their supposedly-impregnable defense is breached and they have no
mitigation plan.

We NEED to optimize for this case.

(note: "unknown_issuer" without talking at all about who the issuer
claims to be -- and being able to download a certificate and then
accept it without having to see who it's issued by -- is a "WTF WAS
THE SECURITY TEAM THINK--WAIT, WAS THE SECURITY TEAM THINKING??"
situation.  It failed to mitigate against the attack that Nelson
cites, bug 460374.)

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

Re: Unbelievable!

[Gervase Markham]

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

As I understand it, this is a feature of our implementation of EV, not
anything to do with the guidelines. Just as we are enabling roots for EV
one at a time, we can also disable them.

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

Re: Unbelievable!

[Gervase Markham]

Ben Bucksch wrote:
> We try to train users to check that the bar is green (on sites where it
> was green before), and not use the site when it's merely blue.
> Otherwise, EV is useless, as the scammer could get a, say, CertStar
> cert, to fake an EV site, right? Only when people start getting
> concerned and stop visiting the site when it's truning green->blue is EV
> of any use.
> 
> So, that means we have the same collateral damage as now.

Well... yes and no. If we remove a root, then the user gets scary error
messages and can't easily access the site. If we remove EV status, the
CA and their customers get upset because some customers are going to get
spooked (they don't know how many - that's one of the good things). So
removing EV is, in some senses, not as big a deal as yanking a root.

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

Re: Unbelievable!

[Nelson B Bolyard]

Florian Weimer wrote, On 2008-12-30 13:04:
> * Michael Ströder:
> 
>> 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.
> 
> BCP 38 requires that active MITM attacks don't work on LANs. 

Surely you don't really think that's much of a deterrent to attackers?!

> LANs which violate that and are under attack are typically not very usable:

If an attacker wants his attack to be effective, he will be sure that it
does not render the LAN unusable.

> Search engines blocks you due to automated queries, DHCP and DNS
> delivers data which is not 100% accurate (with unknown consequences),
> you receive even more web ads than usual, rogue PPPoE servers sniff
> your credentials, and so on.

Consider the increasingly common case of the "free" wireless access point
set up for the express purpose of MITMing all those who would use it.
Consider the phenomenon of "phorm".  Most ordinary users never even
notice that they're under attack unless the attacker does a really
poor job of it (e.g. bug 460374).

> In short, I don't think this is the use case to optimize for.

This is the use case that sets SSL apart from other lesser crypto schemes
that do weak/no authentication.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Florian Weimer]

* Michael Ströder:

> 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.

BCP 38 requires that active MITM attacks don't work on LANs. LANs
which violate that and are under attack are typically not very usable:
Search engines blocks you due to automated queries, DHCP and DNS
delivers data which is not 100% accurate (with unknown consequences),
you receive even more web ads than usual, rogue PPPoE servers sniff
your credentials, and so on.

In short, I don't think this is the use case to optimize for.

> 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.

If you can't get rid of CAs which are snake oil because they add no
value beyond suppressing the browser warning, the certificate store
serves little purpose beyond CA revenue generation and improving user
experience (the latter isn't a bad thing per se, actually security and
perceived security are both important).
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Ben Bucksch]

On 27.12.2008 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.
   


Well, really?

We try to train users to check that the bar is green (on sites where it 
was green before), and not use the site when it's merely blue. 
Otherwise, EV is useless, as the scammer could get a, say, CertStar 
cert, to fake an EV site, right? Only when people start getting 
concerned and stop visiting the site when it's truning green->blue is EV 
of any use.


So, that means we have the same collateral damage as now.

See thread "Just change expiry time" for an alternative reaction.

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

Re: Unbelievable!

[Nelson B Bolyard]

Kyle Hamilton wrote, On 2008-12-27 15:56:
> 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.

[rest snipped]

Kyle, I think you're making some good points about the PKI/security related
UI in Mozilla products (especially Firefox).  I'm afraid this will get lost
in this thread which is otherwise about CA behaviors and responsibilities.
So, I suggest you start a new thread for this topic.  Do that by posting
a message which is not a reply to any existing message, but is the first
with a new subject (not reusing a subject in any previously posted message).

When you do that, some may suggest that another of Mozilla's newsgroups and
mailing lists is a better venue for that discussion, and if so, so be it.
But I encourage you to raise the UI issues in a way that is clearly
separated from the current CA brouhaha.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[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  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!

[Eddy Nigg]

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!

[Eddy Nigg]

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!

[Michael Ströder]

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!

[Michael Ströder]

Eddy Nigg wrote:
> 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.

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

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

Re: Unbelievable!

[Florian Weimer]

* Eddy Nigg:

> 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 think so.

> I'm not sure...however it's not about browser warnings. This is
> about security proper.

As a downstream distributor of Mozilla code, I'd hate to roll out
updates (especially security updates) just because CAs start to play
games with each other.  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.)

> Or how else would you explain an MITM attack?

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

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.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Eddy Nigg]

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!

[Ian G]

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

Re: Unbelievable!

[Eddy Nigg]

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!

[Eddy Nigg]

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!

[Frank Hecker]

Michael Ströder wrote:

If e.g. a Linux distributor wants to ship Firefox and trims the list of
pre-installed trusted root CA certs is it still allowed to distribute
the resulting code as Firefox?


That's a decision for the people at the Mozilla Corporation who work 
with Linux distributors and others who want to distribute 
Firefox-branded browsers.


Note that in the past I've proposed having localized versions of Firefox 
have slightly different root lists, e.g. to account for national or 
regional CAs that have limited or no market share elsewhere in the 
world.  As it turned out, people didn't want to do that for various 
reasons, but I myself am not wedded to the idea that the default root 
list should never be changed by downstream distributors.


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!

[Michael Ströder]

Frank Hecker wrote:
> 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.

If e.g. a Linux distributor wants to ship Firefox and trims the list of
pre-installed trusted root CA certs is it still allowed to distribute
the resulting code as Firefox?

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

Re: Unbelievable!

[Michael Ströder]

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!

[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"  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


Go to Mozdev at  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!

[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


Go to Mozdev at  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!

[Florian Weimer]

* Hendrik Weimer:

> Frank Hecker  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!

[Michael Ströder]

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!

[Michael Ströder]

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!

[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]

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!

[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=798&file=pdf
https://cert.webtrust.org/SealFile?seal=804&file=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!

[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!

[Michael Ströder]

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!

[Michael Ströder]

ro...@comodo.com wrote:
> On Dec 24, 2:13 am, "Paul C. Bryan"  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!

[Michael Ströder]

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!

[Ian G]

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

On Dec 26, 4:40 pm, Ian G  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!

[Gervase Markham]

Hi John,

You raise some important questions, but it's worth having clarity on a
few matters of fact.

John Nagle wrote:
>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.

The previous are statements of fact; at this point I express no opinion
as to whether those facts are a good state of affairs.

> Comodo does
> not seem to have taken on the obligations of AddTrust; see
> "http://markmail.org/message/3zr4e5hxwmxjbgnp?q=Comodo+AddTrust";.

That is not what that message says. 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. If you have evidence to the contrary
(leaving the current situation aside for a moment), present it.

>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";.

That is a reasonable question.

>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.

The two things are not connected. 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.

>1.Comodo must undergo an audit to WebTrust standards, and the audit
> report must be published. 

As I understand it, Comodo has a current WebTrust audit (confusion in
this thread notwithstanding):
https://cert.webtrust.org/SealFile?seal=804&file=pdf

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

Re: Unbelievable!

[Eddy Nigg]

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!

[Kyle Hamilton]

I'll also mention that these CAs are supposed to be audited to
"financial services" levels.  The root that it chains to is
EV-enabled.

The fact that audits didn't pick up on the discrepancies that Eddy
found between Comodo's CP/CPS and Robin's statements suggests that
Comodo's playing dirty pool, and Frank's letting them get away with
it.

-Kyle H

On Sat, Dec 27, 2008 at 4:43 AM, 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? 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
>
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Eddy Nigg]

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!

[Gervase Markham]

Dan Colascione wrote:
> Frankly, that's even *more* disturbing. It means that there are almost
> certainly unverified certificates in the wild, and that this problem
> is pervasive.

You mean, you wouldn't be disturbed at all if Comodo had done loads of
auditing and found absolutely no problems whatsoever?

Gerv

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

Re: Unbelievable!

[Gervase Markham]

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.

Gerv

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

Re: Unbelievable!

[Gervase Markham]

Michael Ströder wrote:
> Given the large amount of self-generated server certs this problem
> already exists. 

Large number != large % of visits. A million Joe Publics might use the
Internet for 5 years to do their online shopping without once
encountering a self-signed cert or a certificate error. Geeks, on the
other hand, encounter them the first time they visit some major Bugzilla
installations.

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

Re: Unbelievable!

[Ian G]

On 27/12/08 04:47, Paul C. Bryan wrote:

On Dec 26, 5:38 pm, Nelson B Bolyard  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.



Curious.  I thought it was the standard business model of many CAs to 
outsource some or all of the functions to the reseller or customer. 
Indeed, this is the "Verisign buyout model";  outsource something new, 
get huge, get bought out by Verisign.


Has anyone done a survey about how this is done in all CAs?



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.



Hold on, that is leaping to far...

All businesses place their all trust in "outsourced" entites.  They are 
called "employees" and "suppliers" and various other names.  This is normal.


However, when a contract is signed or an agreement otherwise reached 
(and the latter is more the case here), the responsibility for the 
agreement remains in the primary party.  Again, this is normal.


Nothing has changed here in the CA business.  The CA has reached 
agreement on its offered CPS, and the assumptions should hold:


the CPS describes what it does.
the CA takes the responsibility.

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


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?  This would be a controversial criteria because we know 
that a popular incentive is to generate opportunities for business revenues.




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.




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.





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

Re: Unbelievable!

[Paul C. Bryan]

On Dec 26, 5:38 pm, Nelson B Bolyard  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!

[Kyle Hamilton]

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  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 tak

Re: Unbelievable!

[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 deleg

Re: Unbelievable!

[Eddy Nigg]

On 12/27/2008 03:22 AM, Eddy Nigg:


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...



And listen up! What's the difference between storing the private key of 
mozilla.com at an Internet facing web server [1] and that of having a 
so-called RA turned reseller performing [or not performing] domain 
validation at a Servage hosting account?


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=470897#c13

--
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!

[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!

[Paul C. Bryan]

On Dec 26, 4:40 pm, Ian G  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!

[Ian G]

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!

[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!

[Ian G]

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

On Fri, Dec 26, 2008 at 3:12 PM, Ian G  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!

[Kyle Hamilton]

On Fri, Dec 26, 2008 at 3:12 PM, Ian G  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!

[Ian G]

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!

[Ian G]

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!

[Paul C. Bryan]

On Dec 26, 2:18 pm, "Paul C. Bryan"  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!

[Paul C. Bryan]

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=45239&la_id=1&re_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!

[Kyle Hamilton]

On Fri, Dec 26, 2008 at 1:52 PM, Eddy Nigg  wrote:
> 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=804&file=pdf

My apologies, I didn't see this.  I retract my disbelief.
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[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=804&file=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!

[Kyle Hamilton]

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,   wrote:
> On Dec 24, 2:13 am, "Paul C. Bryan"  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=45239&la_id=1&re_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!

[robin]

On Dec 24, 2:13 am, "Paul C. Bryan"  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=45239&la_id=1&re_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!

[Paul C. Bryan]

Dear Robin:

You have not yet responded to my questions. I believe they are
reasonable. Will you answer them in this forum?

Yours truly,

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

Re: Unbelievable!

[Eddy Nigg]

On 12/26/2008 01:28 PM, ro...@comodo.com:

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.


It would behoove yourself if you'd stick with the facts at least. You 
keep claiming that you detected it and revoked the certificate.


All times in GMT:
- Dec 22 19:47 Certificate issued to mozilla.com
- Dec 22 22:25 The Story broke at dev.tech.crypto
- Dec 22 22:46 Certificate revoked (thanks for not fixing the time in 
the CRL)


Additionally I really hope that your agreement with certstar allows you 
to sue the h*** out of them. I could have received any certificate for 
any domain I'd have been willing to pay $ 45 and nothing would have 
prevented that. If that's not clearly acknowledged I'll feel myself 
forced to publish more material I have at my disposal. The mail for the 
verisign domain was just a small sample.


Since this company uses a domain resembling that of ours which we 
operate already for four years and which has a very high ranking at 
Google, I'm insisting that this company closes their web site. We 
received already calls from people confusing us with them.


- *certstar.com* as opposed to *cert.startcom*.org

Also in light of the damage caused to us and other certification 
authorities due to their attempts to mislead our customers, it's the 
least to have them shut down immediately. Failing to do so will make it 
only worse.


You also claimed that this was an anomaly and that the validation 
mechanism was bypassed by accident. If this is the case would you agree 
with me that such events are very unlikely to reoccur? If that's 
correct, whatever actions or recommendations are decided in relation to 
*this* event, I will suggest to Frank that any re-occurrence would have 
to have appropriate consequences. If it's not correct, I expect you from 
notifying about the actions you are performing within a reasonable 
time-frame to prevent such re-occurrence.


--
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!

[Frank Hecker]

Kyle Hamilton wrote:

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

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


My apologies, you are right and my recollection was wrong.

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!

[robin]

On Dec 25, 4:49 pm, Frank Hecker  wrote:
> Michael Ströder wrote:
> > 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,
 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
___
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Unbelievable!

[Kyle Hamilton]

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
 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!

[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!

[Eddy Nigg]

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!

[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!

[Michael Ströder]

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!

[Eddy Nigg]

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!

[Eddy Nigg]

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!

[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!

[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!

[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
 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: Unbelievable!

[Michael Ströder]

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!

[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]

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!

[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!

[Eddy Nigg]

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!

[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.

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

Re: Unbelievable!

[Michael Ströder]

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!

[Michael Ströder]

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!

[Michael Ströder]

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!

[Michael Ströder]

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!

[Michael Ströder]

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: Unbelievable!

[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!

[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!

[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!

[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!

[sayrer]

On Dec 23, 10:33 pm, 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.
>
> 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!

[Nelson B Bolyard]

Kyle Hamilton wrote, On 2008-12-24 14:53:
> On Wed, Dec 24, 2008 at 2:46 PM, Eddy Nigg  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!

[Kyle Hamilton]

On Wed, Dec 24, 2008 at 2:46 PM, Eddy Nigg  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!

[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