1. INTRODUCTION

This component identifies and introduces the set of provisions, and indicates the types of entities and applications for which the document (either the CP or the CPS being written) is targeted.

This document follows the framework and structure outlined in the Internet Engineering Task Force s RFC 3647 [Chokhani03]. Extracts of this document have been included in this document in a blue font to assist the reader in understanding the certificate policies and certification practice statements. Compliance of this document with the current minimum requirements of the International Grid Trust Federation (IGTF) Classic CA profile [CCA06] is highlighted in Section 10.

Entries in black type represent text translated from DOEGrids v2.10 and used in v3.0. Any changes to the text in v3.0 are indicated by green type.

See the References section at the end of the document for links to source documents.

1.1. Overview

This subcomponent provides a general introduction to the document being written. This subcomponent can also be used to provide a synopsis of the PKI to which the CP or CPS applies. For example, it may set out different levels of assurance provided by certificates within the PKI. Depending on the complexity and scope of the particular PKI, a diagrammatic representation of the PKI might be useful here.

This document is structured according to [RFC3647]. Not all sections of RFC 3647 are used. Sections that are not included have a default value of No stipulation.

This document is both the Certificate Policy (CP) and the Certification Practice Statement (CPS) for the DOEGrids Certification Authority (CA) and Public Key Infrastructure (PKI). It describes the set of rules and procedures established by the DOEGrids Policy Management Authority (PMA) for the operation of the DOEGrids (PKI) service. The DOEGrids PMA is responsible for this document.

ESnet operates the DOEGrids CA under the authority of the DOEGrids PMA. ESnet headquarters are located at Lawrence Berkeley National Laboratory (LBNL) in Berkeley, California. LBNL and ESnet own and operate the CA and are ultimately responsible to the University of California and the US Department of Energy for the Certification Authority equipment, data, and operations.

The general architecture is a certification authority (CA) with multiple Registration Authorities. The DOEGrids CA is a subordinate of the ESnet root CA. There is a Registration Authority for each DOEGrids site or Virtual Organization (VO). Each Registration Authority is responsible for verifying user identities of its community. Special guidelines for the individual RAs of the DOEGrids PKI are covered in the specific Registration Authority Appendices in this document.

DOEGrids CA is a Traditional X.509 Public Key Certification Authority that complies with the International Grid Trust Federation (IGTF) Profile for Classic X.509 Public Key Certification Authorities with secure infrastructure. The DOEGrids CA issues personal and service certificates for use in Grids. These certificates are for DOE researchers and their colleagues. These certificates are compatible with the middleware that is used on these Grids.

The DOEGrids personal certificates by themselves should not to be used to determine authorization. The DOEGrids personal certificate should be used only to assert the identity of the individual named in the personal certificate. Authorization decisions should be based on criteria other than the DOEGrids personal certificate.

RFC 2527: 1.1

IGTF Classic: 1 (general)

DOEGrids v2.10: 1.1

1.2. Document Name and Identification

This subcomponent provides any applicable names or other identifiers, including ASN.1 object identifiers, for the document. An example of such a document name would be the US Federal Government Policy for Secure E-mail.

Document title: DOEGrids CA Certificate Policy and Certification Practice Statement

Document version: 3.1

Document date: July 30, 2009

OID: [ESnet].ERmember.DOEGrids.CP-CPS.CPVersionNumber.CPReleaseNumber

1.2.840.113612.3.7.1.3.1

The next table describes the meaning of the OID:

1.2.840	Prefix for US ANSI registrants Iso(1) member-body(2) us(840)
113612	Energy Sciences Network (ESnet)
3	Ermember
7	DOEGrids
1	DOEGrids CP/CPS
3.1	Major and minor CP/CPS version number

This OID assignment can be verified here:

http://www.es.net/OID/ESnet-OID-list.txt

and (in part) here:

http://www.oid-info.com/get/1.2.840.113612

