-- DavidBannon - 03 Dec 2007

APAC-GRID CA Policy Statement

History

• CPS OID : 1.3.6.1.4.1.23953.1.2.1.1 Released November 1st 2005. Associated with a non production Certificate Authority, withdrawn end 2005.
• CPS OID : 1.3.6.1.4.1.23953.1.2.1.2 Released 5/1/2006
• CPS OID : 1.3.6.1.4.1.23953.1.2.1.3 Released 26/6/2006
• CPS OID : 1.3.6.1.4.1.23953.1.2.1.4 Released 17/5/2007 (clarification of physical location, relevent people, confidentiality rules, CRL encryption and support for NZ)
• Moved to new ARCS TWIKI but no changes made to content - 4/12/2007

Note that this CPS is based on RFC2527 but will be moved to RFC3647 at some stage in the future.

1. Introduction

1.1 Overview

This document describes policies and procedures used by APACGrid staff in relation to the APACGrid PKI.

1.2 Identification

Title: APACGrid CA Certificate Policy Statement

OID : The OID of the organisation for which the CA operates, APAC, is 1.3.6.1.4.1.23953, please see http://www.iana.org/assignments/enterprise-numbers, the actual current number for this document appears at the top of the document. (Prefix 1.3.6.1.4.1, OID 23953, Group, CA, Version, Release)

Please note that the version (1) and release (1) was initialised on November 1, 2005 by David Bannon from a document constructed during 2004 and 2005 by Damon Smith.

1.3 Community and Applicability

APACGrid CA provides certificates for grid users and infrastructure, and PKI operators involved in the APAC Grid.

Additionally, the APACGrid CA issues certificates for the New Zealand based BeSTGrid? at the request of the BeSTGrid? Director. If the BeSTGrid? Director requests the APACGrid to stop issuing certificates of this nature, the APACgrid will do so and will revoke all NZ certificates then current. For the purpose of certificate revocation requests, the Director of the BeSTGrid? will have the same effect as APAC Grid Program Manager.

The Certificate Authority is operated by VPAC on behalf of APAC. The CA Manager is David Bannon, the APAC Grid Infrastructure Project Manager. This role reports to the APAC Grid Manager, Lindsay Hood and the APAC Executive Director, John O'Callaghan.

1.3.1 Certificate Authorities

No certificates will be issued to subordinate CAs.

1.3.2 Registration Authorities

This PKI system includes one Registration Authority. More may be added later if required.

1.3.3 End Entities

End Entities serviced by this PKI are any actors (people, machines, software) involved in APAC Grid infrastructure activities. In practice these are compute systems, researchers and students from associated universities and research institutes. Occasionally people from other organisations may be involved but it will be under the sponsorship of that first named group.

1.3.4 Applicability

Certificates issued are to be used for grid security, generally with the various Globus certificate related security tools, and PKI object signing and authentication.

1.4 Contact Details

Contact APACGrid CA staff by email: camanager@vpac.org.

2. General Provisions

2.1 Obligations

2.1.1 CA Obligations

• To ensure that reasonable care is taken to met the requirements of this CPS
• To report and / or correct any security or operational matter of concern.
• To promptly process certificate and revocation applications and to notify the applicant in a reasonable time frame.
• To ensure that appropriate lists are published and end entities are informed as necessary.
• To ensure that backups and archives are appropriately done.

2.1.2 RAO Obligations

• To ensure that reasonable care is taken to meet the requirments of this CPS
• To report and / or correct any security or operational matter of concern.
• To authorise applications only after a face to face meeting with the applicant, only after the applicant has displayed appropriate photo ID and only after the RAO is reasonably sure that the applicant is an appropriate person to have an APACGrid Certificate.
• To ensure that the applicant is aware of rules, policy and limitations of the APACGrid.
• To ensure that the applicant is aware that they must protect their private key in the manner described in 6.1.8
• To keep suitable records of applicant meetings.
• To assist users with lodging applications and collecting certificates if necessary.

