Academia Sinica Grid Computing Certification Authority (ASGCCA) Certificate Policy and Certification Practice Statement

Version 3.0

June, 2013

 

 

 

Document Revision History

Version	Date	Editor
3.0	June 2013	Jinny Chien
2.1	March 2008	Jinny Chien
2.0	July 2006	Jinny Chien
1.5	September 2005
1.4	August 2005
1.1	February 2002

 

 

Abstract

Abstract 2

1. Introduction.. 8

1.1 Overview.. 8

1.2 Document Name and Identification.. 8

1.3 PKI Participants. 9

1.3.1 Certification Authorities. 9

1.3.2 Registration Authorities. 9

1.3.3 Subscribers. 9

1.3.4 Relying Parties. 10

1.3.5 Other Participants. 10

1.4 Certificate Usage. 10

1.4.1 Appropriate Certificate Uses. 10

1.4.2 Prohibited Certificate Uses. 10

1.5 Policy Administration.. 10

1.5.1 Organization Administering the Document 10

1.5.2 Contact Person.. 11

1.5.3 Person Determing CPS Suitability for the Policy. 11

1.5.4 CPS Approval Procedures. 11

1.6 Definitions and Acronyms. 11

2. Publication and Repository Responsibilities. 14

2.1 Repositories. 14

2.2 Publication of Certification Information.. 14

2.3 Time or Frequency of Publication. 14

2.4 Access Controls on Repositories. 14

3. Identification and Authentication. 15

3.1 Naming. 15

3.1.1 Types of Names. 15

3.1.2 Need for Names to be Meaningful 15

3.1.3 Anonymity or pseudonymity of Subscribers. 15

3.1.4 Rules for Interpreting Various Name Forms. 15

3.1.5 Uniqueness of Names. 15

3.1.6 Recognition, Authentication, and Role of Trademarks. 16

3.2 Initial Identity Validation.. 16

3.2.1 Method to Prove Possession of Private Key. 16

3.2.2 Authentication of Organization Identity. 16

3.2.3 Authentication of Individual Identity. 16

3.2.4 Non-verified Subscriber Information.. 17

3.2.5 Validation of Authority. 17

3.2.6 Criteria of Interoperation.. 17

3.3 Identification and Authentication for Re-key Requests. 17

3.3.1 Identification and Authentication for Routine Re-key. 17

3.3.2 Identification and Authentication for Re-key after Revocation.. 17

3.4 Identification and Authentication for Revocation Request 17

4. Certificate Life-Cycle Operational Requirements. 18

4.1 Certificate Application.. 18

4.1.1 Who Can Submit a Certificate Application.. 18

4.1.2 Enrollment Process and Responsibilities. 18

4.2 Certificate Application Processing. 19

4.2.1 Performing Identification and Authentication Functions. 19

4.2.2 Approval or Rejection of Certificate Applications. 19

4.2.3 Time to Process Certificate Applications. 19

4.3 Certificate Issuance. 19

4.3.1 CA Actions During Certificate Issuance. 19

4.3.2 Notifications to Subscriber by the CA of Issuance of Certificate. 20

4.4 Certificate Acceptance. 20

4.4.1 Conduct Constituting Certificate Acceptance. 20

4.4.2 Publication of the Certificate by the CA.. 20

4.4.3 Notification of Certificates Issuance by the CA to Other Entities. 20

4.5 Key Pair and Certificate Usage. 20

4.5.1 Subscriber Private Key and Certificate Usage. 20

4.5.2 Relying Party Public Key and Certificate Usage. 21

4.6 Certificate Renewal 21

4.6.1 Circumstances for Certificate Renewal 21

4.6.2 Who May Request Renewal 21

4.6.3 Processing Certificate Renewal Requests. 21

4.6.4 Notification of New Certificate Issuance to Subscriber 21

4.6.5 Conduct Constituting Acceptance of a Renewal Certificate. 21

4.6.6 Publication of the Renewal Certificate by the CA.. 21

4.6.7 Notification of Certificate Issuance by the CA to Other Entities. 22

4.7 Certificate Re-key. 22

4.7.1 Circumstances for Certificate Re-key. 22

4.7.2 Who May Request Certification of a New Public Key. 22

4.7.3 Processing Certificate Re-key Requests. 22

4.7.4 Notification of New Certificate Issuance to Subscriber 23

4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate. 23

4.7.6 Publication of the Re-keyed Certificate by the CA.. 23

4.7.7 Notification of Certificate Issuance by the CA to Other Entities. 23

