The TACC Classic CA Managers must have Linux sysadmin experience as well as experience using and managing grid certificates. Designated L RAs must have experience using and managing grid certificates and familiarity with using the RA web interface . So ftware developers must follow security best practices and test code for potential compromise.
TACC Classic CA personnel will be full -time University of Texas – Austin employees who meet state and university requirements fo r employment. No specific background check is required. Designated L RAs must have official documented standing with both the TACC Classic CA and the organization hosting the L RA and must have authority to perform RA identification functions as stated in a n official letter to the TACC Root CA. A TACC Security Officer accepts this letter . A “Request for TACC L RA Designation” letter template (See Appendix B) is available from the TACC CA website.
TACC Classic CA personnel will rec eive training in: o Security hardware operation of the hardware security module (HSM) . o Web interface usage o Organization, Grid or VO specific identity requirements o Security software maintenance and usage o Physical and procedural security mechanisms.
Retraining shall be mandatory when new software or features, as well as new organizational procedures are introduced.
Not applicable.
In th e event of unauthorized actions, abuse of authority or unauthorized use of entity systems by the CA or RA personnel, the TACC Security Officers may revoke the privileges concerned. Sanctions for unauthorized actions by TACC Classic CA personnel follow Uni versity of Texas personnel policy and procedures.
No stipulation.
All TACC Classic CA personnel shall be provided with all documentation required to successfully perform th eir assigned tasks. Training documentation containing sanitized examples will be provided to TACC Classic CA and L RA personnel on request.
| RFC 2119 Category | Count |
|---|---|
| MUST, REQUIRED, SHALL | 9 |
| SHOULD, RECOMMENDED | 0 |
| MAY, OPTIONAL | 1 |
All ULAGrid CA personnel shall have system administrator experience. ULAGrid Certification Authority CP/CPS 1.0.0 30
• All access to the servers and applications that comprise the ULAGrid service is limited to RedULA system support staff. • The RA Manager must be a staff member of the Physical Organization hosting that Registration Authority and must be appointed by an Authority responsible for a Department within that physical orga nization. The RA Manager must be a member of that Department. The Authority will make a declaration to the CA Manager in writing on the organization's h eaded note paper. The information that must be contained in this letter is defined by the CA Manager. • The RA Operator must be a staff member of the site hosting that Registration Authority and will be appointed by the RA Manager concerned. The RA Manager will make a declaration to the CA Ma nager in writing on the organization's headed note paper. If the RA Operator is appointed in a different department from the RA Manager then the le tter must be countersigned by an authority for the department in which the Operator is a ppointed. The information that must be contained in this letter is defined by th e CA Manager. RA Operators must have certificates and must adhere also to the subscribers’ Obligations. • An RA Manager may appoint himsel f/herself as an RA Operator.
Internal training is given to RedULA CA and RA operators.
Retraining shall be mandatory when new software or features, as well as new organizational procedures are introduced.
No stipulation.
In the event of unauthorized actions, abuse of authority or unauthorized use of entity systems by the CA or RA Operators, th e CA manager may revoke the privileges concerned.
No stipulation.
Personnel has access to a restricted part of ULAGrid CA were all operational procedures can be found, as well as this document. ULAGrid Certification Authority CP/CPS 1.0.0 31
| RFC 2119 Category | Count |
|---|---|
| MUST, REQUIRED, SHALL | 11 |
| SHOULD, RECOMMENDED | 0 |
| MAY, OPTIONAL | 2 |
Each Entity shall identify at least one individual or group responsible and accountable for the operation of each CA in that Entity. For the FBCA, these are the Federal PKI Policy Authority and the FBCA Operational Authority.
All persons filling trusted roles shall be selected on the basis of loyalty, trustworthiness, and integrity, and must be U.S. citizens. The requirements governing the qualifications, selection and oversight of individuals who operate, manage, oversee, and audit the CA shall be set forth in the Entity CA CPS.
FBCA Operational Authority personnel shall hold TOP SECRET security clearances. Entity CA personnel may hold security clearances if deemed appropriate by their respective Entity.
Entity background check procedures shall be described in the CPS and shall demonstrate that Entity requirements set forth in Section 5.3.1 are met.
All personnel performing duties with respect to the operation of the FBCA or Entity CA shall receive comprehensive training. Training shall be conducted in the following areas:
CA/RA security principles and mechanisms All PKI software versions in use on the CA system All PKI duties they are expected to perform Disaster recovery and business continuity procedures.Individuals responsible for PKI roles shall be aware of changes in the FBCA and Entity CA operation. Any significant change to the operations shall have a training (awareness) plan, and the execution of such plan shall be documented. Examples of such changes are FBCA and Entity CA software or hardware upgrade, changes in automated security systems, and relocation of equipment.
No stipulation.
The Federal PKI Policy Authority or Entity CA Policy Authority shall take appropriate administrative and disciplinary actions against personnel who have performed actions involving the FBCA or its repository not authorized in this CP, the FBCA CPS, or other procedures published by the FBCA Operational Authority.
Contractor personnel employed to perform functions pertaining to the FBCA or an Entity CA shall meet applicable requirements set forth in the FBCA CP or Entity CP as determined by the FBCA Operational Authority or the corresponding Entity.
The FBCA and Entity CA shall make available to its CA and RA personnel the certificate policies it supports, relevant parts of the CPS, and any relevant statutes, policies or contracts. Documentation shall be maintained identifying all personnel who received training and the level of training completed.
| RFC 2119 Category | Count |
|---|---|
| MUST, REQUIRED, SHALL | 16 |
| SHOULD, RECOMMENDED | 0 |
| MAY, OPTIONAL | 1 |
Grid and scientific or research organizations or VOs control access to their computation or storage resources by validating identity certificates. Grid organizations or VOs may also establish relationships betwee n multiple CAs (e.g. federation, bridge, subordinate). Any CA entering into an agreement with the TACC Classic CA , for the purposes of transitive trust, agrees that: • Person or User certificates can be used only to authenticate a person as eligible for acce ss to some defined set of scientific computation or storage resources. This authentication may require the signing of Globus proxy certificates. It is expected that participating sites will be collaborating with TACC. While Person or User certificates may be used for other activities such as email signing and encryption, these are not activities supported by TACC personnel . Issued certificates are not suitable for legally binding digital signatures on financial or contractual documents. • Host and Service ce rtificates can be used to identify a named resource or service and for encryption of communication via SSL/TLS. These certificates may be used to authenticate the resource or service to another Grid entity . Rel ying parties may or may not also be subscriber s.
| RFC 2119 Category | Count |
|---|---|
| MUST, REQUIRED, SHALL | 0 |
| SHOULD, RECOMMENDED | 0 |
| MAY, OPTIONAL | 6 |
Relying parties may be: • Natural persons receiving signed e-ma ils, or accessing hosts or services. • Hosts that provide a servi ce to certificate owners. • Services called by owners of a certificate.
| RFC 2119 Category | Count |
|---|---|
| MUST, REQUIRED, SHALL | 0 |
| SHOULD, RECOMMENDED | 0 |
| MAY, OPTIONAL | 1 |
A Subscriber is the entity whose name appears as the subject in a certificate, who asserts that it uses its key and certificate in accordance with the certificate policy asserted in the certificate, and who does not itself issue certificates. FBCA Subscribers include only FBCA Operational Authority personnel and, when determined by the Federal PKI Policy Authority, possibly certain network or hardware devices such as firewalls and routers when needed for infrastructure protection. CAs are sometimes technically considered “subscribers” in a PKI. However, the term “Subscriber” as used in this document refers only to those who request certificates for uses other than signing and issuing certificates or certificate status information.
A Relying Party is the entity that relies on the validity of the binding of the Subscriber's name to a public key. The Relying Party is responsible for deciding whether or how to check the validity of the certificate by checking the appropriate certificate status information. The Relying Party can use the certificate to verify the integrity of a digitally signed message, to identify the creator of a message, or to establish confidential communications with the holder of the certificate. A Relying Party may use information in the certificate (such as certificate policy identifiers) to determine the suitability of the certificate for a particular use.
| RFC 2119 Category | Count |
|---|---|
| MUST, REQUIRED, SHALL | 0 |
| SHOULD, RECOMMENDED | 0 |
| MAY, OPTIONAL | 1 |
Refer to sections 3.1.1 and 3.1.2 .
| RFC 2119 Category | Count |
|---|---|
| MUST, REQUIRED, SHALL | 0 |
| SHOULD, RECOMMENDED | 0 |
| MAY, OPTIONAL | 0 |
• The CN component of the subject name in a certificate fo r a natural person contains the full name as it appears on the authentication document that proves the identity of the subscriber to reduce the possibi lity for name collisions. It is also possible to use a text directly de rived from the full name. • The CN entry for a host shall be the fully qualified domain name (FQDN) as published in DNS that can be univers ally used to access that host. CN=grid001.cecalc.ula.ve • The CN entry for a service shall be the name of the application followed by a slash (“/”) followed by the FQDN of the hos t on which the application is executed. CN=ldap/grid001.cecalc.ula.ve
| RFC 2119 Category | Count |
|---|---|
| MUST, REQUIRED, SHALL | 2 |
| SHOULD, RECOMMENDED | 0 |
| MAY, OPTIONAL | 0 |
Rules for interpreting name forms shall be contained in the applicable certificate profile and are established by the Federal PKI Policy Authority. The authority responsible for Entity CA name space control shall be identified in the respective CP.
| RFC 2119 Category | Count |
|---|---|
| MUST, REQUIRED, SHALL | 2 |
| SHOULD, RECOMMENDED | 0 |
| MAY, OPTIONAL | 0 |