RAO Procedures

RAOs are required to check the photo ID, in person, of a user before approving a request. The procedure for approval is:

1. The applicant meets the RAO at an agreed upon time in person, and presents the RAO with the serial number of their request, and some photo ID to prove their identity.
2. The RAO logs in to the RA website at https://ca.apac.edu.au/ra, and follow the menu tabs to the Active CSRs->new and clicks Search. The RAO uses the applicant's serial number to find the request
3. The RAO checks that the name provided by the applicant closely relates to the name that person generally uses, and that their photo ID is valid.
4. The RAO then checks that the certificate lifetime is no more than 365 days (or n/a, which is effectively the same), and that the organisation unit field is correct for the user RAO List. If these or anything else are incorrect on the application, the RAO edits the request and changes them.
5. If the RAO is satisfied that an appropriate certificate will be generated, they may approve the request, or delete it if they feel the application isn't valid.
6. The approved request will then be signed by the Certificate Authority, this is generally done at the end of each business day. The user should then follow the instructions on the CaInterface? for collecting their certificate. The RAO isn't required to do anything further.

Note

1. An RAO may not nominate a substitute or 'stand in' RAO to perform their duty in the their absence. If necessary, another person can be appointed an RAO (subject to normal RAO appointment process) and act in their own right.
2. An RAO must meet, face to face, in person with the applicant. Phone calls, video conferences, Access Grid Sessions are not appropriate approval forums.
3. A RAO must always err on the safe side, that is, if there is any doubt about an approval process it must be rejected.
4. Occasionally the restrictions placed on the approval process will cause unwelcome delays in processing a certificate application. This cannot be avoided.
5. RAOs may decide to sign requests only from within their own area (as they define) or to help end users from other organisations as they wish if they are satisfied it is appropriate to do so. In all cases the security policies as mentioned above take precedence over the need to assist people.

2.1.3 Subscriber Obligations

• Acknowledge, read and adhere to the rules, policies and limitations as per the CPS.
• Not falsify personal information
• Protect private key in the manner described in 6.1.8.
• Notify APACGrid CA staff if the private key is suspected of compromise.

2.1.4 Relying Party Obligations

• To allow use of certificates for only the purposes that they are issued for.
• To collect and observe revocation and suspension lists.
• Acknowledgement of liability caps and limitations (2.2, 2.3)

2.1.5 Repository Obligations

• To publish certificates, revocation and suspension lists in a timely manner.
• To ensure appropriate records are retained as described elsewhere in this document.

2.2 Liability

The APACGrid CA and its agents issue certificates to persons and hosts according to the practices described in this document to validate identity. No liability, implicit or explicit, is accepted.

APACGrid CA certificates are intended only to provide a reasonable indication that a user is authentic, and cannot guarantee that a certificate and key aren't controlled by another party. No financial obligation exists between users and APACGrid CA.

APACGrid CA and its agents make no guarantee about the security or suitability of a service that is identified by a APACGrid CA certificate. The certification service is run with a reasonable level of security, but it is provided on a best-effort 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.

The APAPGrid CA denies any financial or any other kind of responsibility for damages or impairments resulting from its operation.

2.3 Financial Responsibility

APACGrid CA assumes no financial responsibility in any aspect of Certificate Authority

2.4 Interpretation and Enforcement

The APACGrid CA staff will attempt to rectify any identified breach of these procedures.

2.4.1 Governing Law

APACGrid CA is subject to Australian law.

2.5 Fees

APACGrid CA is a project funded by the Australian Partnership for Advanced Computing (APAC). All members of APAC involved in the APAC GRID project will therefore will be able to use the services provided by APACGrid CA at no charge.

2.6 Publication and Repositories

2.6.1 Publication of CA information

All publication of CA information will happen through the APAC Grid website and the APAC Grid Twiki VPAC, the operator of the CA is located at 110 Victoria St Carlton South Victoria, Australia

Information that is published includes :