4.8 Certificate Modification.. 23

4.8.1 Circumstances for Certificate Modification.. 23

4.8.2 Who May Request Certificate Modification.. 23

4.8.3 Processing Certificate Modification Requests. 23

4.8.4 Notification of new certificate issuance to subscriber 23

4.8.5 Conduct Constituting Acceptance of Modified Certificate. 23

4.8.6 Publication of the Modified Certificate by the CA.. 24

4.8.7 Notification of Certificate Issuance by the CA to Other Entities. 24

4.9 Certificate Revocation and Suspension. 24

4.9.1 Circumstances for Revocation.. 24

4.9.2 Who Can Request Revocation.. 24

4.9.3 Procedure for Revocation Request 24

4.9.4 Revocation Request Grace Period. 25

4.9.5 Time Within Which CA Must Process the Revocation Request 25

4.9.6 Revocation Checking Requirements for Relying Parties. 25

4.9.7 CRL Issuance Frequency. 25

4.9.8 Maximum latency for CRLs. 25

4.9.9 Online Revocation/Status Checking Availability. 25

4.9.10 Online Revocation Checking Requirements. 25

4.9.11 Other Forms of Revocation Advertisements Available. 26

4.9.12 Special Requirements Re-key Compromise. 26

4.9.13 Circumstances for Suspension. 26

4.9.14 Who can Request Suspension. 26

4.9.15 Procedure for Suspension Request 26

4.9.16 Limits on Suspension Period. 26

4.10 Certificate Status Services. 26

4.10.1 Operational Characteristics. 26

4.10.2 Service Availability. 26

4.10.3 Operational Features. 26

4.11 End of Subscription.. 27

4.12 Key Escrow and Recovery. 27

4.12.1 Key Escrow and Recovery Policy and Practices. 27

4.12.2 Session Key Encapsulation and Recovery Policy and Practices. 27

5. Physical, Procedural and Personnel Security Controls. 28

5.1 Physical Controls. 28

5.1.1 Site Location and Construction.. 28

5.1.2 Physical Access. 28

5.1.3 Power and Air Conditioning. 28

5.1.4 Water Exposures. 28

5.1.5 Fire Prevention and Protection.. 28

5.1.6 Media Storage. 28

5.1.7 Waste Disposal 29

5.1.8 Off-Site Backup. 29

5.2 Procedural Controls. 29

5.2.1 Trusted Roles. 29

5.2.2 Number of Persons Required per Task. 29

5.2.3 Identification and Authentication for Each Role. 29

5.2.4 Roles Requiring Separation of Duties. 29

5.3 Personnel Controls. 29

5.3.1 Qualifications, Experience, and Clearance Requirements. 29

5.3.2 Background Check Procedures. 29

5.3.3 Training Requirements. 30

5.3.4 Retraining Frequency and Requirement 30

5.3.5 Job Rotation Frequency and Sequence. 30

5.3.6 Sanctions for Unauthorized Actions. 30

5.3.7 Independent Contractor Requirements. 30

5.3.8 Documentation Supplied to Personnel 30

5.4 Audit Logging Procedures. 30

5.4.1 Types of Events Recorded. 30

5.4.2 Frequency of Processing Logs. 31

5.4.3 Retention Period for Audit Logs. 31

5.4.4 Protection of Audit Log. 31

5.4.5 Audit Log Backup Procedures. 31

5.4.6 Audit Collection System (internal vs. external) 31

5.4.7 Notification to Event-Causing Subject 31

5.4.8 Vulnerability Assessments. 31

5.5 Records Archival 31

5.5.1 Types of Records Archived. 31

5.5.2 Retention Period for Archive. 31

5.5.3 Protection of Archive. 32

5.5.4 Archive Backup Procedures. 32

5.5.5 Requirements for Time-Stamping of Records. 32

5.5.6 Archive Collection System (Internal or External) 32

5.5.7 Procedures to Obtain and Verify Archive Information.. 32

5.6 Key Changeover 32

5.7 Compromise and Disaster Recovery. 32

5.7.1 Incident and Compromise Handling Procedure. 33

5.8 CA or RA Termination.. 33

6. Technical Security Controls. 34

6.1 Key Pair Generation and Installation.. 34

6.1.1 Key Pair Generation.. 34

6.1.2 Private Key Delivery to Subscriber 34

6.1.3 Public Key Delivery to Certificate Issuer 34

6.1.4 CA Public Key Delivery to Relying Parties. 34

6.1.5 Key Sizes. 34

6.1.6 Public Key Parameters Generation and Quality Checking. 34

