MD-Grid
CERTIFICATION AUTHORITY
CERTIFICATE POLICY
AND
CERTIFICATION PRACTICE STATEMENT
Version
1.4
October,
2014
MD-Grid
CERTIFICATION AUTHORITY
CERTIFICATE POLICY
AND
CERTIFICATION PRACTICE STATEMENT
Version
1.4
October,
2014
1.2 Document name and identification
1.3.1 Certification Authorities
1.3.2 Registration authorities
1.4.1 Appropriate certificate uses
1.4.2 Prohibited certificate uses
1.5.1 Organization administering the
document.
1.5.3 Person determining CPS
suitability for the policy
2 PUBLICATION AND REPOSITORY
RESPONSIBILITIES
2.2 Publication of certification information
2.3 Time or frequency of publication
2.4 Access control on repositories
3 IDENTIFICATION AND AUTHENTICATION
3.1.2 Need for names to be
meaningful
3.1.3 Anonymity or pseudonimity of
subscribers
3.1.4 Rules for interpreting various
name forms
3.1.6 Recognition, authentication,
and role of trademarks
3.2 Initial identity validation
3.2.1 Method to prove possession of
a key
3.2.2 Authentication of organization
identity
3.2.3 Authentication of individual
entity
3.2.4 Non-verified subscriber
information
3.2.6 Criteria of interoperation
3.3 Identification and authentication for
re-key requests
3.3.1 Identification and
authentication for routine re-key
3.3.2 Identification and
authentication for re-key after revocation
3.4 Identification and authentication for
revocation request
4 CERTIFICATE LIFE-CYCLE OPERATIONAL
REQUIREMENTS
4.1.1 Who can submit a certificate
application
4.1.2 Enrollment process and
responsibilities
4.2.1 Performing identification and
authentication functions
4.2.2 Approval or rejection of
certificate applications
4.2.3 Time to process certificate
applications
4.3.1 CA actions during certificate
issuance
4.3.2 Notification to subscriber by
the CA of issuance of certificate
4.4.1 Conduct constituting
certificate acceptance
4.4.2 Publication of the certificate
by the CA
4.4.3 Notification of certificate
issuance by the CA to other entities
4.5 Key pair and certificate usage
4.5.1 Subscriber private key and
certificate usage
4.5.2 Relying party public key and
certificate usage
4.6.1 Circumstance for certificate
renewal
4.6.3 Processing certificate renewal
requests
4.6.4 Notification of new
certificate issuance to subscriber
4.6.5 Conduct constituting
acceptance of a renewal certificate
4.6.6 Publication of the renewal
certificate by the CA
4.6.7 Notification of certificate
issuance by the CA to other entities
4.7.1 Circumstances for certificate
re-key
4.7.2 Who may request certification
of a new public key
4.7.3 Processing certificate
re-keying requests
4.7.4 Notification of new
certificate issuance to subscriber
4.7.5 Conduct constituting
acceptance of a re-keyed certificate
4.7.6 Publication of the re-keyed
certificate by the CA
4.7.7 Notification of certificate
issuance by the CA to other entities
4.8.1 Circumstances for certificate
modification
4.8.2 Who may request certificate
modification
4.8.3 Processing certificate modification
requests
4.8.4 Notification of new
certificate issuance to subscriber
4.8.5 Conduct constituting
acceptance of modified certificate
4.8.6 Publication of the modified
certificate by the CA
4.8.7 Notification of certificate
issuance by the CA to other entities
4.9 Certificate revocation and suspension
4.9.1 Circumstances for revocation
4.9.2 Who can request revocation
4.9.3 Procedure for revocation
request
4.9.4 Revocation request grace
period
4.9.5 Time within which CA must
process the revocation request
4.9.6 Revocation checking
requirement for relying parties.
4.9.8 Maximum latency for CRLs
4.9.9 On-line revocation/status
checking availability
4.9.10 On-line revocation checking
requirements
4.9.11 Other forms of revocation
advertisements available
4.9.12 Special requirements re key
compromise
4.9.13 Circumstances for suspension
4.9.14 Who can request suspension
4.9.15 Procedure for suspension
request
4.9.16 Limits on suspension period
4.10 Certificate status services
4.10.1 Operational characteristics
4.12.1 Key escrow and recovery policy
and practices
4.12.2 Session key encapsulation and
recovery policy and practices
5 FACILITY, MANAGEMENT, AND
OPERATIONAL CONTROLS
5.1.1 Site location and construction
5.1.3 Power and Air Conditioning
5.1.5 Fire Prevention and Protection
5.2.2 Number of persons required per
task
5.2.3 Identification and
authentication for each role
5.2.4 Roles requiring separation of
duties
5.3.1 Qualifications, experience and
clearance requirements
5.3.2 Background check procedures
5.3.4 Retraining frequency and
requirements
5.3.5 Job rotation frequency and
sequence
5.3.6 Sanctions for unauthorized
actions
5.3.7 Independent contractor
requirements
5.3.8 Documentation supplied to
personnel
5.4.1 Types of events recorded
5.4.2 Frequency of processing log
5.4.3 Retention period for audit log
5.4.5 Audit log backup procedures
5.4.6 Audit collection system
(internal vs. external)
5.4.7 Notification to event-causing
subject
5.4.8 Vulnerability assessments
5.5.1 Types of records archived
5.5.2 Retention Period for Archive
5.5.4 Archive backup procedures
5.5.5 Requirements for time-stamping
of records
5.5.6 Archive collection system
(internal or external)
5.5.7 Procedures to obtain and
verify archive information
5.7 Compromise and Disaster Recovery
5.7.2 Computing resources, software,
and/or data are corrupted
5.7.3 Entity private key compromise
procedures
5.7.4 Business continuity
capabilities after a disaster
6. TECHNICAL SECURITY CONTROLS
6.1 Key Pair Generation and Installation
6.1.2 Private key delivery to
subscriber
6.1.3 Public key delivery to
certificate issuer
6.1.4 CA public key delivery to
relying parties
6.1.6 Public key parameters
generation
6.1.7 Key usage purposes (as per
X.509 v3 key usage field)
6.2 Private key protection and
cryptographic module engineering controls
6.2.1 Cryptographic module standards
and controls
6.2.2 Private key (n out of m)
multi-person control
6.2.6 Private key transfer into or
from a cryptographic module
6.2.7 Private key storage on
cryptographic module
6.2.8 Method of activating private
key
6.2.9 Method of deactivating private
key
6.2.10 Method of destroying private
key
6.2.11 Cryptographic Module Rating
6.3 Other Aspects of Key Pair Management
6.3.2 Certificate operational
periods and key pair usage periods
6.4.1 Activation data generation and
installation
6.4.2 Activation data protection
6.5 Computer security controls
6.5.1 Specific computer security
technical requirements
6.5.2 Computer security rating
6.6 Life Cycle technical controls
6.6.1 System development controls
6.6.2 Security management controls
6.6.3 Life cycle security controls
7. CERTIFICATE, CRL AND OCSP
PROFILES
7.1.3 Algorithm Object Identifiers
7.1.6 Certificate Policy Object
Identifier
7.1.7 Usage of Policy Constraints
extension
7.1.8 Policy qualifiers syntax and
semantics
7.1.9 Processing semantics for the
critical Certificate Policies extension
7.2.2 CRL and CRL entry extensions
7.2.2.1 Authority key identifier
8 COMPLIANCE AUDIT AND OTHER
ASSESSMENTS
8.1 Frequency or circumstances of assessment
8.2 Identity/qualifications of assessor
8.3 Assessor's relationship to assessed entity
8.4 Topics covered by assessment
8.5 Actions taken as a result of deficiency
9 OTHER BUSINESS AND LEGAL MATTERS
9.1.1 Certificate issuance or
renewal fees
9.1.3 Revocation or status
information access fees
9.2.3 Insurance or warranty coverage
for end-entities
9.3 Confidentiality of business
information
9.3.1 Scope of confidential
information
9.3.2 Information not within the
scope of confidential information
9.3.3 Responsibility to protect
confidential information
9.4 Privacy of personal information
9.4.2 Information treated as private
9.4.3 Information not deemed private
9.4.4 Responsibility to protect
private information
9.4.5 Notice and consent to use
private information
9.4.6 Disclosure pursuant to
judicial or administrative process
9.4.7 Other information disclosure
circumstances
9.5 Intellectual property rights
9.6 Representations and warranties
9.6.1 CA representations and
warranties
9.6.2 RA representations and
warranties
9.6.3 Subscriber representations and
warranties
9.6.4 Relying party representations
and warranties
9.6.5 Representations and warranties
of other participants
9.10.3 Effect of termination and
survival
9.11 Individual notices and communications with
participants
9.12.1 Procedure for amendment
9.12.2 Notification mechanism and
period
9.12.3 Circumstances under which OID
must be changed
9.13 Dispute resolution provisions
9.15 Compliance with applicable law
9.16.4 Enforcement (attorneys' fees
and waiver of rights)
This document describes the rules and procedures used by the MD-Grid
Certification Authority.
This document is organized according to the specifications proposed by
the RFC 3647. It describes the procedure followed by MD-Grid (National Grid
Initiative of Moldova) Certification Authority and is the combination of
Certificate Policy and Certification Practice Statement (CP/CPS).
This document is a valid CP/CPS as of March 04, 2008, 09:00 UTC.
Document title: MD-Grid Certification Authority Certificate Policy and
Certification Practice Statement
Document version: 1.4
Document date: 01.10.2014.
ASN.1 Object Identifier (OID): 1.3.6.1.4.1.31194.10.1.1.4
The next table describes the meaning of the OID:
|
1.3.6.1.4.1 |
Prefix for IANA private enterprises |
|
31194 |
RENAM registered identifier |
|
10 |
Certification Authorities |
|
1 |
CP/CPS |
|
1.4 |
Major and minor CP/CPS number. |
The RA Operators are responsible for verifying Subscribers’ identities
and approving their certificate requests. RA Operators do not issue
certificates. The list of RAs is available on the MD-Grid CA website.
The MD-Grid CA issues user (personal), host and service certificates.
Subscribers eligible for certification from
·
Users (people).
·
Computers (hosts).
·
Services (host applications).
All entities that use public keys of certificates, issued by
No stipulation.
Personal certificates can be used to authenticate a user that would like
to benefit from the Grid resources.
Host certificates can be used to identify computers that have special
tasks related to the Grid activities.
Service certificates can be used to recognize the host applications and
data or communication encryption (SSL/TLS).
In addition, it is permissible to use certificates for email signing.
Notwithstanding the above, using certificates for purposes contrary to
Moldavian law is explicitly prohibited.
MD-Grid Security Group at RENAM is in charge of the management of
Phone: +373 22 288006 or
+373 22 234635
Fax: +373 22 288006
e-mail: ca@renam.md
Address:
5
Academiei str., of. 331
MD-2028,
Chisinau
The contact person that can deal with any questions related to this
document or operational issues:
Valentin Pocotilenco
Address:
RENAM Association
5
Academiei str., of. 331
MD-2028,
Chisinau
Phone: +373 22 288006 or
+373 22 234635
Fax: +373 22 288006
e-mail: pvv@renam.md
Valentin Pocotilenco
Address:
RENAM Association
5
Academiei str. of. 331
MD-2028,
Chisinau
Phone: +373 22 288006 or
+373 22 234635
Fax: +373 22 288006
e-mail: pvv@renam.md
Website: http://ca.grid.md/
The CP/CPS document and all CPS modifications should be approved by the
EuGridPMA before being applied.
|
RENAM |
Research and Educational Networking Association of |
|
ASN.1 |
Abstract Syntax Notation One
(http://asn1.elibel.tm.fr/) |
|
CA |
Certification Authority |
|
CP/CPS |
Certificate Policy/Certification Practice Statement |
|
CRL |
Certificate Revocation List |
|
DNS |
Domain Name System |
|
FQDN |
Fully Qualified Domain Name |
|
HTTP |
Hypertext Transfer Protocol |
|
IANA |
Internet Assigned Numbers Authority |
|
IP |
Internet Protocol |
|
OCSP |
Online Certificate Status Protocol |
|
OID |
Object Identifier |
|
PKI |
Public Key Infrastructure |
|
RA |
Registration Authority |
|
RFC |
Request For Comment |
|
S/MIME |
Secure / Multipurpose Internet Mail Extensions |
|
SEE-GRID |
South East European GRid-enabled eInfrastructure Development |
|
SSL |
Secure Sockets Layer |
|
URL |
Uniform Resource Locator |
|
USB |
Universal Serial Bus |
The
MD-Grid CA operates an on-line repository that contains:
·
The MD-Grid CA root certificate
·
User, Host and Service certificates issued
by the CA
·
Certificate Revocation Lists (periodically
updated)
·
A copy of the most recent version of this
CP/CPS and all previous versions
·
A list of current operational Registration
Authorities
·
Links to all trust anchor repositories
where
·
Other relevant information
http://ca.grid.md/
The MD-Grid CA communication information for information regarding
repositories is:
RENAM Certification authority
RENAM Association
5
Academiei str. of. 331
MD-2028,
Chisinau
Phone: +373
22 288006 or +373 22 234635
Fax: +373
22 288006
e-mail:
See section 2.1
Certificates will be put to the MD-Grid CA website as soon as they are
issued.
·
CRL publication will be updated
immediately after a revocation is issued and it will be updated at least 7 days
before the expiration date of the CRL where CRL life time is 30 days.
·
New versions of all
·
New versions of this CP/CPS document will
be published soon after they are validated and former versions will be kept as
a record in the repository.
The MD-Grid CA does not impose any access control on its CP/CPS, issued
certificates or CRLs available on website.
The
subject names for the certificate applicants shall follow the X.500 standard:
1. in case of user
certificate the subject name must include the persons name in the CN field;
2. in case of host
certificate the subject name must include the DNS FQDN in the CN field;
3. in case service
certificate the subject name must include the service name and the DNS FQDN
separated by a „/“ in the CN field.
The
subject name must represent the subscriber in a way that is easily
understandable by humans and must have a reasonable association with the
authenticated name of the subscriber. Each host certificate must be linked to a single network entity.
See section 3.1.1.
The subject name included in the CN part of a certificate must be unique
for all certificates issued by the MD-Grid CA. When essential, extra characters
may be affixed to the original name to guarantee the uniqueness of the subject
name.
Private keys must not be shared among end entities.
DNs must retain the uniquity for whole CA lifetime.
No stipulation.
The MD-Grid CA proves possession of the private key that is the
companion to the public key in
The MD-Grid CA verifies the possession of the private key relating to
certificates requests by out-of-band, non-technical means at the time of
authentication. Such verification may take the form of a directly posed
question to requester. A cryptographic challenge-response exchange may be used
to prove possession of the private key at any point in time before
certification of subscriber.
The MD-Grid CA will not generate the key pair for subscribers and will
not accept or retain private keys generated by subscribers.
The MD-Grid CA authenticates organizations by:
·
Checking that organization is affiliated
with RENAM Initiative;
·
Contacting the person who represents the
organization in the project.
·
Contacting the person who represents the
organization or other legal entity that is not affiliated to RENAM initiative
or not involved in project.
The subscriber should contact personally the RA or CA staff in order to
validate his/her identity. The subscriber’s authentication is fulfilled by
providing an official document for personal identification (ID-card, driving
license or a passport), and a valid document proving subscriber’s relation with
an institute or organization, declaring that the subject is a valid end entity.
Certificate of a host or service:
Host or service certificates can only be requested by the administrator
responsible for the particular host. In order to request a host or service
certificate the following conditions must be met:
1.The host must have a valid FQDN.
2.The administrator must already possess a valid
personal MD-Grid certificate.
3.The administrator must provide a proof of his or
hers relation to the host itself.
The subscriber requesting service from the MD-Grid CA should contact
personally the RA or CA staff in order to validate his/her identity.
During the initial identity validation the requester's e-mail is not
verified. This is done during the processing of the certificate application as
described in section 4.2.2.
No stipulation.
No stipulation.
Expiration warnings will be sent to subscribers before it is re-key
time. Re-key before expiration can be executed by stating a re-key request
signed with the personal certificate of the subscriber but after 4 years
face-to-face identity validation is required as described in 3.2.3. Re-key
after expiration uses completely the same authentication procedure as new
certificate.
The procedure for re-key after revocation is exactly the same with an
initial registration.
Certificate revocation requests should be authenticated in one of the
following ways:
·
By signing a revocation request e-mail via
a valid personal key corresponding to the certificate that is requested to be
revoked which must be a valid, non-expired and non-revoked RENAM certificate.
·
For persons who do not have a valid RENAM
certificate, but hold an evidence of a revocation circumstance: by personal
authentication as described in 3.2.3
·
If the revocation request is for a host or
service certificate, then the e-mail must be signed by the private key
corresponding to the certificate of the person responsible of the host or
service. When e-mail is not an option, the request will be authenticated using
the procedure described in section 3.2.3.
·
Revocation request by the RA should be
done by e-mail, signed with valid RA operator key.
The essential procedures that must be conformed in a certificate
application request are as follows:
· The
subject must be appropriate to the specifications stated in this
policy.
· The
key length of a generated certificate must be 2048 or 4096 bits.
· For personal
private keys use a strong passphrase of at least 12
characters.
4.2 Certificate application processing
All the certificate applications will be authenticated and validated by
the MD-Grid CA and RAs as stated in section 3.2.3. In the cases of re-key of
user certificate or request for host or service certificate, the authentication
of the certificate application will take place by checking that the requester
has a valid
If the certificate request does not meet one or
more of the criteria in 4.1.1, it will be rejected and the requester will be
informed via signed e-mail.
Each
certificate application will take no more that 5 working days to be processed.
CA will
check that identity validation is properly performed as described in 3.2.3.
CA will
ensure secure communication with RAs by signed e-mails or voice conversations.
Applicants
will be notified via e-mail when the certificate is issued and the issued
certificate will be hosted at the online CA repository.
If the
user wants to accept the certificate, he or she must follow the procedure in
section 4.4.1.
If a
user wants to reject a certificate, he or she must submit a revocation request
as described in section 4.9.
Subscribers
of
· acknowledgment
of conditions and loyalty to the procedures interpreted in this
document
· permanent
provision of correct information to the MD-Grid CA and avoidance of unnecessary
information out of purposes of this document
· use of the
certificate for only authorized purposes that are stated in this
document
· admission of
restrictions to liability defined in section 9.8
· admission of
statements about confidentiality of information emphasized in section
9.4
· key pair
(public key and private key) generation using a secure
method
· acceptable
precautions against loss, disclosure or illegal use of the private
key
· notifying
· notifying
· notifying
If the RA has handled the communication with the subscriber, then it
will be notified of the certificate issuance.
The RA will be informed about any certificate signatures and re-keys
before expiration that were submitted through it.
The
subscribers' private keys along with the certificates issued by the MD-Grid CA
can be used for:
· email signing/verifying and
encryption/decryption (S/MIME);
· server authentication and encryption of
communications;
· authentication purposes in Grid Infrastructures;
· non-repudiation.
Relying
parties can use the public keys and certificates of the subscribers for:
·
email
encryption and signature verification (S/MIME);
·
server
authentication and encryption of communications;
·
authentication
purposes in Grid infrastructures.
Before using a
certificate the relying party must validate it against the CRL (or, later,
using the
planned
OCSP facility) most recently published in the MD-Grid CA repository.
If
subscribers want to use their certificates, they must regenerate their key pair
in the following circumstances:
1.Expiration of their certificate signed by the MD-Grid CA;
2.Revocation of their certificate by the MD-Grid CA.
Every subscriber holding a valid
Expiration
warnings will be sent to subscribers before it is re-key time.
a) Re-key before expiration can be executed by stating a re-key request
signed with the private key corresponding to the
public one in the valid personal
certificate of the subscriber. The requester is not
required to pass the authentication procedure described in section 3.2.3, if
this does not contrast with c) or d).
b) Re-key after certificate expiration uses completely the same
authentication procedure as that for the new
certificate.
c) At least once every 4 years the subscriber must go through the same
authentication procedure as the one described for a new certificate.
d) In case the request for a new certificate is due to revocation of
certificate the subscriber must follow the same procedure as the one described
in for a new one.
Same
as in section 4.3.2
Same
as in section 4.4.1
Same
as in section 4.4.2
Same
as in section 4.4.3
the revocation and
re-key procedures should be followed.
the revocation and
re-key procedures should be followed.
the revocation and
re-key procedures should be followed.
the revocation and
re-key procedures should be followed.
the revocation and
re-key procedures should be followed.
the revocation and
re-key procedures should be followed.
the revocation and
re-key procedures should be followed.
A
certificate will be revoked in the following situations:
· The CA is informed that the Subscriber has
ceased to be an eligible subject as defined in 1.3.3:
· The Subscriber’s private key is lost or
suspected to be compromised;
· The information in the Subscriber’s certificate
is wrong or inaccurate, or suspected to be wrong or inaccurate;
· The Subscriber violates his/her obligations.
· The Subscriber does not need the certificate any
more.
In one
of the conditions above, end entity must request revocation of the certificate
as soon as possible but within one working day.
The
CA, RA, subscriber of the certificate or any other entity holding evidence of a
revocation circumstance about that certificate can request revocation.
The
entity requesting the certificate revocation is authenticated by signing the
revocation request with a valid
Before using a
certificate the relying party must validate it against the CRL (or, later,
using the
planned
OCSP facility) most recently published in the MD-Grid CA repository. [section
2.1]
1.CRLs will be published in the on-line repository as soon as issued and
at least once every 23 days;
2.The maximum CRL lifetime is 30 days;
3.Each new CRL is issued at least 7
days before expiration of the previous CRL.
No
stipulation.
Currently
there are no on-line revocation/status services offered by the MD-Grid CA.
Currently
there are no on-line revocation/status services offered by the MD-Grid CA.
No
stipulation.
No stipulation.
The
on-line repository is maintained on best effort basis with intended
availability of 24x7.
No
stipulation.
No
stipulation.
No
stipulation.
The MD-Grid CA operates in a controlled and protected room located in
Technical University of Moldova.
The address is:
78, 31 August
str.,
Chisinau
Phone: +373 22
234635
E-mail: ca@renam.md
Physical
access to the MD-Grid CA is restricted to authorized personnel only.
Premises containing the CA machine are air conditioned.
No stipulation.
Technical
Backups are to be stored in removable storage media (CD-ROM, USB Flash)
in a safe location in Technical University of Moldova.
CDs are physically destroyed before being trashed.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
No stipulation.
MD-
No stipulation.
Internal training is given to
No
stipulation.
No
stipulation.
No
stipulation.
Operational
manual for CA and RA operators is supplied to the new
The following events are recorded by
·
certification requests;
·
issued certificates;
·
requests for revocation;
·
issued CRLs;
·
login/logout/reboot/shutdown of the
signing machine;
Each RA must keep log of the following:
·
for each approved request, how it was
approved;
·
for each rejected request, why it was
rejected;
·
for each approved revocation request, the
reason for revocation;
·
for each rejected revocation request, the
reason for revocation and the reason the request was rejected.
Audit logs will be processed at least once per year.
Audit logs will be retained for a minimum of 3 years.
Only
authorized CA personnel are allowed to view and process audit logs (stipulated
in 8.1). Audit logs are kept in a safe storage in a
room with limited access.
Audit
logs are copied to an offline medium and kept in a
safe storage in a room with limited access.
Audit log collection system is internal to the MD-Grid CA.
No stipulation.
No
stipulation.
The following data and files are recorded and archived by the CA:
·
certification requests
·
issued certificates
·
requests for revocation
·
issued CRLs
·
all e-mail messages of correspondence
between RA and CA
·
login/logout/reboot/shutdown of the
signing machine
·
identity validation records (section
3.2.3).
Each RA must keep log of the following:
·
for each approved request, how it was
approved
·
for each rejected request, why it was
rejected
·
for each approved revocation request, the
reason for revocation
·
for each rejected revocation request, the
reason for revocation and the reason the request was rejected
·
all e-mail messages of correspondence
between RA and CA
·
identity validation records (section
3.2.3).
Minimum retention period is three years.
Archives are kept in a safe storage in a room with limited access.
All data and files, but not private keys, are
copied to an off-line medium. (see section 6.2.5)
No stipulation.
The
archive collection system is internal to the MD-Grid CA.
No stipulation.
Lifetime of
If the CA’s private key is (or is suspected to be) compromised, the CA
will:
·
Inform the EUgridPMA;
·
Inform the Registration Authorities,
Subscribers and Relying Parties of which the CA is aware;
·
Conclude the issuance and distribution of
certificates and CRLs;
·
Prepare a new presentation of site
security for CA re-accreditation.
If an RA Operator’s private key is compromised or suspected to be
compromised, the RA Operator or Manager must inform the CA and request the
revocation of the RA Operator’s certificate.
No
stipulation.
No
stipulation.
No stipulation.
Before the CA terminates its services, it will:
·
Inform the Registration Authorities,
Subscribers and Relying Parties of which the CA is aware;
·
Make information of its termination
available on it’s website;
·
Stop issuing certificates;
·
Annihilate all copies of private keys;
·
Audit logs will be kept for 3 years from
CA or RA termination date.
Before the RA terminates its services, it will:
·
Inform the CA and Relying Parties it is
aware of.
·
Make information of its termination
available on it’s and CA websites.
·
Stop accepting certificate requests.
An advance notice of no less than 60 days will be given in the case of
normal (scheduled) CA or RA termination.
Keys for the MD-Grid CA root certificate are generated on a dedicated
machine, not connected to any type of network. The software used for key
generation is OpenSSL.
Each subscriber must generate his/her own key pair.
As each applicant generates his/her own key pair, CA has no access to
subscribers' private keys.
Applicants can make user/host/service certificate requests as described
in section 4.1
The MD-Grid CA root certificate is available on the:
·
MD-Grid NGI website: http://ca.grid.md/files/ca.der
·
TACAR website: https://www.tacar.org/cert/install/77
For a user or host certificate the key size is 2048 or 4096 bits. The
MD-Grid CA key size is 2048 bits.
No stipulation.
Keys may be used for authentication,
non-repudiation, data encipherment, message integrity and session
establishment.
The CA’ private key is only used for signing
certificates and CRLs.
No
stipulation.
No
stipulation.
No
stipulation.
A backup of the MD-Grid CA private key is kept encrypted in multiple
copies in USB flash drive and CD-ROM in a safe location. The password for the
private key is kept separately in paper form with an access control. Only
authorized CA personnel have access to the backups.
The
subscriber is required to generate a secure pass phrase, at least 12 characters
long for the private key. Private key cannot be shared and it is subscriber
responsibility to protect the private key properly.
No
stipulation.
No stipulation.
No
stipulation.
No stipulation.
As a part of the certificate archival, the public key is archived.
End Entity certificates have maximum lifetime of 1 year.
The
MD-Grid CA does not have access to or generate the private keys of a
subscriber. The key pair is generated and managed by the client and it is
subscriber's responsibility to keep the private key secure.
The
passphrase for the private key of CA root certificate is kept separately in
paper form with an access limited to CA personnel.
6.4.3 Other
aspects of activation data
No
stipulation.
Computers operating at
·
Operating systems are maintained at a high
level of security by applying in a timely manner all recommended and applicable
security patches;
·
Monitoring is done to detect unauthorized
software changes;
·
System services are reduced to the bare
minimum;
·
The signing machine is kept off between
uses and is kept
off-line all its lifetime.
No stipulation.
No
stipulation.
No
stipulation.
No stipulation.
Certificates are issued on a machine, not connected to any kind of
network. Protection of other machines is provided by firewalls.
No stipulation.
X.509 v3
The values of extensions in case of CA certificate are following:
·
X509v3
Basic Constraints: critical CA:TRUE
· X509v3 Key Usage: critical Certificate Sign, CRL Sign
·
X509v3
Authority Key Identifier: <CA key ID>
·
X509v3
Subject Key Identifier: <CA key ID>
·
X509v3
Subject Alternative Name: email: ca@renam.md
·
X509v3
Issuer Alternative Name:
The values of extensions in case of user certificates are following:
·
X509v3
Basic Constraints: critical CA:FALSE
· X509v3 Key Usage: Digital Signature, Key Encipherment, Data Encipherment
· X509v3 Extended Key Usage: TLS Web Client Authentication, E-mail Protection, Object Signing
· X509v3 CRL Distribution Points
·
X509v3
Authority Key Identifier: <CA key ID>
·
X509v3
Subject Key Identifier: <subject key ID>
· X509v3 Certificates Policies:
·
X509v3
Subject Alternative Name: <subject email>
·
X509v3
Issuer Alternative Name:
The values of extensions in case of host and service certificates are
following:
·
X509v3
Basic Constraints: critical CA:FALSE
·
X509v3
Key Usage: Digital Signature, Key Encipherment, Data Encipherment
·
X509v3
Extended Key Usage: TLS Web Server Authentication, TLS Web Client
Authentication
· X509v3 CRL Distribution Points
·
X509v3
Authority Key Identifier: <CA key ID>
·
X509v3
Subject Key Identifier: <subject key ID>
· X509v3 Certificates Policies:
·
X509v3
Subject Alternative Name: DNS:FDQN
·
X509v3
Issuer Alternative Name:
No stipulation.
Issuer:
DC=MD,
DC=MD-Grid, O=RENAM, OU=Certification Authority, CN=MD-Grid-CA
Subject:
DC=MD,
DC=MD-Grid, O=XXX, CN=Subject-name
Where XXX is the
name or acronym of the institution. The “CN” field structure for the user or host/service
are described in section 1.3.
In case of person,
the CN part of DN can contain only letters, numbers and following special
characters: left round bracket (‘(’), right round bracket (‘)’), space (‘ ‘)
(at least one space should be used in CN) and hyphen (‘-‘). In case of host and
service, the CN part of DN can contain only letters, numbers and following
special characters: dot (‘.‘) and hyphen (‘-‘). Additionally, in case of grid
service certificate character ‘/’ can be used. The maximal length of the CN is
128 characters for all types of certificates.
Subject
attribute constraints:
Domain Component:
must be “MD”
Domain Component:
must be “MD-Grid”
Organization:
must
be name or acronym of the institution
CommonName:
First
name and last name of the subject for user certificate, DNS FQDN for host
certificate. In case of service certificate the subject name must include the
service name and the DNS FQDN separated by a “/”.
See section 1.2, and OID of the profile on which this CP&CPS is
based.
No
stipulation.
No
stipulation.
No
stipulation.
The MD-Grid CA creates and publish X.509 v2
CRLs.
The CRL extension Authority Key
Identifier will be used in CRLs. CRL entry extensions used are: CRL Number and
CRL Reason Code. They are described in the following sections.
Non-critical extension, a unique
identifier for the CA key as defined in RFC 3280.
Non-critical extension, the number
of current CRL as defined in RFC 3280.
7.2.2.3
CRL Reason Code
Non-critical extension, carrying the
revocation reason code as specified in RFC3280, section 5.3.1.
No
stipulation.
No
stipulation.
No
stipulation.
The
MD-Grid CA must allow to be audited by a member of organization in which
MD-Grid CA is a member of, to verify its compliance with the rules and
procedures specified in this document. Any auditor's costs associated with such
an audit must be covered by the requesting party.
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
No
fees shall be charged.
No
fees shall be charged.
No
fees shall be charged.
No
fees shall be charged.
No
fees shall be charged, so there is no refund policy.
No stipulation.
No
stipulation.
1. Subscriber's e-mail address;
2. Subscriber's name;
3. Subscriber's organization;
4. Subscriber's position;
5. Subscriber's certificate;
No
stipulation.
No
stipulation.
No
stipulation.
This
document is based on:
1. RFC 3647;
2. HellasGrid CA Certificate Policy;
3.
4. UK e-Science CA Certificate Policy;
5.
6. RomanianGRID CA
Certificate Policy;
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
1. MD-Grid CA guarantees to check the identity of the
certification requests according to the procedures described in this document;
2. MD-Grid CA guarantees to check the identity of the
revocation requests according to the procedures described in this document;
3. MD-Grid CA is run on a best effort basis.
4. MD-Grid CA guarantees its service security.
5. MD-Grid CA shall not be held liable for any
problems arising from its operation or improper use of the issued certificates
;
6. MD-Grid CA denies any kind of responsibilities for
damages or impairments resulting from its operation.
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
Subscribers
will not be informed in advance if the CP / CPS document is changed. Differences
are announced to EUGridPMA and get approved before the new CP/CPS is declared
on the website as defined in section 2.3. Changes are published on the website
as well.
No
stipulation.
OID
must change whenever the version of CP/CPS document is updated.
Legal
disputes arising from the operation of the MD-Grid CA will be resolved
according to the Moldovian Law.
The
enforceability, construction, interpretation, and validity of this policy shall
be governed by the Laws of Moldova, republic of.
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
No
stipulation.
The CP/CPS document and all CPS modifications should be approved by the
EuGridPMA before being applied.