• CA Certificate and Clients Certificates, published soon after issue.
• The Certificate Revocation List, published immediately after a revocation and before the current list expires.
• The RAO List
• The current CPS document and a list of suggested organisation names.
• Instructions, forms and other information to be used when applying for a certificate.

2.6.2 Frequency of Publication

All certificates and related data is available publicly on the APACGrid website shortly after it is created, or added. Certificate Revocation Lists will be published at least every 23 days, with a buffer of 7 days before the expiry of the previous CRL (4.4.9). A new CRL must be issued immediately after a revocation.

2.6.3 Access Controls

Access to the web interface is free to anyone. Access to the RA interface is limited via x509 based login to users with the role of RA or CA Operator. Access to the CA machine and interface is physically restricted to the CA operator.

The online components of the Authority are available 24x7 on a best effort basis except for a brief period for backup early Sunday mornings.

2.6.4 Repositories

All data relating to APACGrid CA can be found at http://www.vpac.org/apacgrid

2.7 Compliance Audit

The CA will undergo an internal audit from time to time to ensure compliance with this document and general security rules.

The CA expects to be audited, probably annually, by representatives of the Asia Pacific PMA.

2.8 Confidentiality

Limited information will be publicly available, other than names and email addresses (where supplied). Other information, such as phone numbers and physical addresses will be stored in a private manner, and will only be readily accessible to RA Operators and CA Operators for use in contacting end users about certificate status. However, the CA cannot undertake to keep this information completely secure, it can be derived from material that the CA is required to publish.

2.9 Intellectual Property Rights

All certificate related data issued by APACGrid CA is not under any copyright or intellectual property protection.

3. Identification and Authentication

3.1 Initial Registration

Initial Registration

There are no intellectual property rights attached to certificates, or certificate related material. This document is adapted from the Grid Canada policy statement, which in turn was adapted from various sources, see references [GCCA] [CNRS].

3.1.1 Types of Names

The subject name is an X500 Distinguished Name, it may be one of the following :

• Person - must include the organisation name and the name of the subject that closely relates to the name that person generally uses.
• Host - Must include the fully qualified domain name of the host.
• Service - Must include the organisation name, fully qualified domain name and the named service.

3.1.2 Name Meanings

Certificates for people must have a common name that closely relates to the name that person generally uses.

3.1.3 Rules for Interpreting Various Name Forms

No rules are given. APACGrid will be reasonable about name requests, but reserves the final say on what names will appear on certificates.

3.1.4 Uniqueness of Names

Distinguished Names must be unique. Two users can have the same common name, as long as there is a difference somewhere else in the DN, such as the organizational unit. Host will always have different fully qualified domain names.

OpenCA? prevents the issuing of a certificates if the DN will clash with an existing valid certificate.

Certificates must apply to unique individuals or resources. Users must not share certificates.

3.1.5 Name Claim Dispute Resolution Procedure

There is no set procedure for name claim resolution.

3.1.6 Recognition, Authentication, and Role of Trademarks

APACGrid does not provide certificates to trademarked entities, such as private companies.

3.1.7 Method to Prove Possession of Private Key

There is no requirement for users to prove possession of private keys, it is implicit in the grid system.

3.1.8 Authentication of Organization Identity

All Certificates issued must be associated with an organisation that is, in turn, associated with the APAC Grid Project. For this purpose, only organisations personally know to be associated with the APAC Grid by the CA Manager and / or the RAO will be considered. See Sect 4. "RAO Establishment"

3.1.9 Authentication of Individual Identity

Certificates will be issued to

• Members of the APACGRID project or people associated in some way with the APACGrid project, subject to the CA Manager's approval.
• Members of the New Zealand BeSTGRID? or people associated in some way with the BeSTGRID? project, subject to the CA Manager's approval.

The process used to establish an individual's identity and their appropriateness to have a certificate is detailed in Section 2.1.2.

3.2 Routine Rekey