6.1.7 Key Usage Purposes (as per X.509 v3 Key Usage Field) 34

6.2 Private Key Protection and Cryptographic Module Engineering Controls  35

6.2.1 Cryptographic Module Standards and Controls. 35

6.2.2 Private Key (n out of m) Multi-person Control 35

6.2.3 Private Key Escrow.. 35

6.2.4 Private Key Backup. 35

6.2.5 Private Key Archival 35

6.3 Other Aspects of Key Pair Management 35

6.3.1 Public Key Archival 36

6.3.2 Certificate Operational Periods and Key Pair Usage Periods. 36

6.4 Activation Data. 36

6.4.1 Activation Data Generation and Installation.. 36

6.4.2 Activation Data Protection.. 36

6.4.3 Other Aspects of Activation Data. 36

6.5 Computer Security Controls. 36

6.5.1 Specific Computer Security Technical Requirements. 36

6.5.2 Computer Security Rating. 36

6.6 Life Cycle Technical Controls. 37

6.7 Network Security Controls. 37

6.8 Time-Stamping. 37

7 Certificate, CRL, and OCSP Profiles. 38

7.1 Certificate Profile. 38

7.1.1 Version Number(s) 38

7.1.2 Certificate Extensions. 38

7.1.3 Algorithm Object Identifiers. 38

7.1.4 Name Forms. 38

7.1.5 Name Constraints. 39

7.1.6 Certificate Policy Object Identifier 39

7.1.7 Usage of Policy Constraints Extensions. 39

7.1.8 Policy Qualifier Syntax and Semantics. 39

7.1.9 Processing Semantics for the Critical Certificate Policies Extension   39

7.2 CRL Profile. 39

7.2.1 Version Number(s) 39

7.2.2 CRL and CRL Entry Extensions. 39

7.2 OCSP Profile. 39

7.3.1 Version Number(s) 39

7.3.2 OCSP Extensions. 40

8. Compliance Audit and Other Assessment 41

8.1 Frequency and Circumstances of Assessments. 41

8.2 Identity / Qualifications of Assessor 41

8.3 Assessor’s Relationship to Assessed Entity. 41

8.4 Topic covered by assessment 41

8.5 Actions taken as a result of deficiency. 41

8.6 Communication of result 42

9. Other Business and Legal Matters. 43

9.1 Fees. 43

9.2 Financial Responsibility. 43

9.4 Privacy Plan.. 43

9.5 Intellectual Property rights. 43

9.12 Amendments. 43

9.14 Governing Law.. 43

 

1. Introduction

1.1 Overview

This document is based on the structure suggested by the ''Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework'' [RFC 3647]. 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://ca.grid.sinica.edu.tw).

1.2 Document Name and Identification

• Document title:

Academia Sinica Grid Computing Certification Authority (ASGCCA) Certificate Policy and Certification Practice Statement

• Document version:

3.0

• OID:

The following ASN.1 Object Identifier (OID) has been assigned to this document: 1.3.6.1.4.1.5935.10.1.3.0. This OID is constructed as shown in the table below

IANA	1.3.6.1.4.1
Academia Sinica Computing Centre	.5935
ASGCCA	.10
CP/CPS	.1
Major Version	.3
Minor Version	.0

• Document date:

 June 2013

1.3 PKI Participants

1.3.1 Certification Authorities

ASGCCA is managed by Academia Sinica Grid Computing Centre.

