Academia Sinica Grid Computing
Certification Authority (ASGCCA) Certificate Policy and Certification Practice
Statement
Version 2.0
July, 2006
1.3 Community and
Applicability
1.3.1 Certification
Authorities
1.3.2 Registration
Authorities
2.1.4 Relying Party
Obligations
2.4 Interpretation
and Enforcement
2.6 Publication and
Repositories
2.6.1 Publication
of CA information
2.6.2 Frequency of
Publication
2.9 Intellectual
Property Rights
3 Identification
and Authentication
3.1.4 Method to
Prove Possession of Private Key
3.1.5 Authentication
of Organization Identity
3.1.6
Authentication of Individual Identity
4.4 Certificate
Suspension and Revocation
4.4.1 Circumstances
for Revocation
4.4.2 Who Can
Request Revocation
4.4.3 Procedure for
Revocation Request
4.4.4 Circumstances
for Suspension
4.4.6 Online
Revocation/status checking availability
4.4.7 Online
Revocation checking requirements
4.4.8 Other forms
of revocation advertisement available
4.5 Security Audit
Procedures Security
4.5.1 Types of
Events Recorded
4.5.2 Processing
Frequency of Audit Logs
4.5.3 Retention
Period for Audit Logs
4.6.2 Retention
Period for Archives
4.8 Compromise and
Disaster Recovery
5 Physical,
Procedural and Personnel Security Controls
5.1 Physical
Security Controls
5.1.1 Site Location
and construction
5.1.3 Power and air
conditioning
5.1.5 Fire
prevention and protection
5.3 Personnel
Security Controls
5.3.1 Background
Checks and Clearance Procedures for CA Personnel
5.3.2 Background
Checks and Security Procedures for Other Personnel
5.3.3 Training
Requirements and Procedures.
5.3.4 Training
Period and Retraining Procedures
5.3.5 Frequency and
Sequence of Job Rotation
5.3.6 Sanctions
Against Personnel
5.3.7 Controls on
Contracting Personnel
5.3.8 Documentation
Supplied to Personnel
6.1 Key Pair
Generation and Installation..
6.1.2 Private Key
Delivery to Entity
6.1.3 Public Key
Delivery to Certificate Issuer
6.1.4 CA Public Key
Delivery to Users
6.1.6 Public Key
Parameters Generation
6.1.7 Parameter
Quality Checking
6.1.8
Hardware/software key generation
6.2.1 Private Key
(n out of m) Multi-person Control
6.2.3 Private Key
Archival and Backup
6.3 Other Aspects
of Key Pair Management
6.5 Computer
Security Controls
6.5.1 Specific
Security Technical Requirements
6.5.2 Computer
Security Rating
6.6 Life Cycle
Security Controls
6.8 Cryptographic
Module Engineering Controls.
7.1.3 Algorithm
Object Identifiers
7.1.6 Certificate
Policy Object Identifier
7.1.7 Usage of
Policy Constraints Extensions
7.1.8 Policy
Qualifier Syntax and Semantics
7.2.2 CRL and CRL
Entry Extensions
8 Specification
Administration
8.1 Specification
Change Procedures
8.2 Publication and
Notification Procedures
This document is based on the structure
suggested by the ''Internet X.509 Public Key Infrastructure Certificate Policy
and Certification Practices Framework'' [RFC 2527]. Sections that are not included have a
default value of "No stipulation". This document describes the set of
rules and procedures established by the Academia Sinica Grid Computing
Certification Authority (ASGCCA).
(http://grid.sinica.edu.tw).
The following definitions and associated
abbreviations are used in this document.
- ASGCCA
The
Academia Sinica Grid Computing Certification Authority.
- Certificate
Policy (CP)
A named
set of rules that indicates the applicability of a certificate to a particular
community and/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
Practice Statement (CPS)
A
statement of the practices, which a certification authority employs in issuing
certificates.
- Certification Authority
(CA)
An entity trusted by
one or more users to create and assign public key certificates and be
responsible for them during their whole lifetime.
- 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.
- Policy qualifier
Policy-dependent
information that accompanies a certificate policy identifier in an X.509
certificate.
- 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).
- Relying party
A recipient of a
certificate who acts in reliance on that certificate and/or digital signatures
verified using that certificate.
- Document title:
Academia Sinica Grid
Computing Certification Authority (ASGCCA) Certificate Policy and Certification
Practice Statement
- Document
version:
2.0
- OID:
The following ASN.1
Object Identifier (OID) has been assigned to this document: 1.3.6.1.4.1.5935.10.1.2.0.
This OID is constructed as shown in the table below
|
IANA |
|
|
Academia Sinica
Computing Centre |
.5935 |
|
ASGCCA |
.10 |
|
CP/CPS |
.1 |
|
Major Version |
.2 |
|
Minor Version |
.0 |
- Document date:
July 2006
1.3 Community and Applicability
ASGCCA is managed by Academia Sinica Grid Computing
Centre.
.The ASGCCA
delegates the authentication of individual identity to Registration Authorities.
RAs must sign an agreement with the ASGCCA, stating their adherence to the
procedures described in this document. RAs are not allowed to issue
certificates under this CP/CPS. The list of RAs is available from the ASGCA
website.
Every
organization has only one Registration Authority who is in charge of an
organization. Only permanent staff
members are eligible to become an ASGCCA RA for their organization.
The following is the ASGCCA RA registration
procedure:
- RA candidate
must accept the CP/CPS and agree to all RA responsibilities.
- RA candidate
must be an employee of the institution or organization and provide work ID
or proof of work.
- Complete the RA
application form and fax it to ASGCCA.
- Send a verification
e-mail to ASGCCA.
- ASGCCA will then
arrange face to face or web-conference meeting with RA candidate.
- After completing
the request, ASGCCA will publish the RA contact information on ASGC
website and reserve the right to issue the name space for the institution.
ASGCCA issues certificates for the following
subjects:
- Users of
Academia Sinica.
- Users of
domestic Grid-based Application/Projects.
- Collaborators
related to Academia Sinica Grid Computing research.
- Users and hosts/services
involved in LCG/EGEE Project without CA support in
The certificates issued by ASGCCA must not be
used for financial transaction.
The authorized uses of certificate issued by
ASGCCA are:
- e-mail signing
and encryption (S/MIME)
- authentication
and encryption of communication (SSL/TLS)
- object-signing
The ASGCCA is managed by Academia Sinica Grid
Computing Centre. Contact person for questions related to this document or the
ASGCCA in general:
Yen, Eric
Address: 128, Sec. 2,
Phone: +886-2-2789-9494
Mobile: +886-922-959211
Fax: +886-2-2789-6793
Email:
- Accept
certificate signing request from acceptable entities (see section
- Authenticate
entities according to procedures outlined in this document;
- Issue
certificates based on the requests from authenticated entities;
- Notify the
subscriber about the certificate issuance;
- Publish the
issued certificates;
- Accept
certificate revocation requests from entities;
- Authenticate
entities requesting the revocation of certificate;
- Issue CRLs
according with the rules described in this document;
- Publish the
issued CRLs;
- Follow the
policies and procedures described in this document.
- Authorize the RA as
a representative of the organization.
ASGCCA RA has meet
the following obligations according to the procedures described in this document:
- Authenticate the
identity of the person requesting a certificate.
- Assist end entities
with ASGCCA service requests and issues.
- Reconfirm the
end entities' identity and current employment status for a certificate
renewal request when informed by ASGCCA
- Archive all
activity records including (1) new certificate requests (2) renewal
requests (3) revocation request and send it to ASGCCA on a regular basis.
- Inform ASGCCA
when the RA plans to leave their organization.
In requesting a certificate, subscribers agree
to:
- Read and adhere
to the procedures published in this document;
- Generate a key
pair using a trustworthy method;
- Take reasonable
precautions to prevent any loss, disclosure or unauthorized use of the
private key associated with the certificate, including:
- Selecting a
pass phrase of at minimum 12 characters
- Protecting the
pass phrase from others
- Provide correct
personal information and authorize the publication of the certificate.
- Notify
immediately ASGCCA in case of private key loss or compromise.
- User must not
share certificate.
- Request host certificate
with valid FQDN (Fully Qualified Domain Name).
2.1.4 Relying Party Obligations
In requesting a certificate, subscribers
agree to:
- Read the
procedures published in this document.
- Verify the
certificate by checking whether the validity period has expired and
whether the certificate is on the latest CRL.
- Use the
certificates for the permitted uses only.
ASGCCA maintain an online accessible
repository of certificate revocation information. The CRL is operated at a
best-effort basis, and will be published as soon as issued.
ASGCCA only guarantees to control the
identity of the subjects requesting a certificate according to the practices
described in this document. No other liability, implicit or explicit, is
accepted.
ASGCCA will not give any guarantees about the
security or suitability of the service that is identified by an ASGCCA
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.
ASGCCA denies any financial or any other kind
of responsibility for damages or impairments resulting from its operation.
No Financial responsibility is accepted.
2.4 Interpretation and Enforcement
Interpretation of this policy is according to
R.O.C. laws.
No fees are charged for any service provided
by ASGCCA.
2.6 Publication and Repositories
ASGCCA operates a secure online repository
that contains:
- ASGCCA's
certificate;
- All Certificates
issued by ASGCCA;
- A Certificate
Revocation List (CRL) signed by ASGCCA;
- A copy of this
policy;
- Other
information relevant to the ASGCCA.
- Certificates
will be published as soon as issued.
- The frequency of
CRL publication is specified in subsection
- New version of CP/CPSs are published as soon as they have
been approved.
The online repository is available 24 hours a
day, 7 days a week, subject to reasonable scheduled maintenance.
ASGCCA doesn't impose any access control on
its CP/CPS, its Certificate and issued certificates and CRLs.
The CRL list is signed by ASGCCA private key.
A website is maintained by ASGCCA. It
contains all the information published by ASGCCA specified in section 2.6.1.
The website can be reached at the following address:
http://ca.grid.sinica.edu.tw
ASGCCA may be audited by other trusted CAs to
verify its compliance with the rules and procedures specified in this document.
2.7.1 Frequency of Entity Compliance Audit
The ASGCCA will
accept at least one external Compliance Audit per year. In addition, the ASGCCA
performs operational self-assessment of CA/RA staff at least once per year.
2.7.2 Identity/Qualifications of Auditor
The
CA will be audited by the other cross-certifying CAs.
2.7.3
Auditor' Relationship to Audited Party
It is
desirable that the auditor is a third-party to this PKI system
2.7.4
Topics Covered by Audit
Audit items will be selected based on the WebTrust criteria and minimum CA
requirements enacted by the APPMA and EUPAM. The Audit must cover both
compliance audit and operational audit.
2.7.5 Actions
Taken as a Result of Deficiency
The ASGCCA has the responsibility for the action to be taken as a result
of deficiency when the ASGCCA 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.
2.7.6
Communications of Results Frequency of Entity Compliance
The
result of the audit will be made available to members of any policy management
authorities in which ASGCCA participates. It may make the results of the audit
publicly available. The decision will be made by the ASGCCA in case-by-case
basis.
ASGCCA collects each subscriber’s full names,
organization and e-mail addresses. Some of this information is used to
construct unique, meaningful subject names in the issued certificates.
Information included in issued certificates
and CRLs is not considered confidential.
ASGCCA does not collect any kind of
confidential information.
Under no circumstances ASGCCA will have
access to the private keys of any subscriber to whom it issues a certificate.
2.9 Intellectual Property Rights
Parts of this document are inspired by [CERN CA], [DOE Grid PKI], [DATAGRID-ES CA].
3 Identification and Authentication
Name components vary depending on the type of
certificate. Names will be consistent with the name requirements specified in
``Internet X.509 Public Key Infrastructure Certificate and CRL profile'' [RFC 2459].
For a user certificate, the CN must be the
full name of the subscriber. For a host certificate, the CN must be functional
fully qualified domain name. For a service certificate, the CN must be related
to the type of service the certificate is identifying.
The Distinguished Name must be unique for
each subject name certified by ASGCCA.
The public and private keys are generated on
the user station when he/her fills the certificate request form with Netscape,
Mozilla or Internet Explorer browser.
If the name of an organization is requested
to be part of subject name, ASGCCA may take steps to ascertain that the
organization consent to such use. The information of authenticated organization
is published on
http://ca.grid.sinica.edu.tw/general/auth_organization.html .
Procedures differ if the subject is a user, host
or service:
- User:
A user requesting a user certificate must meet
in person with the RA and show their work ID. If the ID card is valid and the
photo image corresponds to the bearer, the RA shall consider that the user is
correctly identified. The RA will sign the user’s application form. Then the
user will fax the application form to the CA. Once the user's identification is
verified, ASGCCA will authenticate the subscriber and issue a certificate
without namespace clash with other CAs in APPMA, EUPMA and American Grid PMA.
- Host or Service
certificate:
Requests must be
signed with a valid personal ASGCCA user certificate.
Rekeying of
certificates can be requested by an online procedure, which checks the validity
of certificates.
3.3
Rekey After Revocation
Rekey after revocation follows the same rules
as an initial registration.
Certificate revocation request must be sent
in the following ways:
- Send e-mail to
- Contact
personally the CA/RA staff in order to verify his/her identity and the
validity of the request.
Procedures are different if the subject is a
person or a server. For every certificate applications, the subject has to
generate his/her own key pair. Minimum key length is 1024 bits.
- User:
Certificate requests are submitted by an online procedure, using a
Netscape, Mozilla or Internet Explorer browser.
- Host/Service:
Certificate requests are submitted by an online procedure, using a Netscape,
Mozilla or Internet Explorer browser with a valid personal ASGCCA user
certificate.
ASGCCA issues the certificate if, and only
if, the authentication of the subject is successful.
If the subject is a person, a message is sent
to his/her e-mail address with the instructions on how to download it from the
ASGCCA web server. If the subject is a host or a service entity, the
certificate itself is sent to the address specified in the request email.
If the authentication is unsuccessful, the
certificate is not issued and e-mail with the reason is sent to the subject.
No Stipulation.
4.4 Certificate Suspension and Revocation
A certificate is revoked when the information
it contains is suspected to be incorrect or compromised. This includes
situations where:
- the entity's
private key is lost or suspected to be compromised
- the information
in the entity's certificate is suspected to be inaccurate
- the entity
requests for revocation
- the entity
violates its obligations
- the entity
leaves the organization
- RA can also
request revocation with any reasons describe above.
- Name space
conflict – Since ASGCCA supports CA service in Asia region, therefore
people in Asia countries and organizations such as
The revocation of the certificate can be
requested by:
- The certificate
subscriber
- Any other entity
presenting evidence of circumstances as described in section 4.4.1.
The entity requesting revocation of a certificate
must authenticate themselves in one of the following ways:
- Sending an
email, signed by a valid and trusted certificate, to
asgcca@grid.sinica.edu.tw, RA will contact subscriber for confirmation.
- 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 as described in section
There is no provision for certificate suspension.
The lifetime of the
CRL is 30 days.
The CRL is updated
immediately after every revocation.
CRL is reissued 7
days before expiration even if there have been no revocations.
No stipulation
No stipulation.
No stipulation.
4.5
Security Audit Procedures Security
- Certification
requests;
- Revocation
requests;
- Issued
certificates;
- Issued CRLs.
No Stipulation.
Logs will be kept for a minimum of 3 years.
The following events are stored and backed-up
in safekeeping:
- certification
requests
- issued certificates
- revocation
request
- issued CRLs
- all e-mail
messages sent to ASGCCA
- all e-mail
messages sent by ASGCCA
- CA system logs
will be recorded and archived, including
- boot / shutdown system log
- system message log
- secure message log
- /root directory
4.6.2 Retention Period for Archives
The minimum retention period is three years.
No stipulation.
4.8 Compromise and Disaster Recovery
If the CA's private key is (or suspected to
be) compromised, the CA will:
- Inform
subscribers and subordinate RAs;
- Terminate the
certificates and CRL distribution services for certificates and CRLs
issued using the compromised key.
If the CA server is damaged, the CA will
- Replace a new
server machine
- Recover all
functions and the database with archived files and directories
Before ASGCCA terminates its services, it
will:
- Inform
subscribers, subordinate CAs and cross-certifying CAs;
- Make widely
available information of its termination;
- Stop issuing
certificates and CRLs.
- Destroy its private
key's and all copies.
5 Physical, Procedural and Personnel Security Controls
5.1 Physical Security Controls
The ASGCCA is located safely at Academia
Sinica Grid Computing Centre facilities in
Physical access to the ASGCCA is restricted
to authorized personnel. The access key is controlled by one of the ASGCCA
staff who is assigned to secure the facilities safety. All access to the
facilities needs to be scheduled and the facilities security staff needs to be
presented at all time.
The CA signing machine and the CA web server
are both protected by uninterruptible power supplies. Environment temperature
in rooms containing CA related equipment is maintained at appropriate levels by
suitable air conditioning systems.
Due to the location of the ASGCCA facilities
floods are not expected.
ASGCCA facilities obey to the R.O.C. law
regarding fire prevention and protection in buildings.
The ASGCCA key is kept in several removable storages.
Backup copies of CA related information are kept in removable media.
Wastes carrying potential confidential information
such as old floppy disks are physically destroyed before being disposal of.
No off-site backups are currently performed.
5.1.9 CA
pass phrase and application documents safety
The CA pass phrase and documents will be
stored safely in a safety box. Only the CA administrator has the access right
to the safety box.
No Stipulations.
5.3 Personnel Security Controls
All access to servers and applications that
compromise the Academia Sinica Grid Computing Centre is controlled.
CA personnel are recruited from the Academia Sinica
Grid Computing Centre.
No other personnel are authorized to access
ASGCCA facilities without the physical presence of CA personnel.
Internal training is given to CA operators.
No Stipulation
Job rotation is not performed.
No Stipulation.
No Stipulation
- Copies of this
document;
- ASGCCA Operations
Manual.
6.1 Key Pair Generation and Installation
A CA key pair is generated using Hardware
Security Module by the Security Officer. Each subscriber must generate its own
key pair. The ASGCCA does not generate private keys for subjects. An end entity
key pair is generated using a software tool in subscriber's personal or server
hardware.
The ASGCCA does not generate private keys
hence does not deliver private keys.
User's private key will be generated by
browser application in personal computer.
Entities' public keys are delivered to
issuing CA in a secure and trustworthy manner.
CA certificate can be downloaded from the
ASGCCA secure web site.
- The minimum key
length for user or host/service certificate is 1024 bits
- The CA key
length is 2048 bits.
No Stipulation.
No Stipulation.
It is defined in this document [6.1.1 key
pair generation].
ASGCCA private key is the only key used for
signing CRLs and Certificates for person, server and service.
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
The CA's private key
is not under (n out of m) multi-person control. But the ASGCCA implements
multi-person control for the access to the CA server as described in this
document [5.1 Physical Access]. Backup Copy of the CA's private key is under (2
out of 5) multi-person control.
ASGCCA keys are not given in escrow. ASGCCA
is not available for accepting escrow copies of keys of other parties.
The ASGCCA's private key is kept encrypted in
multiple copies in floppy disks and CDROMs in safe
places. For emergencies, the passphrase is in a sealed envelope kept in a safe.
6.3 Other Aspects of Key Pair Management
- The lifetime of
ASGCCA certificate is five years.
- The lifetime of
user certificate is one year.
- The lifetime of
host certificate is one year.
- The lifetime of
service certificate is one year.
The ASGCCA's private key is protected by a 15
characters passphrase.
6.5 Computer Security Controls
- The operating
systems of CA/RA computers 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.
No Stipulation.
6.6 Life Cycle Security Controls
No Stipulation.
- The CA signing
machine is kept off-line;
- CA website
machines other than the signing machine are protected by a firewall.
6.8 Cryptographic Module Engineering Controls
No Stipulation.
7
Certificate and CRL Profile
Certificate profile is described in a separate document, “ASGCCA
certificate and CRL profile version 1.5”. The document is available on the
http://ca.grid.sinica.edu.tw
X.509 v3.
Basic constraints:
Not a CA.
Key usage:
Digital
signature, non-repudiation, key encipherment, data encipherment.
Subject key
identifier
Authority key identifier
Subject alternative name
Issuer alternative name
CRL distribution points
Certificate policies
No Stipulation.
Issuer:
l
C=TW, O=AS, CN=Academia Sinica Grid Computing
Certification Authority
Person DN:
l
C=Country,
O=Organization, OU=Unit, CN=First Name Last Name/Email=email
Server name DN:
l
C=Country,
O=Organization, OU=Unit, CN=DNS server name(FQDN)
Service DN:
l
C=Country,
O=Organization-Name, OU=OrganizationUnit-Name,
CN=Service-Name/Domain-Name
Country Name: must be “TW”or countries abbreviated name in
Example:
/C=TW
/C=CN
/C=SG.
See section 1.2.
No Stipulation.
No Stipulation.
x.509 v1.
No Stipulation.
8
Specification Administration
8.1 Specification Change Procedures
Users will not be warned in advance of
changes to ASGCCA's policy and CPS. Revision is made and approved by the APPMA
and EUPMA. Minor editorial changes to this document can be made without
approval by the APPMA and EUPMA. New OID will not be assigned to the revised
document when minor changes would be made. Major changes such as changes in
policy or technical security controls need to be approved by the AIST GRID PMA.
New OID will be assigned to the revised document for such major changes would
be made.
8.2 Publication and Notification Procedures
Both minor and major changes of this document
will be announced at the news section at: http://ca.grid.sinica.edu.tw/
.
All major changes must be approved by the
AIST GRID PMA.
CERN CA Certificate Policy and Certification Practice Statement.
http://home.cern.ch/globus/ca/CPS.pdf
DATAGRID-ES CA Certificate Policy and Certification Practice Statement.
http://www.ifca.unican.es/datagrid/ca/datagrid-ca-policy.doc
DOE Science Grid PKI Certificate Policy and Certification Practice
Statement Version 2.1. http://www.doegrids.org/Docs/CP-CPS.pdf
Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
http://www.ietf.org/rfc/rfc2459.txt
Internet X.509 Public Key Infrastructure Certificate Policy and
Certification Practices Framework.
http://www.ietf.org/rfc/rfc2527.txt