Renewal of certificates involves generating a new CSR and submitting it in the same way as a new application. Rekey after expiration follows exactly the same procedure. The APACGrid CA will send renewal reminders at least a month before expiration.

3.3 Rekey After Revocation

This procedure is the same as for requesting a new certificate.

3.4 Revocation Request

Revocation requests may be submitted via the web interface.

4. Operational Requirements

RAO Establishment

The Authority seeks to establish a person at each institute or other physical location who accepts the role as an Registration Authority Operator. This person will be personally known to one of the CA staff or will be personally introduced to them by another person, of some standing, who personally knows both the potential RAO and the CA staff member. Once the potential RAO's identity is established and an appropriate personal certificate issued they are permitted to vouch for other people at their physical site.

When an RAO countersigns a certificate application, it is done over a https connection using the RAO own certificate enabled browser. An RAO cannot countersign an application using another persons browser.

The procedures to be followed by a RAO are listed at http://wiki.arcs.org.au/bin/view/Main/RaoGuide. Section 2.1.2 lists RAO obligations.

A written agreement with each RAO stating that they will follow those procedures is established.

4.1 Certificate Application

Grid users will generate a certificate signing request on a system under their own control using either the globus certificate request tools, or openssl tools. The request is uploaded over https to the OpenCA? web interface. Once the request is submitted, their identity will be verified by face to face meeting with a RA Operator, who will verify them using photo ID, and take a record of their request approval. The RAO will then electronically counter sign the application over a secure connection. If there is not an available RAO at the physical site, then travel to another site where the face to face meeting can take place, must happen.

The APACGrid CA does not support RAOs verifying applications using video conference or any other remote electronic means.

4.2 Certificate Issuance

Approved certificate requests will be signed at the end of each business day, and the signed certificates will be made available online shortly afterwards. Emails will be sent to new certificate holders, if they have supplied an email address.

4.3 Certificate Acceptance (or otherwise)

APACGrid CA does not confirm acceptance before publishing new certificates. If its necessary to reject a certificate application, the responsible administrator will advise the unsuccessful candidate and will, wherever possible, advise them of the reason as to why the application was rejected.

4.4 Certificate Suspension and Revocation

4.4.1 Circumstances for Revocation

The CA Manager should establish that a revocation request is appropriate before acting on that request, however, there may be times when such a request needs to be acted on quickly so unnecessary delays must be avoided. The following situations may apply :

• If for any reason a user requests the revocation of their own certificate, APACGrid CA will accept the request as soon as its reasonably certain that the request is genuine.
• If a senior APAC office holder requests a user's certificate be revoked, APACGrid CA will accept the request as soon as its reasonably certain that the request is genuine.
• If another user requests a certificate revocation, they must supply a reason, which will be considered, and APACGrid CA operator may also contact the revocation requester, the certificate holder, or both, before being satisfied that a certificate should be revoked.

4.4.2 Who Can Request Revocation

Any certificate holder. A senior APAC office holder such as APAC Chairman, APAC Grid Project Manager or the APAC Grid CA Manager.

4.4.3 Procedure for Revocation Request

Revocation requests can be submitted online, using the OpenCA? web interface. If necessary, one of the persons nominated under "Who Can Request Revocation", 4.4.2 can contact the Certificate Authority Manager or his/her nominee and request revocation.

4.4.4 Revocation Request Grace Period

There is no explicit grace period, although the revoked certificate may continue to work on any particular server up until the next certificate revocation list is activated.

4.4.5 Circumstances for Suspension

No Stipulation.

4.4.6 Who Can Request Suspension

No Stipulation.

4.4.7 Procedure for Suspension Request

No Stipulation.

4.4.8 Limits on Suspension Period

No Stipulation.

4.4.9 CRL Issuance Frequency

CRLs will be published every 23 days, seven days before the existing CRL is due to expire, or sooner (see also 2.6.2).

4.4.10 CRL Checking Requirements for Relying Parties

