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: 5
Name Surname
Contacts
Organization
Virtual Organization
Norayr Akopov
[email protected]
A.Alikhanyan National Laboratory
belle
Gevorg Karyan
[email protected]
A.Alikhanyan National Laboratory
belle
Hazaravard Ghumaryan
[email protected]
A.Alikhanyan National Laboratory
belle
Gayane Gevondyan
[email protected]
A.Alikhanyan National Laboratory
belle
Gevorg Nazaryan
[email protected]
A.Alikhanyan National Laboratory
belle

    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
    [email protected]
    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
     

    Instructions for requesting personal, server/host or service certificates from Armenian e-Science Foundation Certification Authority (ArmeSFo CA)

    1        Introduction

    This document describes the steps, which have to be done in order to request personal, server, host or service certificates from ArmeSFo CA. It is based on the ArmeSFo CA Certificate Policy and Certification Practice Statement (CP/CPS) document available at http://www.escience.am.

     

    Before starting the process of application for ArmeSFo CA certificate, you have to read the ArmeSFo CA CP/CPS, understand its policy, requirements to the certificate requestors, obligations of the subscribers of the ArmeSFo CA certificates and agree to follow the CP/CPS and all operational procedures derived from this document.

     

    2    Who can request ArmeSFo CA certificate?

    ArmeSFo CA issues certificates to physical persons, servers, hosts and services. The entities that are eligible for certification by the ArmeSFo CA are all those entities related to the organisations formally based in and/or having offices inside the Republic of Armenia, that are involved in the research or deployment of multi-domain distributed computing infrastructures, intended for cross-organisational sharing of resources.

    3    Choose the subject distinguished name (DN) of the certificate

    Requesters of the certificate have to determine the subject DN of the certificate before they apply for a certificate. You can write down the subject DN on the paper to use it when generating certificate request.

     

    The use of printable characters in the DN: The following characters are allowed: Upper and lower case letters: ‘a’-‘z’, ‘A’-‘Z’,

    Numbers: ‘0’-‘9’,

    Characters: ‘(‘, ‘)’, ‘+’, ‘,’, ‘-‘, ‘.’, ‘:’, ‘?’, ‘ ‘,‘/’, that is, left and right parentheses, plus, comma, minus/hyphen, dot (period), colon, question mark, space and forward slash.

    Note: In order the forward slash to be interpreted by openssl as a standard visible character it must be prefixed by the backslash (‘’).

     


    The subject DN must have the following form:

    “/C=AM/O=ArmeSFo/O=organisationName/OU=organisationalUnitName/CN=common Name”.

    You have to replace organisationName and organisationalUnitName and commonName

    with relevant to your organisation and organisational unit names.

    The value of the commonName will correspond either to your full name (for personal certificate) or to the server/host name (for server/host certificate), or to the service name (for service certificate)

    3.1     organisationName

    Use the official acronym of your organisation/institution.

    For example, if you are working in the Yerevan Physics Institute, choose

    ‘O=YerPhI’

    If your organisation has no official acronym, choose its full official name. For example, ‘O= Some Institute’

    3.2     organisationalUnitName

    Put the official acronym or the full name of your division/department/laboratory in the organisation

    For example, ‘OU=Experimental Division’

    3.3     commonName

    The commonName value in CN field differs in the case of personal, server/host and service certificates.

    3.3.1    commonName for personal certificates

    Put your common name in the form For example: ‘CN=Hakob Hakobyan’

    Please note, that your first and last names must be identical to those in your passport. Do not write CN=Hakob Hakobian if you have Hakob Hakobyan in your passport.

    3.3.2      commonName for server/host certificates

    The value of commonName for a server/host is its fully-qualified domain name (FQDN). For example, ‘CN=aligrid1.yerphi.am’

    3.3.3      commonName for service certificate

    The value of commonName for a service is the service name separated by slash from fully-qualified domain name (FQDN) of the server/host where the service runs

    For example, ‘CN=ldap/aligrid1.yerphi.am’


    4    Generate certificate request (CR)

    The instructions given in this section assume that you are using Unix-like OS with OpenSSL software included in. If you are user of the other operating system, refer to https://www.openssl.org/community/binaries.html page.

    In the commands presented below ‘$’ represents the shell prompt (it should not be typed!).

     

    If you are planning to have certificate for working in Grid, issue the following commands:

    $   mkdir ~/.globus

    $   cd ~/.globus

     

    If you are not planning to work in Grid, we advise you to issue the following commands:

    $   mkdir ~/.private

    $   cd ~/.private

    Run the following command to generate your CR:

    $ openssl req -sha512 -newkey rsa:2048 -keyout userkey.pem -out userreq.pem - subj

     

     

    Note: This command should be typed as one line and you have to replace

    with actual subject DN string as described in the previous section.

     

    Examples of subject DN strings:

    for personal certificate: “/C=AM/O=ArmeSFo/O=YerPhI/OU=Experimental

    Division/CN=Hakob Hakobyan”

    for server/host certificate: “/C=AM/O=ArmeSFo/O=YerPhI/OU=Experimental

    Division/CN=aligrid1.yerphi.am”

    for service certificate:      “/C=AM/O=ArmeSFo/O=YerPhI/OU= Experimental

    Division/CN=ldap/aligrid1.yerphi.am”

     

    You will be asked for your private key password – choose one with at least 12 characters long (see ArmeSFo CA CP/CPS, Section 1.1.1, Strong pass-phrase).

    As a result, you will get 2048-bit RSA private and public key pair. The private key is stored in the file userkey.pem, while the public key is stored together with the DN in the file userreq.pem.

     

    Change the permissions of your private key file:

     

    $ chmod 400 userkey.pem


    5.  Verify the subject DN of your CR:

    $ openssl req -in userreq.pem -subject -noout

     

    6.  Your steps after generation of CR:

    6.1     Read the ‘Minimum Security Requirements of ArmeSFo CA’ (http://www.escience.am)

     

    6.2     If you are requesting user certificate, then

     

    6.2.1    Copy the userreq.pem file to the USB flash or CD/DVD, or floppy disk.

     

    6.2.2    Prepare following documents and data: Your passport (or ID card),

    Copy of your passport (ID card),

    Official document from your organisation proving your relations with the organisation, signed and stamped by an official representative of the organisation. See Appendix for an example of such document.

           Your work e-mail address and personal phone number

     

     

    Note: ArmeSFo CA does not accept the e-mail addresses at social mail servers like yahoo.com, gmail.com, mail.ru, list.ru, rambler.ru, etc. The CRs sent from these addresses will be rejected.

     

    6.2.3     Send message to Registration Authority of ArmeSFo CA in ArmeSFo using the following e-mail address:

    [email protected]

    The subject of your message should be:

    User certificate request from

     

    The body of your message should be:

    Dear RA,

    I have read the ArmeSFo CA CP/CPS and ‘Minimum Security Requirements of ArmeSFo CA’ to subscribers and agree to follow these documents. I would like to meet with the personnel of ArmeSFo RA in order to present my CR and requested documents.

     

    The RA will appoint a face-to-face authentication meeting with you, where you will present the requested data, documents and CR.


    6.3    If you are requesting server/host or service certificates (you can do that only if you have a valid ArmeSFo CA user certificate and you are the system administrator of the server/host), then your steps are as follows:

     

    6.3.1        Using your private key and certificate, you have to generate the user certificate in pkcs#12 format, which is used for signing the message.

    Create the pkcs#12-format certificate with the following command:

    $ openssl pkcs12 -export -in usercert.pem -inkey userkey.pem -out usercert.p12

    You will be asked for two passwords: the password of the private key, which was set when generating the key pair and the password for creating pkcs#12 file (asked twice)

    6.3.2      Install a mail agent that handles with the certificates in pkcs#12 format (we recommend the Open Source mail agent Thunderbird available for both Windows and Linux platforms http://www.mozilla.com/en-US/thunderbird/) and import to the agent usercert.p12 and ArmeSFo CA root certificate (from http://escience.am/ca/cacert/cacert.pem).

    6.3.3      Send digitally signed message to [email protected]

    The subject of your message should be: (Host, Server, Service) certificate request for .

     

    The message must contain short description of the purpose of the use of the (host, server, service) certificate.

    The message must also contain the statement that you are the administrator of the host/server.

     

     

    Note: The content of certificate request file has to be included in the body of the message.

     

     

    7 Certificate delivery to subscribers

    The accepted CRs will be sent to ArmeSFo CA for the certificate issuance. As soon as the certificate is issued, it will be sent to you by ArmeSFo CA via digitally signed e-mail.

     

    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]