CAcert System Admins discussion list

[Ian G <iang AT iang.org>]

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

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