Servers relying on APACGrid CA Certificates are required to update their CRL every day or more frequently.

4.4.11 Online Revocation/Status Checking Availability

CRLs will be available for download at anytime, as long as the public web server is operational. No OCSP service is provided.

4.4.12 Online Revocation Checking Requirements

No stipulation.

4.4.13 Other Forms of Revocation Advertisement Available

None.

4.5 Security Audit Procedures

A person within the VPAC system team but not a CA Operator is appointed to watch the Online machine's security logs and to advise when its necessary to update security sensitive components. Access to the security logs is granted to this person in a way that does not allow them control of OpenCA? itself.

The CA expects to be audited as per section 2.7.

4.6 Records Archival

All records will be backed up to CD or DVD every week as part of the backup process. The entire image of the machine will be backed up including the databases. No separate backup of individual records takes place. As a log rotate system will eventually flush interesting records (such as boot and shutdown messages) one backup CD or DVD will be retained for each month indefinitely. This means that three and sometimes four CDs or DVDs may be discarded each month (to prevent the archive becoming too large), these disks must be physically destroyed.

4.6.1 Types of Event Audited

The following events will be logged :

• Any error reports
• Applications for Certificates (pkcs10_req)
• Approvals of application for certificate, by RAO. (approvecsr)
• Issuing of certificates.
• Requests for revocation (via web interface). (revoke_req)
• Revocations. (approvecrr)

Additionally, a time stamped backup copy of any new CRL is made every hour.

4.6.2 Retention Period for Audit Logs

Twenty four months minimum

4.6.3 Protection of Archive

The archive is stored in a large secure safe in the VPAC Machine room. This safe is accessible to only the VPAC Systems Manager (in the capacity of APACGrid CI Project Leader) and, potentially, the VPAC CEO. The machine room security is described in section 5.1

4.6.5 Time-Stamping Requirements

All archived logs and documents are time stamped.

4.6.6 Archive Collection System

Archives are collected using the OpenCA? software. The CRL backups are collected using a cron driven script and placed in /usr/local/archive

4.6.7 Procedures to Obtain and Verify Archive Information

Archives may be viewed as xml text files. Access to the web interface may be restricted for privacy or security reasons as determined by the CA Manager. Additionally a log of interesting events (4.6.1) is kept in ~/var/log. CRL backupd can be obtained by application to a CA Operator or the CA Manager.

4.7 Key Changeover

APACGrid CA expects no key changeover will happen for the lifetime of the CA. This limits the lifespan of APACGrid CA to nine years (until 2014).

The CA will stop issuing new user certificates with the CA private key when the validity of CA certificate is less than the validity of user certificate.

4.8 Compromise and Disaster Recovery

In the event of CA private key compromise, all certificates will be revoked, and the CA removed from service. In the event of disaster, the CA will be restored to full function from backups. If the backups are destroyed as well, the existing certificates can keep functioning until CRLs expire, but no new certificates can be issued, and therefore the CA must be replaced.

4.9 CA Termination

In the event that the CA operates until the end of it's certificate lifespan, it will be removed from service. All users and relying services will be notified well before this happens. Appropriate bodies may be notified and given the opportunity to access archives and records that might be necessary to establish an on going service.

5. Physical, Procedural and Personnel Security Controls

5.1 Physical Security Controls

The CA machine is stored in a secured machine room. Only specific VPAC Systems staff (and CEO) will have access to it physically. The CA machine is not connected to any network of any sort. Unauthorised users will not be permitted to have access to the CA machine. Certain other people, authorised by RMIT may, from time to time, enter the room where the CA machine is located for building maintainance purposes. Such entries are logged.

5.1.1 Site Location

No stipulation.

5.1.3 Power and Air Conditioning

Power and air conditioning are tightly controlled and alarmed to provide a reliable environment.

5.1.4 Water Exposure

Water detection alarms are in place on machine room underfloor.

5.1.5 Fire Prevention and Protection

The CA machine room has fire and heat detection.

