Chris, Folks,
> I have been thinking about future development for OpenCA and have
> come up with the following list. I thought I would share them with
> you to get some feedback before putting them on the "OpenCA
> Features Request page". What do you think ?
this is actually a very good summary of some missing key features.
I have some additional feature requests and ideas (see bottom of
this mail).
But first let me comment on a few topics you mentioned I consider
most important:
> 2. Command line API to CA and RA functions - This would allow for complex
> scripts to be written around the OpenCA environment, hopefully paving the
> way
> for future modifications. This would also lead to the posibility of XKMS,
> CMS, SOAP based clients. I suspect the new batch processes are well on the
> way to delivering this.
definitely a "must have". The batch processor is a nice start, but
a CLI interface and a properly documente Perl API would be really great.
E. g. out of my project requirements I have started a Perl script
that collects all pending certificates and issues them automatically
on the CA. (I will contribute it once it works properly...)
> 3. Automation functions - Automation of regular operations like: CRL
> production, certificate signing. This is important in production
> environments
> where you do not want Operations staff to have to manually produce regular
> CRLs.
Yes, one of the most important automated functions is fully
automatic CRL generation and publication. I do need this right soon
now.
Another is automated certificate renewal, the system should insert
certificates with approaching expiry date automatically into the
RA's "New requests" category. The "warning period" should be
configurable.
> 4. On-line CA model option - To accommodate an on-line CA model. i.e. a
> user
> can request a certificate and in the same session get the requested cert
> back. This can be used for "free email certs" or in closed user groups
> where
> only certain people have access to the public interface. It may be that
> this
> would only work with CA root key in hardware, or a special CA user logged
> on
> on a secure terminal to give the environment access to the CA password.
This, too, is needed by my current project. As said above, I have
started to write some scripts that perform exactly these automations.
Together with an online CA key and
> 5. Audit logging - Audit of RA and CA operations to a tamper proof signed
> log.
> This is possibly a requirement to achive any form of accreditiation.
this brings us to another requirement that is not easy to implement
but would really be important:
OpenCA should know exactly how many private key operations are performed
on the CA key. If using a HSM that is kept online (with usable private
key opened), then another process might abuse the HSM to perform
private key operations.
We cannot do much to *prevent* this, but it can be *detected*:
Some HSMs support a read-only "private key usage counter" that
is incremented every time the private key is accessed. By reading
this counter, OpenCA (or an Auditing System) could detect if unauthorized
key operations have happened circumventing control of OpenCA.
One module that supports this is nCipher's nShield HSM. Unfortunately
this function is not available with the stock CLI tools provided with
the HSM. Instead, custom programming is required against the nCipher
API, and for this the nCipher SDK is required.
> 6. Script/environment validation - A function that ensures OpenCA is
> running
> in a "known" environment. Perhaps md5 signature creation (after
> installation)
> and run time validation.
Yes, but this could also be done using a host based IDS. Not too
important, I think.
> 9. Web based OpenCA configuration and management - Enhancing the existing
> management screens to allow management of certificate roles and
> extensions, access control settings and node management i.e. a
> front end to the OpenSSL config files.
Sounds like a *lot* of work. I am fine with today's XML based
configuration. I don't like the template -> config file hack much,
though.
> 11. Authentication via a third party - The ability to allow a user to
> request
> a certificate and authenticate themselves the authentication token is then
> checked against an independent directory.
Definitely! I considered filing a RFE for this already, and Michael
answered to my other question that this might be implemented (but with
low priority).
Let me add
13. Automated CA Key rollover
When reaching the end of the CA certificate lifetime, there is
a certain point after which no usable end entity certificates
can be issued whose desired validity *fully* fits into the CA
certificates validity.
To address this problem, we issue a rollover certificate that becomes
valid when reaching half of the CA certificates validity range:
notBefore(new) := notBefore(old) +
((notAfter(old) - notBefore(old) / 2)
New certificates are *always* and *only* issued using the "newest"
CA certificate available. After rollover happens (automatically by
reaching the "NotBefore" date of the new certificate) the old
one still remains valid and is *exclusively* used for CRL
generation, revocation etc.
This ensures that you will always be able to issue certificates
with a lifetime up to half of the "standard" CA certificate
lifetime.
CA operators need only remember to issue a new rollover
certificate within the first half of the currently used certificate's
validity.
BUT the CA software has to be able to deal with this.
14. Improved debugging support
I frequently get lost in the system when trying to debug things,
often I wonder what functions get executed by OpenCA, the CGI
system seems very opaque to me (and I consider myself an
experienced Perl hacker)
15. Improved error handling
I have seen OpenCA report crude error messages on seemingly
harmless error conditions. When checking the code it was
often something like an uninitialized variable that was
used to call a method on.
What do you think?
cheers
Martin
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
OpenCA-Devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/openca-devel
