Policy-Discussion

[maurice Kellenaers <maurice AT gkbikes.com>]

samj AT samj.net
 wrote:
> Ok so that sounds like a 'yes' vote for the 'verified by issuer' wording.
>
> I think you're missing the point of the subroot concerns. Nobody is
> saying that we should surrender control of the subroots to the orgs as
> other CAs have been doing-to do so is the PKI equivalent of writing a
> blank cheque.
>
> The key and critical difference is that users will see 'verified by
> Acme' rather than 'verified by CAcert.org'. This is pretty much
> essential for functional org assurance without blowing a hole in our
> security identical to the one the vendors are now scrambling to close.
>   
maybe a strange idea, but is there a way to say :  "verified by Acme, 
who is verified by CAcert.org" or something like this?
that way Acme can use cn="" at their discretion in their cert while 
CAcert MAY/COULD ask to evaluate/verify the cn= of the cert.
> Calling for us to produce a unicorn is not useful...
>
> Sam on iPhone
>
> On 10/16/08, Philipp Dunkel 
> <p.dunkel AT cacert.org>
>  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.
> >
> > ---
> > 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
>
>
>

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