5.1.6 Media Storage

Data is stored on local hard drives. Backups are stored on CDs or DVDs as per 4.6.3.

5.1.7 Waste Disposal

No pass phrases or private keys will be recorded on paper apart from one copy in the safe (4.6.3). Any media that has been used for backups or archives must be thoroughly cleaned and destroyed before being disposed of.

5.1.8 Off-site Backup

No off site backup will occur other than lodging images of the machines initial state with the APACGrid Manager who will store them in an appropriate secure place.

5.2 Procedural Controls

Procedures will be tested by APACGrid staff to ensure correct operation as part of internal audit as mentioned in Sect 2.7

5.2.1 Trusted Roles

Two nominated VPAC Systems Administrators operate the CA. They both know the CA Pass phrase. No other person will know the pass phrase although the VPAC Systems Manager can find out what it is from the archive (4.6.3) if deemed necessary.

5.3 Personnel Security Controls

Personnel are checked using identity cards before getting access to the building. Logs are retained (by external security contractor) of all entries.

6. Technical Security Controls

The CA Key

The CA is 2048 or greater bits. The CA Key is protected by a pass phrase of 15 characters or longer. See above 4.6.3 and 5.2.1 for details of backup storage of the CA key.

6.1 Key Pair Generation and Installation

6.1.1 Key Pair Generation

Key pairs for grid users and servers will be generated by the user, and no network transfer of private keys is required to get a certificate.

6.1.3 Public Key Delivery to Certificate Issuer

Certificate Signing Requests are submitted online using the https web interface.

6.1.4 CA Public Key Delivery to Users

The CA certificate is available online using the secure web interface.

6.1.5 Key Sizes

Personal Keys sizes can be either 1024, 2048 or 4096. Host Keys can be 2048 or 4096.

Key Lifetime

Personal keys have a life of 12 months. Host keys have a life of 12 months. The CA itself has a life of ten years.

6.1.6 Public Key Parameters Generation

Key generation parameters are controlled by grid config files and openssl.cnf file.

6.1.7 Parameter Quality Checking

No stipulation

6.1.8 Hardware/Software Key Generation

Software key generation is used in APACGrid.

End User Key Protection

End users must protect their private key with a pass phrase at least 12 characters long. A pass phrase of at least 12 characters long must also be applied to the users browser master password. Under no circumstances should an end user share their private key with another user or any other person. The CA cannot enforce these rules apart from making them plain to end users and advising them that CA services could be withdrawn if they are identified as not complying.

6.1.9 Key Usage Purposes

User keys are intended for generating proxy certificates and identifying browser users. They may be used for other standard certificate applications as well.

6.2 Private Key Protection

6.2.1 Standards for cryptographic module

No Stipulation

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

No Stipulation

6.2.3 Private Key Escrow

No Stipulation

6.2.5 Private Key Archival and Backup

The Certificate Authority private key backup is stored on a CD located as described in section 4.6.3.

6.3 Other Aspects of Key Pair Management

6.4 Activation Data

No Stipulation

6.5 Computer Security Controls

6.5.1 Specific Computer Security Technical Requirements

APACGrid CA regularly apply security patches to ensure the security of publicly accessible servers.

6.5.2 Computer Security Rating

No Stipulation

6.6 Life-Cycle Security Controls

No Stipulation

6.7 Network Security Controls

The APACGrid CA machine is unconnected to any network, and is therefore secured from network based attack. The RA machine is protected in the normal manner, that is maintained with current OS patches and observed closely.

Machine Use

Neither of the two machines used for the CA are allowed to be used for any other purpose.

6.8 Cryptographic Module Engineering Controls

No Stipulation

7. Certificate and CRL Profiles

7.1 Certificate Profile

7.1.1 Version Number

x509 v3

7.1.2 Certificate extensions

Personal Certificates (eg a CA Operator), specific information shown for example.

