CAcert Code Development list.

[Ian G <iang AT cacert.org>]

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.  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

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