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 $
On-line reference: http://certificate.nikhef.nl/
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
2 The NIKHEF CA
Mailing address: NIKHEF, c/o David Groep, P.O. Box 41882, NL 1009
DB Amsterdam, The Netherlands.
Internet e-mail: firstname.lastname@example.org
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
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:
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.
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.
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
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.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
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
the private part of the key may only be present on the system in encrypted
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.
No automatic processing of certificate requests is allowed under the m.s.
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.
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:
and only after the affiliation to the organisation mentioned in the request
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.
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.
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
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.
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
5.3 For persons and entities not affiliated to the DutchGrid organisations
The NCAO will not issue certificates to such persons or entities.
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:
Such records are kept for a period of at least three years.
any electronic mail sent to the NIKHEF CA
any electronic mail sent by the NIKHEF CA
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:
In the following cases, instant revocation by the NIKHEF CA is mandatory:
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.
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.
abuse of certification
apparent compromise of the private key
failure to comply with this policy after relevant warning by the RA or
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=servers/O=NIKHEF/OU=Virtual Lab Project/CN=vlabwww.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
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
1.4 to 1.5: corrected error in version numbering in section 10 (off-by-one).
David Groep <email@example.com>