• X509v3 Basic Constraints: critical, CA:FALSE
• Netscape Cert Type: SSL Client, S/MIME, Object Signing
• X509v3 Key Usage: critical, Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
• Netscape Comment: Certification Authority Administrator of APACGrid
• X509v3 Subject Alternative Name: email:D.Bannon@vpac.org
• X509v3 Issuer Alternative Name: email:camanager@vpac.org
• X509v3 CRL Distribution Points: URI:http://ca.apac.edu.au/pub/crl/cacrl.crl
• CPS: http://www.vpac.org/twiki/bin/view/APACgrid/CaPolicy_1_3
• User Notice: Explicit Text: Certificate issued by the APACGrid Interim Certificate Authority. Use of certificate indicates acceptance of the appropriate CPS, its limitations and rules.

Host Certificates (eg the RA machine), specific information shown for example.

• X509v3 Basic Constraints: critical, CA:FALSE
• Netscape Cert Type: SSL Client, SSL Server
• X509v3 Key Usage: critical, Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
• Netscape Comment: Server of APACGrid
• X509v3 Extended Key Usage: TLS Web Client Authentication, TLS Web Server Authentication
• X509v3 Subject Alternative Name: DNS:ca.apac.edu.au, email:camanager@vpac.org *Note this still needs to be done DNS name in subjectAltName
• X509v3 Issuer Alternative Name: email:camanager@vpac.org
• X509v3 CRL Distribution Points: URI:http://ca.apac.edu.au/pub/crl/cacrl.crl
• CPS: http://www.vpac.org/twiki/bin/view/APACgrid/CaPolicy_1_3
• User Notice: Explicit Text: Certificate issued by the APACGrid Interim Certificate Authority. Use of certificate indicates acceptance of the appropriate CPS, its limitations and rules.

(note last character or set of characters in CPS number is a release number, '3' in the example above, see top of this document for details of whats current at the present time.)

CA Certificates

• X509v3 Basic Constraints: critical, CA:TRUE
• X509v3 Key Usage: critical, Digital Signature, Non Repudiation, Certificate Sign, CRL Sign
• X509v3 Subject Alternative Name: email:camanager@vpac.org
• X509v3 Issuer Alternative Name: email:camanager@vpac.org
• Netscape Cert Type: SSL CA, S/MIME CA, Object Signing CA
• Netscape Comment: APACGrid Certification Authority Certificate
• X509v3 CRL Distribution Points: URI:http://ca.apac.edu.au/pub/crl/cacrl.crl
• Netscape CA Revocation Url: http://ca.apac.edu.au/pub/crl/cacrl.crl
• Netscape Revocation Url: http://ca.apac.edu.au/pub/crl/cacrl.crl

7.1.3 Algorithm Object Identifiers

No Stipulation

7.1.4 Name Forms

CA Certificate
Subject: C=AU, O=APACGrid, OU=CA, CN=APACGrid/emailAddress=camanager@vpac.org

Person e.g.
Subject: C=AU, O=APACGrid, OU=VPAC, CN=David Bannon

Hosts eg
Subject: C=AU, O=APACGrid, OU=VPAC, CN=ca.apac.edu.au

Grid Services eg

Subject: C=AU, O=APACGrid, OU=VPAC, CN=gits2/ngdev.vpac.org

Variations to DN Name Form for personal and host certificates The DN of a certificate can contain CN, OU, O and C terms. Certificates issued by the APACGrid can have

• C=AU or C=NZ
• O=APACGrid or O=BeSTGRID
• OU set to an appropriate organisation name within the indicated Grid
• CN set to an appropriate name such as a FQHN, eg nggums.hpsc.csiro.au for a host or the common name of a person for a personal certificate.

7.1.5 Name Constraints

No stipulation

7.1.6 Certificate Policy Object Identifier

The Object Identifier Number currently used is as specified at the top of this document.

7.1.7 Usage of Policy Constraints Extensions

No stipulation

7.1.8 Policy Qualifier Syntax and Semantics

No stipulation

7.2 CRL Profile

7.2.1 Version

x509 version 3 Encryption method is md5WithRSAEncryption

7.2.2 CRL and CRL Entry Extensions

No stipulation

8. Specification Administration

8.1 Specification Change Procedures

Changes may be made to the CPS Document, subject to provisions in "CPS Approval Procedures", 8.3 without individual user notification. Users may read the current CPS at any time and reasonable attempts will be made to notify users of changes that affect them.

8.2 Publication and Notification Procedures

A summary of changes made to the CPS Document will appear in newsletters, electronic and printed, from time to time. Project Leaders and site managers may receive notifications by email if its deemed appropriate.

8.3 CPS Approval Procedures

Changes to the CPS must be approved by APACGrid CI-Project Leader or APAC-Grid Project Manager before the document is changed.

Changes that make no alteration to meaning can be made without releasing a new version. This would normally be limited to spelling corrections and similar. A record of such changes should be made in the document header.

Whenever there is a minor change in the CP/CPS document the O.I.D. of the document must change by incrementing the release number. This would include clarification of unclear meanings and alterations to procedures that have limited impact.

Whenever there is a major or significant change in the CP/CPA document, it must be announced to the APGrid PMA and approved before signing any certificates affected by that change.

Records will be maintained of changes against version and release numbers.

---

Glossary

• Activation Data

Data values, other than keys, that are required to operate cryptographic modules and that need to be protected (e.g., a PIN, a pass phrase, or a manually-held key share).

• APAC

Australian Partnership for Advanced Computing - an organistaion funded, in part, from the Australian Federal Government with members in all states of Australia (including some national organisations) and charged with providing advanced computation and related facilities to Australian research groups.

• Certification Authority (CA)

The entity / system that issues X.509 identity certificates (places a subject name and public key in a document and then digitally signs that document using the private key of the CA).

• Certificates � or Public Key Certificates

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

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

• Certificate Revocation Lists (CRL)

A CRL is a time stamped list identifying revoked certificates that is signed by a CA and made freely available in a public repository.

• End Entity

A certificate subject that does not sign certificates (i.e., person, host, and service certificates).

• Host Certificate

A certificate for server certification and encryption of communications (SSL/TSL). It will represent a single machine.

• Public Key Infrastructure (PKI)

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

• Person Certificate

A certificate used for authentication to establish a Grid Person Identity. It will represent an individual person.

• Policy Management Authority (PMA)

For the APACGrid CA this is an ad hoc committee composed of the APACGrid Project Manager, APAC-Grid CA Manager and one or more CA Operators.

• Policy Qualifier

The policy-dependent information that accompanies a certificate policy identifier in an X.509 certificate.

• Private Key

In a PKI, a cryptographic key created and kept private by a subscriber. It may be used to make digital signatures which may be verified by the corresponding public key; to decrypt the message encrypted by the corresponding public key; or, with other information, to compute a piece of common shared secret information.

• Public Key

In a PKI, a cryptographic key created and made public by a subscriber. It may be used to encrypt information that may be decrypted by the corresponding private key; or to verify the digital signature made by the corresponding private key.

• 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). Within the APACGrid, a particular person at a particular geographic site is identified as an RA Operator.

• Relying Party

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

• Service Certificate

A certificate for a particular service running on a host. It will represent a single service on a single host.

• Subscriber

In the case of certificates issued to resources (such as web servers), the person responsible for the certificate for that resource. For certificates issued to individuals, same as certificate subject.

• Virtual Organization (VO)

An organization that has been created to represent a particular research or development effort independent of the physical sites at which the scientist or engineers work.

Bibliography

Asia Pacific Grid minimum requirments, http://www.apgridpma.org/docs/APGridPMA-Minimum-CA-Requirements-1.2.doc

RFC2459 - http://rfc.net/rfc2459.html

• Protect this page:
  • Set ALLOWTOPICCHANGE = DavidBannon SamMorrison AndyBotting