Policy-Discussion

[samj AT samj.net]

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.

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
>