Policy-Discussion

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

Now that's a good question.

That is also why we are saying that all information has to be  
verified. We did not say that all information has to be assured. So we  
could for example state in OA Policy:

The O-Admin has the responsibility to verify the CN of certificates he  
issues in the name of an Organisation.

There are several ways this could be accomplished. The first would be  
to rely on assurances. Someone suggested that if there were 2 assurers  
in HR they could assure all new employees. That would be one way. But  
since the statement is verified and not assured another way could be  
to check the CN against a paycheck database or other such database  
available to the employer.

This is one of the reasons that the "Verified" requirement is so good.  
It restricts what goes into the cert, but it does not close the doors  
on OA at all. What it does do is that it prevents Organisations from  
just making up information.

Regards, Philipp

On 2008-10-16, at 11:42, maurice Kellenaers wrote:

> Philipp Dunkel wrote:
> > Hi,
> >
> > I think it time to make something quite clear. Sub roots are not  
> > an  option. I have nothing against keeping the possibility open for  
> > some  day in the far future but now they are not even worth  
> > contemplating.
> >
> > Now here is as to why. Both M$ and MZ have decided that they are  
> > not a  food idea. They are contemplating removing subrooted CAs  
> > from their  browsers. That means that if we want to be on browsers  
> > we won't be  doing sub roots.
> >
> > So while conceptually subroots may be the best concept for OA it  
> > is  not compatible with reality.
> > Think about subroots like you think about The Easter bunny. Yes it   
> > would cool to have a bunny that lays colored eggs, nut unless there  
> > is  a major change in the reality of bunny anatomy it ain't gonna  
> > happen.
> >
> > So please stop bringing up subroots until you can provide these 3   
> > things.
> >  • A signed affidavit from M$ that they allow and will always  
> > allow  CAs with subroots
> >  • A signed affidavit by Mozilla that the will allow CAcert to be   
> > included in its browser with subroots
> >  • A written and coherent policy suggestion of how todo subroots.
> >
> > Regards,
> > Phil
> >
> > P.S.: sorry for being harsh, I just think that it's a disussion we   
> > cannot afford right now, due to the constraints the audit  
> > currently  places on us. Right now we need to work quickly and  
> > effectively to get  the CPS done.
> No offence taken.
>
> Since the general consensus is that all information has to be  
> assured/verified, the CN (and OU) would fail that.
> In what way can we verify the name (and department)? By assuring the  
> employee? Then who does that? the O-admin? external assurers?
> > ---
> > 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 7:34, maurice Kellenaers <maurice AT gkbikes.com>   
> > wrote:
> >
> >
> > > Sam Johnston wrote:
> > >
> > > > On Thu, Oct 16, 2008 at 10:39 AM, Philipp Dunkel  <p.dunkel AT cacert.org 
> > > >  <mailto: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).
> > > I think that sub-roots are the best way.
> > > The organisation is the-man-in-the-middle. CAcert issues to the   
> > > organisation, the organisation to it's employee's/servers.
> > >
> > > > 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
> > > > >   
> > > > > <mailto: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
> > > > >   
> > > > > <mailto:CAcert-Policy AT lists.cacert.org>
> > > > >   https://lists.cacert.org/cgi-bin/mailman/listinfo/cacert-policy
> > > >   ---
> > > >   Philipp Dunkel
> > > >   
> > > > p.dunkel AT cacert.org
> > > >  
> > > > <mailto: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 <mailto: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
> > > _______________________________________________
> > > 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
> _______________________________________________
> 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.
---

Attachment: smime.p7s
Description: S/MIME cryptographic signature