1.3.2 Registration Authorities

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. (http://ca.grid.sinica.edu.tw/contact.html)

Every organization has at least one Registration Authority who is in charge of an organization. Only permanent staff members are eligible to become an ASGCCA RA for their organizations.

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 a face to face 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.

1.3.3 Subscribers

ASGCCA issues certificates to person (user certificate), computers and services (host certificates).

The entities eligible for certification by the ASGCCA are:

• 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/EGI Project without CA support in Asia.

1.3.4 Relying Parties

A recipient of a certificate who acts in reliance on that certificate and/or digital signatures verified using that certificate.

1.3.5 Other Participants

No stipulation

1.4 Certificate Usage

1.4.1 Appropriate Certificate Uses

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.

1.4.2 Prohibited Certificate Uses

The certificates issued by ASGCCA must not be used for financial transaction.

1.5 Policy Administration

1.5.1 Organization Administering the Document

The ASGCCA is managed by Academia Sinica Grid Computing Centre.

128, Sec. 2, Academia Road, Nankang, Taipei, Taiwan 11529

http://www.twgrid.org,  http://ca.grid.sinica.edu.tw

1.5.2 Contact Person

Yen, Eric

Address: 128, Sec. 2, Academia Road, Nankang, and Taipei, Taiwan 11529

Phone: +886-2-2789-9494

Mobile: +886-922-959211

Fax: +886-2-2783-7653

A mailing list containing ASGCCA managers has been setup to ensure quick response :

Email: asgcca@grid.sinica.edu.tw

1.5.3 Person Determing CPS Suitability for the Policy

ASGCCA managers (see 1.5.2) determine CPS suitability for the policy.

1.5.4 CPS Approval Procedures

The document shall be submitted to APGridPMA (Asia Pacific Grid Policy Management Authority) for acceptance and accreditation. All major changes must be approved by APGridPMA.

1.6 Definitions and Acronyms

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.

• Public Key Infrastructure

A term generally used to describe the laws, policies, standards, and software that regulated or manipulate certificates and public and private keys. All of this implies a set of standards for applications that use encryption.

• Policy Management Authority (PMA)

An entity establishing requirements and best practices for public Key Infrastructure.

 

2. Publication and Repository Responsibilities

2.1 Repositories

A website is maintained by ASGCCA. It contains all the information published by ASGCCA specified in section 2.2. The website can be reached at the following address: http://ca.grid.sinica.edu.tw

2.2 Publication of Certification Information

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.

2.3 Time or Frequency of Publication

1. Certificates will be published as soon as issued.
2. The frequency of CRL publication is specified in subsection 4.9.7.
3. New version of CP/CPS is published as soon as they have been approved.

2.4 Access Controls on Repositories

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.

3. Identification and Authentication

3.1 Naming

3.1.1 Types of Names

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 3280].

l   In case of personal certificate the subject name must include the person’s full name. C=Country, O=Organization, OU=Unit, CN=First Name Last Name

l   In case of host certificate the subject name must include the FQDN of the host.  C=Country, O=Organization, OU=Unit, CN=DNS server name(FQDN)

3.1.2 Need for Names to be Meaningful

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.

3.1.3 Anonymity or pseudonymity of Subscribers

ASGCCA will neither issue nor sign pseudonymous or anonymous certificates. The ASGCCA RA validates identity of subscribers.

3.1.4 Rules for Interpreting Various Name Forms

l   Each entity has a clear and unique Distinguished Name in the certificate subject field.

l   For a host certificate, the common name(CN) must be functional fully qualified domain name.

l   Any name under this CPCPS defined as the form “OU=GRID”.

l   To select your organization, please choose “AP” if your organization is outside of Taiwan.

3.1.5 Uniqueness of Names

The Distinguished Name must be unique for each subject name certified by ASGCCA.

3.1.6 Recognition, Authentication, and Role of Trademarks

No stipulation

3.2 Initial Identity Validation

3.2.1 Method to Prove Possession of Private Key

The public and private keys are generated on the user station when he/she fills the certificate request form with Mozilla, Internet Explorer and Google Chrome browser.

3.2.2 Authentication of Organization Identity

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 organization is outside of Taiwan, the name of an organization must be “AP”. The information of authenticated organization is published on
 http://ca.grid.sinica.edu.tw/contact.html.

3.2.3 Authentication of Individual Identity

Procedures differ if the subject is a user or host:

• User certificate:

Users request user certificates must have face to face meetings with the RA and show their work IDs. 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 complete the online 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 APGridPMA, EUGridPMA and TAGPMA.

• Host certificate:

Requests must be signed with a valid personal ASGCCA user certificate.

3.2.4 Non-verified Subscriber Information

No stipulation.

3.2.5 Validation of Authority

See the provisions of section 3.2.2 and 3.2.3.

3.2.6 Criteria of Interoperation

No stipulation.

3.3 Identification and Authentication for Re-key Requests

3.3.1 Identification and Authentication for Routine Re-key

Expiration notifications are sent to subscribers before re-key time. Rekeying of certificates can be requested by an online procedure, which checks the validity of certificates.

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 Request

Certificate revocation request must be sent in the following ways:

l   Send e-mail to asgcca@grid.sinica.edu.tw signed with a valid and trusted certificate.

l   Contact personally the CA/RA staff in order to verify his/her identity and the validity of the request.

4. Certificate Life-Cycle Operational Requirements

4.1 Certificate Application

4.1.1 Who Can Submit a Certificate Application

• 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/EGI Project without CA support in Asia.

