CAcert System Admins discussion list

[Dieter Hennig <dieter.hennig AT id.ethz.ch>]

Dear Daniel, dear Ian,

Ian G schrieb am 12.01.2010 21:46:
> On 12/01/2010 07:16, Daniel Black wrote:
>> On Tuesday 15 December 2009 00:19:22 
>> dieter.hennig AT id.ethz.ch
>>  wrote:
>>> Dear all,
>>>
>>> In reference to the two CAcert root certificates, both hashed by the
>>> MD5-algorithm, I would like to ask you to please follow instructions as
>>>   seen below:
>>>
>>> http://wiki.cacert.org/Brain/Study/Bug665
>>>
>>
>> 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. 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.

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.


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


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


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.

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.

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.

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.

Personally, I like Daniels point

>  6. relax


very pleasurable.

With Best Regards



Dieter



> 
> Alternatively, if you are suggesting that we start putting names into 
> the Class 1 cert, this is a "change of claim" and this could cause 
> problems.  Sticking to the contract is generally a good idea, and if 
> there has to be a change, it should be considered carefully.
> 
> 
>> 1. get policy group to ok us moving all issuing off this the current root 
>> cert
>> only.
> 
> 
> Policy group ... probably (?) follows the CPS, which may say less about 
> the old roots.  So, to an extent, if you are suggesting changes that are 
> ex-audit and ex-CPS, policy group might not say much.
> 
> On the other hand, there is the above point about change of claim, and 
> also policy group may want to simply ban or deprecate any non-CPS roots. 
>   The reason for that would be cleanliness, which in more practical 
> terms would eliminate gotchas when going to root list owners.  They want 
> to feel as though they have the documentation on everything, and ex-CPS 
> roots would be an unhappy exception.  E.g., frequently, on the Mozilla 
> lists, there is concern about the set of roots, and how it relates, so a 
> simple story would be best there.
> 
> OK, so your point is probably well made, and they should be asked.
> 
> 
>> 2. prepare software changes and documentation changes to account for this
> 
> 
> Getting software changes through is very difficult.  If your plan 
> involves software changes, then factor in a lead time of 3-12 months. 
> If the changes are significant, forget it.  We still haven't got the CCA 
> rollout patches done.
> 
> Documentation is easier, but even that can be slow.
> 
> 
>> 3. prepare blog press release and FAQ
>>
>> 4. switch software and release blog press release
>>
>> 5. answer all support questions
>>
>> 6. relax
> 
> 
> pts 3-6 are far too relaxing to comment :)
> 
> 
>> Is this good/better/bad/ugly and why?
> 
> 
> To be honest, I cannot see the benefit.  It looks like a hack, and will 
> take someone a lot of work.
> 
> If I was them, I'd want to see an overall improvement, not a hack.
> 
> Just my 2c.
> 
> iang


-- 
Dieter Hennig
Informatikdienste/Helpdesk
ETH Zuerich, STB G 18.2
8092 Zuerich, Stampfenbachstr. 69
Tel: +41 44 632 4278
Fax: +41 44 632 1900

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