Policy-Discussion

[Philipp Dunkel <p.dunkel AT cacert.org>]

@ wording

The problem is that verified is not available.

Here is what I want to express:

Set A is a superset of set B and C. All elements in A are either in set B or in set C. There is no overlap between set B and C.

We require all information in certs to be in set A. 

Cuurently I have used the following terms for these sets :

 A = Verified

 B = Assured

 C = Evaluated

B is, I think, is undisputed. A I think is good because it is more generalized and non valuing. 

C on the other hand can be disputed. One thing is clear however: since A!=C verified cannot be used. 

Now if you have a better word for C I am eagerly awaiting it. 

Regards, Philipp

P,S.: evaluated is derived from value. However it does not mean assigning value. The preposition e or ex means to extract. So evaluate actually means to extract value. That is why I think it may not be a bad term to use after all. 

---

Philipp Dunkel

Tel: +43-720-407204

Fax: +43-1-3060903-9

---

Your reality and mine may not entirely coincide. Therefore you may not rely on this message meaning what you believe it means. 

---

On Oct 16, 2008, at 6:26, "Sam Johnston" <samj AT samj.net> wrote:

On Thu, Oct 16, 2008 at 10:39 AM, Philipp Dunkel <p.dunkel AT cacert.org> wrote:

I think you hit the nail on the head when you talked about an employee "contracting themselves in the line of duty". That is a key issue.

For  that reason I want to propose the following change to the OA-Policy:

The organisation is the entity in contract with CAcert. As such the organisation is responsible for all certificate use and the safe-keeping of private keys. All the duties that apply to individual members under CCA have to be kept up by organisations as well. So it's like the Organisation IS the member.

@Sam: Do you understand what I mean (at 4:40 in the morning)? Can you try to rephrase that idea in a way that makes sense in the OA policy so we can have a votable proposal for this?

I've been working on kicking off a separate OA thread so as not to risk derailing this discussion but this is certainly one of the things to be addressed; aligning ourselves with reality and hopefully giving users a path to becoming fully fledged members without forcing it on them (which is a non-starter in an organisational environment). It also strays over to the previous decision about organisations not being assurers, but that still essentially holds. I still worry about diluting the value of CAcert by issuing certs (with CAcert as the issuer) which our members have not 'directly' verified too - sub-roots were designed for this and a small amount of additional complexity in terms of creating and storing per-org roots is justified IMO (they're just a few extra fields in a database or some extra files after all).

Anyway, more on that later.

FWIW I don't think 'evaluated' is appropriate in this context; it's derived from the word 'value' in terms of assigning a value to something. Verified is both appropriate and well understood (cf mozilla policy wording which uses 'verified' extensively).

Sam

On 2008-10-16, at 04:13, Sam Johnston wrote:

On Thu, Oct 16, 2008 at 10:06 AM, Elwing <lraderman AT elwing.org> wrote:

>
> Putting the Org Assurance Officer hat on for a second, we've just
> blown the program out of the water. That's OK because it was broken,
> but we don't want to bite the early adopters too hard. Emails are
> always verified so they can be included and org info is verified too
> so it can go in, but to get names in their certs they will need to
> use the standard assurance program for now (eg org admins or other
> assurers verify IDs and apply 50 points). The reality is that
> organisations need to be able to put names in certs en masse, and
> there isn't really any decent options short of running your own CA
> and paying 6 figures for a CA cert. Again I think we should leave
> the door open with something like the 'verified by issuer' wording
> previously discussed.

I see nothing wrong with requiring org members to be Assured by
someone within their company (using Assured in the CA Cert Assurer
sense) - heck, it could be the HR people that verify ID and other work
documents.  It just becomes part of the onboarding process for those
Orgs.  Yes, any initial en masse issuance will require special steps,
but it would anyway - since someone has to tell these workers that
they've got to go sign up for a CACert.org account.

It's a satisfactory interim measure but there are some problems with it, such as requiring individuals to contract themselves 'in the line of duty'. There is typically diminished personal responsibility when acting as an employee so we really need to get a (legal) handle on the organisation itself and consider the admins agents of that organisation. It also raises some privacy issues (eg data collection and storage by individuals within the organisation) and perhaps most importantly, it just doesn't scale.

Again, we just have to say what we do and do what we say so it's ok to give orgs what they've been missing out on for all these years, but we need to be a bit more careful about how we go about it than we have been thus far.

Sam

_______________________________________________
Have you passed the Assurer Challenge yet?
http://wiki.cacert.org/wiki/AssurerChallenge

CAcert-Policy mailing list
CAcert-Policy AT lists.cacert.org
https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy

---

Philipp Dunkel

p.dunkel AT cacert.org

---

Your reality and mine may not entirely coincide. Therefore you may not rely on this message meaning what you believe it means. 

---

_______________________________________________
Have you passed the Assurer Challenge yet?
http://wiki.cacert.org/wiki/AssurerChallenge

CAcert-Policy mailing list
CAcert-Policy AT lists.cacert.org
https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy

_______________________________________________
Have you passed the Assurer Challenge yet?
http://wiki.cacert.org/wiki/AssurerChallenge

CAcert-Policy mailing list
CAcert-Policy AT lists.cacert.org
https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy