Medium security NIKHEF X.509 policy

Document source: nikhef.nl:/global/ices/grid/dutchgrid/ca/policy-medium
Version: $Id: medium.html,v 1.5 2001/05/15 09:02:52 davidg Exp $
Status: draft
On-line reference: http://certificate.nikhef.nl/

1 Introduction

This document describes the certification policy for encryption and authentication keys, used by the NIKHEF/DutchGrid certification authority for medium-security (ms) X.509 certification. In short, ms X.509 certification guarantees that, for every certificate issued, the identity of the requester has been determined (using a proof-of-identity or in accordance with the rules specified in section X). Moreover, the relation of the requester to the organisation mentioned in the certificate has been found to be correct at the moment the certificate was issued.

This document should enable users of the NIKHEF ms X.509 CA to judge what value can be attributed to X.509 certificated signed by the NIKHEF ms X.509 certification authority. It also serves as an operation manual for the NIKHEF CA operators. Similar documents exist for the low-security X.509 policy.

2 The NIKHEF CA

Mailing address: NIKHEF, c/o David Groep, P.O. Box 41882, NL 1009 DB Amsterdam, The Netherlands.
Internet e-mail: ca@nikhef.nl
Sources of information: http://certificate.nikhef.nl/
Validity: this document is valid until December 31, 2001.

3 Limitations of the NIKHEF CA

The liability of the NIKHEF CA is limited to those persons or objects that are affiliated to organisations participating in the Dutch Data Grid (DutchGrid) and/or the WCW. The NIKHEF CA Organisation (NCAO) mains at building a trustworthy certificate-based security infrastructure, suitable for use on production systems of the participating organisations. In this version of the ms X.509 policy, financial transactions based on NCAO ms X.509 certificates are not allowed.

3.1 Legal aspects

The NIKHEF CA X.509 certification service is run with a reasonable level of security, but is provided on a best effort only basis, by following the procedures outlined in this document. De facto, the NIKHEF CA guarantees:

that the identity has been verified before a certificate is issued
that the common name included in the certificate corresponds to the name as used on the proof-of-identity or to the name as used publicly in official publications of the organisation the person is affiliated to
that the date of issue as stated in the certificate is correct
that a relation between the organisation mentioned in the certificate and the person to whom the certificate was issues has a relationship at the time of issue of the certificate. It is specifically not guarantees that such a relation exists or existed at any later time. Also, a certificate will not establish or affirm any authorisation of said person with respect to the organisation
that a certificate will be revoked if any abuse of the certificate is known to the NIKHEF CA.

Apart from the guarantees given above, NIKHEF, the foundation `FOM', the NIKHEF CA, its subordinate RA's, and its personnel are not to be held liable for any damages, including but not limited to lost profit, lost savings and incidental or consequential damages. The NIKHEF CA is not to be held legally responsible for problems arising from its operation, or for the use made of the certificates it issues. It is explicitly forbidden to use certificates issues by the NIKHEF CA under the ms X.509 policy in any way for financial transactions and for any kind of trade.

The NIKHEF CA will publish a list of certificates issues under the ms X.509 policy and a list of all such certificated that are revoked. Except for the data contained in the certificate itself, no personal data shall be published by the NIKHEF CA. Any additional data presented to the NIKHEF CA in the coarse of the authentication process may be verified, but will not be retained by the NIKHEF CA in the on-line repository. By requesting a certification from the NIKHEF CA, you grant permission to the NIKHEF CA to publish your certificate data in the aforementioned on-line repository (as meant by the Dutch `wet persoonsregistratie'). Identification data derived from official proofs of identity will not be retained (no passport number will be stored by the NIKHEF CA in any way). For identity checks performed by RAs or by personal introduction, the name of the introducing party will be recorded.

3.2 The NIKHEF CA certification hierarchy

