Skip to content.
|Networking government in New Zealand.
 
You are here: Home » Services » SEEMail » S.E.E. PKI Paper 11 - S.E.E. Key enabling a web based application » 12 Appendix A - RFP Boilerplate for SENSITIVE PKI enabled

12 Appendix A - RFP Boilerplate for SENSITIVE PKI enabled

1. The system must authenticate users with S.E.E. Key digital certificates - http://see.govt.nz/pki/

2. The system must create an access audit log entry when this form of authentication is used to access the system.

3. There must be no way to use alternative authentication mechanisms like username/password to access the system except from the console, i.e. the user must not be prompted for username and password.

4. The server must be able to be configured to specify which CAs are trusted, and this list must be easy for the system administrator to maintain.

5. The server must check the client certificate against the CRL or OCSP service specified in the certificate to confirm that the certificate has not been revoked. If only one is available, use that one.

6. The server must drop the connection if the certificate has been revoked, the certificate is expired or not yet valid, or if a current CRL or OCSP response is unavailable, the signature is not good, or if the certificate has not been issued by a trusted CA.

7. SENSITIVE systems must support the 3DES algorithm, and may also accept AES. SENSITIVE systems must be configured not to accept any other symmetric encryption algorithms.

8. IN CONFIDENCE systems must support DES, 3DES or 128 bit RC4 encryption algorithms, and may also accept AES. IN CONFIDENCE systems must be configured not to accept any other symmetric encryption algorithms.

9. The crypto libraries should be FIPS evaluated.

10. Random key generation methods should be known to be good.

11. Private keys should be stored in hardware modules.


[ Previous | Next ]