Procedures are different if the subject is a person or a server. For every certificate application, 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 Mozilla or Internet Explorer browser.
• Host: Certificate requests are submitted by an online procedure, using a Mozilla or Internet Explorer browser with a valid personal ASGCCA user certificate.

4.1.2 Enrollment Process and Responsibilities

Certificates requests are submitted by an online procedure on ASGCCA website (http://ca.grid.sinica.edu.tw), using a web browser. Authentication using a user certificate mandatory to request a host certificate.

For user certificates, the subject requests an appointment with the CA/RA (in person). The authentication according to sections 1.3.3, 3.2.2 and 3.2.3 must be processed in a face to face meeting. After a successful authentication, the CA/RA process and sign the request.

For host certificate, the request is through the secure online portal. The authentication is performed according to sections 1.3.3, 3.2.2 and 3.2.3.

4.2 Certificate Application Processing

4.2.1 Performing Identification and Authentication Functions

The certificate applications will be validated by the CA/RA. For new user certificate request, the CA/RA will authenticate the request according to sections 3.2.2 and 3.2.3. The host administrator must already have a valid personal ASGCCA certificate, required to authenticate to ASGCCA secure website and request host certificates.

4.2.2 Approval or Rejection of Certificate Applications

A certificate request is only allowed to users who do not already have a valid certificate assigned, otherwise rekey or revocation will be proposed. Provided the users as defined in section 4.1.1 and already verified by CA/RA. The certificate issuing is allowed.

4.2.3 Time to Process Certificate Applications

The process of issuing certificates is done immediately: identity verification has been made previously by the ASGCCA RA, and is mandatory to proceed with the request for a certificate.

4.3 Certificate Issuance

4.3.1 CA Actions During Certificate Issuance

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.

4.3.2 Notifications to Subscriber by the CA of Issuance of Certificate

After issuance of the certificate, ASGCCA will send a notification and guide to the subscriber how to download the certificate from ASGCCA online website.

4.4 Certificate Acceptance

4.4.1 Conduct Constituting Certificate Acceptance

No Stipulation.

4.4.2 Publication of the Certificate by the CA

All valid certificates are published in an online repository available at the URL: http://ca.grid.sinica.edu.tw/publication/newCRT/newcerts/crt.php

4.4.3 Notification of Certificates Issuance by the CA to Other Entities

During the period of issuance, ASGCCA manager sends the notification to the entity. Also forwards this message to RA.

4.5 Key Pair and Certificate Usage

4.5.1 Subscriber Private Key and Certificate Usage

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 his/her certificate.
• Request host certificate with valid FQDN (Fully Qualified Domain Name).

4.5.2 Relying Party Public Key and Certificate Usage

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.

4.6 Certificate Renewal

4.6.1 Circumstances for Certificate Renewal

ASGCCA does not renew subscribers’ certificates. Subscribers must follow the re-key procedure as described in section 4.7.

4.6.2 Who May Request Renewal

ASGCCA does not renew subscribers’ certificates. Subscribers must follow the re-key procedure as described in section 4.7.

4.6.3 Processing Certificate Renewal Requests

ASGCCA does not renew subscribers’ certificates. Subscribers must follow the re-key procedure as described in section 4.7.

4.6.4 Notification of New Certificate Issuance to Subscriber

ASGCCA does not renew subscribers’ certificates. Subscribers must follow the re-key procedure as described in section 4.7.

4.6.5 Conduct Constituting Acceptance of a Renewal Certificate

ASGCCA does not renew subscribers’ certificates. Subscribers must follow the re-key procedure as described in section 4.7.

4.6.6 Publication of the Renewal Certificate by the CA

ASGCCA does not renew subscribers’ certificates. Subscribers must follow the re-key procedure as described in section 4.7.

4.6.7 Notification of Certificate Issuance by the CA to Other Entities

ASGCCA does not renew subscribers’ certificates. Subscribers must follow the re-key procedure as described in section 4.7.

4.7 Certificate Re-key

4.7.1 Circumstances for Certificate Re-key

The lifetime of ASGCCA certificates must be no longer than 13 months. If users would get the brand-new certificate and private key, they must follow the online procedure to get these achieves from ASGCCA manager.

Subscribers must regenerate the key pairs in the following circumstance:

• Expiration of the certificates signed by ASGCCA.
• Revocation of the certificates by ASGCCA.
• If the current private key is suspected to be compromised.

4.7.2 Who May Request Certification of a New Public Key

See section 4.1.1

4.7.3 Processing Certificate Re-key Requests

• User certificate:

Re-key request before expiration of the user certificate can be accomplished by sending an online request with the current user certificate. Subscriber follows the authentication procedure to get a new certificate. Please note that the user certificate must be imported to the browser to access the secure re-key page.

• Host certificate:

Requests must be signed with a valid personal ASGCCA user certificate.

4.7.4 Notification of New Certificate Issuance to Subscriber

See the provisions of section 4.3.2

4.7.5 Conduct Constituting Acceptance of a Re-keyed Certificate

No stipulation

4.7.6 Publication of the Re-keyed Certificate by the CA

See the provisions of section 4.4.2.

4.7.7 Notification of Certificate Issuance by the CA to Other Entities

See the provisions of section 4.4.3.

4.8 Certificate Modification

Certificates must not be modified. In case of changes, the old certificate must be revoked, and a new certificate must be requested.

4.8.1 Circumstances for Certificate Modification

No stipulation

4.8.2 Who May Request Certificate Modification

No stipulation

4.8.3 Processing Certificate Modification Requests

No stipulation

4.8.4 Notification of new certificate issuance to subscriber

No stipulation

4.8.5 Conduct Constituting Acceptance of Modified Certificate

No stipulation

4.8.6 Publication of the Modified Certificate by the CA

No stipulation

4.8.7 Notification of Certificate Issuance by the CA to Other Entities

No stipulation

4.9 Certificate Revocation and Suspension

4.9.1 Circumstances for 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 a 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 India, Malaysia , Vietnam et al. could apply for ASGCCA. If new CA service started up in their own countries or their organizations, ASGCCA would actively revoke their certificates to avoid name space conflict. Also, ASGC would inform the user/host administrators to apply certificates from applicable CA organizations.

4.9.2 Who Can Request Revocation

The revocation of the certificate can be requested by:

• The certificate subscriber
• Any other entity presenting evidence of circumstances as described in section 4.9.1.

4.9.3 Procedure for Revocation Request

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 subscribers 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 4.9.1.

4.9.4 Revocation Request Grace Period

The CRL is updated immediately after every revocation.

4.9.5 Time Within Which CA Must Process the Revocation Request

The CRL is updated immediately after every revocation.

4.9.6 Revocation Checking Requirements for Relying Parties

There is no provision for certificate suspension.

4.9.7 CRL Issuance Frequency

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.

4.9.8 Maximum latency for CRLs

The maximum latency for CRLs is immediately after every revocation.

4.9.9 Online Revocation/Status Checking Availability

No stipulation

4.9.10 Online Revocation Checking Requirements

No stipulation.

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

There is no provision for certificate suspension.

4.9.14 Who can Request Suspension

There is no provision for certificate suspension.

4.9.15 Procedure for Suspension Request

There is no provision for certificate suspension.

4.9.16 Limits on Suspension Period

There is no provision for certificate suspension.

4.10 Certificate Status Services

4.10.1 Operational Characteristics

The ASGCCA operates as an online repository that contains all the CRLs that have been issued. See http://ca.grid.sinica.edu.tw/publication/newCRT/newcerts/status.php

4.10.2 Service Availability

The online repository is available 24 hours a day, 7 days a week, subject to reasonable scheduled maintenance.

4.10.3 Operational Features

No stipulation

4.11 End of Subscription

The subscription ends with the expiration of the certificate if it is not rekeyed before that date, or if the subscriber requests the revocation of the certificate.

4.12 Key Escrow and Recovery

4.12.1 Key Escrow and Recovery Policy and Practices

ASGCCA does not support key escrow and recovery

4.12.2 Session Key Encapsulation and Recovery Policy and Practices

No stipulation

 

5. Physical, Procedural and Personnel Security Controls

5.1 Physical Controls

5.1.1 Site Location and Construction

The ASGCCA is located safely at Academia Sinica Grid Computing Centre facilities in Taiwan.

5.1.2 Physical Access

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.

5.1.3 Power and Air Conditioning

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.

5.1.4 Water Exposures

Due to the location of the ASGCCA facilities floods are not expected.

5.1.5 Fire Prevention and Protection

ASGCCA facilities obey to the R.O.C. law regarding fire prevention and protection in buildings.

5.1.6 Media Storage

The ASGCCA key is kept in several removable storages. Backup copies of CA related information are kept in removable media.

5.1.7 Waste Disposal

Wastes carrying potential confidential information such as old floppy disks are physically destroyed before being disposal of.

5.1.8 Off-Site Backup

No off-site backups are currently performed.

5.2 Procedural Controls

5.2.1 Trusted Roles

No Stipulations.

5.2.2 Number of Persons Required per Task

No Stipulations.

5.2.3 Identification and Authentication for Each Role

No Stipulations.

5.2.4 Roles Requiring Separation of Duties

No Stipulations.

5.3 Personnel Controls

All access to servers and applications that compromise the Academia Sinica Grid Computing Centre is controlled.

5.3.1 Qualifications, Experience, and Clearance Requirements

CA personnel are recruited from the Academia Sinica Grid Computing Centre and familiar with PKI concept.

5.3.2 Background Check Procedures

No other personnel are authorized to access ASGCCA facilities without the physical presence of CA personnel.

5.3.3 Training Requirements

Internal training is given to CA operators.

5.3.4 Retraining Frequency and Requirement

No Stipulation

5.3.5 Job Rotation Frequency and Sequence

Job rotation is not performed.

5.3.6 Sanctions for Unauthorized Actions

No Stipulation.

5.3.7 Independent Contractor Requirements

No Stipulation

5.3.8 Documentation Supplied to Personnel

• Copies of this document;
• ASGCCA Operations Manual.

5.4 Audit Logging Procedures

5.4.1 Types of Events Recorded

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

5.4.2 Frequency of Processing Logs

No Stipulation.

5.4.3 Retention Period for Audit Logs

Logs will be kept for a minimum of 3 years.

5.4.4 Protection of Audit Log

All audit logs are accessible to the ASGCCA managers and to authorized audit personnel.

5.4.5 Audit Log Backup Procedures

Audit logs are copied to an offline medium every 3 months.

5.4.6 Audit Collection System (internal vs. external)

Audit collection is internal to ASGCCA service.

5.4.7 Notification to Event-Causing Subject

No stipulation

5.4.8 Vulnerability Assessments

No stipulation

5.5 Records Archival

5.5.1 Types of Records Archived

The provisions of section 5.4.1 apply.

5.5.2 Retention Period for Archive

The minimum retention period is 3 years.

5.5.3 Protection of Archive

The archive is accessible to ASGCCA personnel only.

5.5.4 Archive Backup Procedures

Archives are copied to an offline medium and stored in a restricted access area every 3 months.

5.5.5 Requirements for Time-Stamping of Records

All records are saved with an automatically generated time stamp.

5.5.6 Archive Collection System (Internal or External)

Archive collection is internal to ASGCCA service.

5.5.7 Procedures to Obtain and Verify Archive Information

No stipulation

5.6 Key Changeover

No stipulation

5.7 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

5.7.1 Incident and Compromise Handling Procedure

• If the keys of an end entity are lost or compromised, the ASGCCA RA must be informed immediately in order to revoke the certificate. The owner of the certificate can do this by himself using the ASGCCA website (https://ca.grid.sinica.edu.tw/certificate/revoke/revoke.php)
• If ASGCCA's private key is (or suspected to be) compromised, the CA will:
• Inform the Registration Authorities, subscribers and relying parties of which the CA is aware.
• Terminate the certificates and CRL distribution services for certificates and CRLs issued using the compromised key.

5.8 CA or RA Termination

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.

 

 

 

 

 

 

6. Technical Security Controls

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

The key pair of the ASGCCA Root CA is generated by authorized CA staff on the offline ASGCCA Root CA machine. The keys for ASGCCA are generated by software, in the CA service. 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.

6.1.2 Private Key Delivery to Subscriber

The ASGCCA does not generate private keys hence does not deliver private keys.

Entities' private key will be generated by browser application in personal computer.

6.1.3 Public Key Delivery to Certificate Issuer

Entities' public keys are delivered to issuing CA in a secure and trustworthy manner.

6.1.4 CA Public Key Delivery to Relying Parties

CA certificate can be downloaded from the ASGCCA secure web site.

6.1.5 Key Sizes

• The minimum key length for user or host 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)

ASGCCA private key is the only key used for signing CRLs and Certificates for person and server.

The Certificate key Usage field must be used in accordance with the ”Internet X.509 Public Key Infrastructure Certificate and CRL profile'' [RFC 3280].

6.2 Private Key Protection and Cryptographic Module Engineering Controls

6.2.1 Cryptographic Module Standards and Controls

No Stipulation.

6.2.2 Private Key (n out of m) Multi-person Control

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 Controls]. Backup Copy of the CA's private key is under (2 out of 5) multi-person control.

