CAcert Code Development list.

[Christopher Etz <Christopher.Etz AT cetz.de>]

Hi Ian,

Thank you for your eloquent answer to my rather long email.

I totally agree to most of your points.

And as you can see, I'm still keen to join that project.

I waited a few days, hoping to find more reactions on my email. But for now, I'd like to go deeper into two of the points. Sorry for not quoting your response, but I think, the email would become too lengthy.

First, on security objections:

From the overall architecture (https://dev.cacert.cl/wiki/birdshack/Architecture) I understood a clear separation between the signing server and the "application's backend" (or business logic or whatever you want to call it). I did not completely understand, whether your requirements about auditibility concern the one, the other or both systems, or where these needs differ.

For the moment, I'm more interested in that business logic server. I believe, we should make clear, whether the ability for an audit is fulfilled with

• a Java runtime (a complete source code review would be a tremendeous task)
• a JDBC driver (same reason as above)
• and possibly the decision to code anything else by hand (for auditing and security reasons)

The latter would mean: no ORM, no JPA or alike.

What's your opinion / the opinion of the others?

Second, about the level of the API:

From your reply, I've got the impression, that you would vote for an entity-level. Here, I'm still not convinced.

My reasons are:

• If we had an entity-level for the API, the only task of the so-called business logic would be to interpret the requests, convert them into SQL statements, execute them, convert the result into XML (or alike) and pass it to the caller. I personally, wouldn't call that "business logic". :-(
• Instead, I'd expect this to be the right place for all consistency checks. But then, the API needs to be on a "business process level" (big word, but I hope you understand me). I.e. there have to be API calls to create a member (with all its dependant information such as name, DoB, credentials, email addresses etc.), update a member, delete a member, add new assurances, search assurances and so forth.

I admit, the API would become more complex and probably, would experience more changes over the time. But here, I'd consider the consistency the higher value.

Again, I'm curious about all reactions -- from Ian and others.

To make very clear: I'd be happy to join the project, perhaps starting with a first set of business processes extracted from the wiki page called "Actors". What's necessary for my participation? Someone wanting to invite me?

Cheers,

Christopher

--

________________________________________________________________________

Christopher Etz Telefon: +49 93 73 20 42 70

Ohrnbach 1 Telefax: +49 93 73 20 42 71

D-63937 Weilbach/Unterfr. Email: Christopher.Etz AT cetz.de

Attachment: smime.p7s
Description: S/MIME cryptographic signature