Policy-Discussion

[Ian G <iang AT cacert.org>]

On 15/01/2010 03:49, Daniel Black wrote:
> On Friday 15 January 2010 00:13:23 Ian G wrote:
> > On 13/01/2010 10:02, Daniel Black wrote:
> > > I therefore propose: "CAcert stops issuing Class3 certificates."
> >
> > What some may have missed is that in this traffic, Daniel is asking for
> > a formal vote by policy group.  This is recorded in the decisions page:
> >
> > https://wiki.cacert.org/PolicyDecisions
> it was certainly worded like a formal decision.


It was indeed!   But I missed it (possibly because the clear wording for 
vote was at the end, not beginning?).  I'm not criticising the request, 
just hoping that others who might have missed it join in...


...
> > 1.  there are users of this service and there is no "impact" assessment
> > to them.
>
> Ok:
> impact statement:
>
> There may be organisations like registeredcommons.org relying on us issuing
> class3 certificates to provide certified certificates of identity.


OK. I've heard some comments that "not many users are using the Class 
3".  Do we have numbers on that?

Stats page says:
Valid Certificates:     84,081
But no break down Class 3 / Class 1.


> For a long
> time our class1 certificates have contained a validated identity in the common
> name field. Where the certificate owner has not received the required level of
> assurance with respect to identity the text 'CAcert WoT Member' is in the
> common name field.

This is analysis.

CPS 1.4.5 supports above 1st para in its 1st para but contradicts it in 
its last one.  e.g.,

  * (old) Class 3 root.  Used primarily for certificates including the 
names of Assured Members. Signed by Class 1 root. Members can decide to 
rely on these certificates for Assured Members by selecting the Class 3 
root for Assured Members as trust anchor.


> Unfortunately to due to changes to remove our MD5 based class3 certificate
> you, the class3 relying party, will be required to make some changes to your
> software to accept validated identity based on any CAcert issued certificate
> without the text 'CAcert WoT Member'. This change will be compatible for when
> we issue our new roots that are audit friendly.
>
> In fairness to our current class3 relying parties we will be providing notice
> (blog) before implementation.


(OK, so this is a "work-around" advice.  Fine.)


> > 2.  the proposal is based on confused information not analysis.  E.g.,
> > have a look at these three links, and tell us whether you can conclude
> > that stopping class 3 is what is wanted, or not?
> >
> > https://lists.cacert.org/wws/arc/cacert-sysadm/2010-01/msg00040.html
> > https://lists.cacert.org/wws/arc/cacert-sysadm/2010-01/msg00036.html
> > http://wiki.cacert.org/Brain/Study/Bug665
> A conclusion is that the current class 3 or MD5 based certificate root isn't
> wanted. There is some indication that a new class3 based on SHA1 is desired.


Yes.  Yet your vote calls for the stopping of *all* class 3 certs, not 
for a re-issuing.

We could for example, drop the current one and reintroduce a new one ... 
But this should be signalled in advance.  Hence, my call to see a fuller 
plan.

Your motion, if taken at face value, will close that out option.


> > 3.  this vote is over-reaching:  there are detailed SP and CPS issues to
> > take into account.  Policy group's job is to write the SP and CPS
> > policies that affect this, and then hand it over to the teams to
> > implement, via board.  If this vote goes through, it is an empty
> > decision because the SP / CPS still need to be done.  The teams follow
> > the CPS / SP.
> its a vote of agreement in principle.


OK.  I agree that the policy group should be asked for its opinion on 
the matter.

I'm not sure whether a policy group vote is needed, because in 
principle, policy group has already spoken:  CPS clearly states that the 
old roots are deprecated / audit fail etc.  So CPS looks to have those 
roots removed as and when we see fit.

(Which latter is an executive thing, I would say.  Again, the board has 
also clearly spoken, it wants the things gone.)

So what might emerge from this is really, what we want the policy group 
to say is that

   "We have no objection to the Class 3 or Class 1 root being 
terminated at any time, from a policy perspective."



What the policy group might validly ask itself is this:

   "We insist that all new roots be issued according to policy, which 
means no more subroot signing by the existing Class 1, and therefore no 
singular replacement of the Class 3.  Any new roots issued must be to 
the newer scheme as documented in CPS and wiki pages on New Roots."

I propose that as text to clarify the issue ... I'm not saying this is 
what "I want" but .... I feel it is (a? one? only?) valid reading of the 
CPS and Security Policy.


> > 4.  there is a far better path IMO:  follow the New Roots path properly
> > and be done with it (or just implement the 2008 roots for the next year
> > if we need a fast solution, it's probably less work anyway).
> Is the risk of an auditor saying the New Roots are rubbish and we need to a)
> issue new ones mitigated, b) revoke all certs issued off them?


That's a risk.

Also, there is a risk that the auditor looks at the actions of the past 
(these events right now) and concludes that CAcert took ad hoc steps to 
fix local problems, and in the process ignored its own policies. 
Therefore, CAcert is not serious about the representations it makes to 
the public.


> Without this risk mitigated may be issuing new roots twice with all the bad
> PR, confusion, and root distribution issues that go along with it.


Right.  We may inconvenience our users if we issue additional roots that 
then have to be re-issued in order to meet audit.  Hence the desire to 
do that job properly.

On the other hand, if we follow our policies and do the best job 
possible, we are unlikely to push auditor to fail the entire audit.


> > 5.  Any path requires resources.  These resources need to be built up
> > anyway, and are in the process of being built up.
>
> The main thing we need is leadership. I haven't seen the board as a whole
> particularly enthused about solving this issue.


OK.  As you are standing for board, and this is a criticism against the 
board, and I'm on the board (as is Andreas and Ernie and PD who also 
respond to this debate), this is clearly a statement with some political 
import.  So I'll respond on the members list rather than carry on a 
political debate here.

(I really don't mind if it comes back to policy...  I'm not trying to 
suppress the debate, just direct it where we are interested in the 
question of leadership.)


> I'm not saying that other software resources aren't needed,


My point was perhaps too subtle.  The software resources are more or 
less the blocking factor.


> they just need a
> clear leadership to say this is the plan and we're going to stick to it.


On that, I've asked the CH team to consider providing that clear plan, 
and added it to Sunday's agenda.

https://community.cacert.org/board/motions.php?motion=m20100114.1

iang

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