6.2.3 Private Key Escrow

ASGCCA keys are not given in escrow. ASGCCA is not available for accepting escrow copies of keys of other parties.

6.2.4 Private Key Backup

The ASGCCA's private key is kept encrypted in multiple copies in portable Hard Disk device and USBs in safe places. For emergencies, the passphrase is in a sealed envelope kept in a safe.

6.2.5 Private Key Archival

See the provisions of section 6.2.4.

6.3 Other Aspects of Key Pair Management

• The lifetime of ASGCCA certificate is 20 years.
• The lifetime of user certificate is 1 year.
• The lifetime of host certificate is 1 year.

6.3.1 Public Key Archival

The CA archives all issued certificates and its own public keys.

6.3.2 Certificate Operational Periods and Key Pair Usage Periods

Subscriber certificates have a validity period of 1 year. The ASGCCA certificate has a life time of 20 years.

6.4 Activation Data

The ASGCCA's private key is protected by a 15 characters passphrase.

6.4.1 Activation Data Generation and Installation

No stipulation.

6.4.2 Activation Data Protection

If subscriber's private key is protected by a pass phrase, it must be a strong pass phrase.

6.4.3 Other Aspects of Activation Data

No stipulation.

6.5 Computer Security Controls

6.5.1 Specific Computer Security Technical Requirements

