CAcert Code Development list.

[Dieter Hennig <dieter.hennig AT id.ethz.ch>]

Dear all,

I would add only a small restriction to Ians text, though, our people
could appear in two forms at Cacert.

a.) As a personal member of Cacert and become assurer, .... They have to
following the rules and have all rights of individual members.
Organisations members have not the rights to limit this in anyway.

b.) As a staff member/student in our case of a organisation member. And
this we are discussing here.

Am 18.03.2010 11:41, schrieb Ian G:
> On 18/03/2010 17:41, Mario Lipinski wrote:
>> Am 15.03.10 17:59, schrieb Ian G:
>>> If we then move to the Orga Admin context, the member is the Org. In
>>> which case the Org has many private keys which it gives out to its
>>> employees (who are not members). So in this case, the Org is primarily
>>> responsible for the usage of those keys ... just like the Org is
>>> primarily responsible for the usage of the office computers or the
>>> corporate seal for purchasing stuff.
>>
>> So it should be up to the organisation. If orgs like to backup/store all
>> keys, they should. If they want only their employees to know the private
>> part, it should be also fine for us.
> 
> 
> Exactly, that would be my view of the current writings of the other
> policies, especially CCA security obligations:
> 
>       "to secure your private keys, "
> 
> where you == member.  So what we need in the OAP is something like:
> 
>   "The organisation as member is responsible for all actions
>   and results 

on behalf of user certificates in the name of its organisation

> .  It may delegate parts of the responsibilities,
>   such as key creation, storage, backup, signing and so forth
>   to personnel within its organisation, but this must be done
>   under either a general subsidiary policy of CAcert, or an
>   approved organisation-specific policy."
> 
> I mean, it could be anything, really.  That was just what came out of my
> head.  The point being that the auditor comes in and says, what are you
> doing, show me the docs.  And then, show me you're following the docs.
> 
> Now, what would be helpful is to take something like that above text ...
> assuming agreement ... and post it into the PolicyDrafts page I
> mentioned earlier.  Capture all this info.  Then one weekend, we cram it
> all into a rewrite, and spring it on the policy group.
> 
> 
>>> In that context it might be reasonable to have the Org pre-create all
>>> the keys and then provision them into browsers. Indeed it might be
>>> reasonable to suggest that the employees must not create their keys,
>>> because they are not "us" ! But maybe we don't need to go that far if
>>> it is clear that the Org is the responsible entity.
>>
>> We sign certificates, not private keys. So management of the private
>> keys should be up to the organisation.
> 
> 
> ok.
> 
> 
> iang
> 


Best regards


Dieter

-- 
Dieter Hennig
Informatikdienste/Helpdesk
ETH Zuerich, STB G 18.2
8092 Zuerich, Stampfenbachstr. 69
Tel: +41 44 632 4278
Fax: +41 44 632 1900

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