It may be possible to verify the organization name registration Energy Sciences Network directly with ANSI. Contact ANSI (http://ansi.org) and search for Registration Programs.

RFC 2527: 1.2

IGTF Classic: 1 (general)

DOEGrids v2.10: 1.2

1.3. PKI Participants

This subcomponent describes the identity or types of entities that fill the roles of participants within a PKI.

All RA, agents, and subscribers are obliged to notify the CA and their RA when their status changes. Status changes that affect certification include, among other things, change of:

1. Contact e-mail address

2. Name

3. End entity is no longer covered by ESnet AUP or interoperability agreement.

DOEGrids PMA has defined a number of roles that together provide the service to the community. The following roles have been defined:

Certificate Authority Operations

o Are responsible for the day-to-day operations of the CA.

o Have the authority to issue and revoke certificates as needed to run the service.

Registration Authority

o Is responsible for verifying end entity identities for certificates.

RA Agent

o Acts on behalf of the Registration Authority and is responsible to the RA.

Grid Admin

o Acts on behalf of the Registration Authority, but is limited to a defined domain of hosts.

This section describes the top-level obligations for the CA Operator and RA. Appendix A has additional details for RAs, agents and grid administrators. Appendix O has details for CA operations.

RFC 2527: 1.3

IGTF Classic: 1 (general)

DOEGrids v2.10: 2.1

1.3.1. Certification Authorities

The entities that issue certificates. A CA is the issuing CA with respect to the certificates it issues and is the subject CA with respect to the CA certificate issued to it. CAs may be organized in a hierarchy in which an organization s CA issues certificates to CAs operated by subordinate organizations, such as a branch, division, or department within a larger organization.

ESnet will manage and operate the DOEGrids PKI. The DOEGrids CA is operated as a subordinate CA of the ESnet Root CA. Access to the DOEGrids CA Certification Management Service is by a Web browser. Web browsers or other client software are the responsibility of the client, not ESnet. Check the FAQ on the www.DOEGrids.org site for the list of supported browsers. The following is a list of the PKI components:

Component	Location	Function
ESnet Root CA	ESnet Data Center	Signs subordinate CAs.
DOEGrids CA	ESnet Data Center	Signs subscriber, host and Service Certificates.
DOEGrids Community Registration Manager (RM)	ESnet Data Center	Creates Certificate Signed Requests that agents use to approve certificate requests.
DOEGrids Lightweight Directory Access Protocol (LDAP) directory	ESnet Data Center	The DOEGrids CA publishes certificates and other information to the directory. The directory is public and read-only.
Subscriber Web browsers	Subscriber desktops	This is the standard subscriber interface to the RM. It is also used by agents for reviewing certificate requests. The LDAP Directory also provides a Web interface.

RFC 2527: 1.3.1

IGTF Classic: 1 (general)

DOEGrids v2.10: 1.3.1

DOEGrids CA will:

1. Accept certification requests from entitled entities;

2. Notify the RA of certification request and accept authentication results from the RA;

3. Issue certificates based on the requests from authenticated entities;

4. Maintain the binding between DN and registered owner of the DN. One attribute of this binding is the e-mail address included in the certificate.

5. Notify the subscriber of the issuing of the certificate;

6. Publish the issued certificates;

7. Accept revocation requests according to the procedures outlined in this document, and notify the RA that issued the certificate;

8. Authenticate entities requesting the revocation of a certificate, possibly by delegating this task to a DOEGrids RA;

9. Issue a Certificate Revocation List (CRL);

10. Publish the CRL issued;

11. Keep audit logs of the certificate issuance process;

12. Notify the RA of security incidents that have been reported and coordinate incident response between it and the RA;

13. Publish contact information for the CA.

RFC 2527: 1.3.1

IGTF Classic: 1 (general)

DOEGrids v2.10: 2.1.1

1.3.2. Registration Authorities

The entities that establish enrollment procedures for end-user certificate applicants, perform identification and authentication of certificate applicants, initiate or pass along revocation requests for certificates, and approve applications for renewal or re-keying certificates on behalf of a CA. Subordinate organizations within a larger organization can act as RAs for the CA serving the entire organization, but RAs may also be external to the CA.

The DOEGrids PKI consists of a number of individual RAs representing a DOE site or VO. ESnet maintains a browser-accessible shared community Registration Manager for use by the DOEGrids RAs. This interface can be used to:

Approve or reject the certificate request

Initiate certificate revocations

Search for certificates.

See the RA appendices for a more detailed description of the community and practices of each RA.

A DOEGrids RA will:

1. Accept authentication requests from the DOEGrids CA;

2. Authenticate the entity making the certification request according to procedures outlined in this document;

3. Verify that the person making the request is permitted by the community guidelines and ESnet AUP;

4. Verify that the entity making the request is the registered owner if the DN existed previous to this request and resolve conflicts or manage transfer of DN ownership;

5. Notify the DOEGrids CA when authentication is completed for a certification or revocation request;

6. Accept revocation requests according to the procedures outlined in this document;

7. Notify the DOEGrids CA of all revocation requests;

8. Authenticate the entity making the revocation request according to procedures outlined in this document, or the specific Appendix in this document that represents the Virtual Organization or DOE site;

9. Maintain a record of authentication of entities for certification and revocation requests, for a minimum of three years;

10. Will not approve a certificate with a life time greater than 12 months. Each VO/site will specify the life time of its certificate in its specific appendix.

11. Additional guidelines are described in Appendix A and the individual VO Appendix included in this document.

12. Notify CA of security incidents. Notification should be made as soon as possible, ideally within 12 hours of initial knowledge of the incident.

13. Publish contact information for the RA;

14. Notify the CA whenever the contact information for the RA changes.

RFC 2527: 1.3.2/1/4

IGTF Classic: 1 (general)

DOEGrids v2.10: 1.3.2/2.1.1

1.3.3. Subscribers (End Entities)

Examples of subscribers who receive certificates from a CA include employees of an organization with its own CA, banking or brokerage customers, organizations hosting e-commerce sites, organizations participating in a business-to-business exchange, and members of the public receiving certificates from a CA issuing certificates to the public at large.

DOEGrids PKI issues person, host and service certificates to scientists, engineers, graduate students, and others working on Department of Energy Scientific Research programs as allowed in the ESnet Acceptable Usage Policies (AUP) (http://es.net/hypertext/esnet-aup.html), or as allowed by the DOE Office of Science in support of DOE collaborations with other agencies and institutions. The person requesting and responsible for a certificate s private key is the subscriber. The term end entity is used to refer to the holder of the private key. For a person certificate, it will be the subscriber, but for a host or service certificate, the end entity may be some process running on a machine.

Subscribers must:

1. Read and adhere to the procedures published in this document;

2. Read and adhere to the ESnet Acceptable Use Policy (http://es.net/hypertext/esnet-aup.html);

3. Generate a key pair using a trustworthy method;

4. Take reasonable precautions to prevent any loss, disclosure or unauthorized use of the private key associated with the certificate, including:

For Person Certificates

a. Selecting a pass phrase of at minimum twelve characters;

b. Protecting the pass phrase from others;

c. Always using the pass phrase to encrypt the stored private key;

d. Never sharing the private key with other users.

For Service Certificates

a. Storing them encrypted whenever possible;

b. They may be kept unencrypted on the host that they represent;

c. Asserting that they are authorized to run install the specified service on the specified host;

d. Providing correct personal information and authorizing the publication of the certificate;

e. Verifying that the Distinguished Name (DN) being requested does not yet exist, or asserting that they are the registered owner of the DN.

f. Notifying DOEGrids PKI immediately of any security incidents. Notification shall occur within the first 12 hours of initial knowledge of the incident.

g. Use the certificates for the permitted uses only.

RFC 2527: 1.3.3

IGTF Classic: 1 (general)

DOEGrids v2.10: 1.3.3, 2.1.2

1.3.4. Relying Parties

Examples of relying parties include employees of an organization having its own CA who receive digitally signed e-mails from other employees, persons buying goods and services from e-commerce sites, organizations participating in a business-to-business exchange who receive bids or orders from other participating organizations, and individuals and organizations doing business with subscribers who have received their certificates from a CA issuing certificates to the public. Relying parties may or may not also be subscribers within a given PKI.

Relying parties must:

1. Read the procedures published in this document;

2. Use the certificates for the permitted uses only;

3. Not assume any authorization attributes are based solely on an entity s possession of a DOEGrids certificate;

4. Notify DOEGrids PKI of any security incidents. Notification shall occur within the first 12 hours of initial knowledge of the incident.

Relying parties may:

Verify that the certificate is not on the DOEGrids CRL before validating a certificate.

RFC 2527: 1.3.3

IGTF Classic: 1 (general)

DOEGrids v2.10: 2.1.3.

1.3.5. Other Participants

Such as certificate manufacturing authorities, providers of repository services, and other entities providing PKI-related services.

DOEGrids PKI will provide access to DOEGrids CA information, as outlined in Section 2, on its Web site. The following pages deal with individual items from Section 2:

CA information: http://www.doegrids.org/pages/Fingerprints.htm

Certificates: LDAP access: ldap://ldap.doegrids.org

CRL information: http://pki1.doegrids.org/CRL/1c3f2ca8.r0

CP/CPS: http://www.doegrids.org/Docs/CP-CPS.pdf

RFC 2527: N/A

IGTF Classic: 1 (general)

DOEGrids v2.10: 2.1.4.

1.4. Certificate Usage

This subcomponent contains:

A list of the types of applications for which the issued certificates are suitable, such as electronic mail, retail transactions, contracts, and travel orders, and/or

A list of the types of applications for which use of the issued certificates is prohibited.

In the case of a CP or CPS describing different levels of assurance, this subcomponent can describe applications or types of applications that are appropriate or inappropriate for the different levels of assurance.

See Section 1.6 .for definition of certificate types.

Person certificates can be used to authenticate a person to relying sites that have agreed to accept certificates from the DOEGrids CA. This authentication may require the signing of Globus proxy certificates. It is expected that these sites will be supported by DOE funding or will be collaborating with such sites.

RFC 2527: 1.3.4

IGTF Classic: 1 (general)

DOEGrids v2.10: 1.3.4.

1.4.1. Appropriate Certificate Uses

Service certificates can be used to identify a named service on a specific host and for encryption of communication (TLS/SSL).These certificates may be used to authenticate the service to another Grid entity, possibly by signing Globus proxy certificates. While person certificates may be used for other activities, such as e-mail signing and encryption, these are not supported activities.

RFC 2527: 1.3.4

IGTF Classic: 1 (general)

DOEGrids v2.10: 1.3.4

1.4.2. Prohibited Certificate Uses

These certificates are not suitable for legally binding digital signatures on documents.

RFC 2527: 1.3.4

IGTF Classic: 1 (general)

DOEGrids v2.10: 1.3.4.

1.5. Policy Administration

This subcomponent includes the name and mailing address of the organization that is responsible for the drafting, registering, maintaining, and updating of this CP or CPS. It also includes the name, electronic mail address, telephone number, and fax number of a contact person. As an alternative to naming an actual person, the document may name a title or role, an e-mail alias, and other generalized contact information. In some cases, the organization may state that its contact person, alone or in combination with others, is available to answer questions about the document.

Moreover, when a formal or informal policy authority is responsible for determining whether a CA should be allowed to operate within or interoperate with a PKI, it may wish to approve the CPS of the CA as being suitable for the policy authority s CP. If so, this subcomponent can include the name or title, electronic mail address (or alias), telephone number, fax number, and other generalized information of the entity in charge of making such a determination. Finally, in this case, this subcomponent also includes the procedures by which this determination is made.

1.5.1. Organization Administering the Document

ESnet administers the DOEGrids CPS. The DOEGrids CPS is managed by the DOEGrids Policy Management Authority.

RFC 2527: 1.4.1

IGTF Classic: 1

DOEGrids v2.10: 1.4

1.5.2. Contact Person

The contact person for questions related to this document is the chairman of the PMA:

John Volmer

Argonne National Laboratory

volmer@anl.gov

The custodian of this document is:

Michael Helm

ESnet/LBNL

One Cyclotron Road, B50A 3131

Berkeley, CA 94706
phone: +1 (510) 486-7248
E-mail: helm@es.net

Contact information regarding other communications with the DOEGrids PKI, including security incidents, is maintained at http://www.doegrids.org/.

The following e-mail addresses and phone numbers can be used to request information or report problems (security, access or service failures). Security incidents, access problems or other service failures should be reported to ESnet s trouble-reporting service:

ESnet Trouble e-mail: trouble@es.net

ESnet Trouble numbers:

1 (800) 33-ESnet
1 (800) 333-7638
(toll-free within the United States)

+1 (510) 486-7600
(outside the United States)

RFC 2527: 1.4.2

DOEGrids: 1.4

1.5.3. Person Determining CPS Suitability for the Policy

RFC 2527: 1.4.3

1.5.4. CPS Approval Procedures

The DOEGrids CPS is managed by the DOEGrids Policy Management Authority.

The DOEGrids CA and CPS is accredited under the Classic CA profile by the EU Grid Policy Management Authority (EUGridPMA) of the International Grid Trust Federation (IGTF).

RFC 2527: 8.3

1.6. Definitions and Acronyms

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, in this document are to be interpreted as described in RFC 2119 [Brader97].

Note that the force of these words is modified by the requirement level of the document in which they are used.

1. MUST This word, or the terms REQUIRED or SHALL, mean that the definition is an absolute requirement of the specification.

2. MUST NOT This phrase, or the phrase SHALL NOT, mean that the definition is an absolute prohibition of the specification.

3. SHOULD This word, or the adjective RECOMMENDED, mean that there may exist valid reasons in particular circumstances to ignore a particular item, but that the full implications must be understood and carefully weighed before choosing a different course.

4. SHOULD NOT This phrase, or the phrase NOT RECOMMENDED mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.

This subcomponent contains a list of definitions for defined terms used within the document, as well as a list of acronyms in the document and their meanings.

General Definitions

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

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.

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 that a certification authority employs in issuing certificates.

Community Registration Manager (CRM)
One or more Registration Managers (RMs) that serve multiple low request rate sites/Virtual Organizations.

Common Name (CN)

The common name of the subject of a certificate (full name, host name, etc.). Equivalent to Distinguished Name/Subject Name for the purposes of this document (see RFC 2986).

Certificate Signing Request (CSR)

The message sent to a Certification Authority that describes the public key and content that need to be signed.

Distinguished Encoding Rules (DER)

A restricted form of BER, one of a set of encoding rules for the ASN.1 syntax used by X.509 certificates (see X.690).

Distinguished Name (DN)

The complete, unique name of an entity, written as an ordered list of X.500/LDAP attribute-value pairs. Equivalent to Common Name/Subject Name for the purposes of this document (see RFC 4514 and RFC 4519).

DOEGrids PKI
Refers to the whole of the PKI, including the electronic services, the CA managers, RAs, and RAgs.

DOEGrids PKI Members
Refers to the CA managers and the RA Points of Contact, who comprise a large subset of the PMA.

DOEGrids PKI Service
Refers to the electronic services of the PKI, computers, Web interfaces, e-mail, etc.

End Entity
A system entity or person that is the subject of a public key certificate and that is permitted, and able to use, the matching private key only for a purpose or purposes other than signing an X.509 public key certificate; i.e., an entity that is not a CA.

Federal Bridge Certification Authority (FBCA)

FBCA signs certificates of root CAs from other US federal agencies and other interested parties; it attempts to map policies between different PKIs in a standard way to promote interoperability.

Hardware Security Module (HSM)

An HSM provides secure storage and operation of cryptographic data, typically the signing key of a CA or other server (see NIST FIPS-140 document).

Host Certificate
A certificate for server certification and encryption of communications (SSL/TSL). It will represent a single machine. Host certificates are used internally by the PKI service and are not issued to other sites/Virtual Organizations (VOs).

Online Certificate Status Protocol (OCSP)

A protocol that enables an application to determine the revocation or validity status of a certificate, without need for the entire CRL (see RFC 2560).

Owner
The human individual or organizational group with valid rights to exclusive use of a subject name in a certificate. The process of registering the end entity of a certificate request is what maintains the binding between an owner and the subject name (DN).

Privacy-Enhanced Mail (PEM)
A printable encoding of binary objects (such as BER encoded ASN.1 information) that maps every 6 bits of this data into an array of 64 known printable characters.This formatting is also often called base 64 encoding. The encoding was defined in RFC 1421 as part of Privacy Enhanced Mail (PEM) standards and the standard became associated with the encoding.

Person Certificate
A certificate associated with a unique human being.

Personal Identification Number (PIN)

In the context of a Certification Practice Statement, an example of activation data.

Policy Management Authority (PMA)
For the DOEGrids PKI, this is a committee composed of the CA managers and representatives from the site/VO Registration Authorities. The PMA has direct responsibility for the CP/CPS and oversight of ESnet operations of the PKI.

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

Point of Contact

The member of a site/VO RA who has been chosen to handle all communications about policy matters with the DOEGrids PMA.

Private Registration Manager (RM)
Registration Managers that serve sites/VOs with high certificate request rates, and that are operated by the site/VO.

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

Registration Agent (RAg) or Agent
The Registration Agent (RAg) is the entity that interacts with the RM in order to cause the CA to issue certificates.

Registration Manager (RM)
The RM is a front-end Web server for the CA that provides a Web user interface for CA subscribers and agents. The RM forwards certificate-signing requests to the actual CA (DOEGrids) to issue X.509 certificates.

Registered Owner
Once a certificate request has been verified, the ownership of the DN validated, and a certificate issued, the owner is considered to be the registered owner of the DN. See above for definition of owner.

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

Secure Sockets Layer (SSL)
See TLS.

Security Incident
An incident that has the potential of private key loss or compromise, regardless of whether the compromise or loss was definitive. Such incidents include, but are not limited to, user credential compromise, privilege escalation on systems known to contain private keys, accidental exposure of private keys to unauthorized third parties, or loss of a private key.

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

Set of Provisions
A collection of practice and/or policy statements, spanning a range of standard topics, for use in expressing a certificate policy definition or CPS and employing the approach described in this framework.

Subject Name

The person who applied for and was issued a certificate. Equivalent to Distinguished Name for the purposes of this document.

Subscriber

The person who applied for and was issued a certificate.

Transport Layer Security (TLS)

TLS is a protocol that supports communications security over the Internet (see RFC 2246 and 4346).

Virtual Organization (VO)
An organization created to represent a particular research or development effort, independent of the physical sites where the scientists or engineers work.

RFC 2527: N/A

IGTF Classic: 1 (general, use of terms)

DOEGrids v2.10: 1.1.1.

1.6.1. Definitions

RFC 2527: N/A

IGTF Classic: 1 (general, use of terms)

1.6.2. Acronyms

RFC 2527: N/A

3. IDENTIFICATION AND AUTHENTICATION

This component describes the procedures used to authenticate the identity and/or other attributes of an end-user certificate applicant to a CA or RA prior to certificate issuance. In addition, the component sets forth the procedures for authenticating the identity and the criteria for accepting applicants of entities seeking to become CAs, RAs, or other entities operating in or interoperating with a PKI. It also describes how parties requesting re-key or revocation are authenticated. This component also addresses naming practices, including the recognition of trademark rights in certain names.

RFC 2527: 3

IGTF Classic: 3 (general)

3.1. Naming

This subcomponent includes the following elements regarding naming and identification of the subscribers.

RFC 2527: 3.1

3.1.1. Types of Names

Types of names assigned to the subject, such as X.500 distinguished names, RFC 822 names, and X.400 names.

X.500 style names are used.

See Section 7.1.3 for more details.

RFC 2527: 3.1.1

DOEGrids v2.10: 3.1.1

3.1.2. Need for Names to be Meaningful

Whether names have to be meaningful or not.

Subscriber CN (common name) components contain a representation of the subscriber s name and a string of digits for disambiguation.

Host or service CN components usually contain a fully qualified domain name (FQDN) of the host to satisfy Grid and TLS security mechanisms. The CN component may also contain other tags associated with the service.

On an experimental basis, DOEGrids CA operations or RAs may permit special service names or additional name forms in the service common name component.

For person certificates, each CN component will include the full name of the subscriber as determined by the Virtual Organization/site s RA. The registration interface appends five or six random numeric characters (i.e., John K. Doe 12347 ) when constructing the Common Name, to assist in establishing uniqueness

For hosts and services, the CN should contain the FQDN of the host. Each DN must have a unique binding to the end entity, but this does not preclude an end entity from having multiple certificates with the same DN.

See 7.1 for typical examples.

See following sections for additional requirements.

RFC 2527: 3.1.2

DOEGrids v2.10: 3.1.2

IGTF Classic: 3

3.1.3. Anonymity or Pseudonymity of Subscribers

Whether or not subscribers can be anonymous or pseudonymous, and if they can, what names are assigned to or can be used by anonymous subscribers.

Not supported.

RFC 2527: 3.1.2

3.1.4. Rules for Interpreting Various Name Forms

Rules for interpreting various name forms, such as the X.500 standard and RFC822.

See 3.1.1, and 3.1.2.

RFC 2527: 3.1.3

3.1.5. Uniqueness of Names

Whether names have to be unique.

Any single subject distinguished name (DN) must be linked to one and only one entity.

RFC 2527: 3.1.4

DOEGrids v2.10: 3.1.3

IGTF Classic: 3

3.1.6. Recognition, Authentication, and Role of Trademarks

RFC 2527: 3.1.5, 3.1.6

3.2. Initial Identity Validation

This subcomponent contains the following elements for the identification and authentication procedures for the initial registration for each subject type (CA, RA, subscriber, or other participant).

RFC 2527: 3.1

3.2.1. Method to Prove Possession of Private Key

If and how the subject must prove possession of the companion private key for the public key being registered, for example, a digital signature in the certificate request message.

Obtaining a personal or individual certificate is initiated by a key generation tag
or control that the individual s Web browser reads on the CA s user registration Web
page. Key generation and certificate signing request generation and submission are tied together in a single session, and there is a reasonable presumption of possession of private key in requests originating in Web browser functions. Keys generated by other means (such as OpenSSL at http://www.openssl.org, whether for persons or services, have separate key generation, Certificate Signing Request (CSR) generation, and submission stages. No proof of possession of private key test is made in these cases. Renewal and revocation functions employ a proof of possession of private key test.

RFC 2527: 3.1.7

DOEGrids v2.10: 3.1.4

3.2.2. Authentication of Organization Identity

Identification and authentication requirements for organizational identity of subscriber or participant (CA, RA, subscriber, in the case of certificates issued to organizations or devices controlled by an organization or other participant), for example, consulting the database of a service that identifies organizations or inspecting an organization s articles of incorporation.

Registration Authority membership is approved by the DOEGrids PMA.

Membership in the scope of a particular RA is determined by the RA.

RFC 2527: 3.1.8

3.2.3. Authentication of Individual Identity

Identification and authentication requirements for an individual subscriber or a person acting on behalf of an organizational subscriber or participant (CA, RA, in the case of certificates issued to organizations or devices controlled by an organization, the subscriber, or other participant), including:

a)   Type of documentation and/or number of identification credentials required;

b)   How a CA or RA authenticates the identity of the organization or individual based on the documentation or credentials provided;

c)   If the individual must personally present to the authenticating CA or RA;

d)    How an individual as an organizational person is authenticated, such as by reference to duly signed authorization documents or a corporate identification badge.