• The CA system is a dedicated machine
• 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.

6.5.2 Computer Security Rating

No Stipulation.

6.6 Life Cycle Technical Controls

No Stipulation.

6.7 Network Security Controls

• The CA signing machine is kept off-line;
• CA website machines other than the signing machine are protected by a firewall.

6.8 Time-Stamping

No Stipulation.

7 Certificate, CRL, and OCSP Profiles

7.1 Certificate Profile

All certificates issued by ASGCCA conform to the Internet PKI profile (PKIX) for X.509 certificates as defined by RFC 3280.

7.1.1 Version Number(s)

X.509 v3.

7.1.2 Certificate Extensions

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

7.1.3 Algorithm Object Identifiers

No Stipulation.

7.1.4 Name Forms

Issuer:

l   C=TW, O=AS, CN=Academia Sinica Grid Computing Certification Authority Mercury

Person DN:

l   C=Country, O=Organization, OU=GRID, CN=First Name Last Name

Server name DN:

l   C=Country, O=Organization, OU=GRID, CN=DNS server name(FQDN)

7.1.5 Name Constraints

The CA does not support the name constraints extension.

7.1.6 Certificate Policy Object Identifier

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

7.2.1 Version Number(s)

x.509 v1.

7.2.2 CRL and CRL Entry Extensions

