Pacific
Rim Application and Middleware Assembly - UCSD (PRAGMA-UCSD)
Certificate Policy and Certification Practice Statement
Version 1.0 ( June 25, 2008 )
Pacific Rim Application and Middleware Assembly (PRAGMA),
2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
3. IDENTIFICATION AND AUTHENTICATION
4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS
6. TECHNICAL SECURITY CONTROLS
7. CERTIFICATE, CRL, AND OCSP PROFILES
8. COMPLIANCE AUDIT AND OTHER ASSESSMENT
9. OTHER BUSINESS AND LEGAL MATTERS
1.2. Document Name and Identification
2. PUBLICATION AND REPOSITORY RESPONSIBILITIES
2.2. Publication of certification information
2.3. Time or frequency of publication
2.4. Access controls on repositories
3. IDENTIFICATION AND AUTHENTICATION
3.2. Initial identity validation
3.3. Identification and authentication for re-key
requests
3.4. Identification and authentication for
revocation request
4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS
4.2. Certificate application processing
4.5. Key pair and certificate usage
4.9. Certificate revocation and suspension
4.10. Certificate status services
5. MANAGEMENT, OPERATIONAL, AND PHYSICAL CONTROLS
5.1. Physical security controls
5.3. Personnel security controls
5.7. Compromise and disaster recovery
6. TECHNICAL SECURITY CONTROLS
6.1. Key pair generation and installation
6.2. Private Key Protection and Cryptographic
Module Engineering Controls
6.3. Other aspects of key pair management
6.5. Computer security controls
6.6. Life cycle technical controls
6.7. Network security controls
7. CERTIFICATE, CRL, AND OCSP PROFILES
8. COMPLIANCE AUDIT AND OTHER ASSESSMENT
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.3. Confidentiality of business information
9.4. Privacy of personal information
9.5. Intellectual property rights
9.6. Representations and Warranties
9.7. Disclaimers of warranties
9.11. Individual notices and communications with
participants
9.13. Dispute resolution provisions
9.15. Compliance with applicable law
9.16. Miscellaneous provisions
1. Introduction[Content] [RFC3647]
1.1. Overview[Content]
，
This document is structured
according to the RFC3647.
，
Not all sections of RFC3647 are
used. Sections that are not included have a default value of "No
stipulation."
，
This document describes the set
of rules and procedures established by the Pacific Rim Application and
Middleware Assembly Certificate Authority (
，
This document will include both
the Certificate Policy and the Certificate Practice Statement for the PRAGMA
GRID PKI which is a traditional X.509 Public Key Certificate Authority that
complies with the "Profile for a traditional X.509 Public Key Certificate
Authorities with secure infrastructure"* of IGTF.
* http://www.eugridpma.org/guidelines/IGTF-AP-classic-4-1.pdf
，
An intention of the PRAGMA-UCSD CA PKI is to issue identity certificates for
use in grid.
1.2. Document Name and Identification[Content]
，
Document title:
，
Document version: 1.0
，
Document date: June 25, 2008
，
OID:
The following ASN.1 Object Identifier (OID) has been assigned to this document:
1.3.6.1.4.1.13230.101.2.1.0
This OID is constructed as shown in the table below:
|
IANA |
1.3.6.1.4.1 |
|
|
.13230 |
|
|
.101 |
|
CP/CPS |
.2 |
|
Major Version |
.1 |
|
Minor Version |
.0 |
1.3. PKI Participants[Content]
1.3.1.
Certification Authority
The PRAGMA-UCSD CA issues public key certificates for users
and hosts. The PRAGMA-UCSD CA does not issue certificates to subordinate
certification authorities.
1.3.2. Registration Authorities
The PRAGMA-UCSD
Registration Authority (RA) is responsible for the authentication of individual
identity of the requestor of certificates. The role of the PRAGMA-UCSD RA is
clearly separated from the role of the PRAGMA-UCSD CA and the PRAGMA-UCSD RA is
not allowed to issue certificates under this CP/CPS.
1.3.3. Subscribers (End Entities)
The PRAGMA GRID PKI issues person and host certificates to members of
PRAGMA and other individuals working on
，
Programs involved in PRAGMA
，
Grid projects in collaboration
with PRAGMA
The term end entity is used to refer to the holder of the private
key. For a person certificate it will be the subscriber, but for a host or
service certificate the end entity may be some process running on a machine.
The subscriber is required to:
- read and adhere to the procedures published in this document.
- generate a key pair using Naregi-CA
software client which uses a securely encrypted Lightweight Certificate Management Protocol (LCMP) to communicate with
RA server.
- take reasonable precautions to prevent any loss, disclosure or unauthorized
use of the private key associated with the certificate, including:
，
for user certificates
o
selecting a pass phrase of at
minimum 12 alphanumeric characters
o
protecting the pass phrase from
others
o
always using the pass phrase to
encrypt the stored private key
o
never sharing the private key
with other users
，
for host/service certificates
o
storing them encrypted whenever
possible
o
providing correct information and
authorize the publication of the certificate.
o
using the certificates for the
permitted uses only.
- Employees of PRAGMA Grid member institutes
- Employees of international research institutes which collaborate with PRAGMA
in Grid computing area.
- Resource-sharing organizations with PRAGMA
Relying parties' obligations are as follows:
- Must read the procedures published by the PRAGMA-UCSD CA.
- Must use the certificates for the permitted uses only.
- Must notify
- May verify that the certificate is not on the CRL before validating a
certificate.
1.3.5 Policy
Management Authority
PRAGMA-UCSD
Policy Management Authority (PMA) is responsible for defining the policy of the
PRAGMA-UCSD CA and approving the PRAGMA-UCSD CA¨s CP/CPS.
1.4. Certificate Usage[Content]
1.4.1. Appropriate
certificate uses
Certificates
from
1.4.2.
Prohibited certificate uses
Certificates
issued by the CA must not be
used for:
，
Electronic commerce.
，
Any application requiring
fail-safe performance, including those associated with, but not limited to:
o
The operation of nuclear
facilities;
o
Air traffic control systems;
o
Aircraft navigation systems;
o
Hospital life support systems;
o
Municipal water treatment plants;
o
Weapons control systems; or
o
Any other system whose failure
could lead to injury, death, damage to property or environmental damage.
，
Transactions where applicable law
prohibits the use of digital signatures for such transactions or where
otherwise prohibited by law; or
，
Unless supported by other
appropriate security mechanisms and procedural safeguards, the protection of:
o
Information that, if compromised,
could cause extremely grave injury outside the national interest; or
o
Classified information.
1.5. Policy Administration[Content]
1.5.1.
Organization administering the document
1.5.2.
Contact person
For inquiries regarding this document or the PRAGMA GRID PKI
service in general, please contact:
PRAGMA-UCSD
CA/RA:
Cindy Zheng /Luca Clementi / Nadya Williams
PRAGMA-UCSD CA Management Team, PRAGMA
University of California, San Diego
Phone:
+1-858-534-5048
Fax: +1-858-534-5035
Email: pragma-ucsd-ca@sdsc.edu
PRAGMA-UCSD PMA:
Yoshio Tanaka
National Institute
of Advanced Industrial Science and Technology,
Tsukuba
Central 2, 1-1-1, Umezono,
Tsukuba,
Ibaraki 305-8568, Japan
Tel: +81-29-861-5356
Fax: +81-29-862-6601
Email: yoshio.tanaka@aist.go.jp
1.5.3.
Person determining CPS suitability for the policy
PRAGMA-UCSD
PMA is responsible for determining CPS suitability for the policy.
1.5.4.
CPS approval procedures
The PRAGMA-UCSD CA is responsible for maintaining the CP
and CPS. The
modification must be authorized by the PRAGMA-UCSD PMA.
For the global grid collaboration,
Major changes must be approved by the APGrid PMA community.
Minor changes can be done by
1.6. Definitions and
Acronyms[Content]
Certification authority (CA)
An authority trusted by one or more users to create and assign public key certificates.
Optionally the CA may create the user's keys. The CA is responsible for the
public key certificates during their whole lifetime, not just for issuing them.
CA certificate
A certificate for one CA's public key issued by another CA.
Certificate policy (CP)
A named set of rules that indicates the applicability of a certificate to a
particular community or class of application with common security requirements.
For example, a particular certificate policy might indicate applicability of a
type of certificate to the authentication of electronic data interchange
transactions for the trading of goods within a given price range.
Certification path
An ordered sequence of certificates that, together with the public key of the
initial object in the path, can be processed to obtain that of the final object
in the path.
Certification practice statement (CPS)
A statement of the practices that a certification authority employs in issuing
certificates.
Certificate revocation list (CRL)
A time stamped list identifying revoked certificates, which is signed by a CA
and made freely available in a public repository.
Issuing certification authority (issuing CA)
The CA that issues the certificate (see also Subject certification authority).
Public key certificate (PKC)
A data structure containing the public key of an end entity and some other
information, which is digitally signed with the private key of the CA that
issued it.
Public Key Infrastructure (PKI)
The set of hardware, software, people, policies and procedures needed to
create, manage, store, distribute, and revoke PKCs based on public key
cryptography.
Registration authority (RA)
An entity that is responsible for identification and authentication of
certificate subjects but that does not sign or issue certificates (i.e., an RA
is delegated certain tasks on behalf of a CA). The term Local Registration
Authority (LRA) is used elsewhere for the same concept.
Relying party
A recipient of a certificate who acts in reliance on that certificate or on
digital signatures verified using that certificate. In this document, the terms
"certificate user" and "relying party" are used
interchangeably.
Subject certification authority (subject CA)
In the context of a particular CA-certificate, the subject CA is the CA whose
public key is certified in the certificate.
2. Publication and
Repository Responsibilities[Content]
[RFC3647]
2.1. Repositories[Content]
，
The PRAGMA-UCSD CA online
repository is available at http://ca.pragma-grid.net
2.2. Publication of certification information[Content]
，
，
End entity certificates issued by
the PRAGMA-UCSD CA
，
CRLs(Certificate Revocation List)
issued by
，
，
A copy of this Policy (CP/CPS)
，
All the CP/CPS under which valid
certificates are issued
，
Other information relevant to the
PRAGMA GRID PKI
2.3. Time or frequency of publication[Content]
，
Certificates must be published as
soon as issued.
，
CRLs will be published as soon as
issued or refreshed on scheduled update
，
All PRAGMA GRID PKI documents
will be published to the online repository as they are updated.
2.4. Access controls on repositories[Content]
，
The online repository is
available on a substantially 24/7 basis, subject to reasonable scheduled
maintenance.
，
The PRAGMA-UCSD CA does not
impose any access control on the information described in section
2.2.
3. Identification and
Authentication[Content]
[RFC3647]
3.1. Naming[Content] [RFC3647]
3.1.1.
Types of names
Identification of certificates will
be according to X.500 distinguished name. (RFC2459)
The DN must be in the form of a X.501 printable string and must not be blank.
The following table shows attribute values for name.
Both the Organization Name 3 and Common Name are decided based on the data
provided by subscribers when requesting certificates.
|
attributes |
meaning |
value |
|
DomainComponent1 |
Level 1
domain name |
NET |
|
DomainComponent2 |
Level 2
domain name |
PRAGMA-GRID |
|
OrganizationUnit |
Organization
unit name |
Based on
application information |
|
CommonName |
User
name(client certificate) |
Based
on application information |
|
Host
name(host certificate) |
Based
on application information |
3.1.2. Need for names to be meaningful
The Subject Name in a certificate MUST have a reasonable
association with the End Entity.
Each host certificate must be linked to a single network entity.
The common name of the host certificate must be the FQDN of the host.
3.1.3. Anonymity or pseudonymity of subscribers
The subscribers can not be anonymous or pseudonymous.
3.1.4. Rules for interpreting various name forms
See Section 3.1.1.
，
The Distinguished Name(DN) must be
assigned unique among certificates issued by the PRAGMA-UCSD CA.
，
For user certificates each CN
component will include the full name of the subscriber. In case of name
conflict, RA will instruct the user to add a prefix or suffix of the user¨s choosing
to the common name to achieve uniqueness. All DNs of issued certificates are
maintained at the online repository. RA will verify the uniqueness by comparing
a new DN with the DNs of all issued certificates.
3.1.6. Recognition, authentication, and role of trademarks
No Stipulation
3.1.6. Recognition, authentication and role trademarks
No Stipulation
3.2. Initial Identity
Validation[Content] [RFC3647]
3.2.1.
Method to prove possession of private key
3.2.2. Authentication of organization identity
The PRAGMA-UCSD CA verifies the identity of organizations by
checking that the organization is known to the PRAGMA communities.
3.2.3. Authentication of individual identity
，
User: A person who requests a
user certificate will be identified by in person or via video conference
interview with the RA. In case of using video conference
interview, a copy of the photo ID card with a photo image on it
must be faxed to the RA before the interview.
，
Host certificate: Requests must
be authorized as a legal subscriber of the CA. The PRAGMA-UCSD RA also
ensures that the requestor is appropriately authorized by the owner of the FQDN
or the responsible administrator of the machine to use the FQDN identifiers
asserted in the certificate.
3.2.4. Non-verified subscriber information
No Stipulation
3.2.5. Validation of authority
No Stipulation
3.2.6. Criteria for interoperation
No Stipulation
3.3. Identification and
Authentication for Re-key Requests[Content] [RFC3647]
3.3.1.
Identification and authentication for routine re-key
See
section 4.7.2.
3.3.2. Identification
and authentication for re-key after revocation
Rekey after revocation follows the same rules as an initial
registration.
3.4. Identification and
Authentication for Revocation Requests[Content]
Revocation request must be emailed to pragma-ucsd-ca@sdsc.edu. The
PRAGMA-UCSD CA or an authorized RA will verify the requestor¨s identity and the
validity of the request by interviewing the requestor face-to-face, or via video conference, or
pre-registered skype.
4. Certificate Life-Cycle
Operational Requirements[Content]
[RFC3647]
4.1. Certificate Application[Content] [RFC3647]
Certificate Application Process is as follows:
，
A user who requests a user
certificate must have a face-to-face or video conference meeting with the RA
and personally deliver or fax a user
application form to the RA. (The application form is available from the PRAGMA-UCSD
CA web site).
，
The RA examines the request
according to section 3.2.
，
Once the user is identified, the
RA will put his/her signature on the user application form.
，
The RA will personally deliver the
application form to the CA.
，
If the application form is
approved, the PRAGMA-UCSD CA will inform the user of the fact that the
application form has been approved by sending him/her the Naregi-CA client
software package, user guide and a license key.
，
The user will follow the user
guide, install the Naregi-CA client software and use the license key given to
make the certificate request. License key is encrypted and sent to the
requestor by an email. The passphrase for decrypting the encrypted license key
will be sent to the requestor by a fax.
，
Host certificate request is the
same as the user certificate and requires the same enrollment process.
4.2. Certificate Application Processing[Content] [RFC3647]
4.2.1.
Performing identification and authentication functions
PRAGMA-UCSD CA ensures that the followings in the enrollment
process and certificate application process:
In the enrollment process, the CA checks if
- the application form is correct; and
- the RA examined the subscriber in a face-to-face or video conference meeting
or an equivalent inspection process, if required;
- in case of host certificate request, the person is responsible
for the host;
- the RA signed the application form.
In the certificate application process, the CA checks if
- the certificate request is done in accordance with the process in this
document especially in the section 4.1.
- the certificate request subject name has correct format; and
- the key length of the certificate request meets the requirement.
4.2.2. Approval or rejection of certificate applications
- The issuance of a certificate by the CA indicates a complete and
final approval of the certificate application by the CA.
- If any condition specified in section 4.2.1 is not be satisfied, the
certificate application is rejected and the CA notifies to the subscriber with
the reason of the rejection.
4.2.3. Time to process certificate applications
- The CA should process the certificate application within 4
business day from the acceptance of the certificate request.
4.3. Certificate Issuance[Content]
[RFC3647]
，
Upon the receipt of CSR, PRAGMA
CA operator will store the CSR in a memory stick and take it to the signing
machine which is kept off-line as described in section 6.7,
，
The CA operator generates (issues) a user or a
host certificate containing a public key with
CA signature and hand-carrying it to the PRAGMA online CSR server.
，
A notification message is sent to
the e-mail address of the subject with the instructions on how to retrieve it
from the PRAGMA online CSR server.
，
The user will be able to download
his/her user certificate using Naregi-CA client software which uses a securely
encrypted Lightweight
Certificate Management Protocol (LCMP) to communicate with RA server.
，
The detailed procedures are described in
the user¨s guide.
，
If the authentication is
unsuccessful, the certificate is not issued and an error message indicates the
reason is returned to the subject.
4.4. Certificate Acceptance[Content] [RFC3647]
，
If the issued certificate has any
problem, the subscriber should notify the CA that he can not accept the issued
certificate with a proper reason within 7 days from issuance of the
certificate.
，
Unaccepted certificate should be
revoked and the certificate should be re-issued.
4.5. Key Pair and Certificate Usage[Content] [RFC3647]
，
PRAGMA GRID certificates may be
used for any software for grid computing.
，
They could be used in other
capacities, but the PRAGMA-UCSD CA does not recommend or warrant any other use
of the certificates it signs.
，
User certificates must not be
shared between multiple people.
，
Host certificates must be linked
to a single network entity.
，
The subscriber must manage his
certificates and private keys securely. To protect the private key the
subscriber must encrypt his private key with a pass phrase. The pass phrase
should be more than 12 characters long.
4.6. Certificate Renewal[Content] [RFC3647]
4.6.1.
Circumstance for certificate renewal
4.6.2. Who may request renewal
Nobody
can request renewal of certificates.
4.6.3. Processing certificate renewal requests
No
stipulation
4.6.4. Notification of new certificate issuance to subscriber
No
stipulation.
4.6.5. Conduct constituting acceptance of a renewal certificate
No
stipulation.
4.6.6. Publication of the renewal certificate by the CA
No
stipulation.
4.6.7. Notification of certificate issuance by the CA to other
entities
No
stipulation.
4.7. Certificate Re-key[Content]
[RFC3647]
4.7.1.
Circumstance for certificate re-key
Generally, certificate re-key can or must take place in cases such
as:
(case 1) after a certificate is revoked for reasons of key compromise; or
(case 2) after a certificate has expired and the usage period of the key pair
has also expired
(case 3) a certificate will be expired in one month
4.7.2. Who may request certification of a new public key
- If a certificate is revoked for reasons of key compromise (case
1 in section 4.7.1), the certificate must be revoked and the subscriber of the
certificate should follow the enrollment process (of section 4.1) again to get
a new certificate.
- If a certificate has expired and the usage period of the key pair has also
expired (case 2 in section 4.7.1), the subscriber of the certificate should
follow the certificate application process (of section 4.1) to get a new
certificate.
- If a
certificate will be expired in 30 days, the owner of the certificate can
request certification of a new public key.
4.7.3. Processing certificate re-keying requests
- The process of re-key request processing is basically the same
as the initial certificate application of section 4.1.
- If the point of time of the re-key request has passed 5 years from the
previous enrollment process of the subscriber, the subscriber is required to
follow the re-enrollment process.
- During re-key request, the re-enrollment process is the same as initial
certificate application in section 4.1, except that the face to face interview
is not required if
the re-key request has not passed 5 years from the previous identity
verification by a method described in section 3.2.
4.7.4. Notification of new certificate issuance to subscriber
Covered in section 4.7.3.
4.7.5. Conduct constituting acceptance of a re-keyed certificate
Covered in section 4.7.3.
4.7.6. Publication of the re-keyed certificate by the CA
Covered in section 4.7.3.
4.7.7. Notification of certificate issuance by the CA to other
entities
Covered in section 4.7.3.
4.8. Certificate
Modification[Content] [RFC3647]
4.9. Certificate Revocation and Suspension[Content] [RFC3647]
4.9.1.
Circumstances for revocation
A certificate must be revoked when information it contains is
suspected to be incorrect or compromised. This includes situations where:
，
The subscriber's private key is
compromised or is suspected to have been compromised. The subscriber must report the
compromise to the CA within 1 working day.
，
The subscriber's information in
the certificate is suspected to be inaccurate.
，
The subscriber is known to have
violated his obligations which could induce a critical security hole.
，
The subscriber leaves his/her
organization.
，
In case of host/service
certificates, the corresponding host/service is retired.
4.9.2. Who Can Request Revocation
，
The certificate subscriber
，
，
Any other entity presenting
evidence of circumstances
4.9.3.
Procedure for Revocation Request
Entities requesting revocation of a certificate must authenticate
themselves in one of the following ways:
，
Sending an email, maybe signed by
a valid and trusted certificate, to pragma-ucsd-ca@sdsc.edu, RA will contact
the subscriber for confirmation by telephone or video conference.
，
In the other cases,
authentication is performed with the same procedure used to authenticate the
identity of person.
In both case above, the requesting entity must specify the reason
for the revocation request and provide evidence of circumstances.
4.9.4.
Revocation request grace period
，
CA will process revocation as
soon as it receives the revocation request and the request is approved.
，
The revocation information will be
published to the online repository.
，
During the revocation, a
revocation notification is sent to the subscriber through the subscriber's
email.
4.9.5.
Time within which CA must process the revocation request
The CA should process the certificate revocation request within 1
working day from the recognition of the request.
4.9.6.
Revocation checking requirement for relying parties
No stipulation.
4.9.7.
CRL Issuance Frequency (if applicable)
，
The lifetime of the CRL is 30
days.
，
A new CRL is issued immediately
after a revocation or at least 7 days before expiration.
4.9.8. Maximum latency for CRLs (if applicable)
- CRLs must be published in the repository after generation as
soon as possible.
- In
4.9.9. On-line revocation/status checking availability
PRAGMA GRID PKI system does not provide any online status checking
facility.
4.9.10. On-line revocation checking requirements
PRAGMA GRID PKI system does not provides any online status
checking facility.
4.9.11. Other forms of revocation advertisements available
No stipulation.
4.9.12. Special requirements re key compromise
No stipulation.
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[Content] [RFC3647]
4.11. End of Subscription[Content] [RFC3647]
If a subscriber of
The subscriber must do the following:
- Must not use any certificate issued from
The CA must do the following:
- Must revoke all certificates issued for the subscriber.
4.12. Key Escrow and Recovery[Content] [RFC3647]
No stipulation.
5. Management,
Operational, and Physical Controls[Content]
[RFC3647]
5.1. Physical Security Controls[Content] [RFC3647]
The CA operates in a controlled environment, where access is
restricted to authorized people.
5.1.1.
Site location and construction
PRAGMA GRID PKI is located at
Physical access to the PRAGMA-UCSD CA machine is restricted to
authorized personnel.
The PRAGMA-UCSD CA machines (both the issuing machine and the CSR/RA server)
are:
，
running on dedicated machines.
，
The offline CA signing machine is located in a locked cabinet in a locked office. The cabinet key is
held by a designated CA officer.
，
professionally managed.
5.1.3. Power and air conditioning
The CA signing machine are powered off whenever not in use.
Environment temperature in rooms containing CA related equipment is maintained
at appropriate levels by suitable air conditioning systems.
The CA shall ensure that the CA system is adequately protected
from water exposures.
5.1.5. Fire prevention and protection
The building housing the PRAGMA-UCSD CA facilities has a fire
alarm system.
The CA shall ensure that the CA system is adequately protected from fire by a
fire suppression system.
The PRAGMA-UCSD CA key and backup copy of CA related information
is securely saved on USB drives and kept in a locked cabinet. The key of the
cabinet is held by a designated CA officer..
The CA shall ensure that all media containing sensitive
information is sanitized, to remove information such that data recovery is not
possible, or destroyed before release for disposal. CA personnel shall account
for the destruction of sensitive information.
In
5.2. Procedural Controls[Content]
[RFC3647]
5.2.1.
Trusted roles
，
SYSTEM ADMINISTRATOR(SYSADM) has
full control over the CA server and software.
，
CERTIFICATE AUTHORITY
OPERATOR(CAO) can manage all certificates, requests and cryptographic data
including CA private key. CAO is contact point for subscribers about CA
operation. CAO can make changes of CP/CPS.
，
REGISTRATION AUTHORITY
OPERATOR(RAO) examines subscriber's information and checks the trust of the
subscriber in behalf of certificate authority.
，
SYSTEM AUDITOR(SA) have read-only
access to all components of the PKI system to verify the operation complies
with the rules and regulations of this CP/CPS. SA approves any changes of
CP/CPS by CAO in prior to an approval of the regional PMA(APGrid PMA).
5.2.2. Number of persons required per task
For operation of PRAGMA GRID PKI, the number of persons required
for the roles is:
，
SYSTEM ADMINISTRATOR: 1 person or
more.
，
CERTIFICATE AUTHORITY OPERATOR: 2
persons or more for back-up each other.
，
REGISTRATION AUTHORITY OPERATOR:
1 person or more for each RA site.
，
SYSTEM AUDITOR: 1 person or more.
5.2.3. Identification and authentication for each role
In PRAGMA GRID PKI, on-line and/or off-line system will identify
and authenticate the operator when the staff operates the system.
5.2.4. Roles requiring separation of duties
- SYSTEM AUDITOR may not be a SYSTEM ADMINISTRATOR, or CERTIFICATE
AUTHORITY OPERATOR.
5.3. Personnel Security
Controls[Content] [RFC3647]
All access to the servers and applications that comprise the
PRAGMA GRID PKI is limited to PRAGMA GRID PKI security staffs.
5.3.1.
Qualifications, experience, and clearance requirements
The CA shall ensure that all staff performing CA and RA functions
possess the necessary knowledge, experience and qualifications to perform their
duties.
5.3.2. Background check procedures
CA personnel must be an employee of UCSD and a formal member of
PRAGMA.
- The CA shall ensure that all personnel receive appropriate
training. Such training shall address relevant topics such as security requirements,
operational responsibilities and associated procedures.
5.3.4. Retraining frequency and requirements
The CA shall review and update its training program at least once
a year to accommodate changes in the CA system.
5.3.5. Job rotation frequency and sequence
No stipulation.
5.3.6. Sanctions for unauthorized actions
In the event of actual or suspected unauthorized actions by a
person performing duties with respect to the operation of the CA or an RA, the
CA shall suspend his or her access to the CA system.
5.3.7. Independent contractor requirements
The CA shall ensure that contract personnel satisfy the same
personnel security requirements with respect to appointment, training and
background checks as those applicable to CA employees.
5.3.8. Documentation supplied to personnel
The CA shall provide these Certificate Policies, relevant
provisions of the CPS, as well as any specific statutes, policies or contracts
relevant to their positions to CA personnel, RAs and Client Responsible
Individuals.
5.4. Audit Logging
Procedures[Content] [RFC3647]
- The PRAGMA-UCSD CA will retain records as much as possible so
that the PRAGMA-UCSD CA could trace anything if something illegal would happen.
- Such audit information is not publicly available.
- Auditors are allowed to access the information as part of auditing and such
information must be kept confidential.
- CA operator performs operational audits of the CA/RA staff at least once per
year.
5.4.1.
Types of events recorded
，
Certification requests
，
Revocation requests
，
Issued certificates
，
Issued CRLs
，
shutdown/boot/reboot/login/logout/sudo
logs of the CA machine and on-line CSR/RA server.
，
Access to the CA server locker.
，
other logs archived by UNIX
operating of the CA machine and RA server
，
All manual log entries will be
emailed to pragma-ucsd-ca@sdsc.edu.
The mailing list archive is only accessible by PRAGMA-UCSD CA/RA staff and is
backed up monthly.
5.4.2. Frequency of processing log
The CA shall ensure that all significant events are explained in an
audit log summary and that CA personnel review audit logs at least once every
month. Such reviews involve verifying that the log has not been tampered with,
and then inspecting all log entries. CA personnel shall conduct a more thorough
investigation of any "alerts" or irregularities in the logs. The CA
shall indicate who has responsibility for audit log review and audit log
summary preparation in the CPS.
5.4.3. Retention period for audit log
The CA shall retain its audit logs on site for at least two(2)
months and subsequently retain audit logs in the manner described in Section
5.5.
5.4.4. Protection of audit log
The CA shall protect the electronic audit log system and audit
information captured electronically or manually from unauthorized viewing, modification,
deletion or destruction.
5.4.5. Audit log backup procedures
The CA shall back up or copy all audit logs and audit summaries.
5.4.6. Audit collection system (internal vs. external)
No stipulation.
5.4.7. Notification to event-causing subject
No stipulation.
5.4.8. Vulnerability assessments
No stipulation.
5.5. Records Archival[Content]
[RFC3647]
5.5.1.
Types of records archived
o CA records all the types of events listed in section 5.4.1 are archived.
o
In addition to that, email sent
to/from pragma-ucsd-ca@sdsc.edu messages will be archived as well.
o
CA private keys must be backed up
and protected at a level of physical and cryptographic protection equal to or
exceeding that in place at the CA site.
o
RA records all the types of events
regarding user registration, certificate/revocation request including:
」 date of meeting with a subscriber
」 evidence of identity of a subscriber
」 email messages sent to/from the RA's email address.
5.5.2.
Retention period for archive
Certificates and CRLs generated by the CA, must be retained for at
least 2 years after their expiration, and;
The minimum retention period is 3 years. The user identify information will be
retained for 5 years.
System logs and email archives are protected by the authorization
mechanism provided by Unix operating system. Only the owners of the system logs
are able to modify the logs. System logs and email archives are periodically
back-up to the offline media which is stored in a safe place.
5.5.4. Archive backup procedures
No stipulation.
5.5.5. Requirements for time-stamping of records
All archived logs and documents are time stamped.
5.5.6. Archive collection system (internal or external)
No stipulation.
5.5.7. Procedures to obtain and verify archive information
No stipulation.
5.6. Key Changeover[Content]
[RFC3647]
- When the CA's cryptographic data needs to be changed (e.g. CA
key expiration), from the time of distribution of new cryptographic data, only
the new CA certificate will be used for certificate signing purposes.
- From that time, the old CA certificate will not be used for certificate
signing purposes.
- The overlap of the old and new CA certificate must be at least the longest
time an end-entity certificate can be valid(1 year).
- The old CA certificate will be valid and available to verify old signatures
and the secret key to sign CRLs until all the certificates signed using the
associated private key have also expired.
5.7. Compromise and Disaster Recovery[Content] [RFC3647]
，
If it is detected that hardware,
software or data are corrupted or damaged
o
Recover the system by using
backup hardware, software, or data as quickly as possible.
，
If a CA's private key is
compromised or suspected to be compromised, the PRAGMA-UCSD CA will:
o
Notify subscribers, RAs and
relying parties.
o
Revoke all issued certificates.
o
Terminate the certificates and
CRLs distribution service for certificates/CRLs issued using the compromised
private key.
o
Create a new pair of key and
re-build the CA system.
5.8. CA or RA Termination[Content] [RFC3647]
Before
，
Make publicly available
information of its termination.
，
Stop issuing certificates and
CRLs.
，
Destroy its private key's and all
copies.
6. Technical Security
Controls[Content] [RFC3647]
6.1. Key Pair Generation and Installation[Content] [RFC3647]
6.1.1.
Key pair generation
，
A CA key pair is generated by CA
staff on a signing machine which is not connected to any kind of network.
，
End entities' cryptographic keys
are locally generated by their application during the requesting process.
，
PRAGMA GRID PKI does not generate
private keys for subjects.
6.1.2. Private key delivery to subscriber
The PRAGMA-UCSD CA does not generate end entities' private keys
hence does not deliver private keys. User's private key could be generated by
browser application in personal computer.
6.1.3. Public key delivery to certificate issuer
End entity will send its public key included in CSR at time of
certificate request.
6.1.4. CA public key delivery to relying parties
CA certificate will be published on the PRAGMA Grid PKI
repository.
，
The minimum key length for user
or host/service certificate is 1024 bits.
，
The CA key length is 2048 bits.
6.1.6. Public key parameters generation and quality checking
No stipulation
6.1.7. Key usage purposes(as per X.509 v3 key usage field)
The Certificate key Usage field must be used in accordance with the ``Internet
X.509 Public Key Infrastructure Certificate and CRL profile'' [RFC 2459].
6.2. Private Key
Protection and Cryptographic Module Engineering[Content] [RFC3647]
6.2.1.
Cryptographic module standards and controls
6.2.2. Private key (n out of m) multi person control
In
The CA's private key is shared between 2 CA staffs.
Not supported.
The PRAGMA GRID private key backup is performed by CA operator and
the copy of backup key is kept encrypted in a memory stick respectively in a
safe place where access is controlled.
6.2.6.
Private key transfer into or from a cryptographic module
No stipulation.
6.2.7. Private key storage on cryptographic module
No stipulation.
6.2.8. Method of activating private key
6.2.9.
Method of deactivating private key
No stipulation.
6.2.10. Method of destroying private key
No stipulation.
6.2.11. Cryptographic Module Rating
No stipulation.
6.3. Other Aspects of Key
Pair Management[Content] [RFC3647]
6.3.1.
Public key archival
The CA shall retain all public key certificates it generates.
6.3.2. Certificate operational periods and key pair usage periods
，
The lifetime of
，
The lifetime of user certificate
is one(1) year.
，
The lifetime of host certificate
is one(1) year.
6.4. Activation Data[Content]
[RFC3647]
，
The PRAGMA-UCSD CA's private key
is protected by a pass phrase over 15 characters.
，
This pass phrase is only known by
CA operators.
，
The pass phrase is in a sealed
envelop kept in a safe place where access is controlled.
，
But the sealed envelop is kept
separated from the backed private key.
6.5. Computer Security Controls[Content] [RFC3647]
6.5.1.
Specific computer security technical requirements
，
CA operating systems are
maintained at a high level of security by applying all the relevant patches.
，
Monitoring is performed to detect
unauthorized software changes.
，
CA systems configuration is
reduced to the base minimum.
，
Both CA signing machine and CSR
server machine are used for dedicated purpose respectively.
6.5.2. Computer security rating
No stipulation.
6.6. Life Cycle Security
Controls[Content] [RFC3647]
No stipulation.
6.7. Network Security Controls[Content] [RFC3647]
，
The CA signing machine is kept
off-line, powered off and locked in a secure cabinet
，
The CA CSR/RA server machine is a
dedicated machine and no network service other than CA CSR/RA run on the
server.
，
The CA CSR/RA server machine is
protected with appropriate security measures.
，
Appropriate software
upgrade/patch of the RA server is performed immediately if it is required.
6.8. Time-stamping[Content] [RFC3647]
No stipulation.
7. Certificate and CRL
Profiles[Content] [RFC3647]
7.1. Certificate Profile[Content] [RFC3647]
7.1.1.
Version number(s)
X.509 v3.
CA Certificate:
，
X509v3 Basic Constraints: critical,
CA:TRUE
，
X509v3 Key Usage: critical,
Certificate Sign (keyCertSign), CRL Sign (cRLSign)
，
Certificate Policies:
1.3.6.1.4.1.13230.101.2.1.0
User Certificates:
，
X509v3 Basic Constraints:
critical, CA:FALSE
，
X509v3 Key Usage: critical, Digital
Signature (digitalSignature), Key Encipherment (keyEncipherment), Data
Encipherment (dataEncipherment)
，
X509v3 Extended Key Usage: TLS
Web Client Authentication(clientAuth),
，
X509v3 CRL Distribution Points:
URI://ca.pragma-grid.net/ca-certs/7721d4d3.der
，
Subject Alternative Name: email:
(user email address)
，
Certificate Policies:
1.3.6.1.4.1.13230.101.2.1.0
Host Certificates:
，
X509v3 Basic Constraints:
critical, CA:FALSE
，
X509v3 Key Usage: critical,
Digital Signature (digitalSignature), Key Encipherment (keyEncipherment), Data
Encipherment (dataEncipherment)
，
X509v3 Extended Key Usage: TLS
Web Server Authentication(serverAuth), TLS Web Client
Authentication(clientAuth)
，
X509v3 Subject Alternative Name:
DNS:<FQDN of the host>
，
X509v3 CRL Distribution Points:
URI://ca.pragma-grid.net/ca-certs/7721d4d3.der
，
Certificate Policies:
1.3.6.1.4.1.13230.101.2.1.0
|
X.509v3
Extension |
CA
Certificate |
User
Certificates |
Host
Certificates |
|
Basic
Constraints |
critical,
CA:TRUE |
critical,
CA:FALSE |
critical,
CA:FALSE |
|
Key
Usage |
critical |
Critical |
critical |
|
Key
Usage:Certificate Sign |
O |
- |
- |
|
Key
Usage:CRL Sign |
O |
- |
- |
|
Key
Usage:Digital Signature |
- |
O |
O |
|
Key
Usage:Non Repudiation |
- |
- |
- |
|
Key Usage:Key
Encipherment |
- |
O |
O |
|
Key
Usage:Data Encipherment |
- |
O |
O |
|
Extended
Key Usage |
- |
TLS Web
Server Authentication(serverAuth), TLS |
TLS Web
Server Authentication(serverAuth), TLS Web Client Authentication(clientAuth) |
|
Issuer Alternative
Name |
- |
- |
- |
|
Subject
Alternative Name |
- |
Email:<user
email address> |
DNS:<FQDN
of the host> |
|
CRL
Distribution Points |
- |
URI://ca.pragma-grid.net/ca-certs/7721d4d3.der |
URI://ca.pragma-grid.net/ca-certs/7721d4d3.der |
|
Certificate
Policies |
1.3.6.1.4.1.13230.101.2.1.0 |
1.3.6.1.4.1.13230.101.2.1.0 |
1.3.6.1.4.1.13230.101.2.1.0 |
7.1.3. Algorithm object identifiers
Signature Algorithm: sha1 with RSA Encryption (2048 bits)
User and Host Certificate Signature Algorithm: SHA1WithRSAEncryption
，
Issuer:
DC=NET, DC=PRAGMA-GRID,
CN=PRAGMAUCSD CA
，
User DN:
DC=NET,
DC=PRAGMA-GRID, OU=[the name of organization], CN=[the name of applicant]
，
Host DN:
DC=NET, DC=PRAGMA-GRID, OU=[the name
of organization], CN=[FQDN of the hostname]
Subject DN can contain the following characters:
Alphabetic characters: a-z, A-Z
Numerical character: 0-9
Special character: -(dash), _(underscore)
No other characters are allowed for the subject name.
7.1.6 Certificate policy object identifier
X509v3 Certificate Policies: Policy: 1.3.6.1.4.1.13230.101.2.1.0
See Section 1.2.
7.1.7
Usage of policy constraints extensions
No Stipulation.
7.1.8 Policy qualifier syntax and semantics
No Stipulation.
7.1.9. Processing semantics for the critical Certificate Policies
extension
No Stipulation.
7.2. CRL Profile[Content]
[RFC3647]
CRLs are signed by the PRAGMA-UCSD CA private key and are
published in a web page.
7.2.1.
Version number(s)
X.509 v2.
7.2.2. CRL and CRL entry extensions
Message digest algorithm of the CRL: SHA-1
7.3. OCSP Profile[Content]
[RFC3647]
7.3.1.
Version number(s)
No stipulation.
No stipulation.
8. Compliance Audit and Other Assessment[Content] [RFC3647]
8.1. Frequency of Entity Compliance Assessment[Content] [RFC3647]
The PRAGMA-UCSD CA will accept external Compliance Audit.
In addition, the PRAGMA-UCSD CA performs operational self-assessment of CA/RA
staff at least once per year.
8.2. Identity/Qualifications of Assessor[Content]
8.3. Assessor's relationship to assessed entity[Content]
8.4. Topics Covered by Assessment[Content]
Audit items will be selected based on the minimum CA requirements
and documents enacted by the APGrid PMA.
8.5. Actions Taken as a Result of Deficiency[Content]
The PRAGMA-UCSD CA has the responsibility for the action to be
taken as a result of deficiency. When the PRAGMA-UCSD CA receives an audit
report from the auditor, it will send a report on actions to the auditor within
two weeks. The report must describe actions taken as a result of deficiency and
their timetable.
8.6. Communications of Results[Content]
The result of the audit will be made available to APGrid PMA in
which the PRAGMA-UCSD CA participates. It may make the results of the audit
publicly available.
9. Other Business and
Legal Matters[Content]
[RFC3647]
No fees are charged for any service provided by the PRAGMA-UCSD
CA.
9.2. Financial Responsibility[Content] [RFC3647]
Accept no liability at all.
9.3. Confidentiality of Business Information[Content] [RFC3647]
，
，
Information included in issued
certificates and CRLs is not considered confidential.
，
PRAGMA GRID PKI does not collect
any kind of confidential information.
，
PRAGMA GRID PKI does not have
access to or generate the private keys of a digital signature key pair, such as
those used in PRAGMA GRID identity certificates. These key pairs are generated
and managed by the subscribers and are the sole responsibility of the subscribers.
9.4. Privacy of Personal Information[Content] [RFC3647]
The subscriber's private information collected for registration
are:
- Name of subscriber
- Country
- Organization Name
- Position
- Telephone
- Email
We do not provide this information to other organizations.
9.5. Intellectual Property Rights[Content] [RFC3647]
All certificate related data issued by
9.6. Representations and Warranties[Content] [RFC3647]
No stipulation.
9.7. Disclaimers of Warranties[Content] [RFC3647]
No stipulation.
9.8. Limitations of Liability[Content] [RFC3647]
，
PRAGMA GRID PKI issues person certificates
according to the practices described in this document.
，
PRAGMA GRID PKI makes no
guarantee about the security or suitability of a service that is identified by
a PRAGMA GRID certificate.
，
The certification service is run
with a reasonable level of security, but it is provided on a best effort only
basis.
，
It does not warrant its
procedures and it will take no responsibility for problems arising from its
operation, or for the use made of the certificates it provides.
，
PRAGMA GRID PKI denies any financial
or any other kind of responsibility for damages or impairments resulting from
its operation.
9.9. Indemnities[Content] [RFC3647]
No stipulation.
9.10. Term and Termination[Content] [RFC3647]
9.10.1.
Term
This CP/CPS is valid and enforceable from the time of
accreditation by APGrid PMA.
This CP/CPS terminates in the following cases:
- CA certificate expires
- CA terminates its service
- A new version of CP/CPS is accreditated.
9.10.3. Effect of termination and survival
No stipulation.
9.11. Individual notices
and communications with participants[Content] [RFC3647]
No stipulation.
9.12. Amendments[Content] [RFC3647]
，
Users will not be warned in
advance of changes to the PRAGMA-UCSD CA's policy and CPS.
，
Any revision of specification is
made by
，
Minor editorial changes to this
document can be made without approval by the APGridPMA.
，
Major changes such as changes in
policy or technical security controls need to be approved by the APGrid PMA. New
OID will be assigned to the revised document for such major changes. For minor editorial
changes, revision to this document will be announced on the PRAGMA-UCSD GRID
PKI repository. Substantial changes will be notified by Emails to all relevant
relying parties, all cross-certifying CAs, and the PMAs in which the
PRAGMA-UCSD GRID CA participates. These changes will also be announced on the
PRAGMA-UCSD GRID PKI repository.
9.13. Dispute Resolution Procedures[Content]
[RFC3647]
No stipulation.
9.14. Governing Law[Content] [RFC3647]
9.15. Compliance with Applicable Law[Content]
[RFC3647]
No stipulation.
9.16. Miscellaneous Provisions[Content] [RFC3647]
No stipulation.
9.17. Other Provisions[Content] [RFC3647]
No stipulation.