DOEGrids RAs generally follow the 1SCP Identity Vetting: Trusted Third Party mediated (http://www.eugridpma.org/guidelines/1scp/).

OID: 1.2.840.113612.5.2.3.2.1.1

The DOEGrids PKI uses an architecture under which the approval of certificate requests is the responsibility of the Registration Authority for a specific community. The work flow of subscriber certificates request/approval can be found on the service Web site: http://www.doegrids.org/pages/workflow.pdf.

Each RA will be responsible for determining the identity used in the subject field of the certificate. The procedure for determining identity differs depending on the type of certificate and RA policies. Each VO/site must document its procedures in its individual RA appendix in this document.

A name once entered in the DOEGrids CA registry is the property of the original requestor, but is managed by the RA. Management of the ownership of host and service names is delegated to the RA. An existing subscriber name must never be assigned to a new individual. In cases where an RA is asked to assign a pre-existing name to a particular individual subscriber, RAs must determine whether the requesting subscriber is the registered owner of the name requested, and document this determination.

RFC 2527: 3.1.9

DOEGrids v2.10: 3.1.5

3.2.4. Non-Verified Subscriber Information

List of subscriber information that is not verified (called non-verified subscriber information ) during the initial registration.

RFC 2527: N/A

3.2.5. Validation of Authority

Validation of authority involves a determination of whether a person has specific rights, entitlements, or permissions, including the permission to act on behalf of an organization to obtain a certificate.

RFC 2527: 3.1.9

3.2.6. Criteria for Interoperation

In the case of applications by a CA wishing to operate within, or interoperate with, a PKI, this subcomponent contains the criteria by which a PKI, CA, or policy authority determines whether or not the CA is suitable for such operations or interoperation. Such interoperation may include cross-certification, unilateral certification, or other forms of interoperation.

RFC 2527: 4.1

3.3. Identification and Authentication for Re-key Requests

This subcomponent addresses the following elements for the identification and authentication procedures for re-key for each subject type (CA, RA, subscriber, and other participants).

RFC 2527: 3.2, 3.3

3.3.1. Identification and Authentication for Routine Re-key

Identification and authentication requirements for routine re-key, such as a re-key request that contains the new key and is signed using the current valid key.

DOEGrids provides the Replacement certificate interface, which is used by subscribers to replace expiring personal certificates. This interface requires authentication with an acceptable certificate, and enforces re-key.

RFC 2527: 3.2

DOEGrids v2.10: 3.2

3.3.2. Identification and Authentication for Re-key after Revocation

Identification and authentication requirements for re-key after certificate revocation. One example is the use of the same process as the initial identity validation.

In general, re-key after revocation follows the same rules as an initial registration. In addition, if the subscriber requests the continued use of the same name, or other name already recorded in the DOEGrids CA registry, RAs must determine whether the requestor is the registered owner of the name requested, and document this determination.

RFC 2527: 3.3

DOEGrids v2.10: 3.3

3.4. Identification and Authentication for Revocation Request

This subcomponent describes the identification and authentication procedures for a revocation request by each subject type (CA, RA, subscriber, and other participant). Examples include a revocation request digitally signed with the private key whose companion public key needs to be revoked, and a digitally signed request by the RA.

See Section 4.9.2 for details on who can request a certificate revocation.

RFC 2527: 3.4

DOEGrids v2.10: 3.4

Page intentionally left blank

4. CERTIFICATE LIFE-CYCLE OPERATIONAL REQUIREMENTS

This component is used to specify requirements imposed upon issuing CA, subject CAs, RAs, subscribers, or other participants with respect to the life-cycle of a certificate.

Within each subcomponent, separate consideration may need to be given to subject CAs, RAs, subscribers, and other participants.

RFC 2527: 4.4.

IGTF Classic: 4 (general)

DOEGrids v2.10 4

4.1. Certificate Application

This subcomponent is used to address the following requirements regarding subject certificate application: who can submit a certificate application, such as a certificate subject or the RA; and enrollment process used by subjects to submit certificate applications and responsibilities in connection with this process.

An example of this process is where the subject generates the key pair and sends a certificate request to the RA. The RA validates and signs the request and sends it to the CA. A CA or RA may have the responsibility of establishing an enrollment process in order to receive certificate applications. Likewise, certificate applicants may have the responsibility of providing accurate information on their certificate applications.

Procedures are different depending on whether the subject is a person or a host. In every case, the subject has to generate its own key pair. A key pair must have a minimum key length of 1,024 bits. Requests are submitted by a secure online procedure. Notice of the request is sent to the VO s or site s RA for validation (see Appendix A and Appendix for specific RA). Information in the request must comply with Subscriber Obligations specified in Section 1.3.3.

Person
The individual making the request is authenticated according to procedures followed by the chosen RA and described in the RA Appendix.

Host or Service
Individuals requesting a service certificate must either have a valid DOEGrids personal certificate, or the requestor will be authenticated, as for a person certificate request.

RFC 2527: 4.4

IGTF Classic: 4 (general)

DOEGrids v2.10: 4.1

4.1.1. Who Can Submit a Certificate Application

RFC 2527: 4.1

4.1.2. Enrollment Process and Responsibilities

RFC 2527: 4.1, 2.1.3

4.2. Certificate Application Processing

This subcomponent is used to describe the procedure for processing certificate applications. For example, the issuing CA and RA may perform identification and authentication procedures to validate the certificate application. Following such steps, the CA or RA will either approve or reject the certificate application, perhaps upon the application of certain criteria. Finally, this subcomponent sets a time limit during which a CA and/or RA must act on and process a certificate application.

See 4.1.

RFC 2527: 4.1, 4.2

4.2.1. Performing Identification and Authentication Functions

RFC 2527: 4.1, 4.2

4.2.2. Approval or Rejection of Certificate Applications

RFC 2527: 4.1, 4.2

4.2.3. Time to Process Certificate Applications

The CA managers may cancel certificate requests that have not been processed in a reasonable time (at least 30 days from submission). The CA managers will periodically send notifications to the RA to inform them about certificate requests that are pending in the CA queue.

RFC 2527: 4.1, 4.2

DOEGrids v2.10: 4.2

4.3. Certificate Issuance

DOE Grids PKI issues the certificate if, and only if, an RA has validated the identity of the requestor and verified that the requestor is the owner of the DN. A message is sent to the requestor s e-mail address with instructions on how to download it from the DOEGrids PKI Web server.

RFC 2527: 4.2

DOEGrids v2.10: 4.3

4.3.1. CA Actions during Certificate Issuance

Describes the actions performed by the CA during the issuance of the certificate, for example a procedure whereby the CA validates the RA signature and RA authority and generates a certificate.

RFC 2527: 4.2

4.3.2. Notification to Subscriber by the CA of Issuance of Certificate

Describes the notification mechanisms, if any, used by the CA to notify the subscriber of the issuance of the certificate; an example is a procedure under which the CA e-mails the certificate to the subscriber or the RA or e-mails information permitting the subscriber to download the certificate from a Web site.

RFC 2527: 4.2, 4.3

4.4. Certificate Acceptance

No stipulation.

RFC 2527: 4.3, 2.1.3

DOEGrids v2.10: 4.4

4.4.1. Conduct Constituting Certificate Acceptance

The conduct of an applicant that will be deemed to constitute acceptance of the certificate. Such conduct may include affirmative steps to indicate acceptance, actions implying acceptance, or a failure to object to the certificate or its content. For instance, acceptance may be deemed to occur if the CA does not receive any notice from the subscriber within a certain time period; a subscriber may send a signed message accepting the certificate; or a subscriber may send a signed message rejecting the certificate where the message includes the reason for rejection and identifies the fields in the certificate that are incorrect or incomplete.

RFC 2527: 4.3

4.4.2. Publication of the Certificate by the CA

Publication of the certificate by the CA. For example, the CA may post the certificate to an X.500 or LDAP repository.

RFC 2527: 4.3, 2.1.5, 2.6.1

4.4.3. Notification of Certificate Issuance by the CA to Other Entities

Notification of certificate issuance by the CA to other entities. As an example, the CA may send the certificate to the RA.

RFC 2527: 4.2, 4.3, 2.1.5, 2.6.1

4.5. Key Pair and Certificate Usage

This subcomponent is used to describe the responsibilities relating to the use of keys and certificates.

RFC 2527: 1.3.4, 2.1.3, 2.1.4

4.5.1. Subscriber Private Key and Certificate Usage

Subscriber responsibilities relating to use of the subscriber s private key and certificate. For example, the subscriber may be required to use a private key and certificate only for appropriate applications as set forth in the CP and in consistency with applicable certificate content (e.g., key usage field). Use of a private key and certificate are subject to the terms of the subscriber agreement, the use of a private key is permitted only after the subscriber has accepted the corresponding certificate, or the subscriber must discontinue use of the private key following the expiration or revocation of the certificate.

See Subscriber Obligations, 1.3.3.

RFC 2527: 1.3.4, 2.1.3

4.5.2. Relying Party Public Key and Certificate Usage

Relying party responsibilities relating to the use of a subscriber s public key and certificate. For instance, a relying party may be obligated to rely on certificates only for appropriate applications as set forth in the CP and in consistency with applicable certificate content (e.g., key usage field), successfully perform public key operations as a condition of relying on a certificate, assume responsibility to check the status of a certificate using one of the required or permitted mechanisms set forth in the CP/CPS (see Section 4.9 below), and assent to the terms of the applicable relying party agreement as a condition of relying on the certificate.

RFC 2527: 1.3.4, 2.1.4

4.6. Certificate Renewal

This subcomponent is used to describe the following elements related to certificate renewal. Certificate renewal means the issuance of a new certificate to the subscriber without changing the subscriber or other participant s public key or any other information in the certificate.

In general, DOEGrids CA no longer permits renewal without re-key; except for ESnet RA participants, who are guaranteed to use a hardware token.

RFC 2527: 4.1, 4.2, 4.3, 3.2

4.6.1. Circumstance for Certificate Renewal

Circumstances under which certificate renewal takes place, such as where the certificate life has expired, but the policy permits the same key pair to be reused.

Personal certificates may be replaced anytime, automatically, until one month after expiration (NB: the current CA software does not permit post-expiration replacement any more).

Service certificates are not currently renewable.

RFC 2527: 4.1, 3.2

4.6.2. Who May Request Renewal

Who may request certificate renewal, for instance, the subscriber, RA, or the CA may automatically renew an end-user subscriber certificate.

Only the subscriber or certificate owner may replace/renew a certificate.

RFC 2527: 4.1, 3.2

4.6.3. Processing Certificate Renewal Requests

A CA or RA s procedures to process renewal requests to issue the new certificate, for example, the use of a token, such as a password, to re-authenticate the subscriber, or procedures that are the same as the initial certificate issuance.

RFC 2527: 4.1, 4.2, 3.2

Grid Administrator, Agent, and RA POC role renewals follow the procedures in Appendix A.

Personal certificate renewals are currently done with the Replacement Certificate interface (https://pki1.doegrids.org/ca/CertBasedSingleEnroll.html), or by agents (RAgs). See also 3.3.2.

4.6.4. Notification of New Certificate Issuance to Subscriber

RFC 2527: 4.2, 4.3, 3.2

4.6.5. Conduct Constituting Acceptance of a Renewal Certificate

RFC 2527: 4.3, 2.1.3, 3.2

4.6.6. Publication of the Renewal Certificate by the CA

Certificates are posted to the public LDAP database on issuance.

RFC 2527: 4.3, 2.1.5, 2.6.1, 3.2

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

RFC 2527: 4.2, 4.3, 2.1.5, 2.6.1, 3.2

4.7. Certificate Re-key

This subcomponent is used to describe the following elements related to a subscriber or other participant generating a new key pair and applying for the issuance of a new certificate that certifies the new public key.

In general, DOEGrids subscribers and host/service managers re-key certificates at each renewal.

RFC 2527: 4.1, 4.2, 4.3, 3.2

4.7.1. Circumstance for Certificate Re-key

Circumstances under which certificate re-key can or must take place, such as after a certificate is revoked for reasons of key compromise or after a certificate has expired and the usage period of the key pair has also expired.

Certificate renewal MUST re-key, except in those cases where the RA can guarantee that a suitable hardware token secures the private key.

Revoked end-entity certificates MUST be re-keyed in order to be replaced.

RFC 2527: 4.1, 3.2

4.7.2. Who May Request Certification of a New Public Key

Who may request certificate re-key, for example, the subscriber.

A current certificate holder may re-key his own certificate; an agent or RA may require members of a domain to re-key as appropriate.

RFC 2527: 4.1, 3.2

4.7.3. Processing Certificate Re-keying Requests

A CA or RA s procedures to process re-keying requests to issue the new certificate, such as procedures that are the same as the initial certificate issuance.

RFC 2527: 4.1, 4.2, 3.2

4.7.4. Notification of New Certificate Issuance to Subscriber

RFC 2527: 4.2, 4.3, 3.2

4.7.5. Conduct Constituting Acceptance of a Re-keyed Certificate

RFC 2527: 4.3, 2.1.3, 3.2

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

RFC 2527: 4.3, 2.1.5, 2.6.1, 3.2

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

RFC 2527: 4.2, 4.3, 2.1.5, 2.6.1, 3.2

4.8. Certificate Modification

This subcomponent is used to describe the following elements related to the issuance of a new certificate due to changes in the information in the certificate other than the subscriber public key.

RFC 2527: 4.4

4.8.1. Circumstances for Certificate Modification

Circumstances under which certificate modification can take place, such as name change, role change, or reorganization resulting in a change in the DN.

RFC 2527: 4.4.1, 2.1.3

4.8.2. Who May Request Certificate Modification

Who may request certificate modification, for instance, subscribers, human resources personnel, or the RA.

RFC 2527: 4.4.2

4.8.3. Processing Certificate Modification Requests

RFC 2527: 4.4.3

4.8.4. Notification of New Certificate Issuance to Subscriber

A CA or RA s procedures to process modification requests to issue the new certificate, such as procedures that are the same as the initial certificate issuance.

RFC 2527: 4.2, 4.3, 4.4.3

4.8.5. Conduct Constituting Acceptance of Modified Certificate

RFC 2527: 4.3, 4.4.3, 2.1.3

4.8.6. Publication of the Modified Certificate by the CA

RFC 2527: 4.2, 4.3, 4.4.3, 2.1.5, 2.6.1

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

RFC 2527: 4.2, 4.3, 4.4.3, 2.1.5, 2.6.1

4.9. Certificate Revocation and Suspension

4.9.1. Circumstances for Revocation

Circumstances under which a certificate may be suspended and circumstances under which it must be revoked, for instance, in cases of subscriber employment termination, loss of cryptographic token, or suspected compromise of the private key.

A certificate will be revoked when the information it contains is suspected to be incorrect or compromised. This includes situations where:

The subscriber s private key is lost or suspected to be compromised;

The information in the subscriber s certificate is suspected to be inaccurate;

The subscriber no longer needs the certificate to access relying parties resources;

The subscriber violated his/her obligations.

The ownership of the DN is transferred to a new owner. All valid certificates issued to the previous owner will be revoked.

In general, control of revocation of certificates is delegated to the RA or the registered owner of a certificate.

DOEGrids CA operations will revoke certificates whose e-mail address is nonfunctional for 30 days. A best-effort attempt will be made to notify the RA when the first bounce of the e-mail address occurs.

DOEGrids CA operations will follow the direction of the DOEGrids security incident response team (a DOEGrids PMA function) concerning revocations.

DOEGrids CA operations will deal with other emergency situations as needed.

RFC 2527: 4.9

DOEGrids v2.10: 4.2, 4.5.1

4.9.2. Who Can Request Revocation

Who can request the revocation of the participant s certificate, for example, the subscriber, RA, or CA in the case of an end-user subscriber certificate.

CA operational staff has the authority to revoke any certificate issued by DOEGrids.

A request to revoke an end-entity certificate (person, host, or service) can be done by the following entities if they can present reasonable evidence that the private key has been compromised or that the subscriber s data is in error:

The holder or owner of the certificate.

The RA for the VO or site that validated the original certificate request

The DOEGrids CA managers and operational staff.

The DOEGrids Incident response team

Any other official entity that is a member of the VO or site.

Any other official entity responsible for DOEGrids CA ESnet, LBNL, DOE.

The following entities may request revocation of end-entity certificates for any documentable reason:

The DOEGrids CA managers and operational staff.

Any other official entity responsible for DOEGrids CA ESnet, LBNL, DOE.

The subscriber or registered owner may revoke (or request revocation of) the registered owner s own certificate for any reason at any time.

RFC 2527: 4.4.2

DOEGrids v2.10: 4.5.1, 4.5.2

4.9.3. Procedure for Revocation Request

Procedures used for certificate revocation request, such as a digitally signed message from the RA, a digitally signed message from the subscriber, or a phone call from the RA.

Subscribers may authenticate directly to the CA, using a trusted interface, and revoke their own certificates.

In other cases, the entity requesting the revocation must authenticate itself to an appropriate RA, the RAs agents, or the DOEGrids CA operations. The method and steps used to authenticate the identity must be recorded by the RA or DOEGrids CA operations, and must in general conform to the methods used to identify a person.

The RA that issued the certificate will be notified immediately about the revocation request and will be allowed one business day to resolve any uncertainties about the circumstances causing the revocation request.

In cases where the DOEGrids CA operations, or other responsible entity determine that a revocation grace period will cause damage to relying parties, revocation is permissible without this grace period. But in any event, the issuing RA must be notified.

RFC 2527: 4.4.3, 2.1.3

DOEGrids v2.10: 4.5.3

4.9.4. Revocation Request Grace Period

The grace period available to the subscriber, within which the subscriber must make a revocation request;

See 4.9.3. A grace period or revocation requirement for subscribers is not currently addressed.

RFC 2527: 4.4.4

4.9.5. Time Within Which CA Must Process the Revocation Request

Revocation requests are processed immediately and automatically by the CA. Revocation requests that require RA or DOEGrids CA operations attention require one business day for verification and completion.

RFC 2527: N/A

4.9.6. Revocation Checking Requirement for Relying Parties

The mechanisms, if any, that a relying party may use or must use in order to check the status of certificates on which they wish to rely;

Relying parties are encouraged to check for CRLs regularly (see 2.1).

RFC 2527: 4.4.10, 4.4.12, 4.4.14, 2.1.4

4.9.7. CRL Issuance Frequency (if applicable)

If a CRL mechanism is used, the issuance frequency;

See 2.3.

RFC 2527: 4.4.9, 4.8.3

DOEGrids v2.10: 4.5.5

4.9.8. Maximum Latency for CRLs (if applicable)

If a CRL mechanism is used, maximum latency between the generation of CRLs and posting of the CRLs to the repository (in other words, the maximum amount of processing- and communication-related delays in posting CRLs to the repository after the CRLs are generated);

Approximately 15 minutes.

RFC 2527: 4.4.9

4.9.9. Online Revocation/Status-Checking Availability

Online revocation/status checking availability, for instance, OCSP and a Web site to which status inquiries can be submitted;

An online status-checking facility will be provided as an experimental service.

RFC 2527: 4.4.11, 4.8.3

DOEGrids v2.10: 4.5.6

4.9.10.Online Revocation Checking Requirements

Requirements on relying parties to perform online revocation/status checks;

No stipulation.

RFC 2527: 4.4.12

DOEGrids v2.10: 4.5.7

4.9.11.Other Forms of Revocation Advertisements Available

No stipulation.

RFC 2527: 4.4.13, 4.4.14, 4.8.3

DOEGrids v2.10: 4.5.8

4.9.12.Special Requirements Re-key Compromise

Any variations of the above stipulations for which suspension or revocation is the result of private key compromise (as opposed to other reasons for suspension or revocation).

RFC 2527: 4.4.15

4.9.13.Circumstances for Suspension

Circumstances under which a certificate may be suspended.

The DOEGrids PKI does not support certificate suspension.

RFC 2527: 4.4.5, 2.1.3

DOEGrids v2.10: 4.5.4

4.9.14.Who Can Request Suspension

Who can request the suspension of a certificate, for example, the subscriber, human resources personnel, a supervisor of the subscriber, or the RA in the case of an end-user subscriber certificate.

RFC 2527: 4.4.6

4.9.15.Procedure for Suspension Request

Procedures to request certificate suspension, such as a digitally signed message from the subscriber or RA, or a phone call from the RA.

RFC 2527: 4.4.7, 2.1.3

4.9.16.Limits on Suspension Period

How long the suspension may last.

RFC 2527: 4.4.8

4.10. Certificate Status Services

This subcomponent addresses the certificate status-checking services available to the relying parties.

RFC 2527: 4.4.9-4.4.14

4.10.1.Operational Characteristics

The operational characteristics of certificate status-checking services.

RFC 2527: 4.4.9, 4.4.11, 4.4.13

4.10.2.Service Availability

The availability of such services, and any applicable policies on unavailability.

RFC 2527: 4.4.9, 4.4.11, 4.4.13

4.10.3.Optional Features

Any optional features of such services.

RFC 2527: 4.4.9, 4.4.11, 4.4.13

4.11. End of Subscription

This subcomponent addresses procedures used by the subscriber to end subscription to the CA services, including the revocation of certificates at the end of subscription (which may differ, depending on whether the end of subscription was due to the expiration of the certificate or termination of the service).

RFC 2527: N/A

4.12. Key Escrow and Recovery

This subcomponent contains the following elements to identify the policies and practices relating to the escrowing, and/or recovery of private keys where private key escrow services are available (through the CA or other trusted third parties).

Not supported.

RFC 2527: 6.2.3

DOEGrids v2.10: 6.2.2

4.12.1.Key Escrow and Recovery Policy and Practices

Identification of the document containing private key escrow and recovery policies and practices, or a listing of such policies and practices.

RFC 2527: 6.2.3

4.12.2.Session Key Encapsulation and Recovery Policy and Practices

Identification of the document containing session key encapsulation and recovery policies and practices or a listing of such policies and practices.

RFC 2527: 6.2.3

Page intentionally left blank

5. FACILITY, MANAGEMENT, AND OPERATIONAL CONTROLS

This component describes nontechnical security controls (that is, physical, procedural, and personnel controls) used by the issuing CA to securely perform the functions of key generation, subject authentication, certificate issuance, certificate revocation, auditing, and archiving.

This component can also be used to define nontechnical security controls on repositories, subject CAs, RAs, subscribers, and other participants. The nontechnical security controls for the subject CAs, RAs, subscribers, and other participants could be the same, similar, or very different.

These nontechnical security controls are critical to trusting the certificates, since lack of security may compromise CA operations resulting for example, in the creation of certificates or CRLs with erroneous information or compromising the CA private key.

Within each subcomponent, separate consideration will, in general, need to be given to each entity type, that is, the issuing CA, repository, subject CAs, RAs, subscribers, and other participants.

DOEGrids CA operations are managed by ESnet. Please refer to ESnet s NIST SP 800-53 section PE, Physical and Environmental Protection for more information. No requirements are made for non-ESnet participants in the DOEGrids PKI, except where noted.

RFC 2527: 4.5, 5

IGTF Classic: 5 (general)

5.1. Physical Controls

In this subcomponent, the physical controls on the facility housing the entity systems are described.

RFC 2527: 5.1

DOEGrids v2.10: 5.1

5.1.1. Site Location and Construction

Site location and construction, such as the construction requirements for high-security zones and the use of locked rooms, cages, safes, and cabinets;

DOEGrids CA components are housed in ESnet facilities such as the ESnet Data Center, or other locations under contract with various partners and service providers.

RFC 2527: 5.1.1

DOEGrids v2.10: 5.1

5.1.2. Physical Access

Physical access, i.e., mechanisms to control access from one area of the facility to another or access into high-security zones, such as locating CA operations in a secure computer room monitored by guards or security alarms and requiring movement from zone to zone to be accomplished using a token, biometric readers, and/or access control lists.

The ESnet Data center maintains a limited access procedure keyed to the LBNL badge system. The servers are maintained in access-controlled secure racks. All access to the servers is limited to DOEGrids CA security officers and system support staff of ESnet. Access to locations other than the ESnet Data Center have additional requirements. Please see ESnet s NIST SP 800-53 section PE.

RFC 2527: 5.1.2

DOEGrids v2.10: 5.1

5.1.3 Power and Air Conditioning

RFC 2527: 5.1.3

5.1.4 Water Exposures

RFC 2527: 5.1.4

5.1.5 Fire Prevention and Protection

RFC 2527: 5.1.5

5.1.6 Media Storage

Media storage, for example requiring the storage of backup media in a separate location that is physically secure and protected from fire and water damage.

RFC 2527: 5.1.6

5.1.7 Waste Disposal

RFC 2527: 5.1.7

5.1.8 Off-Site Backup

DOEGrids CA stores material in a number of off-site locations in a secure manner.

RFC 2527: 5.1.8

5.2. Procedural Controls

In this subcomponent, requirements for recognizing trusted roles are described, together with the responsibilities for each role. Examples of trusted roles include system administrators, security officers, and system auditors.

RFC 2527: 5.2

DOEGrids v2.10: 5.2

5.2.1. Trusted Roles

CA operator

Security officer (HSM administrator or security officer)

System administrator

RFC 2527: 5.2.1

5.2.2. Number of Persons Required per Task

For each task identified, the number of individuals required to perform the task (n out m rule) should be stated for each role. Identification and authentication requirements for each role may also be defined.

See ESnet HSM Operations Guide.

RFC 2527: 5.2.2

5.2.3. Identification and Authentication for Each Role

This component also includes the separation of duties in terms of the roles that cannot be performed by the same individuals.

RFC 2527: 5.2.3

5.2.4. Roles Requiring Separation of Duties

RFC 2527: 5.2.1, 5.2.2

5.3. Personnel Controls

All access to the servers and applications that comprise the DOEGrids CA is limited to ESnet staff (LBNL employees). Access is limited as appropriate for the role in support of the CA. Please see ESnet s NIST SP 800-53 section PS, Personnel Security Class.

RFC 2527: 5.3

DOEGrids v2.10: 5.3

5.3.1. Qualifications, Experience, and Clearance Requirements

Qualifications, experience, and clearances that personnel must have as a condition of filling trusted roles or other important roles. Examples include credentials, job experiences, and official government clearances that candidates for these positions must have before being hired.

No stipulation.

RFC 2527: 5.3.1

5.3.2. Background Check Procedures

Background checks and clearance procedures that are required in connection with the hiring of personnel filling trusted roles or perhaps other important roles; such roles may require a check of their criminal records, references, and additional clearances that a participant undertakes after a decision has been made to hire a particular person;

Follows LBNL requirements for employees.

RFC 2527: 5.3.2

5.3.3. Training Requirements

Training requirements and training procedures for each role following the hiring of personnel.

RFC 2527: 5.3.3

5.3.4. Retraining Frequency and Requirements

Any retraining period and retraining procedures for each role after completion of initial training.

LBNL requires periodic (typically yearly) retraining of employees in security practices, environmental safety, and organizational practices.

RFC 2527: 5.3.4

5.3.5. Job Rotation Frequency and Sequence

Frequency and sequence for job rotation among various roles.

RFC 2527: 5.3.5

5.3.6. Sanctions for Unauthorized Actions

Sanctions against personnel for unauthorized actions, unauthorized use of authority, and unauthorized use of entity systems for the purpose of imposing accountability on a participant s personnel.

Follows LBNL practice for employees.

RFC 2527: 5.3.6

5.3.7. Independent Contractor Requirements

Controls on personnel that are independent contractors rather than employees of the entity; examples include: bonding requirements on contract personnel; contractual requirements including indemnification for damages due to the actions of the contractor personnel; auditing and monitoring of contractor personnel; and other controls on contracting personnel.

RFC 2527: 5.3.7

5.3.8. Documentation Supplied to Personnel

Documentation to be supplied to personnel during initial training, retraining, or otherwise.

RFC 2527: 5.3.8

5.4. Audit Logging Procedures

This subcomponent is used to describe event logging and audit systems, implemented for the purpose of maintaining a secure environment.

RFC 2527: 4.5

5.4.1. Types of Events Recorded

Types of events recorded, such as certificate lifecycle operations, attempts to access the system, and requests made to the system.

The following events are recorded and archived

Certification requests;

Revocation requests;

Issued certificates;

Issued CRLs;

All e-mail correspondence on the PMA mailing list;

Certification authority events;

HSM events (limited);

Access to devices and servers.

RFC 2527: 4.5.1

DOEGrids v2.10: 4.7.1

5.4.2. Frequency of Processing Log

Frequency with which audit logs are processed or archived, for example, weekly, following an alarm or anomalous event, or whenever the audit log is n% full.

RFC 2527: 4.5.2

5.4.3. Retention Period for Audit Log

Period for which audit logs are kept.

Minimum retention period for CA or computer system logs is three years. Some records are kept indefinitely, and some records not under direct ESnet control follow institutional guidelines; please see ESnet s NIST SP 800-53 section AU, Audit and Accountability.

RFC 2527: 4.5.3

DOEGrids v2.10: 4.7.2

5.4.4. Protection of Audit Log

Who can view audit logs, for example, only the audit administrator. Protection against modification of audit logs, for instance a requirement that no one may modify or delete the audit records or that only an audit administrator may delete an audit file as part of rotating the audit file; and protection against deletion of audit logs.

Most audit logs are controlled by ESnet support staff. Some facilities logs are available by request.

ESnet staff, CA operations, authorized LBNL staff, and authorized auditors may examine audit records on request.

RFC 2527: 4.5.4

5.4.5. Audit Log Backup Procedures

RFC 2527: 4.5.5

5.4.6. Audit Collection System (Internal vs. External)

Whether the audit log accumulation system is internal or external to the entity.

The CA maintains its own audit files.

System logs and monitoring logs are maintained by ESnet, but by separate organizational components.

RFC 2527: 4.5.6

5.4.7. Notification to Event-Causing Subject

Whether the subject who caused an audit event to occur is notified of the audit action.

No (with some exceptions).

RFC 2527: 4.5.7

5.4.8. Vulnerability Assessments

Vulnerability assessments, for example, where audit data is run through a tool that identifies potential attempts to breach the security of the system.

See Section 8. ESnet and DOEGrids CA are subject to a variety of security assessment programs and audits.

RFC 2527: 4.5.8

5.5. Records Archival

This subcomponent is used to describe general records archival (or records retention) policies.

ESnet and DOEGrids follow LBNL institutional policies on record management and retention. Please see ESnet s NIST SP 800-53 section AU, Audit and Accountability.

RFC 2527: 4.6

5.5.1. Types of Records Archived

Types of records that are archived, for example, all audit data, certificate application information, and documentation supporting certificate applications.

All CSRs (which constitute certificate applications) are kept indefinitely.

Versions of CP-CPS documents are kept indefinitely.

RA identification and certification records are maintained by the RA.

RFC 2527: 4.6.1

5.5.2. Retention Period for Archive

For ESnet and DOEGrids, NIST 800-53 AU-11 applies.

RFC 2527: 4.6.2

5.5.3. Protection of Archive

Who can view the archive, for example, a requirement that only the audit administrator may view the archive; protection against modification of the archive, such as securely storing the data on a write-once medium; protection against deletion of the archive; protection against the deterioration of the media on which the archive is stored, such as a requirement for data to be migrated periodically to fresh media; and protection against obsolescence of hardware, operating systems, and other software, by, for example, retaining as part of the archive the hardware, operating systems, and/or other software in order to permit access to and use of archived records over time.

ESnet staff, CA operations, authorized LBNL staff, and authorized auditors may examine records archives on request.

RFC 2527: 4.6.3

5.5.4. Archive Backup Procedures

RFC 2527: 4.6.4

5.5.5. Requirements for Time-Stamping of Records

RFC 2527: 4.6.5

5.5.6. Archive Collection System (Internal or External)

Whether the archive collection system is internal or external.

RFC 2527: 4.6.6

5.5.7. Procedures to Obtain and Verify Archive Information

Procedures to obtain and verify archive information, such as a requirement that two separate copies of the archive data be kept under the control of two persons, and that the two copies be compared in order to ensure that the archive information is accurate.

RFC 2527: 4.6.7

5.6. Key Changeover

This subcomponent describes the procedures to provide a new public key to a CA s users following a re-key by the CA. These procedures may be the same as the procedure for providing the current key. Also, the new key may be certified in a certificate signed using the old key.

See ESnet CA Update Operations Guide.

A new signing key will be signed by the ESnet root CA and published in the appropriate repositories and distribution systems.

RFC 2527: 4.7

DOEGrids v2.10: 4.8

5.7. Compromise and Disaster Recovery

This subcomponent describes requirements relating to notification and recovery procedures in the event of compromise or disaster. Each of the following may need to be addressed separately.

See ESnet CA Update Operations Guide.

Compromise will be announced to the DOEGrids PMA, accrediting authorities, and security personnel. Since the circumstances of a disaster or key compromise can vary enormously, the precise details of the response to such events will be determined at the time after consultation with the appropriate authorities and experts.

RFC 2527: 4.8

DOEGrids v2.10: 4.9

5.7.1. Incident and Compromise Handling Procedures

Identification or listing of the applicable incident and compromise reporting and handling procedures.

Security incidents are reported to the ESnet Security Officer. Please refer to ESnet s NIST SP 800-53 section IR, Incident Response.

RFC 2527: 4.8

5.7.2. Computing Resources, Software, and/or Data Are Corrupted

The recovery procedures used if computing resources, software, and/or data are corrupted or suspected to be corrupted. These procedures describe how a secure environment is re-established, which certificates are revoked, whether the entity key is revoked, how the new entity public key is provided to the users, and how the subjects are recertified.

Backup copies of CA databases and other information are kept in the event of system failure.

Evaluation and recertification will be conducted on a case-by-case basis in cooperation with the associated RAs.

RFC 2527: 4.8.1

5.7.3. Entity Private Key Compromise Procedures

The recovery procedures used if the entity key is compromised. These procedures describe how a secure environment is re-established, how the new entity public key is provided to the users, and how the subjects are recertified.

See ESnet CA Key Operations Guide.

Compromised end-entity keys follow the policy and practices of 4.9.

RFC 2527: 4.8.3

5.7.4. Business Continuity Capabilities After a Disaster

The entity s capabilities to ensure business continuity following a natural or other disaster. Such capabilities may include the availability of a remote hot-site at which operations may be recovered. They may also include procedures for securing its facility during the period of time following a natural or other disaster and before a secure environment is re-established, either at the original site or at a remote site. For example, procedures to protect against theft of sensitive materials from an earthquake-damaged site.

Please consult the ESnet Contingency Plan and other associated documentation for a detailed discussion.

RFC 2527: 4.8.4

5.8. CA or RA Termination

This subcomponent describes requirements relating to procedures for termination and termination notification of a CA or RA, including the identity of the custodian of CA and RA archival records.

RA termination is managed by the DOEGrids PMA.

If the DOEGrids CA terminates its services, ESnet and the DOEGrids PMA will announce this to the community, and take other steps appropriate to the circumstances of the termination.

RFC 2527: 4.8.9

DOEGrids v2.10: 4.10

6. TECHNICAL SECURITY CONTROLS

This component is used to define the security measures taken by the issuing CA to protect its cryptographic keys and activation data (e.g., PINs, passwords, or manually held key shares). This component may also be used to impose constraints on repositories, subject CAs, subscribers, and other participants to protect their private keys, activation data for their private keys, and critical security parameters. Secure key management is critical to ensure that all secret and private keys and activation data are protected and used only by authorized personnel.

This component also describes other technical security controls used by the issuing CA to perform securely the functions of key generation, user authentication, certificate registration, certificate revocation, auditing, and archiving. Technical controls include life-cycle security controls (including software development environment security, trusted software development methodology) and operational security controls.

This component can also be used to define other technical security controls on repositories, subject CAs, RAs, subscribers, and other participants.

Many sections of ESnet s NIST SP 800-53 controls address these issues.

RFC 2527: 6, 2.1.3, 2.1.4

IGTF Classic: 4 (general)

6.1. Key Pair Generation and Installation

Key pair generation and installation need to be considered for the issuing CA, repositories, subject CAs, RAs, and subscribers.

RFC 2527: 6.1

6.1.1. Key Pair Generation

Who generates the entity public, private key pair? Possibilities include the subscriber, RA, or CA. Also, how is the key generation performed? Is the key generation performed by hardware or software?

Each end entity must generate its own key pair. DOEGrids PKI does not generate private keys. Registration authorities that issue hardware tokens to their subscribers, such as the ESnet RA, may generate keys for their subscribers on these tokens.

RFC 2527: 6.1.1, 6.1.7, 6.1.8

DOEGrids v2.10: 6.1.8

6.1.2. Private Key Delivery to Subscriber

How is the private key provided securely to the entity? Possibilities include a situation where the entity has generated it and therefore already has it, handing the entity the private key physically, mailing a token containing the private key securely, or delivering it in an SSL session.

The DOEGrids PKI never has access to the end-entity private key. The private key is under the control of the subscriber, or, in the case of an RA providing hardware tokens, the RA may generate keys and provide them to its subscribers through an auditable process.

RFC 2527: 6.1.2

DOEGrids v2.10: 6.1.2

6.1.3. Public Key Delivery to Certificate Issuer

How is the entity's public key provided securely to the certification authority? Some possibilities are in an online SSL session or in a message signed by the RA.

Entities public keys may be delivered to the issuing CA in a secure and trustworthy manner (e.g. SSL/TLS). Public keys are delivered to the CA in self-signed CSRs. Agents bind the public keys to entities through the process disclosed in their Registration Authority appendix; this process is independent of the submission protocol.

RFC 2527: 6.1.3

DOEGrids v2.10: 6.1.3

6.1.4. CA Public Key Delivery to Relying Parties

In the case of issuing CAs, how is the CA s public key provided securely to potential relying parties? Possibilities include handing the public key to the relying party securely in person, physically mailing a copy securely to the relying party, or delivering it in a SSL session.

CA signing certificate may be retrieved from the DOEGrids repository (see 2.1) or by contacting ESnet directly.

The CA signing certificate is available through various trusted repositories (TACAR, IGTF) and through various software distribution mechanisms. These are the preferred delivery mechanisms.

RFC 2527: 6.1.4

DOEGrids v2.10: 6.1.4

6.1.5. Key Sizes

What are the key sizes? Examples include a 1024-bit RSA modulus and a 1024-bit DSA large prime.

DOEGrids CA signs RSA public keys of modulus 1024 bits or greater, and recommends 2048 bit modulus.

RFC 2527: 6.1.5

DOEGrids v2.10: 6.1.5

6.1.6. Public Key Parameters Generation and Quality Checking

Who generates the public key parameters, and is the quality of the parameters checked during key generation?

DOEGrids CA signs keys with exponent 65537.

Keys are generated under user control. In some cases, an RA may operate a token service and generate keys on hardware on behalf of its clientele.

RFC 2527: 6.1.6, 6.1.7

DOEGrids v2.10: 6.1.6, 6.1.7

6.1.7. Key Usage Purposes (as per X.509 v3 key usage field)

For what purposes may the key be used, or for what purposes should usage of the key be restricted? For X.509 certificates, these purposes should map to the key usage flags in X.509 Version 3 certificates.

DOEGrids certificates are only warranted for authentication and signing proxy certificates [Proxy].

The DOEGrids online CA signing key signs end-entity certificates.

RFC 2527: 6.1.9

DOEGrids v2.10: 6.1.9

6.2. Private Key Protection and Cryptographic Module Engineering Controls

Requirements for private key protection and cryptographic modules need to be considered for the issuing CA, repositories, subject CAs, RAs, and subscribers.

See ESnet HSM Operations Guide.

The scope of this section will only include CA private keys (signing keys). Subscriber and participants keys are out of scope. See Section 6.1.2.

6.2.1. Cryptographic Module Standards and Controls

What standards, if any, are required for the cryptographic module used to generate the keys? A cryptographic module can be composed of hardware, software, firmware, or any combination of them. For example, are the keys certified by the infrastructure required to be generated using modules compliant with the US FIPS 140-1? If so, what is the required FIPS 140-1 level of the module? Are there any other engineering or other controls relating to a cryptographic module, such as the identification of the cryptographic module boundary, input/output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, and self tests.

DOEGrids CA signing private key is managed by a FIPS-140 Level 3 certified hardware and software system.

This private key is stored in 3DES encrypted form on the hard disk of the server, and is backed up by conventional server backup services and by other means. The private key is never available in plain text form (that is, in a usable form) to the server operating system or any backup service. The private key is enabled inside the HSM device by a set of operator smart cards.

The keys for these smart cards and the 3DES key used to encrypt the signing private key are generated by the FIPS-140 device (key generation is based on a hardware random number generator). An additional set of smart cards, the administrative card set, controls the HSM configuration and smart card lifecycle. Several copies of cards have been created and stored in secure locations.

RFC 2527: 6.2.1, 6.8

DOEGrids v2.10: 6.8

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

Is the private key under n out of m multi-person control? If yes, provide n and m (two-person control is a special case of n out of m, where n = m = 2)?

The CA software does not support n of m operations. The HSM administrative tokens use n of m operations.

RFC 2527: 6.2.2

DOEGrids v2.10: 6.2.1

6.2.3. Private Key Escrow

Is the private key escrowed? If so, who is the escrow agent, what form is the key escrowed in (examples include plaintext, encrypted, split key), and what are the security controls on the escrow system?

Not supported.

RFC 2527: 6.2.3

DOEGrids v2.10: 6.2.2

6.2.4. Private Key Backup

Is the private key backed up? If so, who is the backup agent, what form is the key backed up in (examples include plain text, encrypted, split key), and what are the security controls on the backup system?

Encrypted copies of the private key are backed up, and some copies are kept externally.

RFC 2527: 6.2.4

DOEGrids v2.10: 6.2.3

6.2.5. Private Key Archival

Is the private key archived? If so, who is the archival agent, what form is the key archived in (examples include plaintext, encrypted, split key), and what are the security controls on the archival system?

Not supported.

RFC 2527: 6.2.5

DOEGrids v2.10: 6.2.3

6.2.6. Private Key Transfer into or from a Cryptographic Module

Under what circumstances, if any, can a private key be transferred into or from a cryptographic module? Who is permitted to perform such a transfer operation? In what form is the private key during the transfer (i.e., plaintext, encrypted, or split key)?

The private key is never available as plaintext outside the HSM. Inside the HSM, the plaintext private key is only available for cryptographic operations.

The HSM is enabled and the private key transferred to the module through an HSM operation using the operator token.

RFC 2527: 6.2.6

6.2.7. Private Key Storage on Cryptographic Module

How is the private key stored in the module (i.e., plaintext, encrypted, or split key)?

Encrypted until enabled by an operator token.

RFC 2527: 6.2.6

6.2.8. Method of Activating Private Key

Who can activate (use) the private key? What actions must be performed to activate the private key (e.g., login, power on, supply PIN, insert token/key, automatic, etc.)? Once the key is activated, is the key active for an indefinite period, active for one time, or active for a defined time period?

DOEGrids CA operations enable the CA private key, using one of the operator tokens.

The private key is enabled indefinitely, but see 6.2.9.

RFC 2527: 6.2.7

6.2.9. Method of Deactivating Private Key

Who can deactivate the private key and how? Examples of methods of deactivating private keys include logging out, turning the power off, removing the token/key, automatic deactivation, and time expiration.

A DOEGrids CA operator may deactivate the key using an operator card, or the host machine may be rebooted or power-cycled.

RFC 2527: 6.2.8

6.2.10.Method of Destroying Private Key

Who can destroy the private key and how? Examples of methods of destroying private keys include token surrender, token destruction, and overwriting the key.

The private key may be permanently disabled by destroying the administrative tokens of the HSM.

RFC 2527: 6.2.9

6.2.11.Cryptographic Module Rating

Provide the capabilities of the cryptographic module in the following areas: identification of the cryptographic module boundary, input/output, roles and services, finite state machine, physical security, software security, operating system security, algorithm compliance, electromagnetic compatibility, and self tests. Capability may be expressed through reference to compliance with a standard such as U.S. FIPS 140-1, associated level, and rating.

FIPS 140-3.

RFC 2527: 6.2.1, 6.8

6.3. Other Aspects of Key Pair Management

Other aspects of key management need to be considered for the issuing CA, repositories, subject CAs, RAs, subscribers, and other participants.

The DOEGrids CA signing certificate s current validity period is
5 December, 2002, to 25 January, 2013.

RFC 2527: 6.3

DOEGrids v2.10: 6.3

6.3.1. Public Key Archival

Is the public key archived? If so, who is the archival agent, and what are the security controls on the archival system? Also, what software and hardware need to be preserved as part of the archive to permit use of the public key over time? Note: this subcomponent is not limited to requiring or describing the use of digital signatures with archival data, but rather can address integrity controls other than digital signatures when an archive requires tamper-protection. Digital signatures do not provide tamper-protection or protect the integrity of data; they merely verify data integrity. Moreover, the archival period may be greater than the cryptanalysis period for the public key needed to verify any digital signature applied to archival data.

Certificates issued are kept indefinitely in an internal database, and published in an external repository (see 2) while valid.

RFC 2527: 6.3.1

6.3.2. Certificate Operational Periods and Key Pair Usage Periods

What is the operational period of the certificates issued to the subscriber. What are the usage periods, or active lifetimes, for the subscriber s key pair?

DOEGrids Certificates are issued valid for one year (365 days).

DOEGrids permits use of the Replacement Interface for 30 days after certificate expiration (this functionality is currently disabled).

Certificates for software-based subscriber private keys must be re-keyed after expiration.

Certificates for hardware-based subscriber private keys may be renewed after expiration (this capability is currently only available to participants in the ESnet RA.

RFC 2527: 6.3.2

6.4. Activation Data

Activation data refers to data values other than whole private keys that are required to operate private keys or cryptographic modules containing private keys, such as a PIN, pass phrase, or portions of a private key used in a key-splitting scheme. Protection of activation data prevents unauthorized use of the private key, and potentially needs to be considered for the issuing CA, subject CAs, RAs, and subscribers. Such consideration potentially needs to address the entire life-cycle of the activation data, from generation through archival and destruction. For each of the entity types (issuing CA, repository, subject CA, RA, subscriber, and other participants), all of the questions listed in 6.1 through 6.3 potentially need to be answered with respect to activation data rather than with respect to keys.

The CA signing key is managed by an HSM (see 6.2.8).

Subscribers are expected to secure their software private keys with a strong pass phrase, and their hardware private keys with a PIN. Host and service private keys are expected to be secured at an appropriate level for the service in question.

RFC 2527: 6.4

DOEGrids v2.10: 6.4

6.4.1. Activation Data Generation and Installation

RFC 2527: 6.4.1

6.4.2. Activation Data Protection

RFC 2527: 6.4.2

6.4.3. Other Aspects of Activation Data

RFC 2527: 6.4.3

6.5. Computer Security Controls

This subcomponent is used to describe computer security controls such as: use of the trusted computing base concept, discretionary access control, labels, mandatory access controls, object reuse, audit, identification and authentication, trusted path, security testing, and penetration testing. Product assurance may also be addressed.

A computer security rating for computer systems may be required. The rating could be based, for example, on the Trusted System Evaluation Criteria (TCSEC), Canadian Trusted Products Evaluation Criteria, European Information Technology Security Evaluation Criteria (ITSEC), or the Common Criteria for Information Technology Security Evaluation, ISO/IEC 15408:1999. This subcomponent can also address requirements for product evaluation analysis, testing, profiling, product certification, and/or product accreditation-related activity undertaken.

DOEGrids CA follows LBNL and ESnet computer security requirements, refer to ESnet s NIST SP 800-53.

6.5.1. Specific Computer Security Technical Requirements

CA servers include the following:

Operating systems are maintained at a high level of security by applying all recommended and applicable security patches;

Monitoring is done to detect unauthorized software changes;

Services are reduced to the bare minimum.

RFC 2527: 6.5.1

DOEGrids v2.10: 6.5.1

6.5.2. Computer Security Rating

No stipulation.

RFC 2527: 6.5.2

DOEGrids v2.10: 6.5.2

6.6. Lifecycle Technical Controls

This subcomponent addresses system development controls and security management controls.

System development controls include development environment security, development personnel security, configuration management security during product maintenance, software engineering practices, software development methodology, modularity, layering, use of fail-safe design and implementation techniques (e.g., defensive programming) and development facility security.

Security management controls include execution of tools and procedures to ensure that the operational systems and networks adhere to configured security. These tools and procedures include checking the integrity of the security software, firmware, and hardware to ensure their correct operation.

This subcomponent can also address life-cycle security ratings based, for example, on the Trusted Software Development Methodology (TSDM) level IV and V, independent life-cycle security controls audit, and the Software Engineering Institute s Capability Maturity Model (SEI-CMM).

Please see ESnet s Service Placement Guide. Also, please see ESnet s NIST SP 800-53 section CM, Configuration Management, especially parts 2 and 6.

RFC 2527: 6.6

DOEGrids v2.10: 6.6

6.6.1. System Development Controls

RFC 2527: 6.6.1

6.6.2. Security Management Controls

RFC 2527: 6.6.2

6.6.3. Lifecycle Security Controls

RFC 2527: 6.6.3

6.7. Network Security Controls

This subcomponent addresses network security-related controls, including firewalls.

The DOEGrids PKI servers are protected by stateful intrusion detection systems. Access control lists are placed on upstream network interfaces that limit access to and from the public Internet. Active monitoring and blocking is done based on best-practice rule sets.

RFC 2527: 6.7

DOEGrids v2.10: 6.7

6.8. Time-Stamping

This subcomponent addresses requirements or practices relating to the use of time stamps on various data. It may also discuss whether or not the time-stamping application must use a trusted time source.

Most logfiles are time stamped and rely on trusted (but not signed) time information.

RFC 2527: N/A

7. CERTIFICATE, CRL, AND OCSP PROFILES

This component is used to specify the certificate format and, if CRLs and/or Online Certificate Status Protocol (OCSP) are used, the CRL and/or OCSP format. This includes information on profiles, versions, and extensions used.

It is the intention of the DOEGrids CA PMA and CA operators that DOEGrids certificates conform to the current IGTF-approved OGF Grid Certificate Profile.

RFC 2527: 7.1

IGTF Classic: 4 (general)

7.1. Certificate Profile

This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the one defined in IETF PKIX RFC 3280):

RFC 2527: 7.1

7.1.1. Version Number(s)

X.509 v3.

RFC 2527: 7.1.1

DOEGrids v2.10: 7.1.1

7.1.2. Certificate Extensions

DOEGrids CA signing certificate

Attribute	Critical?	Value
Basic Constraints	Critical	Is CA: yes Path Length Constraint: UNLIMITED
Key Usage	Critical	Digital Signature Key CertSign CRL Sign
Extended Key Usage		Omitted
Netscape Certificate Type	No	SSL Client SSL CA Secure e-mail CA ObjectSigning CA
Subject Key Identifier	No	Key Identifier: <160 bit sha1 hash of DOEGrids CA public key> CA:19:1D:12:8E:6E:A4:38:5D:42:D4:31:0E:08:DB:D9:8D:17:0D:5D
Authority Key Identifier	No	Key Identifier: <160 bit sha1 hash of ESnet Root CA public key> BC:5D:4D:48:2F:F8:35:94:59:AB:5C:89:4B:3E:D1:B2:3A:14:01:EA
Certificate Policies		Omitted
CRL Distribution Points		Omitted
Subject Alternative Name	No	RFC822Name: DOEGrids-CA-1@doegrids.org

DOEGrids End Entity certificates

The current default extensions are shown below. Other combinations of extensions may appear if technically feasible and not in conflict with accreditation or security requirements.

Attribute	Critical?	Value
Basic Constraints	Critical	Omitted: ASN.1 compiler removes default empty sequences
Netscape Certificate Type	No	SSL Client Secure e-mail
Netscape Certificate Type (service)	No	SSL Client SSL Server
Key Usage	Critical	Digital Signature Key Encipherment
Key Usage (service)	Critical	Digital Signature Key Encipherment Data Encipherment
Extended Key Usage	No	Omitted
Authority Key Identifier	No	Key Identifier: <160 bit SHA1 hash of DOEGrids CA public key>
Subject Key Identifier	No	Key Identifier: <160 bit SHA1 hash of DOEGrids EE public key>
Certificate Policies	No	Certificate Policies = OID of this CPS (see 1.2) OID of current IGTF Classic Profile OID of current 1SCP Trusted Thirty Party Identity vetting
CRL Distribution Points	No	http://crl.doegrids.org/1c3f2ca8/1c3f2ca8.crl
Subject Alternative Name	No	RFC822Name = <subject s public e-mail address>
Subject Alternative Name (service)	No	RFC822Name = <responsible party s public e-mail address> DNSname= <FQDN of host>

RFC 2527: 7.1.2

DOEGrids v2.10: 7.1.2

7.1.3. Algorithm Object Identifiers

Signature SHA1withRSA - 1.2.840.113549.1.1.5

Keying material RSA - 1.2.840.113549.1.1.1

MD5 hash function is not used.

RFC 2527: 7.1.3

DOEGrids v2.10: 7.1.3

7.1.4. Name Forms

OU=Hosts is for internal use of DOEGrids only.

Issuer: CN=DOEGrids CA 1, OU=Certificate Authorities, DC=doegrids, DC=org

The subject name of the end entity will be a valid Distinguished Name (DN). These DNs will consist of one of the following Relative DNs (RDN):

For People: OU=People, DC= doegrids, DC=org

For Hosts: OU=Hosts, DC= doegrids, DC=org

For Services: OU=Services, DC= doegrids, DC=org

The Common Name (CN) components of the DNs are defined as:

For a Person
Full name as determined by the RA and an additional string of up to six random numeric characters added for uniqueness. (i.e. John K. Doe 98765 ):

CN= John K. Doe 98765, OU=People, DC= doegrids, DC=org

For a Host
A fully qualified domain name as registered in DNS or its 4 octet IP address, optionally prefixed with host/.

CN=foo.example.com, OU=Hosts, DC= doegrids, DC=org

For a Service
The service name/a fully qualified Domain name as registered in DNS (FQDN) or its 4 octet IP address (i.e.<SRV>/<FQDN>;<SRV>/<IP> ). Note: host is an acceptable service name, as for example in Globus gatekeeper certificates.

o CN=FTP/foo.example.com, OU=Services, DC= doegrids, DC=org

o CN=FTP/131.243.2.12, OU=Services, DC= doegrids, DC=org

o CN=foo.example.com, OU=Services, DC= doegrids, DC=org

RFC 2527: 7.1.4

DOEGrids v2.10: 7.1.4

7.1.5. Name Constraints

Not supported.

RFC 2527: 7.1.5

DOEGrids v2.10: 7.1.5

7.1.6. Certificate Policy Object Identifier

Same as this document. See 1.2.

RFC 2527: 7.1.6

DOEGrids v2.10: 7.1.6

7.1.7. Usage of Policy Constraints Extension

Not supported.

RFC 2527: 7.1.7

DOEGrids v2.10: 7.1.7

7.1.8. Policy Qualifiers Syntax and Semantics

The qualifier is a pointer to this document, in the form of an URL.

RFC 2527: 7.1.8

DOEGrids v2.10: 7.1.8

7.1.9. Processing Semantics for the Critical Certificate Policies Extension

Not supported.

RFC 2527: 7.1.9

7.2. CRL Profile

This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the one defined in IETF PKIX RFC 3280).

RFC 2527: 7.2

X.509 v2

RFC 2527: 7.2

DOEGrids v2.10: 7.2.1

7.2.1. CRL and CRL Entry Extensions

CRL and CRL entry extensions populated and their criticality.

The DOEGrids CRL consists of headers, extensions, and a list of revoked certificates, following the structure of the current PKIX profile.

Expired certificates are removed from the CRL.

DOEGrids CA publishes a global CRL.

CRL header and global extensions:

Certificate Revocation List Header	Value
Version	X.509V2
Signature	SHA1withRSA
Issuer	DOEGrids CA subject name (namely CN=DOEGrids CA 1, OU=Certificate Authorities, DC=DOEGrids, DC=org).
ThisUpdate	Varies; date/time CRL published
NextUpdate	thisUpdate +30 days
X509v3 CRL Number	Sequence number (monotonically increasing) of this CRL

CRL entries:

Revoked certificate entry	Required	Value
Serial number	Yes	Serial number of revoked certificate
Revocation date	Yes	Date/time of revocation
Revocation reason	No	Any of X.509 CRL Reason code
Invalidity date	No	As determined by revocation agent

DOEGrids CA may publish other CRLs using other issuers or sets of partial CRLs (indirect and / or delta CRLs).

RFC 2527: 7.2.1

DOEGrids v2.10 2527: 7.2.2

7.3. Online Certificate Status Protocol (OCSP) Profile

This subcomponent addresses such topics as the following (potentially by reference to a separate profile definition, such as the IETF RFC 2560 profile).

Experimental support only at this time.

RFC 2527: N/A

7.3.1. Version Number(s)

Version of OCSP that is being used as the basis for establishing an OCSP system.

RFC 2527: N/A

7.3.2. OCSP Extensions

OCSP extensions populated and their criticality.

RFC 2527: N/A

9. OTHER BUSINESS AND LEGAL MATTERS

This component covers general business and legal matters. Sections 9.1 and 9.2 of the framework discuss the business issues of fees to be charged for various services and the financial responsibility of participants to maintain resources for ongoing operations and for paying judgments or settlements in response to claims asserted against them. The remaining sections are generally concerned with legal topics.

Starting with Section 9.3 of the framework, the ordering of topics is the same as or similar to the ordering of topics in a typical software licensing agreement or other technology agreement. Consequently, this framework may not only be used for CPs and CPSs, but also associated PKI-related agreements, especially subscriber agreements, and relying party agreements. This ordering is intended to help lawyers review CPs, CPSs, and other documents adhering to this framework.

With respect to many of the legal subcomponents within this component, a CP or CPS drafter may choose to include in the document terms and conditions that apply directly to subscribers or relying parties. For instance, a CP or CPS may set forth limitations of liability that apply to subscribers and relying parties. The inclusion of terms and conditions is likely to be appropriate where the CP or CPS is itself a contract or part of a contract.

In other cases, however, the CP or CPS is not a contract or part of a contract; instead, it is configured so that its terms and conditions are applied to the parties by separate documents, which may include associated agreements, such as subscriber or relying party agreements. In that event, a CP drafter may write a CP so as to require that certain legal terms and conditions appear (or not appear) in such associated agreements. For example, a CP might include a subcomponent stating that a certain limitation of liability term must appear in a CA s subscriber and relying party agreements. Another example is a CP that contains a subcomponent prohibiting the use of a subscriber or relying party agreement containing a limitation upon CA liability inconsistent with the provisions of the CP. A CPS drafter may use legal subcomponents to disclose that certain terms and conditions appear in associated subscriber, relying party, or other agreements in use by the CA. A CPS might explain, for instance, that the CA writing it uses an associated subscriber or relying party agreement that applies a particular provision for limiting liability.

RFC 2527: 4.2.5

IGTF Classic: 8 (general)

9.1. Fees

This subcomponent contains any applicable provisions regarding fees charged by CAs, repositories, or RAs.

No fees are charged for DOEGrids Certificates. All costs for operation are covered directly or indirectly by DOE.

RFC 2527: 2.5

DOEGrids v2.10 2.5

9.1.1. Certificate Issuance or Renewal Fees

RFC 2527: 2.5.1

9.1.2. Certificate Access Fees

RFC 2527: 2.5.2

9.1.3. Revocation or Status Information Access Fees

RFC 2527: 2.5.3

9.1.4. Fees for Other Services

Fees for other services, such as providing access to the relevant CP or CPS.

RFC 2527: 2.5.4

9.1.5. Refund Policy

RFC 2527: 2.5.5

9.2. Financial Responsibility

This subcomponent contains requirements or disclosures relating to the resources available to CAs, RAs, and other participants providing certification services to support performance of their operational PKI responsibilities, and to remain solvent and pay damages in the event they are liable to pay a judgment or settlement in connection with a claim arising out of such operations.

No financial responsibility is accepted.

RFC 2527: 2.3

DOEGrids v2.10 2.3

9.2.1. Insurance Coverage

A statement that the participant maintains a certain amount of insurance coverage for its liabilities to other participants.

RFC 2527: 2.3

9.2.2. Other Assets

A statement that a participant has access to other resources to support operations and pay damages for potential liability, which may be couched in terms of a minimum level of assets necessary to operate and cover contingencies that might occur within a PKI, where examples include assets on the balance sheet of an organization, a surety bond, a letter of credit, and a right under an agreement to an indemnity under certain circumstances.

RFC 2527: 2.3

9.2.3. Insurance or Warranty Coverage for End Entities

A statement that a participant has a program that offers first-party insurance or warranty protection to other participants in connection with their use of the PKI.

RFC 2527: 2.3

9.3. Confidentiality of Business Information

This subcomponent contains provisions relating to the treatment of confidential business information that participants may communicate to each other, such as business plans, sales information, trade secrets, and information received from a third party under a nondisclosure agreement.

DOEGrids PKI collects subscribers full names 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.

DOEGrids PKI does not collect any kind of confidential information.

DOEGrids PKI does not have access to or generate the private keys of a digital signature key pair, such as those used in DOEGrids identity certificates. These key pairs are generated and managed by the client and are the sole responsibility of the subscriber.

RFC 2527: 2.8

IGTF Classic: 8

DOEGrids v2.10: 2.8

9.3.1. Scope of Confidential Information

The scope of what is considered confidential information.

RFC 2527: 2.8.1, 2.8.3

9.3.2. Information Not Within the Scope of Confidential Information

The types of information that are considered to be outside the scope of confidential information.

RFC 2527: 2.8.2, 2.8.3

9.3.3. Responsibility to Protect Confidential Information

The responsibilities of participants that receive confidential information to secure it from compromise, and refrain from using it or disclosing it to third parties.

RFC 2527: 2.8, 2.8.3 2.8.7

9.4. Privacy of Personal Information

This subcomponent relates to the protection that participants, particularly CAs, RAs, and repositories, may be required to provide for personally identifiable private information of certificate applicants, subscribers, and other participants. Specifically, this subcomponent addresses the following, to the extent pertinent under applicable law.

DOEGrids CA follows institutional requirements, namely the LBNL Privacy Policy: http://www.lbl.gov/Disclaimers.html.

In particular, certain types of Personally Identifiable Information are not approved for use in DOEGrids CA itself and are not requested or collected by the DOEGrids CA service.

DOEGrids CA collects name, contact information, and affiliation information needed for the purpose of establishing and maintaining eligibility for certification. Users of the DOEGrids CA service should have no expectation of privacy for this information.

DOEGrids RAs may have other rules and other requirements, which should be dealt with in the RA s disclosure.

RFC 2527: 2.8

9.4.1. Privacy Plan

The designation and disclosure of the applicable privacy plan that applies to a participant's activities, if required by applicable law or policy.

RFC 2527: N/A

9.4.2. Information Treated as Private

Information that is considered private within the PKI.

RFC 2527: 2.8.1, 2.8.3

9.4.3. Information not Deemed Private

Information that is not considered private within the PKI.

RFC 2527: 2.8.2, 2.8.3

9.4.4. Responsibility to Protect Private Information

Any responsibility of participants that receive private information to secure it, and refrain from using it and from disclosing it to third parties.

RFC 2527: 2.8, 2.8.1, 2.8.3

9.4.5. Notice and Consent to Use Private Information

Any requirements as to notices to, or consent from individuals regarding use or disclosure of private information.

RFC 2527: N/A

9.4.6. Disclosure Pursuant to Judicial or Administrative Process

Any circumstances under which a participant is entitled or required to disclose private information pursuant to judicial, administrative process in a private or governmental proceeding, or in any legal proceeding.

RFC 2527: 2.8.4, 2.8.5

9.4.7. Other Information Disclosure Circumstances

RFC 2527: 2.8.6, 2.8.7

9.5. Intellectual Property Rights

This subcomponent addresses the intellectual property rights, such as copyright, patent, trademarks, or trade secrets, that certain participants may have or claim in a CP, CPS, certificates, names, and keys, or are the subject of a license to or from participants.

Consistent with the accreditation requirement of IGTF, ESnet/LBNL grants to the IGTF and its member PMAs the right of unlimited redistribution of the documents and metadata required to fulfill the IGTF s mission, namely this CPS document, the signed copies of signing certificates, and contact information (also contained in this document).

In addition, ESnet and DOEGrids CA operations follow institutional requirements concerning copyright, namely http://www.lbl.gov/Disclaimers.html, which allows the grant described above.

This CPS document quotes extensively from RFC 3647 for the purpose of guiding editors and readers. It is heavily influenced by and modeled on the BrGrid CPS. Parts of this document are inspired by [INFN CP], [GridCP], [EuroPKI], [TrustID], [NCSA], [PAG], and [FBCA]. Also see Acknowledgments.

RFC 2527: 2.9

DOEGrids v2.10: 2.9

9.6. Representations and Warranties

This subcomponent can include representations and warranties of various entities that are being made pursuant to the CP or CPS. For example, a CPS that serves as a contract might contain a CA s warranty that information contained in the certificate is accurate. Alternatively, a CPS might contain a less extensive warranty to the effect that the information in the certificate is true to the best of the CA s knowledge after performing certain identity authentication procedures with due diligence. This subcomponent can also include requirements that representations and warranties appear in certain agreements, such as subscriber or relying party agreements. For instance, a CP may contain a requirement that all CAs utilize a subscriber agreement, and that a subscriber agreement must contain a warranty by the CA that information in the certificate is accurate. Participants that may make representations and warranties include CAs, RAs, subscribers, relying parties, and other participants.

RFC 2527: 2.2

9.6.1. CA Representations and Warranties

RFC 2527: 2.2.1

9.6.2. RA Representations and Warranties

RFC 2527: 2.2.2

9.6.3. Subscriber Representations and Warranties

RFC 2527: 2.1.3

9.6.4. Relying Party Representations and Warranties

RFC 2527: 2.1.4

9.6.5. Representations and Warranties of Other Participants

RFC 2527: N/A

9.7. Disclaimers of Warranties

This subcomponent can include disclaimers of express warranties that may otherwise be deemed to exist in an agreement, and disclaimers of implied warranties that may otherwise be imposed by applicable law, such as warranties of merchantability or fitness for a particular purpose. The CP or CPS may directly impose such disclaimers, or the CP or CPS may contain a requirement that disclaimers appear in associated agreements, such as subscriber or relying party agreements.

RFC 2527: 2.2, 2.3.2

9.8. Limitations of Liability

This subcomponent can include limitations of liability in a CP or CPS or limitations that appear or must appear in an agreement associated with the CP or CPS, such as a subscriber or relying party agreement. These limitations may fall into one of two categories: limitations on the elements of damages recoverable and limitations on the amount of damages recoverable, also known as liability caps. Often, contracts contain clauses preventing the recovery of elements of damages such as incidental and consequential damages, and sometimes punitive damages. Frequently, contracts contain clauses that limit the possible recovery of one party or the other to an amount certain or to an amount corresponding to a benchmark, such as the amount a vendor was paid under the contract.

DOEGrids PKI and its agents issue person certificates according to the practices described in this document to validate identity. No liability, implicit or explicit, is accepted.

DOEGrids PKI and its agents make no guarantee about the security or suitability of a service that is identified by a DOEGrids 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.

DOEGrids PKI denies any financial or any other kind of responsibility for damages or impairments resulting from its operation.

RFC 2527: 2.2

DOEGrids v2.10: 2.2

9.9. Indemnities

This subcomponent includes provisions by which one party makes a second party whole for losses or damage incurred by the second party, typically arising out of the first party s conduct. They may appear in a CP, CPS, or agreement. For example, a CP may require that subscriber agreements contain a term under which a subscriber is responsible for indemnifying a CA for losses the CA sustains arising out of a subscriber s fraudulent misrepresentations on the certificate application under which the CA issued the subscriber an inaccurate certificate. Similarly, a CPS may say that a CA uses a relying party agreement, under which relying parties are responsible for indemnifying a CA for losses the CA sustains arising out of use of a certificate without properly checking revocation information or use of a certificate for purposes beyond what the CA permits.

RFC 2527: 2.1.3, 2.1.4, 2.2, 2.3.1

9.10. Term and Termination

This subcomponent can include the time period in which a CP or a CPS remains in force and the circumstances under which the document, portions of the document, or its applicability to a particular participant can be terminated. In addition or alternatively, the CP or CPS may include requirements that certain term and termination clauses appear in agreements, such as subscriber or relying party agreements.

RFC 2527: N/A

9.10.1.Term

The term of a document or agreement, that is, when the document becomes effective and when it expires if it is not terminated earlier.

RFC 2527: