Michael Bell wrote:
>
> Hi,
Hi,
> here are some remarks to the snapshots:
>
> I use snapshot 20010623
>
> If there are old mistakes which are fixed now please ignore them.
>
> CA
> --
>
> genCAReq: -subj " " causes an openssl-error
If the request subject is empty it is right that openssl returns an error or do
we want to be able to request certificates without subject field ???
If this is not the case, then update to a pre-0.9.7 version of openssl, this
should
fix the problem.
> Public
> ------
> NewAsk4ReqSheet "sheets/new_ask4rev.html"
> CAChain "/usr/local/RAServer/chain"
> ShowAsk4ReqSheet "sheets/show_ask4rev.html"
>
> verifyPath "/usr/local/bin/openca-verify"
> signPath "/usr/local/bin/openca-sign"
>
> RBAC_DIR "/usr/local/OpenCA/conf/rbac"
> EXT_DIR "/usr/local/OpenCA/conf/extfiles"
> (neccessary for export-import.lib)
>
> * export-import.lib not loaded
> * export-import.lib too old (please use the one from the cvs)
Can you update the export-import.lib into the openca-0.8 tree ??? I will update
the public
conf file adding the RBAC_DIR and EXT_DIR
> RAServer
> --------
> verifyPath "/usr/local/bin/openca-verify"
> signPath "/usr/local/bin/openca-sign"
> CAChain "/usr/local/RAServer/chain"
Already Fixed.
> ShowAsk4ReqSheet "sheets/show_ask4rev.html"
> pendingcrrbasesheet "pending_crrs.html"
>
> The link "Revoke Requests" is wrong - dataType=PENDING_CRR and no type!
>
> * old viewValidCert.html (please use the one from the CVS)
> * new_crr is missing (take it from the CVS)
> * export-import.lib not loaded
> * export-import.lib too old (please use the one from the cvs)
>
> Modules
> -------
> OpenSSL
>
> verify insteed of openca-verify
> sign insteed of openca-sign
>
> Could we include support for the option -engine via
>
> * $self->{engine}
> * ENGINE => "hardware_engine" (parameter for the sub new)
> * OPENSSL_ENGINE in the conf-files?
>
> (OpenSSL supports the engines for all openssl-commands.)
Added support for engine either into the ca and into raserver. The module will
use the env varibale engine -- so we have the support for it into raserver and
ca for every command.
In future versions of the OpenSSL module I will add the ENGINE=>$engine key,
too.
> Role
> ----
>
> several small changes to handle the role via
> the header of the cert-requests
>
> RAServer
> * viewReq
> * appReq
> CA
> * viewReq
>
> Please see Role/
>
> (The extfiles must be present on the RAServer too but
> a "touch" to the names is enough.)
>
> OpenCA::DBI is massively corrected and has now a better codebase.
> storeItem is still complex but the functionality is splitted
> into 6 new functions. I hope that now other people can
> understand what I'm doing and can check the code. DBI has
> now a small README.
>
> I still missing DBIS in the snapshots which is required for DBI.
Why don't you plan making an E/R schema as you are implementing the
DB into relational database ? This would simplify your life in setting
all the foreign keys and references and obviously other people in
understanding your schema.
> Rolemanagement and OpenSSL-Configuration
> ----------------------------------------
>
> I have a lot of time to play around with LDAP and I think no
> longer that it is a good idea to store the role in the DN because
> this is a problem for the most organizations (but if neccessary
> - because of the local law - it is no problem to use ou).
Yes. I agree with you, role should be left somewhere else.
> A role is only used in the trustcenter itself. So there are three
> ways:
>
> - a db-table: serial -> role
> - a certificate extension
> - a attribute certificate
>
> The second is not a really good idea because it is proprietary and
> perhaps some other applications are not very happy about extensions
> which they don't understand.
This is true. The usage of private extensions could lead to interops
problems, better not following this.
> I think the first variant is the best one but the mapping "serial to
> role"
I would add "SERIAL + DN" => "Role + Signature" to double check what is
being addressed by the role management system. I would code this using
the RBAC module without the usage of the DB/DBI module: the usage of a
simple HASH file (as the DB module does) should fit and it should be
faster than a complex DBMS for this simple storage functions.
> should never be changed because the role decides which extensions and
> which opensslconfig are used. A problem of the mapping is the security
we could have the role management just on the CA computer (which should
be safer as it should be network disconnected) and have the roles just
imported and accessed in reading by the RAServer. The roles would
become a sort of "CRML" Certificate Role Management List (as CRLs..)
carrying SERIAL, DN, and Signature for that entry by the CA.
> The actual module OpenCA::DBI (v0.4.0) supports the column ROLE for
> CERTIFICATE and REQUEST (not for CA_CERTIFICATE). The column is
> searchable. The column ROLE in CERTIFICATE is only present to avoid
> changes on the table if the solution one is choosen. The column
> ROLE_SIGNATURE in CERTIFICATE is only present to avoid changes on the
> tables if we decide us to sign every pair role and serial.
I would separate role management from the DB (of X509 objects).
Another solution for the storage of the Role Information would be adding
them to the LDAP tree and search them there. The only problem with
this approach is that on misconfigured systems (not so difficult to
find... ) these information could be public available (or worst writable!).
> We should made a review of the functions on the CA because a lot of the
> functions related to RBAC and Configuration are no longer needed.
Unfortunately I have to admit I did not followed your work about that...
> Actually the following commands are used:
>
> general
> * show_roles
> * manage_role
> role
> * add_role
> * show_prepared_role
> * new_role
> openssl
> * show_sections
> * show_section
> * edit_option
> * show_prepared_option
> * change_option
> * delete_option
> rights
> * show_rights
> * add_right
> * show_prepared_right
> * new_right
> * delete_right
>
> The other scripts are no longer needed. This includes:
>
> access control
> * edit_ac
> * edit_ac_of_role
> * change_ac_of_role
> * show_changed_ac_of_role
> mapping from roles to openssl
> * change_map
> * delete_map
> * do_delete_map
> * edit_map
> * show_changed_map
> * show_map
> sections
> * change_section
> * show_changed_section
> * edit_section
> * show_prepared_section
can you remove them from the cvs tree (including the related unused
sheets if any) ??
> Finally a security related question. Are the headers of the objects
> protected? I think that the headers are not signed and so they are
> insecure. Is it neccessary to add signature for every relevant
> header (crr, request and certificate not ca_certificate)? If such a
> signature is neccessary then it would be better to implement now
> empty fields in a database than later have to alter tables.
I am not sure this is really needed, in the header there are only
data for the searching (at least in the DB module) and as I can remember
the important data is get from the object parsing.
Also when a request is approved and signed the object is actually
signed and protected - for certificates this obviously is not needed
(as for pkcs#10 requests).
> If we have to sign the headers then we could store the role in the
> header of the certificate and must not store an extra signature only
> for the role. (We must only grant then that we are not faked with
> different headers and certificates which is relatively easy to
> implements via the serials.)
Keep in mind headers are only used internally -- and not accessible by
externals (only RAServer Operator and CA manager should access them
phisically when exporting/importing requests... )so I would not address
this as a real issue...
> I hope this was not too much ;-D
Well... :-D Sorry for the delay of my reply... as always...
> P.S. the attachment extracts to OpenCA/
The files contained into the archive should be added to the original
openca cvs tree or what ?
--
C'you,
Massimiliano Pala
--o-------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager] [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.openca.org Tel.: +39 (0)59 270 094
http://openca.sourceforge.net Mobile: +39 (0)347 7222 365
S/MIME Cryptographic Signature
