Appendix F. Strategy

Table of Contents

1. The Strategy Behind OpenCA Development
1.1. Scalability
1.2. Command Line API to CA and RA Functions
1.3. Automation functions
1.4. On-line CA model option
1.5. High Risk Environment Mode
1.6. Audit logging
1.7. Script/environment validation
1.8. Automated CA Key rollover
1.9. Function to process signing and encryption keys in one go
1.10. Secure storage and recovery of encryption keys
1.11. Web based OpenCA configuration and management
1.12. Improved key lifecycle management
1.13. Authentication via a third party
1.14. Improved debugging support
1.15. Improved error handling
1.16. Accreditation

This appendix gives an over view of the current strategic direction of the OpenCA development. As all things it is liable to change, but this is the current thinking.

1. The Strategy Behind OpenCA Development

1.1. Scalability

A statement from the OpenCA team to say that for a given server and database environment what is the expected volume of certificates. This is important for users planning installations.

1.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.

This would inlcude a fully documented PERL API scripting interface.

1.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, etc.

1.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. In addition to this, the CA may keep a log of the number of times it was accessed.

1.5. High Risk Environment Mode

A high risk environment mode, which is based on a cd-rom or some similar write protected media, changeable configuration data and exchange data are hold on writeable media (like usb-based-hardware, maybe encryptable), and the ossupports something like se-linux or similar.

1.6. 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.

1.7. Script/environment validation

A function that ensures OpenCA is running in a "known" environment. Perhaps md5 signature creation (after installation) and run time validation.

1.8. 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.

1.9. Function to process signing and encryption keys in one go

OpenCA could introduce the idea of "certificate profiles" where a user "requests" once but gets a "Profile" of certificate types". Secure storage and recovery of encryption keys would be part of this mechanism. The start of this is in the new Batch processes in the form of the "Process".

1.10. Secure storage and recovery of encryption keys

A function to provide (optional) key backup and recovery.

1.11. 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.

1.12. Improved key lifecycle management

Screens to allow users to renew their certificates, modify DN's etc.

1.13. 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.

1.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)

1.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.

1.16. Accreditation

Achieve Common Criteria/FIPS accreditation ! This is a long way off, but with OpenSSL being pushed through, then it may be possible !!!