CAcert Code Development list.

[Mathieu Simon <mathieu.simon AT simweb.ch>]

Ian et al.

OK, CAcert ist international - I don't want to focus on national 
problems but rather try to improve things that help both CAcert 
"international" and local users.

Maybe I should change my original request that was: "Please replace the 
key generation field by a CSR pasting text area like servers and org 
servers nowaday are handled"
To: Offer both key generation and alternatively CSR pasting within org 
client cert registration view like nowadays offered for personal 
certificates for any CAcert member.
This would be exactly how its done in actual software.

Therefore I have the following humble question:
Was there a good reason to not give the possibility to paste a CSR for 
Org Client Certificates?
If so, then please enlighten me. -> Please see my example at almost 
bottom of this message.

Ian G schrieb:
> On 16/03/2010 16:04, Mathieu Simon wrote:
>
> ...  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)
>
> [...]
> Tricked again....
No comment for this passage.
Let's try to focus again on a possibility to solve something. I try to 
provide ideas, ways  how to change something in a hopefully positive way.
Until now, no code has been tested, no productive things have been 
touched - therefore I suggest: No damage for CAcert in any way. - OK? ;-)
> 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.
But not solving anything.
> 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.
OK what I'd see is the case that if the local guys prefer the let the 
private key + request be generated by the user (like me) and for those 
who want
to generate the private key for their users shall be able to do as well. 
(see beginning)

Even those one would sometimes prefer to do the key generation with an 
external too like openssl rather than within the browser - which is not
possible with actual software.

I don't see any disadvantage to force org admins to use browser for key 
generation rather than any other tool they trust into. - On the other 
hand the usual
the simple personal cert signing procedure offers this possibility 
(under advanced) to generate my keys for a personal mail cert local in 
they way I wish while
not being bound to the in-browser key generation.

Now back to the responsibilities:
The org-admins, being the the persons able to pass a request to CAcert 
is allways community member and has mandatory assurer status.
So it's up to the org admins' task to verify the CSR if it is ok and 
shall refuse a CSR if it does not pass certain standards or is suspected 
to be rogue 
- or even being forced to sign a rogue request by his boss.

In this case I must agree that there is need for policies protecting 
CAcert, and the org admins and that they need to be developed. But see my
argumentation why I prefer to coding first first (or a least try to do so).
> 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.
OK.
> > 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.
As org admin we're trying to explore developing org assurance in 
practice on new lands.
We are trying to give our best, being as honest with the community as 
possible if we (still small number of org admins) get into trouble - as 
early as possible.
Please: A slight bit of optimism Ian. It helps community members to keep 
up motivation easier. :-)
> 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.)
In the very moment my impression about LibreSSL code base wasn't in a 
way I could say that  developing a patch could be
even doable (for myself) I prefer to see on a test server if I could 
even manage prepare a possible prototype patch.

Then - and if it works on a test server we can think about adapting the 
rules - I duly agree that there is need for it.
But not before a prototype has shown that it's even possible. At least 
that was my idea, because changing any rules
before being able to say if it's even doable with LibreSSL would be a 
waste of time and a rule that cannot be applied to
the software system is IMHO wasted time.

It's almost 1 AM here - I gotta need some sleep
Mathieu

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