No Stipulation.

7.2 OCSP Profile

7.3.1 Version Number(s)

No Stipulation.

7.3.2 OCSP Extensions

No Stipulation.

 

8. Compliance Audit and Other Assessment

ASGCCA may be audited by other trusted CAs to verify its compliance with the rules and procedures specified in this document.

8.1 Frequency and Circumstances of Assessments

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.

8.2 Identity / Qualifications of Assessor

The CA will be audited by the other cross-certifying CAs.

8.3 Assessor’s Relationship to Assessed Entity

It is desirable that the auditor is a third-party to this PKI system.

8.4 Topic covered by assessment

Audit items will be selected based on the WebTrust criteria and minimum CA requirements enacted by the APGridPMA, EUGridPMA and TAGPMA. The audit must cover both compliance audit and operational audit.

8.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.

8.6 Communication of result

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.

 

 

 

 

 

9. Other Business and Legal Matters

9.1 Fees

No fees are charged for any service provided by ASGCCA.

9.2 Financial Responsibility

No financial responsibility is accepted fir certificates issued under this policy.

9.4 Privacy Plan

No stipulation.

9.5 Intellectual Property rights

Parts of this document are inspired by [CERN CA], [DutchGrid CA].

9.12 Amendments

Amendments to this CP/CPS must undergo the same procedures as for the initial approval (see 1.5.4).

9.14 Governing Law

Interpretation of this policy is according to R.O.C laws.

 

Bibliography

CERN CA

CERN CA Certificate Policy and Certification Practice Statement. http://ca.cern.ch/ca/crl/policy/cp-cps.pdf

 

DutchGrid CA

DutchGrid CA Certificate Policy and Certification Practice Statement.

http://ca.dutchgrid.nl/medium/policy/DutchGridCA-CPCPS-3.2.pdf

 

RFC 3280

Internet X.509 Public Key Infrastructure Certificate and CRL Profile. http://www.ietf.org/rfc/rfc3280.txt

 

RFC 3647

Internet X.509 Public Key Infrastructure Certificate Policy and Certification Practices Framework. http://www.ietf.org/rfc/rfc3647.txt