CAcert Code Development list.

[Ian G <iang AT cacert.org>]

On 16/03/2010 16:04, Mathieu Simon wrote:

> > Why is it that we should never let anyone else generate our keys? If
> > there is a reason for this it would want to be documented in the CPS,
> > etc.
> Well, if so, but read later.

...  OK, so we are definately in devil's advocate mode here ... as I 
say, my objective is to get it written down.  Without that, we're in the 
dark.

(fast writing below, gotta travel soon)


> > 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" !
> No! - At least in Switzerland as admin. - Even if your users may not be
> able to use OpenSSL command line to create Keys and CSR:
> Better provide them the tools to create the keys than let them do it.
> It's only a bit different problem when you are using smartcards but
> often then
> the keys are signed by a local PKI. Those certs are almost never used to
> sign or encrypt data.
>
> I have asked a our cantonal data protection mandate who basically said:
> Even as the main sysadmin you should never ask or create
> a private key that does not belong to you personally or u should have
> access to it. This means that you should never generate the private
> key for your co-worker or store a copy with your backups because if the
> keypair gets stolen or abused you are one of the the first to be accused.


Well.  With all due respect to your cantonal data protection person, who 
I'm sure is a very nice person ... but *we are not in Switzerland*.  All 
CAcert stuff is located in NSW Australia, and if you allow others to 
start imposing local ideas on you, you are entering a world of pain.

Think of it this way.  I go to my local cantonal DP person, and she 
says, oh, that's old thinking, based on 1990s commercialisation of the 
concept of digsigs, and we've pretty much trashed that notion because it 
didn't work.  Now, you, Iang, have to make sure that your Org is in 
total control of all keys, because the individual isn't the point, the 
Org is.  If this means the Org creates the keys, so be it.

Ok, so what I'm setting up here is TWO competing scenarios.  Which works 
fine as long as we don't enter into some sort of cross-border scenario 
... but that's exactly where we are:  cross-border by definition. 
CAcert is in all places at the same time!

So, to resolve the obvious clashes, we impose CAcert rules.  And CAcert 
rules are that the Org is responsible, because it is the member.  The 
individual is not responsible (to us) because she is not a member, we 
cannot impose anything over her at all.  (Now, the Org might be able to 
impose something over her ... but that's subject to the same thing as 
the above, one Org might and one Org might not, which leaves the lowest 
common denominator effect again:  the Org is responsible.)


> This applies to certificate request to any existing CA.


Something you can ask your cantonal DP rep:  On the basis of what law is 
she saying this?  Probably she is thinking the EU digsig directive, in 
which case it's being read wrongly, because she is thinking of QC certs, 
and those are not what CAcert does.

This is fairly typical though, the directive is written to confuse the 
possibilities so that everyone gets what they want (without realising 
the weakness of what they got).  So, many people say "all CAs follow 
this law" and they are simply wrong.  Tricked again....


> - This means big
> legal risk for you as org admin - and sorry: I won't risk my job because
> of CAcert ;-)


Actually, by changing the CAcert rules, you may be exposing yourself to 
bigger harm, because you are allowing cherry picking.  By deliberately 
not following the CAcert rules, the CAcert protection can be struck 
down, leaving you without the protection of either regime.  But this is 
complex, all cross-jurisdictional stuff is a nightmare.


> Thus at the very moment I don't issue any client orga certs. Server ones
> are no issue with the actual interface.
> > But maybe we don't need to go that far if it is clear that the Org is
> > the responsible entity.
> Hmm, we have to make it the way it's safe for both us and the orgas.


Sure.  At the moment, we are still at the point of principles.  As far 
as I can see, we have these principles:

  * the member is responsible.
  * the Org is the member.

In that scenario it seems reasonable for the Org (or the O-Admin) to 
create the keys for the Org.

Then, we get to the problem that the Org then distributes that 
responsibility (in form of keys) to the employees.  So speaking 
governance/audit wise, we would want a form of relationship which 
preserves the strength of CAcert's WoT in that scenario.  Therefore:

  * the Org must only distribute responsibility of keys to
    those who are under some clear Org <--> individual agreement
    that conforms to some CAcert standard.

E.g., in your canton, they may say that an individual who signs is fully 
responsible.  But this is unacceptable to CAcert because that individual 
is not a Member of CAcert and cannot be brought to Arbitration.  The 
courts in the canton will protect that individual, because there is no 
agreement.  So now we have a rogue agent in the CAcert WoT that can do 
all sorts of terrible acts ... and we can't stop her.

So we need that extra linkage.  Which would have to be written.


> > (Where, a necessary pre-step to any test of reasonablness is to first
> > document the proposal more fully...)
> > > I have given a look at both of them in the source code package under
> > > pages/account of both pages and the adaptation of
> > > of the used pages/account/16.php from a view's perspective looks
> > > possible without to much effort, but I don't understand
> > > LibreSSL's architecture enough to say if it would imply larger
> > > adaptation on backend's side.
> > >
> > > How is your position? Also remember that this would also improve
> > > CAcert's auditability :-)
> > Well, and with doco. Last auditor (me) dumped the whole Org area
> > because issues like these were not documented.
> >
> > https://wiki.cacert.org/PolicyDrafts/OrganisationAssurance
> Well - then why not improve it step by step rather than doing a big
> bang? :-)
> It would represent a small but not unsignificant step.


I don't mind how it's done :)  As long as it is done !


> > > From my perspective it would look worthy to fix this issue in the
> > > actual software rather than waiting until new software is
> > > finished.
> > From my perspective, without the doco, there is little auditability.
> > I don't want to hold up any work on fixing the software, but the
> > documentation for OA is a real killer, IMO.
> Yea but something where CAcert can grow and bring in new use cases -
> looks worthy to me and maybe others too. :-)


Sure.  But this is a strawman, because without the doco, you cannot say 
if the use cases are positive to the CAcert community or negative.

Without the doco that lays out what the code does, you are in danger of 
making things worse.  And, as you can see from the above, there are 
mines out there in this path ahead.

(Which is to say, carry on with the patch, but it will be hard to deploy 
without policy.)

iang


> Now besides all the regulations needed for OA and its rather bad state -
> may someone have a look at my code?
>
> If it goes into the right direction I could provide a patch for the
> original file last send one is rather a design draft with some
> thoughts and comments.
>
> Mathieu

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