This document is an Authentication Profile (AP) of the
International Grid Trust Federation (IGTF). This AP defines traditional X.509 Public Key Certification Authorities
(traditional PKI CAs) that issue long-term credentials to end-entities, who
will themselves posses and control their key pair and their activation data.
These PKI CAs act as a independent trusted third party for both subscribers and
relying parties within an infrastructure.
authorities will use a long-term signing key, which is stored in a secure
document, the key words `must', `must not', `required', `shall', `shall not',
`should', `should not', `recommended', `may', and `optional' in this document
are to be interpreted as described in RFC 2119.
There should be a single Certification
Authority (CA) organisation per country, large region or international
organization. The goal is to serve the largest possible community with a small
number of stable CAs. To achieve sustainability, it is expected that the CAs
will be operated as a long-term commitment by institutions or organisations
rather than being bound to specific projects.
The CA structure within each region should not
follow the conventional hierarchical model, but there should be a single
end-entity issuing CA. A wide network of Registration Authorities (RA) for each
CA is preferred. The RAs will handle the tasks of validating the identity of
the end entities and authenticating their requests, which will then be
forwarded to the CA. The CA will handle the actual tasks of issuing CRLs,
signing Certificates/CRLS and revoking Certificates.
Any single subject distinguished name must be
linked to one and only one entity. Over the entire lifetime of the CA it must
not be linked to any other entity.
It is not contrary to the above requirement for
a single entity to have more than one associated subject name, e.g., for
different key usages.
Certificates must not be shared among end
A PKI CA must define the role of registration authority (RA),
and these registration authorities are responsible for the identity vetting of
all end-entities, such as natural persons and network entities.
In order for an RA to validate the identity of
a person, the subject should contact the RA face-to-face and present photo-id
and/or valid official documents showing that the subject is an acceptable end
entity as defined in the CP/CPS document of the CA.
In case of host or service certificate
requests, the RA should validate the identity of the person in charge of the
specific entities using a secure method.
The RA should validate the association of the
certificate signing request.
The RAs must record and archive all requests
The CA is responsible for the continued archival and
audit-ability of these records.
The RA must communicate with the CA with secure
methods that are clearly defined in the CP/CPS. (e.g. Signed emails, voice
conversations with a known person, SSL protected private web pages that are
accredited authority must be removed from list of accredited authorities under
this profile if it fails to comply with this authentication profile document,
or with the IGTF Federation Document, via the voting process described in the
Charter of the PMA to which this authority is accredited.
The CA computer, where the signing of the
certificates will take place, needs to be a dedicated machine, running no other services than those needed for
the CA operations. The CA computer must be located in a secure environment
where access is controlled, limited to specific trained personnel and must be
kept disconnected from any kind of networks at all times. In case the CA
computer is equipped with at least a FIPS 140-2 level 3 Hardware Security
Module or equivalent, to protect the CA’s private key, the CA computer can be
connected to a highly protected/monitored network, possibly accessible from the
Internet. The secure environment must be documented and that document or an
approved audit thereof must be available to the PMA.
The CA Key must have a minimum length of 2048
bits and for CAs that issue end-entity certificates the lifetime must be no
less than two times of the maximum life time of an end entity certificate and
should not be more than 20 years.
The private key of the CA must be protected
with a pass phrase of at least 15 elements and that is known only by specific personnel of the Certification Authority, except in
the case of an HSM where an equivalent level of security must be maintained.
Copies of the encrypted private key must be kept on offline mediums in secure
places where access is controlled.
Every CA must have a Certification Policy and
Certificate Practice Statement (CP/CPS Document) and assign it a globally
unique object identifier (OID). CP/CPS documents should be structured as
defined in RFC 3647. Whenever there is a change in the CP/CPS the OID of the
document must change and the major changes must be announced to the accrediting
PMA and approved before signing any certificates under the new CP/CPS. All the
CP/CPS under which valid certificates are issued must be available on the web.
The accredited authority must publish a X.509 certificate as
a root of trust.
certificate must have the extensions keyUsage and basicConstraints marked as
The authority shall issue X.509 certificates to end-entities
based on cryptographic data generated by the applicant, or based on
cryptographic data that can be held only by the applicant on a secure hardware
The EE keys must be at least 1024 bits long.
The EE certificates must have a maximum lifetime of 1 year plus 1 month.
The end-entity certificates must be in X.509v3
format and compliant with RFC3280 unless explicitly stated otherwise. In the
a Policy Identifier must be
included and must contain an OID and an OID only
CRLDistributionPoints must be
included and contain at least one http URL
keyUsage must be included and
marked as critical
basicConstraints should be
included, and when included it must be set to ‘CA: false’ and marked as
if an OCSP responder, operated
as a production service by the issuing CA, is available, AuthorityInfoAccess
must be included and contain at least one URI
for certificates bound to
network entities, a FQDN shall be included as a dnsName in the
commonName component is used as part of the subject DN, it should contain an
appropriate presentation of the actual name of the end-entity.
must be compliant with RFC3280, and can be either version 1 or version 2.
The message digests of the certificates and
CRLs must be generated by a trustworthy mechanism, like SHA1 (in particular,
MD5 must not be used).
The CA must publish a CRL. The CA must react as
soon as possible, but within one working day, to any revocation request
received. After determining its validity, a CRL must be issued immediately. For
CAs issuing certificates to end-entities, the maximum CRL lifetime must be at
most 30 days and the CA must issue a new CRL at least 7 days before expiration
and immediately after a revocation. The CRLs must be published in a repository
at least accessible via the World Wide Web, as soon as issued.
Revocation requests can be made by
end-entities, Registration Authorities and the CA. These requests must be
properly authenticated. Others can request revocation if they can sufficiently
prove compromise or exposure of the associated private key.
End-entities must request revocation if the
private key pertaining to the certificate is lost or has been compromised, or
if the data in the certificate are no longer valid.
When the CA’s cryptographic data needs to be
changed, such a transition shall be managed; from the time of distribution of
the new cryptographic data, only the new key will be used for certificate
signing purposes. The overlap of the old and new key must be at least the
longest time an end-entity cert can be valid. The older but still valid
certificate must be available to verify old signatures – and the secret key to
sign CRLs – until all the certificates signed using the associated private key
have also expired.
section 2.8; modified]
The pass phrase of the encrypted private key
must be kept also on an offline medium, separated from the encrypted keys and
guarded in a safe place where only the authorized personnel of the
Certification Authority have access. Alternatively, another documented
procedure that is equally secure may be used.
Each authority must publish for their subscribers, relying
parties and for the benefit of distribution by the PMA and the federation
a CA root certificate or set of CA root
certificates up to a self-signed root;
a http or https URL of the PEM-formatted CA
a http URL of the PEM or DER formatted CRL;
a http or https URL of the web page of the CA
for general information;
the CP and/or CPS documents;
an official contact email address for inquiries
and fault reporting
a physical of postal contact address
The CA should provide a means to validate the integrity of
their root of trust.
Furthermore, the CA shall provide their trust anchor to a
trust anchor repository, specified by the accrediting PMA, via the method
specified in the policy of the trust anchor repository.
The repository must be run at least on a
best-effort basis, with an intended continuous availability.
The originating authority must grant to the PMA and the
Federation – by virtue of its accreditation – the right of unlimited
re-distribution of this information.
The CA must record and archive all requests for
certificates, along with all the issued certificates, all the requests for
revocation, all the issued CRLs and the login/logout/reboot of the issuing
The CA must keep these records for at least three years.
These records must be made available to external auditors in the course of
their work as auditor.
Each CA must accept being audited by other
accredited CAs to verify its compliance with the rules and procedures specified
in its CP/CPS document.
The CA should perform operational audits of the
CA/RA staff at least once per year. A list of CA and RA personnel should be
maintained and verified at least once per year.
Accredited CAs must define a privacy and data release policy
compliant with the relevant national legislation. The CA is responsible for
recording, at the time of validation, sufficient information regarding the
subscribers to identify the subscriber. The CA is not required to release such
information unless provided by a valid legal request according to national laws
applicable to that CA.
The CA must have an adequate compromise and disaster recovery
procedure, and we willing to discuss this procedure in the PMA. The procedure
need not be disclosed in the policy and practice statements.
The CA should make a reasonable effort to make
sure that end-entities realize the importance of properly protecting their
private data. It’s upon the user to protect his private key with a pass phrase
at least 12 characters long.