The NIKHEF CA hierarchy contains one and only one Certification Authority. In order to facility the identification of persons requesting certificates in the participating institutes, Registration Authorities (RA's) may be appointed. These RAs will not sign the certificates themselves, but will forward the requests to the NIKHEF CA, after they have established the identity of the requester in accordance with the guidelines detailed in this document.
Multiple Certification Authorities with different distinguished names (DNs) may exist for different purposes and policies. The DN will make sufficiently clear with policy applies to the CA.

3.3 Registration Authorities

Registration Authorities (RAs) are trusted intermediaries that verify the identity of requesters and forward the requests to a certification authority. An RA itself does not certify requests. RAs are certified by the NCAO according to the same procedures that apply to regular end-users. Thy do not need a separate `RA' key.
The RA will verify the identity of the requester based on the policy outlines in section 5. He will make sure that the requester is currently affiliated to the organisation mentioned in the certificate request, that should correspond to the organisation to which the RA belongs. The verified request data will be passed by the RA to the NCAO. If this transfer is to be electronically, the message sent from the RA to the CA will be digitally signed. The NCAO should verify the signature to a satisfactory level.
The request should mention the kind of certification required.

Before appointing a RA, the Certification Authority will make sure that the candidate RA is aware of his responsibilities, that he has read the applicable policy documents and that he considers himself bound by the terms of the policy statement. The RA shall not retain any private data presented by the subject to the RA as part of the verification process.

4 Security

4.1 Protection of the NIKHEF CA

The following security demands will apply for the NIKHEF CA:

All cryptographic actions that involve the NIKHEF CA keys will be performed on a dedicated system
This system shall not have a network connection. Any exchange of information between the CA system and any other systems shall be by means of off-line data stores (like floppy disks, ZIP disks, CD's, etc.)
Media containing the certifying key(s) of the NIKHEF CA shall be stored in a safe place. In case of burglary, the keys may not be exposed: only a properly encrypted version may be present and the relevant passwords should be known only to NIKHEF CA personnel. This requirement extends to the NIKHEF CA dedicated system.
The certifying keys may only be used in person by the operators.
The public keys (e.g. RSA of Diffie-Hellman keys) used by the NIKHEF CA will have a key length of at least 2048 bits
The integrity of programs and data on the NIKHEF CA system will be periodically verified using cryptographically strong digests of all files, comparing them to previous versions. Relevant files will be backed up. These backups will have a retention time of at least three years.
The NIKHEF CA will cooperate with a security audit, when requested by a collaborating Certification Authority within the DataGrid project or by a participating organisation of DutchGrid.
The NIKHEF CA operates in a controlled environment, where access is restricted to authorised personnel and entrance and leave is monitored and logged.

4.2 Protection of Registration Authorities

The system used by the RA for activities related to his registration work should be adequately protected against abuse. Use of this machine by others is not permitted.
The key used by the the RA in his communication with the NIKHEF CA shall not be present on his system in an unencrypted form. Storage of the encrypted key on a removable medium is encouraged.
The key used by the RA shall have a length of at least 1024 bits.
The actual method used for securing the RA's system shall be documented. Later changes should be documented and announced.
The RA will cooperate with a security audit, when requested by the NIKHEF CA.

4.3 Protection of end-users

End-users applying for certification by the NIKHEF CA Organisation will comply with the following rules:

The secret keys pertaining to the certificate request shall be protected against abuse. They will not be transferred to other persons or organisations that do not correspond to the information presented in the certificate. Every end-users is individually responsible for this.
In order to be eligible for certification by the NIKHEF CA, the key length should be at least 1024 bits.
Storage of the secret key on removable media in encouraged.

4.4 Protection of certified entities (non-persons)

Non-personal entities can be certified by means of X.509 certificates (e.g. servers, Java applets, etc). In such cases it might be necessary to store the private key part of the certificate on-line. In these cases, the following rules apply:

the private part of the key may only be present on the system in encrypted form.
A server process using the private key part may only store it in unencrypted form in real memory. The server manager is obliged to enter the password protecting the private key personally.
For specific applications where this is not a viable option, the secret key may be stored unencrypted in a file that is readable only by the systems administrator (e.g. root). Only certificates with a distinguished name that includes /O=hosts/ may be stored in this way. In particular, keys beloging to certificates within the /O=server/ hierarchy may not be stored this way.
the user policy on certified server machine should prevent unauthorised access to the private keys pertaining to certificates.
The key length should be at least 1024 bits.

5 Certification Rules

This section describes the procedures for certification of persons and systems.

As described in section 8, the certificate requests (and certificates) should comply with certain naming rules. The real names or persons, organisations or other entities are part of these naming rules.
All certificate requests should be generated by the users themselves.
the private part of the key should be protected by a strong password of at least 8 (eight) characters in length.
The user should generate his own key-pair. The private part of the key should not be disclosed to the CA.

No automatic processing of certificate requests is allowed under the m.s. X.509 policy.

Certificates will be issues under the NCAO m.s. X.509 policy only after both the identity and the affiliation have been verified by the CA. There are several possibly verification methods:

5.1 For persons directly affiliated to participating DutchGrid organisations

When an RA has been appointed at the end-users institute, certification requests can only be issues to the NIKHEF CA via the assigned RA. In case no RA has yet been appointed, end-users may request certification directly at the NIKHEF CA.
The RA or the NIKHEF CA will certify the request, only after the identity has been established by:

for anyone: presenting an officially recognised identity card, containing a photograph, in person to the RA or CA, or
by a person officially affiliated to the institute (by being listed in an publicly issued phone book or by written confirmation of affiliation by a pre-certified person in said organisation, personally known to the CA): after out-of-band contact (e.g. by voice phone or by facsimile) has confirmed the issue of a request.

and only after the affiliation to the organisation mentioned in the request by:

presenting a written proof of affiliation, no more than two month old (e.g. a salary specification) or a written statement by the director of the organisation mentioned.
by being listed in a recent official publication by said organisation, e.g. a phone book.
by having a pre-certified, trusted person inside said organisation testify by out-of-band communication (phone or facsimile) the claimed affiliation.

The RA of CA may verify the possession of the private key part pertaining to the request by sending an encoded challenge to the requester.

5.3 For non-personal entities affiliated to DutchGrid organisations

A certificate for non-personal entities (e.g. web-servers) implies that the NCAO certifies that the server or program was, at the time of certification, being maintained by the organisation mentioned in the certificate. This affiliation is verified by out-of-band communication between the RA or CA and a pre-certified person affiliated to the organisation involved. The NIKHEF CA will not issues `wild card' certificates on the the m.s. X.509 policy.

5.3 For persons and entities not affiliated to the DutchGrid organisations

The NCAO will not issue certificates to such persons or entities.

5.4 Validity

The validity of certification for persons and non-personal entities is at most 1 year.

6 Certificate publication and Operational Requirements

The NIKHEF CA Organisation will publish its certificate and a signed list of revoked certificates (CRL). The NCAO will publish a list of names of certificates signed by the NCAO and a list of names of certificates revoked by the NCAO.
This publication will be on a publicly available server, accessible via HTTP (Web). The NCAO will publish the certificates issues to end-users publicly to enable secure message exchanges, but the list will not contain electronic mail addresses unless part of the public certificate data as requested by the subject.

Newly signed certificates will be sent to the original requester. In case of a request received electronically, the certificate will be sent to the mail address specified in the reply-to header field. When this field is not present, the certificate will be sent to the address of the sender.

When the original request was received by other means, a suitable return path will be chosen.

6.1 Certification Records

The NIKHEF CA will keep records of the following events:

certification requests
certificates issued
CRL's issued
any electronic mail sent to the NIKHEF CA
any electronic mail sent by the NIKHEF CA

Such records are kept for a period of at least three years.

6.2 CA key compromise and CA termination

If the CA's private key is compromised or suspected to be compromised, the NIKHEF CA will inform the end-users known to the NIKHEF CA, all cross-certifying CAs, and all certified persons and entities.

Before termination of services by the NIKHEF CA, it will inform the end-users known to the NIKHEF CA, all persons and entities currently holding a valid NIKHEF CA certificate. It will publicly announce termination of its services and stop issuing certificates and CRL.

7 Certificate revocation

The NIKHEF CA may revoke certificates before their expiration date. Such revocation might be triggered by:

loss of the certified private key
failure to comply with this medium-security X.509 policy
disappearance of the certified person or entity from the organisation mentioned in the certificate.

In the following cases, instant revocation by the NIKHEF CA is mandatory:

abuse of certification
apparent compromise of the private key
failure to comply with this policy after relevant warning by the RA or CA.

Besides, the legitimate owner of a certified key can request revocation, without stating reasons. The NIKHEF CA will honour such a request immediately, but only after the NIKHEF CA has sufficiently verified that the requester is the same person as the one that originally requested certification.

Certificate Revocation Lists (CRL) are issues whenever a certificate is revoked, but at least every one month.

8 Naming conventions

All certificates issued by the NIKHEF CA should have clear and unambiguous names. Aliases are not allowed. Organisations should be mentioned using either their official or current name. The key of a certification authority shall be recognisable as such, preferably by including the abbreviation `CA' in its common name.

Certificates signed by the NIKHEF/DutchGrid CA should start with a top-level organisation name `/O=dutchgrid/', followed by an identification of the entity (`O=users' or `O=hosts' -for globus hosts or `O=servers' for (web)servers), followed by the name or the organisation and the common name of the requester or entity. For persons, an electronic-mail address may be included but is not compulsory.

Examples of possible distinguished named:

/O=dutchgrid/O=users/O=UvA/OU=wins/CN=Zeger Hendrikse
/O=dutchgrid/O=users/O=NIKHEF/CN=David Groep
/O=dutchgrid/O=hosts/OU=amolf.nl/CN=macro3.amolf.nl
/O=dutchgrid/O=servers/O=NIKHEF/OU=Virtual Lab Project/CN=vlabwww.nikhef.nl
/O=dutchgrid/O=hosts/OU=nikhef.nl/CN=host/polyeder.nikhef.nl

8.1 Certificate Contents

The NIKHEF CA issues X.509v3 certificates. Its purpose field will reflect the allowed usage: SSL client/server, S/MIME signing and encryption, and Netscape SSL server when relevant. When needed by applications of the certificate, purpose `Any' may be assigned. Every certificate will contain a URI reference to the relevant policy document.

9 Obligations of users of the NIKHEF CA

Persons, organisations or entities are only allowed to make use of the certificates issued by the NIKHEF CA if they comply with the following rules:

they must read and understand the policy as describe din this document,and feel themselves bound by its conditions
no kind of financial transaction of transaction representing direct financial value may be conducted using certificates issued by the NIKHEF CA
users of the NIKHEF CA will periodically retreive the Certificate Revocation List issued by them NIKHEF CA and implement the restrictions implied by this CRL
certified users or persons responsible for certified entities will inform the NIKHEF CA immediately when compromise of the associated private key part is suspected.

10 Change Log

1.2 to 1.3: allowed keys for certs within /O=hosts/ to be stored unencrypted.
1.3 to 1.4: extented the validity period of this policy to December 2001. Made explicit the requirement for RA's to destroy any private data used in the validation process. The NCAO will now disclose also the certificates themselves in a web-accessible repository (as was already allowed for but not used in version 1.2). Updated web-references to certificate.nikhef.nl. 1.4 to 1.5: corrected error in version numbering in section 10 (off-by-one).

David Groep <davidg@nikhef.nl>