Armenian e-Science Foundation
Armenian e-Science Foundation (http://www.escience.am/) is an Armenian non-profit institution aimed at the introduction and dissemination of e-Science technologies in Armenian scientific, educational and other organizations. One of the main objectives of ArmeSFo is the deployment of the Grid infrastuctures in Armenia. ArmeSFo CA is an Armenian Certification Authority maintained by ArmeSFo as a courtesy service to the e-Science activities in Armenia.
This is a draft document structured according to the memo “Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practice Framework” [RFC 2527]. This document describes the set of rules and operational practices used by the ArmeSFo CA.
The process of establishing that individuals, organizations, or things are who or what they claim to be. In the context of a PKI, authentication can be the process of establishing that an individual or organization applying for or seeking access to something under a certain name is, in fact, the proper individual or organization. This process corresponds to the second process involved with identification as shown in the definition of the “identification” below. Authentication can also refer to a security service that provides assurances that individuals, organizations, or things are who or what they claim to be or that a message or other data originated from a specific individual, organization, or device. Thus, it is said that a digital signature of a message authenticates the message’s sender.
-
The ArmeSFo CA only guarantees to control the identity of the subjects requesting a certificate according to the practices described in this document;
-
The ArmeSFo CA is run on a best effort only basis and does not give any guarantees about the service security or suitability;
-
The ArmeSFo CA does not warrant its procedures and it will take no responsibility for problems arising from its operation or for the use made of certificates it issues;
- The ArmeSFo CA denies any financial or any other kind of responsibilities for damages or impairments resulting from its operation.
Types of information to be kept confidential
The only confidential information kept by ArmeSFo CA is a photocopy of the subscriber’s organization identity card or organization official document proving the relation of the subscriber with the organization.
Types of information not considered confidential
The ArmeSFo CA collects the following information that is not considered confidential:
- The subscriber’s full name;
- A photocopy of the subscriber passport;
- The subscriber’s e-mail address;
- The subscriber’s organization address;
- The subscriber’s certificate request file;
- The subscriber’s public key file.
The information included in issued certificates and CRLs is not considered confidential. Under no circumstances will the ArmeSFo CA have access to the private keys of any subscriber to whom it issues a certificate.
Disclosure of certificate revocation/suspension information
The ArmeSFo CA will notify and inform the following entities:
- The subject of the personal certificate;
- The requestor of the server or service certificate.
Release to law enforcement officials
The information collected by the ArmeSFo CA will be made available to the law enforcement officials upon their request.
Release as part of civil discovery
The information collected by the ArmeSFo CA will be subject to the law of the Republic of Armenia.
Disclosure upon owner’s request
The information collected by the ArmeSFo CA will be subject to the law of the Republic of Armenia.
Other information release circumstances
The information collected by the ArmeSFo CA will be subject to the law of the Republic of Armenia.
Number of registrants: 7
Name Surname
Contacts
Organization
Virtual Organization
Initial Registration
Types of names
Name components vary depending on the type of certificate. Names will be consistent with the name requirements specified in [RFC3280].
The certificate subject name is an X.500 distinguished name. Any name under this CP/CPS starts with a fixed component common to all certificates issued by ArmeSFo CA
C=AM, O=ArmeSFo
The variable component contains the name of the organization (O) with which the subject is officially related. A second optional organizational unit name (OU) must be specified when the certificate subject is related with a sub-organization as branch or department of the main organization. A common name (CN) that uniquely identifies the subject name must follow the organization name. The CN must be obtainable from the subject real name as stated in Section 3.1.2. For a server, the CN is the fully qualified domain name (FQDN) of the server. For a grid host, the CN is the FQDN of the server prefixed with the qualifier “host/”. For a service, the CN is the FQDN of the server prefixed with the service name followed by a slash.
Following this, the distinguished name has one of the following forms:
For issuer
C=AM, O=ArmeSFo, CN=ArmeSFo CA
For persons
C=AM, O=ArmeSFo, O=organizationName, OU=organizationunitName, CN=commonName
Example: C=AM, O=ArmeSFo, O=YerPhI, OU=Experimental Department,
CN= Artem Harutyunyan
For servers
C=AM, O=ArmeSFo, O=organizationName, OU=organizationunitName, CN=server FQDN
Example: C=AM, O=ArmeSFo, O=YerPhI, OU=Experimental Department,
CN= aligrid.yerphi.am
For grid hosts
C=AM, O=ArmeSFo, O=organizationName, OU=organizationunitName, CN=host/server FQDN
Example: C=AM, O=ArmeSFo, O=YerPhI, OU=Experimental Department,
CN= host/aligrid.yerphi.am
For services
C=AM, O=ArmeSFo, O=organizationName, OU=organizationunitName, CN=serviceName/server FQDN
Example: C=AM, O=ArmeSFo, O=YerPhI, OU=Experimental Department,
CN= ldap/aligrid.yerphi.am
Need for names to be meaningful
- The names specified in the common name, in the organization name and in the organizational unit name must be meaningful. The names must be related with the subject organization and with the subject real name.
- For persons, the CN must be obtainable from the legal person name as presented in an official governmental identity document such as a passport or identity card.
- For servers and grid hosts, the CN must be formed from the FQDN.
- For a service, the CN must be related to the type of service and the FQDN of the server where the service is running.
Uniqueness of names
The distinguished name for each certificate must be unique. In case of real subject name duplication, additional numbers and/or letters will be appended to the distinguished name to guarantee uniqueness.
Name claim dispute resolution procedure
No stipulation.
Recognition, authentication and role of trademarks
No stipulation.
Method to prove possession of private key
No stipulation.
Authentication of organization identity
The relation between the subscriber and the organization or organizational unit mentioned in the subject name must be proved through an organization identity card or organization official document stamped and signed by an official representative of the organization. In case of doubt the CA may take any required steps to inquire about the relation of the subscriber with the organization.
Authentication of individual identity
Procedure differs if the subject is a person, server or service:
For person requesting a certificate:
The certificate must be requested from the ArmeSFo CA in person. The person authentication is performed through the presentation of valid official identification documents proving that the subject is an acceptable end entity as defined in the Section of this CP/CPS:
For server or service:
Certificate requests must be sent by e-mail, signed by a valid personal ArmeSFo CA certificate of the corresponding system administrator. The requests must be enclosed in the message body.
Name
grid-cert-request - Generate a X.509 certificate request and corresponding private key
Synopsis
grid-cert-request [-help] [-h] [-?] [-usage]
[-version] [-versions]
grid-cert-request [-cn NAME | -commonname NAME]
[-dir DIRECTORY] [-prefix PREFIX]
[-nopw | -nodes | -nopassphrase]
[-nopw | -nodes | -nopassphrase]
[-ca [HASH]] [-verbose] [-interactive | -int] [-force]
grid-cert-request -host FQDN [-service SERVICE] [-dns FQDN...] [-ip IP-ADDRESS...]
[-dir DIRECTORY] [-prefix PREFIX]
[-ca [HASH]] [-verbose] [-interactive | -int] [-force]
Description
The grid-cert-request program generates an X.509 Certificate Request and corresponding private key for the specified name, host, or service. It is intended to be used with a CA implemented using the globus_simple_ca package.
The default behavior of grid-cert-request is to generate a certificate request and private key for the user running the command. The subject name is derived from the gecos information in the local system's password database, unless the -commonname, -cn, or -host command-line options are used.
By default, grid-cert-request writes user certificate requests and keys to the $HOME/.globus directory, and host and service certificate requests and keys to /etc/grid-security. This can be overridden by using the -dir command-line option.
The full set of command-line options to grid-cert-request are:
-help, -h, -?, -usage
Display the command-line options to grid-cert-request and exit.
-version, -versions
Display the version number of the grid-cert-request command. The second form includes more details.
-cn NAME, -commonname NAME
Create a certificate request with the common name component of the subject set to NAME. This is used to create user identity certificates.
-dir DIRECTORY
Write the certificate request and key to files in the directory specified by DIRECTORY.
-prefix PREFIX
Use the string PREFIX as the base name of the certificate, certificate_request, and key files instead of the default. For a user certificate request, this would mean creating files $HOME/.globus/PREFIXcert_request.pem, $HOME/.globus/PREFIXcert.pem, and $HOME/.globus/PREFIXkey.pem.
-ca CA-HASH
Use the certificate request configuration for the CA with the name hash CA-HASH instead of the default CA chosen by running grid-default-ca.
-verbose
Keep the output from the OpenSSL certificate request command visible after it completes, instead of clearing the screen..
-interactive, -int
Prompt for each component of the subject name of the request, instead of generating the common name from other command-line options. Note that CAs may not sign certificates for subject names that don't match their signing policies.
-force
Overwrite any existing certificate request and private key with a new one.
-nopw, -nodes, -nopassphrase
Create an unencrypted private key for the certificate instead of prompting for a passphrase. This is the default behavior for host or service certificates, but not recommended for user certificates.
-host FQDN
Create a certificate request for use on a particular host. This option also causes the private key assoicated with the certificate request to be unencrypted. The FQDN argument to this option should be the fully qualified domain name of the host that will use this certificate. The subject name of the certificate will be derived from the FQDN and the service option if specified by the -service command-line option. If the host for the certificate has multiple names, then use either the -dns or -ip command-line options to add alternate names or addresses to the certificates.
-service SERVICE
Create a certificate request for a particular service on a host. The subject name of the certificate will be derived from the FQDN passed as the argument to the -host command-line option and the SERVICE string.
-dns FQDN,...
Create a certificate request containing a subjectAltName extension containing one or more host names. This is used when a certificate may be used by multiple virtual servers or if a host has different names when contacted within or outside a private network. Multiple DNS names can be included in the extension by separating then with a comma.
-ip IP-ADDRESS,...
Create a certificate request containing a subjectAltName extension containing the IP addresses named by the IP-ADDRESS strings. This is used when a certificate may be used by services listening on multiple networks. Multiple IP addresses can be included in the extension by separating then with a comma.
Examples
Create a user certificate request:
% grid-cert-request
A certificate request and private key is being created.
You will be asked to enter a PEM pass phrase.
This pass phrase is akin to your account password,
and is used to protect your key file.
If you forget your pass phrase, you will need to
obtain a new certificate.
A private key and a certificate request has been generated with the subject:
/O=org/OU=example/OU=grid/CN=Joe User
If the CN=Joe User is not appropriate, rerun this
script with the -force -cn "Common Name" options.
Your private key is stored in /home/juser/.globus/userkey.pem
Your request is stored in /home/juser/.globus/usercert_request.pem
Please e-mail the request to the Example CA [email protected]
You may use a command similar to the following:
cat /home/juser/.globus/usercert_request.pem | mail [email protected]
Only use the above if this machine can send AND receive e-mail. if not, please
mail using some other method.
Your certificate will be mailed to you within two working days.
If you receive no response, contact Example CA at [email protected]
Create a host certificate for a host with two names.
% grid-cert-request -host grid.example.org -dns grid.example.org,grid-internal.example.org
A private host key and a certificate request has been generated
with the subject:
/O=org/OU=example/OU=grid/CN=host/grid.example.org
----------------------------------------------------------
The private key is stored in /etc/grid-security/hostkey.pem
The request is stored in /etc/grid-security/hostcert_request.pem
Please e-mail the request to the Example CA [email protected]
You may use a command similar to the following:
cat /etc/grid-security/hostcert_request.pem | mail [email protected]
Only use the above if this machine can send AND receive e-mail. if not, please
mail using some other method.
Your certificate will be mailed to you within two working days.
If you receive no response, contact Example CA at
Environment Variables
The following environment variables affect the execution of grid-cert-request:
X509_CERT_DIR
Path to the directory containing SSL configuration files for generating certificate requests.
GRID_SECURITY_DIR
Path to the directory containing SSL configuration files for generating certificate requests. This value is used if X509_CERT_DIR is not set.
GLOBUS_LOCATION
Path to the directory containing the Globus Toolkit. This is searched if neither the X509_CERT_DIR nor the GRID_SECURITY_DIR environment variables are set.
Files
$HOME/.globus/usercert_request.pem
Default path to write a user certificate request.
$HOME/.globus/usercert.pem
Default path to write a user certificate.
$HOME/.globus/userkey.pem
Default path to write a user private key.
/etc/grid-security/hostcert_request.pem
Default path to write a host certificate request.
/etc/grid-security/hostcert.pem
Default path to write a host certificate.
/etc/grid-security/hostkey.pem
Default path to write a host private key.
TRUSTED-CERT-DIR/globus-user-ssl.conf, TRUSTED-CERT-DIR/globus-user-ssl.conf.CA-HASH
SSL configuration file for requesting a user certificate. The first form is the default location, the second form is used when the -ca command-line option is specified.
TRUSTED-CERT-DIR/globus-host-ssl.conf, TRUSTED-CERT-DIR/globus-host-ssl.conf.CA-HASH
SSL configuration file for requesting a host or service certificate. The first form is the default location, the second form is used when the -ca command-line option is specified.
Author
University of Chicago
Certificate re-keying request
Re-keying is allowed to subscribers of ArmeSFo CA before the expiration of their current personal/host/server/service certificate. Subscribers must generate a new key pair and send the CR to RA via e-mail, signed by the private key associated with the current valid certificate.
The personal/host/server/service certificate re‐keying request must be sent not sooner than 30 days before and not later than 10 days before expiration of the current certificate.
The subject DN and e-mail address in the CR must be the same as those in the current valid certificate.
Below is the example of user certificate re-keying request:
Send digitally signed message to ArmeSFo CA using the following e-mail address: [email protected]
The subject of your message should be: Certificate re-keying request of
The body of your message should be:
Dear ArmeSFo CA,
I send you Certificate re-key request.
I have read the ArmeSFo CA CP/CPS and ‘Minimum Security Requirements of
ArmeSFo CA’ to subscribers and agree to follow these documents.
The current certificate is valid till
The CR is attached bellow.
Below is the example of server/host or service certificate re-keying request:
Send digitally signed message to ArmeSFo CA using the following e-mail address: [email protected]
The subject of your message should be: Certificate re-keying request of
The message body should be:
Dear ArmeSFo CA,
As administrator of the
I send you certificate re-key request for .
Current certificate of is valid till
The CR is attached bellow.
Certificate Revocation Request
Anyone can submit CRR to ArmeSFo CA. However, any CRR requestor must be authenticated and her/his CRRs must be validated, unless the ArmeSFo CA can independently verify that security requirements to the key protection have been violated.
ArmeSFo CA accepts the following authentication and validation procedure for CRRs:
In case of the personal certificate revocation requested by user:
l If the subscriber has access to the key associated with her/his certificate, (s)he must send to ArmeSFo CA an e-mail with CRR, signed with the private key associated to the certificate requested to revoke;
l If the private key is lost or corrupted, (s)he must send CRR to RA by e-mail or by any other way. The RA appoints a face-to-face meeting with subscriber. The subscriber presents at the meeting her/his passport.
In case of the ‘host’ certificate revocation requested by administrator: send an e-mail to ArmeSFo CA signed with the personal private key of the ‘host’ administrator;
Below is the example of CRR for the user in case of lost or corrupted private key.
Send message to Registration Authority who has performed your authentication
The subject of your message should be: Certificate revocation request from <your full name>
The body of your message should be:
Dear RA,
<the reason of your revocation request>
<your full name>
Below is the example of CRR for server/host or service.
Send digitally signed message to Registration Authority of ArmeSFo CA.
The subject of your message should be: Certificate revocation request of <the CN of the host/server/service>
The body of your message should be:
Dear RA,
<the reason of your revocation request>
<your full name>
The ArmeSFo CA is managed by the CP&IT Division at Alikhanyan National Science Laboratory.
AANL CP&IT Division
2 Alikhanian Brothers Street
0036 Yerevan Armenia
Phone: (+37410) 342088
Email: [email protected]
ArmeSFo CA contact person at AANL
Robert Avetyan
Email: [email protected]