CAcert System Admins discussion list

[Ian G <iang AT cacert.org>]

Hi Dieter,

It appears there is a (new?) proposal on the table.  Unfortunately it 
appears you don't like it.  Can you clarify?


On 12/01/2010 23:01, Dieter Hennig wrote:
> Dear Daniel, dear Ian,

> > > I mentioned a plan to replace an intermediary certificate before. As a simpler
> > > alternate can we stop issuing certificates of the class3 and only issue them
> > > of the current class1/root cert?
> >
> >
> > I thought this was already possible and offered on the website?
>
>
> We are using it this way, but until now, the class3-way is the default
> one.


The way the above reads -- and the way some people may be reading it -- 
is that your end-users are following the default choice offered on the 
website, only.

So, a simple solution suggests itself:   to switch the default mechanism 
from class 3 to class 1.

Is that sufficient?  If not, why not?


> It it not our problem, that *our*  certificates are showing no
> doubt about the MD5-MD5-situation, but we are a part of the community,
> where other sites can show up this construction.


Do the other sites have the CAcert root installed?  So the only issue is 
that other places are getting MD5 warnings from Class 3 certs?


> What we try to explain is not, we (ETH) are safe, we will explain, that
> our people should trust CAcert at all. This is the point, I think.


It is the marketing point of CAs, sure.  It's not security, tho.


> > There
> > must be some reason why the customers in question are uninterested in
> > this "step-down".  It may be that they are org-assured, and want to put
> > their corporate name in the certs?  Just speculating.
>
> No, this is not a point for us. We put the official name (ETH Zuerich)
> into all certificates, we use independent from the sources.


I don't parse that sentance, sorry.  As far as I recall, the class 1 
cannot have the organisation name in it.  Does this stop you or not?

Above you seem to be saying that using the Class 1 root is unacceptable 
to you.

(Maybe I'm wrong, I have never dug deeply into Organisation Assurance.)

Would it be helpful if the Org name could be displayed in the class 1 
root-signed certs?


> We are running several hundred of certificates (CAcert-certificates are
> in the moment of the order of 10%), for us it is important, how quick an
> organization can react for a doubtful situation, to where we have to go,
> if one CA-root is compromised, how fast we can identify certificates


OK, so now we have drifted into politics, and I feel I have to explain 
why this reads badly, as "pressure".

Sure.  Is your point that we "aren't secure" because we don't respond 
fast enough?  This directly contradicts your point above where you are 
simply saying you want to avoid having to explain to your users that the 
browser warnings are false.

Either you trust the whole package, or you don't.

Let me explain further why this isn't helpful.  If we want, I can list 
out 100 areas where CAcert is "too slow" to respond.  You've found one, 
below I mention another.

Picking on 1 bad issue, and championing it for local reasons is bad 
leadership, bad management, bad community.  Using other "bad things 
discovered" to push through the local fix is "pressure", and further 
amplifies any damage being done by pushing one thing at the expense of 
99 others.


> with let us say old-debian-keys, ... This are questions about our
> internal  security policy, which we have to follow.


OK, so now you are suggesting that we should stop using Debian.  After 
all, Debian was breached, and if MD5 was broken, and it's all about 
brands, .... then we should stop, right?

The comparison is a false comparison.  If we are going to talk about 
brands and perception, then you should be aware:  we are not the market 
leader in brands and perception.

We are the market leader in community :)  We also do security.  But we 
try not to compromise on it just to improve our perception.


> If my proposal was interrupting your movement into a new set of
> certificates, we will wait for that and use CAcert until this day more
> ore less internal. Maybe UZH (much more people as we) is doing it in
> another way and will not use CAcert at all until this day.


This is a standard risk for us all.  We accept it.

(we have no choice :)


> In my opinion, the possibility to change fast an intermediate
> certificate (without to interrupt the services) is a way to keep safe
> the central root certificate.


This is standard, and is in our security policy.  Two points:

 + Recall, there is no security issue here, only a perception issue and 
a user-support issue.  So we would likely not institute this process in 
this case.
 - Also, the actual ability for us to roll out a new root in quick time 
is flawed, we don't have a proper procedure to do it anyway.

So, which is your preference?

Either you are part of the community and accept the whole risks, 
liabilities, obligations package, like everyone else does, happily!

And are willing to help us on this issue (see below) .......

Or you are analysing the overall delivery of the (audited) security & 
perception model.

It doesn't help to bounce back and forth:  that's politics, and unfair 
on our other community members, who can't take the time to explain why 
any solution is going to hurt them.


> At last, the Opera-problem (OCSP-server and https for the revocation
> address) should be solved. This is important for cell phone application,
> just in the moment it is not really too much imported for us.


That is good news.  I was not aware of it, any details?  As far as I 
know, it was a difficult issue, and if it has been worked on quietly in 
the background this is good.


> What we(ETH and UZH) are willing to do: we will discuss to our people,
> why we are using CAcert, why we believe to the WoT, what means, we trust
> somebody and where we have be critical about that, but what we will not
> do, is to discuss the sophisticated cases of MD5-hashes, ... .
>
>
> If you believe, that we can help practical to improve or support CAcert,
> please tell us about. Please believe, my proposal was a step into this
> direction.


If you are offering to explain to your users, this is useful, and I am 
glad.  But it is not so much "help" rather it is your obligations within 
the community.  Calling it help might cause people to think you are 
providing something that our other community members don't provide (in 
their hundreds and thousands....) already.



What I am specifically interested in, and what will help us and the 
community and you as well, is whether you can provide technical 
assistance to resolve the current root "crisis" that you have raised.

Perhaps it could be as simple as building a wiki page that records these 
facts, rather than have the discussion over and over again on random 
maillists, and continually bounce up against the same missing facts?



iang

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature