1
Introduction
The Hellenic
Academic community (22 Universities and 16 Technological Educational
Institutions - TEI), have established the Greek Universities Network GUNet S.A.
Among GUnet’s goals is the provision of network services to its members and any
third party (organizations, institutes, foundations) involved with education
and research
activities.
According
to a mutual understanding and agreement between the Greek Research and
Technology Network (GRNET), the Academic Network (GUNet), the Aristotle
University of Thessaloniki, the Agricultural University of Athens, the
Democritus University of Thrace, the National Center for Research and
Technological Development, the National Documentation Center, the National
Technical University of Athens, the Ionian University, the University of the Aegean,
the University of Thessaly, the University of Ioannina, the University of
Crete, the Technical University of Crete, the TEI of Athens, Kalamata, Crete,
Lamia, Messolonghi, Serres and other agencies of the Greek Academic and
Research Community who will sign a Memorandum of Understanding (MoU), a Public
Key Infrastructure (PKI) is created which will subsequently be referred to as the
Hellenic Academic & Research Institutions Certification Authority (HARICA)
acting as a Certification Services Provider (CSP). The memorandum is published
on the website http://www.harica.gr/procedures. The development and initial operation
of the service began as part of the Virtual Network Operations Center (VNOC) project,
funded by the National Research Network - GRNET and continues under the
supervision and funding of GUNet. Organizations
involved in this Public Key Infrastructure unconditionally accept this Certificate
Practice Statement / Certificate Policy and co-sign the previously mentioned Memorandum.
This Certification Policy and Certification Practice
Statement, describes the set of rules and procedures concerning digital
certificates within the HARICA Public Key Infrastructure.
The HARICA Certification Authority issues User Certificates,
Network Device Certificates (e.g. Servers, routers etc.) and Subordinate
Certification Authority Certificates. All certificates contain a reference to
this document. Certificate owners and relying parties, must be aware of this
policy document and must comply with its statements.
This document is called «Certification Policy and
Certification Practice Statement of HARICA Public Key Infrastructure» and constitutes
the documentation and regulatory frame of HARICA Public Key Infrastructure. In
abbreviation, it will be refereed as “HARICA CP-CPS”.
The Certification Policy’s purpose is to determine, document
and make known to all interested entities (e.g. members of the academic
community, collaborators, third-party entities that rely on the provided
services, other organizations, Institutions and Authorities) the terms and the
operational practices that are applied or govern the Certification Services
that HARICA provides.
The structure of this document is based on IETF RFC-3647
with the minimum necessary changes in order to reflect the particular needs of the
Academic community.
The globally unique Identification Number (OID) of this
document is: 1.3.6.1.4.1.26513.1.0.2.6 where:
|
1.3.6.1.4.1.26513
|
Identification
Number (OID) of HARICA, registered to IANA (www.iana.org)
|
|
1
|
Certification
Services Provision
|
|
0
|
Certification
Practice Statement
|
|
2.6
|
First
and Second digit of the version number of the Certification Practice
Statement
|
The entities that use digital certificates issued by HARICA
Public Key Infrastructure constitute the community governed by this Certification
Policy and Certification Practice Statement.
Certification Authorities (CAs) are the entities of the
Public Key Infrastructure responsible for issuing certificates. Every
Certification Authority utilizes one or more Registration Authorities (RAs).
RAs provide the means of communication between the users and the corresponding
Certification Authority.
The hierarchy of the Certification Services Provider is
constituted by the following entities:
1. Root Certification Authority (HARICA-ROOT-CA) which issues
digital certificates exclusively for Subordinate Certification Authorities that may operate in other
academic institutions or other organizations and does not issue certificates to
end users. As an exception, it is allowed to only issue a
certificate for the OCSP responder according to RFC2560 and draft-cooper-pkix-rfc2560bis-00.txt
(see Figure 7 of the draft: “Designated OCSP Responder and CA with Two Keys
Certified by Root CA”).
The validity period of HARICA-ROOT-CA certificate is twenty
(20) years.
2. Subordinate Certification Authorities of HARICA that operate
in administrative units of GRNET, GUnet or other academic institutions that comply
with and fully adopt this Certification Policy and Certification Practice
Statement. The validity period of the certificates of the Subordinate
Certification Authorities is ten (10) years. The subordinate CAs that
come initially into operation, certify entities that belong to HARICA
(HARICA-Administration-CA). They issue certificates for users and
servers/devices of HARICA, but not for entities of other institutions. In case
HARICA receives requests for entities of other Institutions, the relevant
subordinate Central Certification Authorities will be created for each
Institution. The creation of more than one subordinate CA is possible, e.g. the
creation of the CAs (<Institution>-SUBSCRIBERS-CA and
<Institution>-SERVERS-CA), that will issue the requested certificates but
they will be signed by the Central CA of the Institution. These CAs may be operated
by the Institution itself or outsourced to HARICA.
Registration Authorities (RA) are entities responsible for identity
validation of all applicants before the issuance of the certificate. They transfer
the requests to the particular Certification Authority in a secure manner.
GUnet is the central Registration Authority of HARICA and apply strict procedures
for users’ authentication.
PKI Subscribers are entities who request and successfully
acquire a digital certificate signed by HARICA or any subordinate CA. Subscribers
can be persons or devices that have a relationship with organizations within
the Hellenic academic, research and educational community.
The subscription of roles (e.g. ‘Rector’) or persons
that are not real, apart from network devices or
services, is neither explicitly foreseen in the current
document nor forbidden. The issuance of ‘role certificates’ is possible by a
subordinate CA of an Institution, provided that the relevant procedure is
described in the CP/CPS of the corresponding subordinate CA and that this
procedure does not conflict with any condition of the current document.
The entities that trust the provided certification services
or otherwise called the Relying Parties or simply ‘users’ of the certification
services can be any entity, inside or outside the Hellenic academic community,
which uses in any way the certification tokens (digital certificates, digital
signatures, time stamps etc) and relies on the information that they contain.
In particular, entities that trust the Certification
Services Provider (CSP) are the persons or legal entities who, after being
informed and having agreed with the terms and conditions concerning the use of the
certificates as described in the present document and the relative certificate policy,
and after having checked and verified the validity of a certificate that has
been issued by the CSP of HARICA PKI, they decide whether they can rely on the
content of this certificate in order to proceed to specific actions or justified
belief.
In order to verify the validity of the certificate, the user
must check that:
Ö
The validity period of the certificate has begun and has not
expired.
Ö
The certificate is correctly signed by a Trusted Certification
Authority.
Ö
The certificate has not been revoked for any reason.
Ö
Subject identification matches the details that the signer
presents.
Ö
The usage for which the certificate is presented and is according
to the reason it was issued by the CA.
Ö
Abides by the terms and the conditions that are described in the
present Certification Practice Statement.
Not specified.
The certificates can be used by the members of the wider
academic and research community and other parties as described in paragraph 1.3.
The certificates can be used only for academic and research
purposes, in all network services and applications in which the required level
of security is equal or lower than that of the certificate issuance process.
Typical applications in which digital certificates issued by
the Certification Services Provider Service, can be used, are the following
(the list is not restrictive):
a) Signing of an “electronic document” by a person using her/his
digital certificate and the relevant private key, preferably with the use of a
“secure mechanism for signature creation” (e.g. smart card or e-token), so that
at least the following characteristics are ensured: 1) the authenticity of
origin, 2) the integrity of the signed document i.e. that its content has not
been modified since the time of its’ signature and 3) the binding of the signer
to the content of document and the non-repudiation of signature.
b) Signing of e-mail messages, as a proof of authenticity of
the sender’s address and for all the attributes described in (a). Moreover,
they can be used for the purpose of secure proof of receipt of messages
(non-repudiation of receipt).
c) Persistent proof of identity (Strong Authentication) of a
person or a device throughout communication with other entities, guaranteeing
high level security characteristics, stronger than the ones provided by the password-based
access control method.
d) “Encryption of documents and messages” with the use of
the recipient’s public key, ensuring that only she/he, the holder of
corresponding private key, can decipher and read the document or the message.
e) Certification of other Certificate Services Providers such
as a Subordinate CA or other additional services of certification, e.g.
time-stamping, digital notarization and long-term secure preservation of data.
f) In the implementation of secure network protocols, such as
SSL, DNSsec, IPSec etc.
Certificates cannot be used for commercial, financial, legal
or any other transactions that are not included in the first paragraph of section
1.4.1.
ca-admin@harica.gr
Greek University Network GUnet
National and Kapodestrian University of Athens. – Network Operations Center
University Campus 157 84
Tel: +30-210 7275611
Fax: +30-210 7275601
ca@harica.gr
Dimitris Zacharopoulos [jimmy@ccf.auth.gr]
Dimitris Daskopoulos [dimitris@ccf.auth.gr]
Spiros Bolis [sbol@noc.uoa.gr]
Hellenic Academic and Research Institutions Certification
Authority
Greek University Network GUnet
National and Kapodestrian University of Athens. – Network Operations Center
University Campus 157 84
Tel: +30-2310 998483, +30-2310 998435
Fax: +30-2310 998492
cp@harica.gr
Dimitris Zacharopoulos [jimmy@ccf.auth.gr]
Dimitris Daskopoulos [dimitris@ccf.auth.gr]
Spiros Bolis [sbol@noc.uoa.gr]
Certification Authority Management
Greek University Network GUnet
National and Kapodestrian University of Athens. – Network Operations Center
University Campus 157 84
Tel: +30-2310 998483, +30-2310 998435
Fax: +30-2310 998492
The CP/CPS is approved by the members that participate in
HARICA according to the “Memorandum of Cooperation” that can be found at the
website http://www.harica.gr/procedures.
|
Long
Term
|
Short
term
|
|
Object
Identifier
|
OID
|
|
Registration
Authority
|
RA
|
|
Policy
Certification Authority
|
PCA
|
|
Certification
Authority
|
CA
|
|
Certification
Practice Statement
|
CPS
|
|
Distinguished
Name
|
DN
|
|
Trusted
Third Party
|
TTP
|
|
Hierarchic
Certification Structure
|
HCS
|
|
CommonName
|
CN
|
|
Certificate
Revocation List
|
CRL
|
|
Certification
Trust List
|
CTL
|
|
OrganizationName
|
O
|
|
Organizational
Unit
|
OU
|
|
CountryName
|
C
|
|
Certification
Policy
|
CP
|
|
Public
Key Infrastructure
|
PKI
|
|
Online
Certificate Status Protocol
|
OCSP
|
|
Public-Key
Cryptography Standards
|
PKCS
|
|
Secure
Socket Layer
|
SSL
|
|
Uniform
Resource Identifier
|
URI
|
The HARICA PKI has a central data repository where policy
documents, certificates of Certification Authorities and certificates of
subscribers/devices are published. Distributed repositories may exist for each subordinate
Certification Authority / Registration Authority that participates in the PKI.
The HARICA PKI maintains a repository accessible through the
Internet in which it publishes the Digital Certificate of the Root
Certification Authority (type X.509.v3), the Digital Certificates that are issued
according to the Certification Practice Statement, the current CRL, the
document of Certification Policy / Certificate Practice Statement and other documents
regarding its operation (e.g. Cooperation agreements).
The CA performs all the necessary actions for the
uninterrupted - as possible - availability of its repository.
The HARICA PKI repository address is http://www.pki.auth.gr/rep_dyn.
Moreover, the storage and search of certificates and CRLs is
possible using the directory service of HARICA or that of the participating
institutions.
The CRL is updated according to the paragraph 4.9.7.
The certificates issued by the CA are being published after
their retrieval from the subscriber.
The repository section containing the certificates is publically
available through a search web page. The search is performed either by entering
the certificate serial number (therefore a single certificate is returned), or
by entering part of the distinguished name of the certificate subject,
therefore a list of certificates is likely to be returned.
Restrictions may be applied to the repository access to
protect it against enumeration attacks.
3
Identification and
Authentication
The names that are used for certificate issuance depend on
the class of the certificate and they are according to the X.500 standard.
The user certificates must include the full name of the
user, his electronic address (according to rfc822), the name of institution she/he
belongs to, and the abbreviation of her/his country.
Optionally, additional fields may be included, such as the
organizational unit the user belongs to and her/his location.
Certificates that are issued for appliances (server, router
or any other network device) must include the complete distinguished name of
the appliance according to the Domain Name System (FQDN DNS), the name of
institution it belongs to, and the abbreviation of the country. The certification
of IP addresses or hostnames instead of the FQDNs is not allowed.
Optionally, additional fields may be included, such as the
organizational unit the device’s location.
3.1.1.3
Code Signing certificates
Code Signing certificates are provided through user
certificates described in section 3.1.1.1. The user, in addition to the general
terms-and-conditions of simple user certificates, is committed (via an
appropriate extra RA agreement) to provide complete, accurate and truthful
information (eg, application name, information URL, application description,
etc.) in the digitally signed code.
The digital signing of malicious code (malware) is expressly
prohibited.
Failure by a Subscriber to comply may result in revocation
of the code signing certificate.
The names that are included in the user certificates must be related to the
subscriber / recipient of the certificate.
The HARICA PKI does not allow certificate issuance for
anonymous users. The certificate issuance for pseudonyms eg “Rector” is not
provided in the present Certification Practice Statement but also it is not
prohibited. A special purpose intermediate Certification
Authority can be created for these types of distinguished names.
3.1.4
Rules for
interpreting various name forms
The names are composed according to the certificate type.
The subscriber’s name that is composed according to the rules of the current
section is called Distinguished Name (DN).
Regarding the user certificates, the field that includes the
name of a user corresponds to the characteristic “CN”, the e-mail to “E”, the
institution in which it belongs to “O” or/and “OU”, the country to “C” and
optionally the locality in which it is found to “L”. It is preferable to adapt
to the naming conventions used by the national directory service (today hosted
at ds.grnet.gr). The HARICA User Certificates must include the characteristic
“C=GR” in the Distinguished Name.
The name of the device certificate (FQDN DNS) corresponds to
the characteristic «CN», the name of institution the device belongs to the
characteristic «O» and/or «OU», the country the device is located in to the
characteristic «C» and optionally the locality is found to the characteristic
«L». Device Certificates must include the characteristics “C=GR” in the
Distinguished Name.
The Distinguished Name of a subscriber bearing attributes of
a specific institution must be unique for the particular CA that issues the
certificate, while it is desirable to be unique in the entire hierarchy of
certification of HARICA. The issuance of more certificates with the same DN is
allowed only in case of different class or certificate usage.
The regulatory body for matters concerning disputes about
naming property rights HARICA PKI is the HARICA members General Assembly.
The Registration Authority must verify that the alleged subscriber
really possesses the private key that corresponds to the public key of the
about-to-be-issued certificate. This is achieved with the following process:
- The identity
of the subscriber is authenticated.
- An application
for certificate issuance is submitted. The application contains the public
key of the subscriber and has been signed with the private key of
subscriber
- The key
matching is verified.
3.2.2
Authentication of
organization identity
The Registration Authority must confirm that the subscriber
belongs to the Institution, the name of which is included in the certificate. The subscriber must:
a) be
registered in the official directory service of her/his Institution and her/his
Institution must appear in this record, or
b) Possess
an electronic mail address in the official mail service of the Institution and the
administration of her/his Institution confirms its relationship with the
subscriber.
The certificates of individuals that are issued by the
HARICA PKI must be checked for identification. There are two classes of user
certificates. Class A includes certificates whose private key is generated and
resides in a secure cryptographic device (eToken or smartcard) and are issued
under the presence of authorized personnel of the RA. Class B includes
certificates whose private key has been generated using some software (software
certificate store). Note that there is a secure identification of the recipient
with her/his physical presence and an acceptable official document proving his
identity in both classes of certificates.
The Registration Authority relies on the control of identity
performed by the institutions the subscriber belongs to and uses authentication
ways of user identities that are available in the institutions in order to
check the identity. The collaborating institutions are compelled to have
certified the identity of a user by means of an official document that bears
the photograph of the beneficiary (eg police identity, passport, driving
license, student identity card) and which is considered reliable by the
familiar institution. Alternatively, the RA of HARICA can execute the above
process of applicant identification.
In case the familiar institution of the user, according to
its policy, has already performed a procedure of physical identity verification
in the past (e.g. for the provision of a user account or e-mail address) there
is no need to repeat the procedure but a typical confirmation through the
officially certified e-mail address of the user is sufficient.
HARICA central RA uses two methods
for e-mail ownership and control verification:
- The first method uses simple
e-mail verification. The user enters the e-mail address at the initial
certificate request form and a verification e-mail is sent to the user
with a link to a unique web page. After following this link, an e-mail is
sent to the institution's network operation center mail administrator that
requires an approval based on the full name entered by the user and the
user's email. This approval requires the identification of the user with
his/her physical presence and an acceptable official document. If this
procedure took place before (e.g. for the creation of an e-mail account)
then there is no reason to be repeated.
- The second method uses an LDAP
server. The user enters the personal e-mail address at the initial
certificate request form and the corresponding password. This information
is verified against the institution's LDAP server. If the verification is
successful, the RA queries the real name of the user and creates the
certificate request. In order for a user to be listed in the Institutional
Directory server, the institution must have verified the user with his/her
physical presence and an acceptable official photo-id document.
Certificates of Class A are recommended to include an extra
organizational unit (OU) in the subject field with the value ‘Class A – Private
Key created and stored in hardware CSP’. Certificates of Class B are
recommended to include an extra organizational unit (OU) in the subject field
with the value ‘Class B – Private Key created and stored in software CSP’.
The individual who is in charge of the operation of the
device and its conformity to the Certification Policy should possess a
certificate which was issued by a CA that conforms to the “HARICA Certification
Practice Statement/ Certification Policy”.
The subscriber submits the application for a device
certificate on a web interface where she/he must be authenticated presenting her/his
personal certificate. The issuance of a certificate for a device owned by an
institution other than the institution of its administrator, is not allowed.
HARICA central RA uses the following methods for device ownership
verification. First of all, issuance of an SSL/TLS certificate is only allowed
for domains belonging to each institution. Secondly, in order for a user to
apply for an SSL/TLS device certificate he must own a user certificate which
proves his identity. Then a verification e-mail is sent to an institution's
network operations center designated administrator who verifies the validity of
the FQDN of the certificate request. He also checks that the person who applied
for the certificate is the rightful owner of the FQDN according to the
institution's database of users / servers.
The certificates that are issued do not include non-verified
subscriber information.
The Registration Authorities determine procedures according to
which the subscriber’s status and his conventional relationship with the
institution, are being verified. This is possible either with electronic lists assembled
by each RA from the qualified - for each category- sources (e.g. secretariats
of departments /faculties, institution’s central registry etc.), or by presenting
official certificates where the relationship of the subscriber with the
institution is certified.
Not defined.
The user can request the issuance of a Re-key/Certificate fifteen
(15) days before the expiration of the existing valid certificate, following
the described procedures in chapter 3.2.
The user can request the issuance of a Re-key after the
revocation of the initial section, following the described procedures in section
3.2.
As stated in paragraph 3.2.3. Moreover, the CA and the
subscriber agree to a secret revocation code during the retrieval of the
certificate. The subscriber can require the revocation of the certificate
through the appropriate web interface, using the revocation secret code.
Alternatively, a certificate revocation can be asked by the subscriber making a
call to the appropriate Certification Authority therefore his identity must be
verified.
Applications for certificate issuance may be submitted only
by the subscribers as described in paragraph 1.3.3.
The certificate DN of an applicant must be according to
section 3.1. The validation of a user identity must be performed according to
section 3.
Subscribers may submit the application for the issuance of a
certificate through the web page of the Registration Authority, http://www.harica.gr/, or through the
Registration Authority of her/his own institution.
The processing of the applications is based on what is
outlined in section 3.2. All certificate applications are checked for validity.
The subscriber’s identity and official relationship with the institution are
also checked.
After all identity and attribute checks of the applicant, the
content of the application for the digital certificate is also checked. In case
the applicant is not eligible for a digital certificate or the digital
application contains faults, the application is rejected. Otherwise the
application is approved.
The certificate applications are processed within a period of ten
(10) business days maximum, apart from the cases of force majeure.
The certificates are published after the secure transmission
of applications from the Registration Authority to the Certification Authority
and after the verification of the DN of the certificate. The DN of the
certificate of the applicant must agree with the specifications outlined in
section 3.1.
The Certification Authority informs the subscriber about the
success or rejection of the publication of certificate via e-mail. In the same e-mail
message, provided that the application is accepted, a unique URI is sent to the
subscriber who must accept the terms and services of HARICA PKI before
accepting and receiving the issued certificate.
The HARICA PKI subscribers must accept (retrieve and install
through a secure webpage) the new certificate within thirty (30) days,
otherwise the certificate is cancelled and the subscriber must repeat the
application process. The subscribers must declare on the
secure webpage that they have checked all certificate elements and that they
are correct, in order to retrieve their certificate. Finally, they accept and
receive the certificate.
All CAs publish the certificates only after they have been
retrieved by the owners according to section 4.4.1.
No action is taken for the notification of other entities
other than what is stated in section 9.16.
The HARICA PKI subscribers are allowed to use their private
keys and certificates for the usages stated in section 6.1.7.
Relying parties can use the HARICA PKI subscribers’ public
keys and certificates following what was stated in section 1.3.4. The
operations they can execute are:
Ø
Verification of digitally signed e-mail messages using the S/MIME
protocol
Ø
Encryption of e-mail messages using the S/MIME protocol
Ø
Verification of digitally signed documents/application code
Ø
Verification of digital timestamps in documents
Ø
Encryption of files, data and communication channels
Ø
Authentication
Ø
Authorization
Certificate renewals are allowed provided that the key
lifetime of the certificates is not exceeded. Furthermore, everything listed in
section 1.3.3 applies. The lifetimes are stated in section 6.3.2.
The renewal request is submitted by the subscriber wishing renewal
through a secure web page after authentication.
Ø
Initially, a check whether renewals of the same certificate were
made in the past takes place.
Ø
Afterwards a check whether the certificate or the certificates
containing the same key exist for a smaller duration than the maximum validity
period takes place.
Ø
For the rest of the permitted time period a new certificate is
issued using the initial certificate request which is stored in the Certificate
Authority.
For instance, a user who has an
existing certificate with a one year validity period can renew it (without
changing the private key) for another year, since the maximum validity period
of the private key is two (2) years for user certificates.
The same new certificate issuance procedure is followed, as
stated in section 4.3.2.
The user/subscriber should receive the renewed certificate
following the same procedure of acceptance and receipt of a new certificate, as
stated in section 4.4.1.
The new certificate is published according the procedures
stated in section 4.4.2.
No action is taken for the notification of other entities
other than what is stated in section 9.16.
Certificate re-keys are permitted when the certificate is
almost expired or the certificate is revoked and a new one should be issued.
The beneficiary subscribers receive an e-mail message from the
Registration Authority fifteen (15) days before the expiry date of their
certificate and are informed for its imminent expiry. The subscribers
afterwards make a certificate re-key request via a secure web page after
authenticating in which they choose re-key issuance.
The same re-key issuance procedure is followed, as stated in section
4.3.
The same re-key issuance procedure is followed, as stated in section
4.3.2.
The
user/subscriber must receive the certificate with the new key, following the
same acceptance procedure, as described in section 4.4.1.
The certificate with the new key is published, according to
the repository procedures, as stated in section 4.4.2.
No action is taken for the notification of other entities
other than what is stated in section 9.16.
Modification of certificate details is not permitted. In case
there is a mistake during certificate issuance (e.g. spelling), the certificate
is revoked and the re-key issuance process is followed, as stated in section 4.3.
Modification of certificate
information is not permitted.
Modification of certificate information is not permitted.
Modification of certificate information is not permitted.
Modification of certificate information is not permitted.
Modification of certificate information is not permitted.
Modification of certificate information is not permitted.
A certificate is revoked when it is not used any more, when
the fields it contains have changed or when the corresponding private key has
been exposed or lost or when there is suspicion that it has been exposed or
lost. Moreover, the certificate is revoked when the subscriber has not accepted
it in the time interval defined in section 4.4.1 or if it has been proven that
the usage of the certificate does not conform to the certification policy.
Finally, it is revoked if it contains erroneous information.
The loss of applicant’s attribute or relationship, labor or other,
with the institution or the specific unit in which she/he was originally a
member (e.g. graduation, termination of employment), is a revocation reason as
well.
The certificate can be revoked by the subscriber or by another
entity that can prove the exposure or the misuse of the certificate according
to the Certification Policy.
The secretariats or personnel services of the institution’s
units are obliged to make a revocation request for persons who lost their
attribute under which they were certified.
The validation of the subscriber’s identity is required
according to section 3.3.3.
Submission of proof that,
a) the private key of the certificate has been exposed, or
b) the use of the certificate does not conform to the
Certification Policy or
c) the certificate owner’s relationship with the institution
does not exist any more
is required.
The subscriber can make a revocation request anytime during
the validity period of the certificate. Certificate revocations can take place
if the CA which issued these certificates is still in operation.
The Certification Authority must process the revocation
requests within five (5) business days except from force majeure cases.
Relying parties must follow the procedures described in section
1.3.4 before they rely on any certificate. They should load the Certificate
Revocation Lists of all the intermediate Certification Authorities that
intervene. The Revocation lists are always published in the Repository.
4.9.7
CRL issuance frequency
The CRL must be updated and published at least every five
(5) days. The CRL will be in effect for the time interval equal with the biggest
period of publication.
In case of secret key exposure or of any other important
security compromise incident an updated Certificate Revocation List must be
published immediately.
4.9.8
Maximum latency for
CRLs
After a certificate revocation, the CRL is issued and the
repository is updated. The CRL is published at the Repository
within minutes of its issuance. The certificate is marked as revoked in
the Repository.
The subscriber
and the person in charge of the CA security are notified in case of exposure of
the private key during the certificate revocation.
4.9.9
Online
revocation/status checking availability (OCSP)
An Online Certificate Status Protocol (OCSP) service
operates under the HARICA PKI. The URL of this service is included in the
issued certificates. The operation of an OCSP service is not mandatory for all
subordinate Certification Authorities.
Relying Parties must follow the procedures described in section
1.3.4 before relying on any certificate. Before trusting a certificate of the
HARICA PKI, they must also check every time the OCSP service of the HARICA PKI
and inquire the status of all intermediate CAs that intervene.. The URL of the
OCSP service is included in all issued certificates. Operation of an OCSP
service is not mandatory for subordinate Certification Authorities.
The revoked certificates appear as “Revoked” in the search engine
of the Certificate Repository.
As defined in section 4.9.3.2.
Certificate suspension is not provided.
Certificate suspension is not provided.
Certificate suspension is not provided.
Certificate suspension is not provided.
Relying parties can use one of the following offered services
or a combination of these in order to decide for the validity of some
certificates.
As defined in section 4.9.10.
The online Certificate Repository offers a web-based certificate
search engine, supporting queries that contain the serial number or a part of
the Distinguished Name of the certificate. The search results include the
certificate’s information and an indication on whether the certificate is valid
or if it has been revoked. The Certificate Repository must display all
certificates issued / revoked for as long as HARICA is operational.
As defined in section 4.9.6.
The CA performs all the necessary
actions for the uninterruptible - as possible - availability of its OCSP
service.
Not defined.
After the end of validity of the HARICA PKI certificates, the
revocation is not necessary unless there is a reason such as the ones referred
in section 4.9.1.
Not defined.
Not defined.
The Root Certification Authority of HARICA is currently
located at the Network Operations Center of the Aristotle University of
Thessaloniki (AUTH-NOC) premises on the 1st floor of the building of Biology,
Faculty of Sciences, Aristotle University of Thessaloniki. Other subordinate
Certification Authorities may be located inside and outside AUTH NOC.
Physical access to the equipment of the CAs and the RAs is
only allowed to authorized personnel. The connection of the Root CA to any
telecommunications network is prohibited.
All equipment of the HARICA Public Key Infrastructure
currently hosted at AUTH NOC, is in air-conditioned rooms with power supply
protected by Uninterruptible Power Supply units (UPS) and backup power
generators.
The equipment of HARICA currently hosted at AUTH NOC site is
not exposed to a large extent to flooding danger.
The equipment of the HARICA PKI currently hosted at AUTH NOC
is subject to the Greek law on prevention and fire protection in public
buildings.
The private keys of the HARICA Certification Authorities must
be stored on external storage media (eg. CD-Roms) or other removable media in
encrypted form, with a passphrase that is distributed in parts only to
authorized personnel. No single member of the authorized personnel has the full
passphrase to decrypt a private key.
Backup of the entire Public Key Infrastructure of HARICA, is
kept on tape or memory flash disks kept by qualified executives.
Both of the previously mentioned storage media are in
different physical locations, outside of the central servers of HARICA,
protected from exposure to water and fire.
Waste containing any confidential information, such as floppy
disks, hard disks etc. are destroyed before being discarded.
There are off-site backups of all servers of the HARICA PKI.
The private key of each CA is always stored encrypted. The decryption
passphrase is only known to the authorized personnel of each CA. The private
keys of the Certification Authorities operated by the HARICA PKI are stored in detachable
storage media. A backup of the entire Public Key Infrastructure of HARICA is
stored in a magnetic tape held by authorized personnel. No single member of the
authorized personnel possesses the private key and the complete passphrase to
decrypt the private key at the same time.
Both of the previously mentioned storage media are in
different physical locations, outside of the central servers of HARICA,
protected from exposure to water and fire.
The personnel assigned to operate the CAs is considered to be
trusted and authorized to perform all the works of the Certification and
Registration Authorities. Personnel assigned to administer the servers of the
Registration Authorities are authorized to back up the transaction log files.
Not defined.
Not defined.
Not defined.
Personnel handling roles of Certification Authorities and
Registration Authorities must have experience in digital certificates and
Public Key Infrastructure issues. They must also have experience in managing
sensitive personal data and classified information in general.
Personnel handling Certification Authorities and
Registration Authorities comply with the applicable laws and framework.
Personnel operating the CA and the RA and has access to
cryptographic procedures, is trained and educated on issues of the Public Key
Infrastructure of HARICA by technicians of GUnet. For this purpose there is
adequate documentation that describes all the operational procedures of the
infrastructure. Personnel working within the HARICA PKI needs to know all
policy / procedures documents, and the Certificate Practice Statement and the
Certification Policy of the HARICA PKI in particular.
Not defined.
Not defined.
All legal procedures prescribed for certain offenses are
followed.
In case HARICA PKI hires an independent contractor for audit
or other operations, the contractor is obliged to sign a Non Disclosure
Agreement contract. The same principle applies for external auditors.
Relevant documentation is available from GUnet and offered to
trainees who undertake specific roles within the HARICA PKI.
The HARICA PKI systems record applications for certificates,
the issued certificates and CRLs, issued CAs and the messages exchanged with
the Registration Authority. Furthermore, in all HARICA PKI servers, other
processes of the operating system and applications are recorded such as
connections and disconnections of the administrators, HTTP connections to web
servers, etc. All servers that record logs are synchronized via NTP (Network
Time Protocol) as described in section 6.8.
All transactions are archived in a daily basis.
The transactions-events files are kept for two (2)
years in order to be available for any lawful control. This period may be
modified depending on developments of relevant laws.
Access to the transactions file in general is prohibited. Only
reading and addition by authorized systems and authorized personnel is allowed.
Deletion of file entries is not allowed.
Access to the transactions file is allowed only for reading to
certain applications of the CAs and RAs and to authorized personnel.
An access policy is applied that allows changes only to the
administrators of the operating system of the CA and the RA.
An access policy that allows changes only to the
administrators of the operating system of the CA and the RA is applied.
A backup of the transactions-events file is kept.
Not defined.
Not defined.
Not defined.
All records of transactions referred to in section 5.4, and
all documentation related to requests for issuance / revocation of digital
certificates are archived.
The records file is kept for two (2) years in order
to be available for any lawful control. This period may be modified depending
on developments of the relevant legislation.
Access to the records file in general is prohibited. Only
reading by authorized systems and authorized personnel is allowed. No changes
or cancellations of the records of the file are allowed.
Only authorized personnel may access the records file.
An access policy which does not allow changes is applied.
An access policy which does not allow deletions is applied.
Not defined.
Not defined.
A backup of the records files is kept.
Currently, the time stamping of the records files is not
required.
Not defined.
Not defined.
In case a certification authority key is changed, the keys of
the final certificates must be canceled and recreated according to the
procedures in section 4.1.
The logs are periodically monitored to detect security
breaches of systems and subsystems. If an abnormality or a suspected violation
is detected, the service is suspended and a thorough check of all systems takes
place.
In case of
suspected violation, the service is suspended and a thorough check of all
systems takes place. If a violation is confirmed, a check is done whether there
is infringement on private keys. In case of violation without loss of private
keys, the system is restored from backups where there is no suspicion of
violation, new security checks take place to find potential security holes and
then the service returns. In case of lost keys, the procedures of the next
paragraph are followed.
In case of loss of private keys, final certificates are
revoked by the certification authority and issuance of new is done without
interruption of the service. In case of private key loss of a subordinate
Certification Authority, all subscribers of this subordinate Certification
Authority are notified, all final certificates issued by this Certification
Authority are revoked, along with the certificate of the Certification
Authority. If the private key of the Root Certification Authority is lost, each
CA must stop the service, notify all subscribers of all subordinate
Certification Authorities, proceed with the revocation of all certificates,
issue a final CRL and then notify the relevant security contacts. Then the
Public Key Infrastructure will be set up again with new Certification
Authorities starting with a new Root Certification Authority.
The HARICA PKI has the ability to operate continuously using
backups of all systems/subsystems in a location outside the premises of the
HARICA servers.
Upon its termination, each CA informs its subscribers,
revokes all issued certificates, updates the relevant CRL and revokes its own
certificate. Finally, it informs the security officers and announces the end of
its operation. The log files of the CA and RA are kept for two (2) years
in order to be available for any lawful control. This period may be modified
depending on the relevant legislation.
The keys of the subscribers are generated by hardware and
software at the candidate subscribers’ side and remain under their absolute
control throughout their period of validity. If the procedures of a
Certification Authority allow the mass creation of keys for third parties,
there must be a procedure for the destruction of all copies of the private keys
after their delivery to the users in order for the private keys to be under the
possession of the recipient subscribers only. Especially, in case a subscriber
wishes to obtain a Class A certificate, as described in section 3.2.3.1 she/he must
submit the application under the presence of an authorized person of the
Registration Authority to certify the usage of a crypto-token hardware device.
The keys of the CAs are generated by special software or
hardware cryptographic devices (eToken, smartcard) that are installed in the CAs.
These cryptographic devices must comply with the FIPS 140-2 standard. Checks
must be performed during the creation of the keys in order to identify the
existence of bugs in software or hardware used, involving the creation of keys.
The creation of private keys by any entity on behalf of the
candidate subscriber or another entity or from the CA on behalf of the
subscribers is not allowed. The delivery of the private key of the candidate
subscriber to any third entity is not allowed. If a Certification Authority
allows the creation of private keys on behalf of another entity, the following
procedure must take place:
·
If the CA has enough information to confirm the validity of the
identity of the user in advance, it has the ability to generate a key pair and
a certificate for this user.
·
The verification of the authenticity of this certificate is
implemented when owners receive the credentials (certificate and keys) from the
RA. This model is called collective.
·
The CA must have a procedure to delete the secret key associated
with each certificate the moment it is delivered to the subscriber, so that eventually,
the private key is in possession of the subscriber only.
The subscriber must submit his public key to the
Registration Authority through a structured application (e.g. format PKCS#10)
for certificate issuance. The request is signed with the relevant private key.
The RA verifies a) the correctness of the signature and b) that the applicant is
in possession of the corresponding private key.
CAs provide mechanisms for the secure digital delivery of all
certificates. Each digital certificate contains the public key when it is
requested by interested entities. Interested entities may send a request by
email. The CA can also send a certificate via snail-mail in a magnetic media
device, which contains the public key. All certificates of each CA are
published through a secure web site, whose identity is certified by a different
trusted third party.
Each CA publishes its certificate at the certificate store
describe in section 2.1.
The minimum allowed key size for a subscriber is 1024 bits
for a personal user or device certificate, 2048 bits for the Certification
Authority certificates and 1024 bit for all other cases (e.g. code-signing or
timestamping certificates).
Not defined.
The intended use of a key is referred by the designated
basic field and the designated extension of the X509v3 type of certificate. The
certificate usage purposes are not restrictive (i.e. non-critical certificate
extension) but “suggested”. Monitoring compliance with the authorized purposes usage
is at the discretion of relevant parties.
Depending on the certificate class, certificate fields
include at least the following uses:
Personal user certificate class:
Basic usages: ‘Digital
Signature’, ‘Non-Repudiation’, ‘Data Encipherment’, ‘Key Encipherment’.
Extensions: ‘Client
Authentication’, ‘Secure Email’, ‘Encrypting File System’
Device certificate class:
Basic usages: ‘Digital
Signature’, ‘Key Encipherment’.
Extensions: ‘Client
Authentication’, ‘Server Authentication’
Certificates with additional special services class:
Extensions: ‘IP Security User’, ‘Timestamping’,
‘Code Signing’, ‘OCSPSigning’
Not defined.
The activation code of the private key of every CA is
segmented using a method described in an internal HARICA PKI document.
Not defined.
The private key of every CA must be kept at a backup copy.
The backup copy of the private key must be encrypted and the procedures
referenced at section 5.1.6 must be followed. Access to the backup copy is
allowed only by authorized personnel.
The backup copy of the private key of each Certification
Authority must be archived and kept using secure methods at a secure place.
Private keys at the backup copy are always encrypted but there is an additional
encryption protection of all archived backup copies. Furthermore, all
procedures at section 5.1.6 are followed. Access to the archived backup copy is
allowed only by authorized personnel.
Owners of private keys may transfer their private key from a
software certificate store to any hardware cryptographic device, e.g.
crypto-tokens, smartcards. This procedure does not change the class of the
certificate from B to A since the private key was not generated originally at
the hardware cryptographic device. The reverse procedure (transfer of the
private key from a hardware device to a software certificate store) is not allowed.
Not defined.
The private key of every CA is protected (encrypted) with a
passphrase. Each authorized person knows a different
part of the passphrase. Only a combination of authorized personnel can decrypt
the private key of each CA in order to perform cryptographic procedures. The
procedure is described in an internal HARICA CA document, which describes the
‘ceremony to activate Certification Authorities’.
The private key of user and device certificates must also be
protected-encrypted. Only the owner or administrator of the device or service
may enable and use a private key that corresponds to the certificate.
In order to activate a private key, a passphrase must be entered
to decrypt and use the private key in combination with the certificate. In case
of hardware cryptographic device (e.g. crypto-tokens) a specific PIN is
required.
For CA private key activation that is stored in crypto-tokens,
a combination of codes is required. Each authorized administrator knows a
different part of the activation PIN. Only a combination of the authorized
personnel can activate a private key.
In case of end user certificates that are stored in software
certificate stores (e.g. CryptoAPI at MS Windows), a passphrase may not be
required but a simple question of whether or not to use the private key.
Finally, private keys used in devices-services may be permanently activated and
not protected at all using a passphrase, as long as there are other sufficient
security measures at the file system level (file system permissions) or other
security precautions.
Not defined. Usually the key stays «active» for as long as the
particular application that uses the certificate, is active.
Not defined.
Not defined.
Not defined.
Public keys are embedded within the digital certificates
during their issuance and are archived according to the procedures defined in
section 5.4.
The key pair operational period is defined by the
operational period of the corresponding digital certificate. The maximum
operational period of the keys is defined as twenty (20) years for the Central CA, ten (10) years for a Subordinate CA and two (2) for end user and
device certificates. The operational period must be defined according to the
size of the keys and the current technological developments at the field of
cryptography, so that the best level of security and efficiency of use is
guaranteed.
The activation data (passphrases and PINs) must be chosen in
such a way so that it is difficult to be discovered. The minimum size of the passphrase
and the PIN is eight (8) digits.
In case there is an embedded private key destruction
mechanism after a certain number of incorrect entries, then the PIN size may be
smaller. In any case, the procedures defined in section 6.2.8 are used.
Not defined.
Not defined.
Ø
The Operating Systems of the computers of the HARICA PKI are kept
in high security level with the implementation of international standards and
security guidelines.
Ø
There are logging systems at the computers of the HARICA PKI which
are checked on a regular basis and the log files are scrutinized periodically in
order to identify potential anomalies.
Ø
Only the absolutely necessary programs/applications for the
correct operation of the RA/CA are installed within the Operating System.
Not defined.
Not defined.
Not defined.
Not defined.
The connection of CAs to wider data networks or other
telecommunication media (e.g. the telephone network using a modem) is not
allowed. The Registration Authority is protected from the internet using strong
security mechanisms including firewalls.
All time-stamping services -including logging operations- at
HARICA PKI (either at the RA or the CA operations) must be synchronized via NTP
(Network Time Protocol).
A certificate profile according
to RFC 3280 “Internet X.509 Public Key Infrastructure: Certificate and Certificate
Revocation List (CRL) Profile” is used.
The version number of the certificates is 2, which
corresponds to X.509v3 certificates.
Every issued certificate must include the BasicConstraints extension
marked as critical and the KeyUsage, SubjectKeyIdentifier and
CertificatePolicies extensions marked as non-critical. Furthermore, the
CRLDistributionPoint extension must be included marked as non-critical.
The signature algorithm must be SHA1 or
stronger. Use of MD5 is prohibited along with other hashing
algorithms that have been compromised.
The name form is done according the rules of section 3.1.
HARICA constrains all of its CAs according
to RFC 5280. This extension is marked as “non-critical”.
HARICA ROOT CA is limited to the following domains: .gr, .eu, .edu, .org.
Especially for the “.org” domain, in case an institution requires a server certificate for a
particular educational or research activity (no user certificates will be
allowed for this subCA), they will request it from a single subCA, limited only
to “.org”. This CA doesn't currently exist, but will be created upon first
request of such a certificate.
Each subCA MUST be constrained to the
Institution’s domain name that the subCA signs for. For example, Aristotle
University of Thessaloniki subCA will be limited to the “auth.gr” domain, using the name constraints extension.
The OID (Object Identifier) of the certificate policy 1.3.6.1.4.1.26513.1.0.2.6,
which complies with the CP/CPS, is included in the certificates.
Not defined.
The policy qualifier is the URI which points to the
published CP/CPS of HARICA PKI.
Not defined.
The version number is 1 or/and 2, which corresponds to CRL
X.509v2, following RFC 3280.
Not defined.
The Online Certificate Status Protocol (OCSP) is used to
validate the revocation status of all certificates signed by the Root
Certification Authority. The use of OCSP is mandatory for all subordinate
Certification Authorities.
The OCSP responders must conform to RFC2560.
Version 1 of the OCSP specification as defined by RFC2560 is
supported.
The OCSP service uses a secure timestamp and a maximum validity
period of 5 minutes to verify the freshness of the signed response. The hash
algorithm used for the issuer name and key is SHA1.
The nonce extension is supported by the OCSP responder.
Requests containing a nonce should use it to verify the freshness of the
response. Otherwise, the local clock and the timestamp contained in the
response should be used.
HARICA PKI meets the technical specifications of ETSI TS 101
456 standard “Electronic Signatures and Infrastructures (ESI); Policy
requirements for certification authorities issuing qualified certificates”.
An external CP/CPS compliance audit is required on a yearly basis.
A compliance audit may be conducted on demand by interested
parties, provided there is appropriate permission by the institution which
operates HARICA and as long as the interested parties cover the audit expenses.
No dues are paid for the provided services. All kinds of
exploitation or subcontracting of provided services from their recipients is
expressly prohibited.
No fees are charged
No fees are charged
No fees are charged
No fees are charged
No fees are charged
HARICA PKI cannot undertake or pay damages for potential
liability.
HARICA PKI does not handle commercial type of information.
Not defined.
Private keys of the Certification Authorities, the source
code and the private keys storage/operation procedures are considered classified
and confidential information which are stored in the Certification and
Registration Authorities. Information concerning the physical access and
security of the premises where the Certification and Registration Authorities
are installed and operated, is also considered classified.
It is likely that Registration Authorities undergo personal
information processing during the identification procedure of the applicant.
Information included in the issued digital certificates is
not considered private or confidential.
All private and personal information handled and processed
by HARICA PKI is in accordance to the Greek legislation concerning personal
data protection.
All non classified information stored at the Certification
and Registration Authorities is available to the law enforcement authorities,
after their official written request. Classified and personal information can
be disclosed to the judicial authority if there is an official court order according
to the privacy and data protection applicable law. The process is carried out
through the Administration of HARICA. Currently, HARICA is operated by GUnet S.A. Private keys used to sign and issue digital certificates are never disclosed to any
third-parties, unless applicable law specifically demands disclosure.
All non classified information stored at the Certification
and Registration Authorities is available for entity queries, once applied for.
All information stored at the CA and RA is available to its rightful
owner (e.g. individual who applied for a certificate), once applied for.
Not defined.
HARICA PKI does not hold any intellectual property rights on
the issued certificates.
Anyone can copy parts of this CP/CPS with the condition that
the original document is properly referenced.
Not defined
Not defined
HARICA PKI cannot be held liable for any problems or damages
that may arise from its services or from wrongful, negligent or improper use of
the issued certificates. HARICA does not undertake any financial, civil or
other responsibilities. Using HARICA and its certification services requires
that users unconditionally accept the terms and services of this CP/CPS and
that HARICA is not liable and does not undertake any financial, civil or other
responsibilities, except for cases where there is evidence of fraudulent intent
or serious negligence by its operators.
HARICA PKI cannot be held liable and does not undertake any
financial, civil or other responsibilities unless there is evidence of fraudulent
intent or serious negligence by its operators. HARICA PKI is strictly used for
Academic and Research activities and cannot be used for commercial, financial,
legal or any other transactions that are not included in the first paragraph of
section 1.4.1. Therefore, HARICA PKI is exempt from any liability or damage
that is not directly linked with the certification services for the already
mentioned purposes.
This CP/CPS is valid and effective for as long as HARICA PKI
is operational.
When a subordinate Certification Authority or Registration
Authority decides to terminate their services and withdraw from HARICA PKI, it
is obliged to officially inform the Administration of HARICA. Similar
correspondence is essential when an Academic or Research Institution in Greece wishes to participate and become a member of HARICA PKI.
Syntax changes can be made to the Certification Policy and
to the Certification Practice Statement without any prior notice and without
OID modification.
There will be prior notification to subscribers in case of
major changes to the CP/CPS. HARICA PKI is obligated to publish (at its web
site), previous versions of its CP/CPS in case of major document changes. The
most recent CP/CPS is always published at the following URL: http://www.harica.gr/documents/CPS.php.
In case of major and significant changes of the CP/CPS, the
name and identifier (OID) which is reported in section 1.2 will be altered.
Subscribers will be informed beforehand in case of important changes in the
Certification Policy.
Differences or disputes that
result from the interpretation of the Certificate Policy/Certification Practice
Statement and the operation of the Certification Authority will be solved
according to the Academic deontology and the Greek Law.
In the case of disputes it is Greek
courts that are competent and the venue is Athens Greece.
HARICA is focused on serving the Hellenic Academic and
Research Community. Each certificate issued, clearly states in the Certificate
Policy Notice field that “This certificate is subject to Greek laws and our
CPS. This Certificate must only be used for academic, research or educational
purposes”. No financial transactions will take place with HARICA PKI unless
otherwise specified in a subCA with a separate CP/CPS. The operation of the
HARICA PKI as well as the interpretation of the CP/CPS is subject to the
Academic ethics and in the national Greek Legislation. Particularly as far as
the Presidential Decree 150/2001 «Adaptation to directive 99/93/EE of European
Parliament and Council with regard to the Community frame for electronic
signatures» is concerned, the certificates that are published they ARE NOT
generally considered as “Qualified Certificates”, although the CAs and the
issued certificates MEET the technical requirements for “Qualified
Certificates”.
Under specific conditions and treaties, the certificates
that are published can be used as ‘qualified’ in closed teams of entities, as
for example in certain administrative service of Academic Institutions.
These procedures must be described on a separate
Certification Policy/Certificate Practice Statement (CP/CPS) document that
correspond to that particular subordinate Certification Authority, taking
account and meeting all the requirements (including the liability issues) described
in the Presidential Decree 150/2001. As stated in section 1.3.3, these procedures
must not conflict with any condition of the present document.
Basic conditions for this “qualification” and accordingly
the “qualification” of a relative produced digital signature as equivalent to a
handwritten signature include:
a) The use of “secure environment for the creation of digital
signatures” in the subscriber’s side (e.g. smart card exclusively in which the
private key is created, stored and used) and
b) The official approval of each responsible body (eg senate
or governing board of an Institution).
HARICA PKI is completely abided by the Greek Legislation.
A Certification Authority is responsible for the issuance
and the management of the certificates. Specifically HARICA certification
authorities are bound to:
ü
Provide and maintain the infrastructure that is required for
constitution of hierarchy of certification services for the Greek academic and
research community, according to the certification processes described in this
document.
ü
Implement and maintain the security requirements according to
relative sections of the present document
ü
Accept or reject requests for certificate issuance according to
the relative sections of the present document.
ü
Maintain a publicly accessible directory for certificates and
CRLs. This information should be publicly available via widely used protocols such
as HTTP, FTP and LDAP.
ü
Revoke certificates when specific reasons apply or after a proper
request by the subject of the certificate.
ü
Maintain the CRLs up to date.
ü
Manage all personal and private information of the subscribers
with confidentiality.
ü
Immediately inform the technical personnel of Subordinate CAs for
any loss, exposure, modification or unauthorized usage of the CA’s private key.
ü
Ensure that all the services provided within the whole
infrastructure, abide by the terms and conditions of the present CP/CPS.
Each subordinate Certification Authority approved by HARICA
PKI is committed to:
ü
Grant certificates with validity period within the limits of the
active employment (or other) relationship between the applicant and the
institution, according to the applicant’s affiliation (i.e student, employee, faculty).
ü
Inform the parent Certification Authority immediately in case of
private key exposure.
ü
Protect the private keys, used for certificate signing, at least
in the security level that is described in the present document.
ü
Develop (optionally) its own policies and procedures of
certification which must be at least as strict and binding as the ones
described in the present document.
ü
In case an institution -within the HARICA constituency- wants to
run its own CA, it must provide an official audit certificate according to the ETSI
TS 101 456 (or equivalent) requirements
Each Registration Authority manages the applications for
subscriber registration.
ü
Each Registration Authority is responsible to receive certificate
applications from subscribers. It validates the identity of the subscriber,
confirms that the public key that is submitted belongs to the subscriber and
securely transmits the application to the CA.
ü
According to the certificate type, applications can be submitted via
face-to-face meeting with the interested party, via e-mail, via a secure web
form, or via any mechanism that securely identifies the user. The application
includes all information identifying the subscriber, and the corresponding
public key.
ü
Mass applications submission from a specific administrative department
is possible on behalf of the persons that belong to that department or organization
ü
Each Registration Authority must verify if each person requesting
a personal certificate is the rightful owner of the certified e-mail address.
ü
Each Registration Authority must verify that the person
requesting a device certificate is the rightful owner and administrator of the
device’s FQDN.
ü
In case an institution -within the HARICA constituency- wants to
run its own RA, it must provide an official audit certificate according to the ETSI
TS 101 456 (or equivalent) requirements
ü
HARICA PKI subscribers are obligated to read, accept and comply with
this Certificate Policy/Certification Practice Statement. Subscribers are obliged
to use the certificates solely for the purposes described in this CP/CPS and
the applicable law.
ü
Subscribers must create a key pair (private and public) using a
reliable and secure system and take all necessary precautions to protect their
private key from accidental destruction, loss or theft.
ü
After they receive their certificate, subscribers agree and
confirm that the information contained in the certificates is accurate.
ü
Subscribers must request certificate revocation when it is not
used anymore, when the data contained has changed or when it is suspected that
the private key has been compromised or lost.
ü
Especially in case of code signing, subscribers are bound by the RA
to provide complete, accurate and truthful information (eg, application name,
information URL,application description, etc.) in the signed code.
ü
Entities that trust the issued certificates are obligated to read
and accept this Certificate Policy/Certification Practice Statement and to use
the certificates only in ways that conform to this CP/CPS and the current
legislation.
ü
Entities that trust the certificates must check the validity of
the digital certificate signature and trust the parent Certification
Authorities. Finally, they should periodically check the validity of the
certificate against the relevant Certificate Revocation List of use the Online
Certificate Status Protocol (OCSP) service for possible revocations.
Each Certification Authority (root or intermediate) is
obligated to operate and maintain a publicly accessible data repository
containing:
ü
the certification authority certificate
ü
the Certificate Policy/Certification Practice Statement
ü
the HARICA Memorandum of Understanding
ü
the issued and retrieved certificates
ü
the Certificate Revocation Lists
