forked from hellasgrid/hellasgrid-ca-cp-cps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
chapter3_identification_authentication.tex
95 lines (52 loc) · 6.82 KB
/
chapter3_identification_authentication.tex
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
\chapter{IDENTIFICATION AND AUTHENTICATION}
\section{Naming}
\subsection{Types of names}
\label{sub:TypesOfNames}
The subject names for the certificate applicants shall follow the X.500 standard:
\begin{enumerate}
\item{in case of user certificate the subject name must include the person's name in the commonName component;}
\item{in case of host certificate the subject name must include the DNS FQDN in the commonName component;}
+\item{in case of service certificate the subject name must include the service name and the DNS FQDN separated by a '/' in the commonName component;}
+\item{in case of robot certificate the commonName component of the subject name must include the string 'Robot' followed by a humanly recognizable and meaningful description of the Robot along with an electronic mail address of the person or a persistent group of persons responsible for the robot operations separated from the 'Robot' string by a COLON ':'.}
\end{enumerate}
\subsection{Need for names to be meaningful}
The subject name must represent the subscriber in a way, that is understandable by humans.
In addition, see subsection \ref{sub:TypesOfNames}.
\subsection{Anonymity or pseudonimity of subscribers}
HellasGrid CA neither issues nor signs pseudonymous or anonymous certificates.
\subsection{Rules for interpreting various name forms}
See subsection \ref{sub:TypesOfNames}.
\subsection{Uniqueness of names}
\label{sub:UniquenessOfNames}
The subject name listed in a certificate shall be unambiguous and unique for all end entities to whom certificates have been issued by the HellasGrid CA. In the case of personal certificates, additional numbers or letters may be appended to the real name of the subscriber, when necessary, in order to ensure the uniqueness of the name within the domain of certificates issued by the HellasGrid CA.
\subsection{Recognition, authentication, and role of trademarks}
No stipulation.
\section{Initial identity validation}
\subsection{Method to prove possession of key}
The HellasGrid CA proves possession of the private key, that is the companion to the HellasGrid CA certificate, by signing certificates and CRLs.
The HellasGrid 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 the 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 HellasGrid CA will not generate the key pair on behalf of subscribers and will not accept or retain private keys generated by subscribers.
\subsection{Authentication of organization identity}
HellasGrid CA does not authenticate organization identity.
\subsection{Authentication of individual identity}
\label{sub:AuthenticationOfIndividualIdentity}
\paragraph{Physical Person:} The subject must contact the RA in person, in order to verify his/her identity and the validity of the request. The authentication of the subject is performed through the presentation of a valid photo ID document (national ID, passport, driver license etc). The subject must also provide a copy of the receipt he or she received after the successful submission of his/her request and present a valid official document stating his/her relationship with the organization (or one of the organizations) the RA is serving. [see subsections \ref{sub:Subscribers} and \ref{sub:ValidationOfAuthority}]. In cases where the subject resides in a geographical location where access to an RA is not possible, identity vetting may be performed via video call. In this case, an authenticated photocopy of the required document (national ID, passport, driver license etc) must be delivered by mail or courier service to the RA prior to this online meeting.
\paragraph{Digital Processing Entity or Service:} The entity must already have a valid DNS entry and be an acceptable end entity as defined in this document [see subsection \ref{sub:Subscribers}]. The system administrator requesting the certificate must use his/her personal HellasGrid CA certificate to authenticate to the HellasGrid CA web portal in order to submit the certificate request. The nearby RA must verify the relation between the host/service and the requestor.
\paragraph{Robot:} The entity must be an acceptable end entity as defined in this document [see subsection \ref{sub:Subscribers}]. At least one of the responsible persons for the operations of the Robot must use his/her personal certificate, issued by an IGTF accredited CA, to authenticate to the HellasGrid CA web portal in order to submit the certificate request.
\subsection{Non-verified subscriber information}
The telephone number of the user is not verified by HellasGrid CA.
\subsection{Validation of Authority}
\label{sub:ValidationOfAuthority}
The subscriber requesting services from the HellasGrid CA must present valid documents stating his/her affiliation with the organization.
\subsection{Criteria of interoperation}
HellasGrid CA is member of IGTF and as such the basic criterium for interoperation is the accreditation based on the adherence to the IGTF minimum requirements.
\section{Identification and authentication for re-key requests}
\subsection{Identification and authentication for routine re-key}
Expiration warnings will be issued to subscribers when re-key time arrives. re-key before expiration can be accomplished by logging into the HellasGrid CA web portal using his/her valid HellasGrid CA user certificate and requesting for re-key. Re-key after expiration follows the same authentication procedure as when requesting for a new certificate. At least once every five years the user has to be authenticated by an RA as when requesting a new certificate.
\subsection{Identification and authentication for re-key after revocation}
After the revocation of a certificate, the subscriber must generate a new key pair in order to request for a new certificate and follow the rules specified in section \ref{sub:AuthenticationOfIndividualIdentity}.
\section{Identification and authentication for revocation request}
Certificate revocation requests should be submitted to Hellasgrid CA via e-mail [see subsection \ref{sub:OrganizationAdministeringTheDocument}] or through the HellasGrid CA web portal.
In case the revocation request is for a user certificate, the e-mail must be signed by the private key corresponding to a valid HellasGrid CA certificate.
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 signed e-mail or submission through the HellasGrid CA web portal is not an option, the request will be authenticated using the procedure described in section \ref{sub:AuthenticationOfIndividualIdentity}.