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
Forces RFC 3647 [Chokani03], (extracts of which 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. Underlined
type indicates substantive changes in that text made for this revision. Where
section headings in v2.10 vary from those in the new template, they are listed,
so that a comparison may be made.
See the
References section at the end of the document for links to source documents.
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 RFC 3647 [RFC3647].
Not all sections of RFC 3647 are used. Sections that are not included have a
default value of No stipulation.
RFC 2527:
1.1
IGTF
Classic: 1 (general)
DOEGrids
v2.10: 1.1
This document describes the set of rules and procedures
established by the DOEGrids Policy Management Authority for the operations of
the DOEGrids Public Key Infrastructure (PKI) service. ESnet operates the
DOEGrids Public Key Infrastructure under the authority of the DOEGrids PMA. ESnet
and the data center housing the PKI servers are located at Lawrence Berkeley
National Laboratory, in Berkeley, California.
This document will include both the Certificate Policy and
the Certification Practice Statement for the DOEGrids PKI. The general
architecture is a certificate authority (CA) with multiple Registration
Authorities. The certificate authority 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 VO or Site
Appendices in this document.
DOEGrids PKI is a Traditional X.509 Public Key
Certification Authority that complies with the International Grid Trust
Federation (IGTF) Profile for a traditional X.509 Public Key Certification
Authorities with secure infrastructure, version 4.0. It is the intent of the
DOEGrids PKI to issue identity and service certificates for use in Grids.
These certificates are for DOE researchers and their colleagues. These
certificates will be compatible with the Globus middleware that is used on
these Grids.
The DOEGrids personal certificates by themselves are not
to be used for determining authorization. The DOEGrids personal certificate can
be used only to assert the identity of the individual it was assigned to.
Authorization decisions must be based on other criteria than the DOEGrids
personal certificate.
RFC 2527:
1.1
IGTF
Classic: 1 (general)
DOEGrids v2.10: 1.1
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.
Identification
Document title: DOEGrids CA Certificate Policy and
Certification Practice Statement
Document version: 3.0
Document date: March 6, 2009
OID:
[ESnet].ERmember.DOEGrids.CP-CPS.CPVersionNumber.CPReleaseNumber
1.2.840.113612.3.7.1.3.0
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.0
|
Major and minor
CP/CPS version number
|
RFC 2527:
1.2
IGTF
Classic: 1 (general)
DOEGrids v2.10: 1.2
This
subcomponent describes the identity or types of entities that fill the roles of
participants within a PKI.
Obligations
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
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 organizations
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 Release 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
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
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 certificates 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.
Subscriber Obligations
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 eight 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
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 Party Obligations
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 entitys
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.
Such as
certificate manufacturing authorities, providers of repository services, and
other entities providing PKI-related services.
Repository Obligations
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.
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.
Applicability
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.
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.
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.
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
authoritys 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.
DOEGrids PKI is operated by ESnet
and managed by a Policy Management Authority. The members of the PMA can be
found on the project Web site (www.doegrids.org/pages/doegridspma.html).
RFC 2527:
1.4.1
IGTF
Classic: 1
DOEGrids v2.10: 1.4
Contact Details
The contact person for questions related to this document
is the chairman of the PMA. The PMA chairman (acting) and his/her contact
information:
John Volmer
Argonne National
Laboratory
volmer@anl.gov
The acting 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 ESnets 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
RFC 2527:
1.4.3
RFC 2527:
8.3
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) (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.
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.
RFC 2527:
N/A
IGTF
Classic: 1 (general, use of terms)
RFC 2527:
N/A
Publication and
Repositories
Publication of CA
information
DOEGrids PKI will operate a secure online repository that
contains:
DOEGrids CAs certificate;
Certificates issued by the PKI;
A Certificate Revocation List;
A copy of this policy;
Other information deemed relevant to the DOEGrids PKI.
RFC 2527:
2.1.5, 2.6
IGTF Classic: 6 (general)
DOEGrids v2.10: 2.6.1
An
identification of the entity or entities that operate repositories within the
PKI, such as a CA, certificate manufacturing authority, or independent
repository service provider.
Repositories
Repository of certificates and CRLs can be found in the
services LDAP directory: LDAP.DOEGrids.org or on its Web site at www.DOEGrids.org:
CA certificate:
ldap://ldap.doegrids.org/
CN=DOEGrids CA 1, OU=Certificate Authorities, DC=DOEGrids, DC=org :
cacertificate: <attribute value>
http://www.doegrids.org/CA/DOEGrids%20CA%201
CRLs:
ldap://ldap.doegrids.org/
CN=DOEGrids CA 1, OU=Certificate Authorities, DC=DOEGrids, DC=org:
certificaterevocationlist: <attribute value>
http://crl.doegrids.org/1c3f2ca8/1c3f2ca8.r0
http://pki1.doegrids.org/CRL/1c3f2ca8.r0
CP/CPS:
http://www.doegrids.org/CA/DOEGrids%20CA%201/Certificate%20Policy.pdf
Third-party repositories are maintained by the EUGridPMA
(www.EUGridPMA.org) and TERENA Academic
CA Repository (http://www.tacar.org/).
These repositories maintain trusted copies of the following information:
ESnet Root CA certificate
DOEGrids CA certificate
Links to the CRLs for each CA
Links to ESnets CP/CPS.
RFC 2527:
2.6.4
IGTF
Classic: 6 (general)
DOEGrids:
2.6.4
The responsibility of a PKI participant to publish
information regarding its practices, certificates, and the current status of
such certificates, which may include the responsibilities of making the CP or
CPS publicly available using various mechanisms and also of identifying
components, subcomponents, and elements of such documents that exist but are
not made publicly available due to their sensitivity (e.g., security controls,
clearance procedures, or trade secret information).
RFC 2527:
2.6.1, 8.2
When
information must be published and the frequency of publication.
Frequency of Publication
Certificates will be published to the DOEGrids PKI repository as
soon as issued.
CRLs will be published as soon as issued, and the CRL is also
refreshed once daily, with nextUpdate set to +30 days.
All DOEGrids PKI documents will be published to the project Web
site as they are updated.
RFC 2527:
2.6.2, 8.2
DOEGrids
v2.10: 2.6.2
Access
control on published information objects including CPs, CPS, certificates, certificate
status, and CRLs.
Access Controls
The online repository is available on a substantially 24/7
basis, subject to reasonable scheduled maintenance.
DOEGrids PKI does not impose any access control on its
policy, its signing certificate and issued certificates, and its CRLs. In the
future, DOEGrids PKI may impose access controls on issued certificates, their
status information and CRLs at its discretion, subject to agreement between the
CA, relying parties, and subscribers.
RFC 2527:
2.6.3
DOEGrids
v2.10: 2.6.3
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)
This
subcomponent includes the following elements regarding naming and
identification of the subscribers.
RFC 2527:
3.1
Types of
names assigned to the subject, such as X.500 distinguished names, RFC 822 names,
and X.400 names.
Name components vary depending on
the type of certificate. Names will be consistent with the name requirements
specified in RFC2459. See Section 7.1.3 for more details.
RFC 2527:
3.1.1
DOEGrids
v2.10: 3.1.1
Whether
names have to be meaningful or not.
Name Meanings
For individuals, the value of the CN component of the DN
has no semantic significance. It should have a reasonable association with the
authenticated name of the subscriber. For hosts or services, the CN component
has a structure that is defined to support SSL/TLS and Globus software. It should
include the Fully Qualified Domain Name (FQDN) of the host.
RFC 2527:
3.1.2
DOEGrids
v2.10: 3.1.2
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.
RFC 2527:
3.1.2
Rules for
interpreting various name forms, such as the X.500 standard and RFC822.
RFC 2527:
3.1.3
Whether
names have to be unique.
The Distinguished Name (DN) must be unique for each
subject name certified by the DOEGrids PKI.
For person certificates, each CN component will include
the full name of the subscriber as determined by the Virtual
Organization/sites 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. Certificates must apply to unique
individuals or resources. Private keys associated with person certificates may
not be shared between people.
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.
RFC 2527:
3.1.4
DOEGrids
v2.10: 3.1.3
RFC 2527:
3.1.5, 3.1.6
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
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 individuals Web browser reads on the CAs 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
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 organizations articles of incorporation.
See next
section.
RFC 2527:
3.1.8
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.
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.
RFC 2527:
3.1.9
DOEGrids
v2.10: 3.1.5
List of
subscriber information that is not verified (called non-verified subscriber
information) during the initial registration.
RFC 2527:
N/A
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
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
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
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.
Routine Re-key
DOEGrids Replacement certificate interfaces and
is used by subscribers to replace expiring certificates, and this interface
requires re-key.
RFC 2527:
3.2
DOEGrids
v2.10: 3.2
Identification
and authentication requirements for re-key after certificate revocation. One
example is the use of the same process as the initial identity validation.
Re-key After Revocation
Re-key after revocation follows the same rules as an
initial registration.
RFC 2527:
3.3
DOEGrids
v2.10: 3.3
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.
Revocation Request
See Section 4.9.2 for details on who can request a
certificate revocation.
RFC 2527:
3.4
DOEGrids v2.10: 3.4
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
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 VOs or sites 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
RFC 2527:
4.1
RFC 2527:
4.1, 2.1.3
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
RFC 2527:
4.1, 4.2
RFC 2527:
4.1, 4.2
Certificate Request Cancellation
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
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 requestors 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
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
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
No stipulation.
RFC 2527:
4.3, 2.1.3
DOEGrids
v2.10: 4.4
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
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
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
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
Subscriber
responsibilities relating to use of the subscribers 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
Relying
party responsibilities relating to the use of a subscribers 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
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 participants public key or
any other information in the certificate.
RFC 2527:
4.1, 4.2, 4.3, 3.2
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.
RFC 2527:
4.1, 3.2
Who may
request certificate renewal, for instance, the subscriber, RA, or the CA may
automatically renew an end-user subscriber certificate.
RFC 2527:
4.1, 3.2
A CA or
RAs 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
RFC 2527:
4.2, 4.3, 3.2
RFC 2527:
4.3, 2.1.3, 3.2
RFC 2527:
4.3, 2.1.5, 2.6.1, 3.2
RFC 2527:
4.2, 4.3, 2.1.5, 2.6.1, 3.2
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.
RFC 2527:
4.1, 4.2, 4.3, 3.2
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.
RFC 2527:
4.1, 3.2
Who may
request certificate re-key, for example, the subscriber.
RFC 2527:
4.1, 3.2
A CA or
RAs 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
RFC 2527:
4.2, 4.3, 3.2
RFC 2527:
4.3, 2.1.3, 3.2
RFC 2527:
4.3, 2.1.5, 2.6.1, 3.2
RFC 2527:
4.2, 4.3, 2.1.5, 2.6.1, 3.2
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
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
Who may
request certificate modification, for instance, subscribers, human resources
personnel, or the RA.
RFC 2527:
4.4.2
RFC 2527:
4.4.3
A CA or
RAs 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
RFC 2527:
4.3, 4.4.3, 2.1.3
RFC 2527:
4.2, 4.3, 4.4.3, 2.1.5, 2.6.1
RFC 2527:
4.2, 4.3, 4.4.3, 2.1.5, 2.6.1
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 subscribers private key is lost or suspected to be
compromised;
The information in the subscribers 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.
The CA managers will revoke certificates whose e-mail
address is nonfunctional for 30 days. They will make a best effort attempt to
notify the RA when the first bounce of the e-mail address occurs.
RFC 2527:
4.9
DOEGrids
v2.10: 4.2, 4.5.1
Who can
request the revocation of the participants 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
subscribers 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 CAESnet, 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 CAESnet, LBNL, DOE.
The subscriber may revoke (or request revocation of) the
subscribers own certificate for any reason at any time.
RFC 2527:
4.4.2
DOEGrids
v2.10: 4.5.1, 4.5.2
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.
The entity requesting the revocation must authenticate
itself to the DOEGrids PKI or the VOs RA staff, which must use the same
procedures used for the authentication of identity of a person. The RA that
issued the certificate will be notified immediately about the revocation
request and will be granted one business day to resolve any uncertainties about
the circumstances causing the revocation request, except in cases where the CA
managers determine that a revocation grace period will cause damage to relying
parties.
RFC 2527:
4.4.3, 2.1.3
DOEGrids
v2.10: 4.5.3
The grace
period available to the subscriber, within which the subscriber must make a
revocation request;
RFC 2527:
4.4.4
RFC 2527:
N/A
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;
RFC 2527:
4.4.10, 4.4.12, 4.4.14, 2.1.4
If a CRL
mechanism is used, the issuance frequency;
CRLs are issued after every certificate revocation and
issued periodically even if there are no changes.
RFC 2527:
4.4.9, 4.8.3
DOEGrids
v2.10: 4.5.5
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);
RFC 2527:
4.4.9
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
Requirements
on relying parties to perform online revocation/status checks;
No stipulation.
RFC 2527:
4.4.12
DOEGrids
v2.10: 4.5.7
No stipulation.
RFC 2527:
4.4.13, 4.4.14, 4.8.3
DOEGrids
v2.10: 4.5.8
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
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
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
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
How long
the suspension may last.
RFC 2527:
4.4.8
This
subcomponent addresses the certificate status-checking services available to
the relying parties.
RFC 2527:
4.4.9-4.4.14
The
operational characteristics of certificate status-checking services.
RFC 2527:
4.4.9, 4.4.11, 4.4.13
The availability
of such services, and any applicable policies on unavailability.
RFC 2527:
4.4.9, 4.4.11, 4.4.13
Any
optional features of such services.
RFC 2527:
4.4.9, 4.4.11, 4.4.13
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
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).
Private Key Escrow
Not supported.
RFC 2527:
6.2.3
DOEGrids
v2.10: 6.2.2
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
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
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.
RFC 2527:
4.5, 5
IGTF
Classic: 5 (general)
In this
subcomponent, the physical controls on the facility housing the entity systems
are described.
RFC 2527:
5.1
DOEGrids
v2.10: 5.1
Site
location and construction, such as the construction requirements for
high-security zones and the use of locked rooms, cages, safes, and cabinets;
Physical Security Controls
The DOEGrids PKI is located at Lawrence Berkeley National
Laboratory (LBNL) in the ESnet Data Center. All servers are Sun Solaris
systems. Security on these systems is maintained and configured to highest
level provided for by Sun. All security patches will be applied as soon as
they are released by Sun and verified by the ESnet support staff. The DOEGrids
PKI servers are located behind a Cisco Pix Firewall. The entire server farm
will be monitored by the Bro intrusion detection system.
RFC 2527:
5.1.1
DOEGrids
v2.10: 5.1
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 PKI security
officers and system support staff of ESnet.
RFC 2527:
5.1.2
DOEGrids
v2.10: 5.1
RFC 2527:
5.1.3
RFC 2527:
5.1.4
RFC 2527:
5.1.5
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
RFC 2527:
5.1.7
RFC 2527:
5.1.8
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.
No stipulation.
RFC 2527:
5.2
DOEGrids
v2.10: 5.2
RFC 2527:
5.2.1
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.
RFC 2527:
5.2.2
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
RFC 2527:
5.2.1, 5.2.2
Personnel Security
Controls
All access to the servers and applications that comprise
the DOEGrids PKI is limited to DOEGrids PKI security officer and the ESnet
system support staff.
RFC 2527:
5.3
DOEGrids
v2.10: 5.3
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.
RFC 2527:
5.3.1
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;
RFC 2527:
5.3.2
Training
requirements and training procedures for each role following the hiring of
personnel.
RFC 2527:
5.3.3
Any
retraining period and retraining procedures for each role after completion of
initial training.
RFC 2527:
5.3.4
Frequency
and sequence for job rotation among various roles.
RFC 2527:
5.3.5
Sanctions
against personnel for unauthorized actions, unauthorized use of authority, and
unauthorized use of entity systems for the purpose of imposing accountability
on a participants personnel.
RFC 2527:
5.3.6
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
Documentation
to be supplied to personnel during initial training, retraining, or otherwise.
RFC 2527:
5.3.8
This
subcomponent is used to describe event logging and audit systems, implemented
for the purpose of maintaining a secure environment.
RFC 2527:
4.5
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;
RFC 2527:
4.5.1
DOEGrids
v2.10: 4.7.1
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
Period
for which audit logs are kept.
Retention Period for Archives
Minimum retention period is three years.
RFC 2527:
4.5.3
DOEGrids
v2.10: 4.7.2
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.
RFC 2527:
4.5.4
RFC 2527:
4.5.5
Whether
the audit log accumulation system is internal or external to the entity.
RFC 2527:
4.5.6
Whether
the subject who caused an audit event to occur is notified of the audit action.
RFC 2527:
4.5.7
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
This
subcomponent is used to describe general records archival (or records
retention) policies.
RFC 2527:
4.6
Types of records that are archived, for example, all audit
data, certificate application information, and documentation supporting certificate
applications.
RFC 2527:
4.6.1
RFC 2527:
4.6.2
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.
RFC 2527:
4.6.3
RFC 2527:
4.6.4
RFC 2527:
4.6.5
Whether
the archive collection system is internal or external.
RFC 2527:
4.6.6
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
This
subcomponent describes the procedures to provide a new public key to a CAs
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.
No stipulation.
RFC 2527:
4.7
DOEGrids
v2.10: 4.8
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.
If the CAs private key isor is suspected to
becompromised, the CA will:
1. Inform
subscribers and subordinate RAs;
Terminate the certificates and CRL
distribution services for certificates and CRLs issued using the compromised
key.
RFC 2527:
4.8
DOEGrids
v2.10: 4.9
Identification
or listing of the applicable incident and compromise reporting and handling
procedures.
RFC 2527:
4.8
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.
RFC 2527:
4.8.1
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.
RFC 2527:
4.8.3
The
entitys 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.
RFC 2527:
4.8.4
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.
CA Termination
Before DOEGrids PKI terminates its services, it will:
1. Inform
subscribers and subordinate RAs;
2. Make
widely available information of its termination;
3. Stop
issuing certificates and CRLs;
4. Destroy
its private keys and all copies.
RFC 2527:
4.8.9
DOEGrids
v2.10: 4.10
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.
RFC 2527:
6, 2.1.3, 2.1.4
IGTF Classic: 4 (general)
Key pair
generation and installation need to be considered for the issuing CA,
repositories, subject CAs, RAs, and subscribers.
RFC 2527:
6.1
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.
Hardware/Software Key
Generation
No stipulation.
RFC 2527: 6.1.6, 6.1.7
DOEGrids v2.10: 6.1.8
RFC 2527:
6.1.1, 6.1.8
DOEGrids
v2.10: 6.1.1
Private Key Delivery to
Entity
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 their subscribers through an auditable process.
RFC 2527:
6.1.2
DOEGrids
v2.10: 6.1.2
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
In the
case of issuing CAs, how is the CAs 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 Public Key Delivery to
Users
CA certificate is delivered by an online transaction from
a secure Web server or by other out-of-band secure process.
RFC 2527:
6.1.4
DOEGrids
v2.10: 6.1.4
What are
the key sizes? Examples include a 1024-bit RSA modulus and a 1024-bit DSA
large prime.
Keys of length of less than 1024
bits will not be signed.
RFC 2527:
6.1.5
DOEGrids
v2.10: 6.1.5
Who
generates the public key parameters, and is the quality of the parameters
checked during key generation?
Public Key Parameters
Generation/Parameter Quality Checking
No stipulation.
RFC 2527:
6.1.6, 6.1.7
DOEGrids
v2.10: 6.1.6, 6.1.7
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.
Key Usage Purposes
DOEGrids certificates are only
warranted for authentication and signing proxy certificates [Proxy].
The ESnet root CA private key
will only be used to sign subordinate CAs. The DOEGrids online CA
signing key is the only key that will be used for signing CRLs and certificates
for persons, services.
The certificate Key Usage field must be used in accordance
with RFC2459.
RFC 2527:
6.1.9
DOEGrids
v2.10: 6.1.9
Requirements
for private key protection and cryptographic modules need to be considered for
the issuing CA, repositories, subject CAs, RAs, and subscribers.
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.
Cryptographic Module Engineering
Controls
DOEGrids CA signing private key
is managed by an nCipher FIPS-140 compliant 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 managed by a set of
smart cards.
The keys for these smart cards,
and the 3DES key used to encrypt the signing private key, are generated by the
nCipher nShield FIPS-140 device (key generation is based on a hardware random
number generator). Access to these keys is only available through a set of
administrator smart cards. Several copies of cards have been created and stored
in secure locations.
RFC 2527:
6.2.1, 6.8
DOEGrids
v2.10: 6.8
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)?
Not supported.
RFC 2527:
6.2.2
DOEGrids
v2.10: 6.2.1
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
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?
There
is no support for private key backup for end-entity certificates.
RFC
2527: 6.2.4
DOEGrids
v2.10: 6.2.3
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?
Private Key Archival and Backup
There is no support for private
key archival for end-entity certificates.
RFC 2527:
6.2.5
DOEGrids
v2.10: 6.2.3
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)?
RFC 2527:
6.2.6
How is
the private key stored in the module (i.e., plaintext, encrypted, or split
key)?
RFC 2527:
6.2.6
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?
RFC 2527:
6.2.7
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.
RFC 2527:
6.2.8
Who can
destroy the private key and how? Examples of methods of destroying private
keys include token surrender, token destruction, and overwriting the key.
RFC 2527:
6.2.9
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.
RFC 2527:
6.2.1, 6.8
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 certificates
current validity period is
5 December, 2002 to 25 January, 2013.
RFC 2527:
6.3
DOEGrids
v2.10: 6.3
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.
RFC 2527:
6.3.1
What is
the operational period of the certificates issued to the subscriber. What are
the usage periods, or active lifetimes, for the subscribers key pair?
RFC 2527:
6.3.2
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.
DOEGrids CA private key is protected by a pass
phrase.
DOEGrids CA signing key is
protected by a 3DES key. This key is known only to a set of operator smart
cards (the Operator Card Set or OCS), which are unlocked by pass phrases
individually assigned to each card.
RFC 2527:
6.4
DOEGrids
v2.10: 6.4
RFC 2527:
6.4.1
RFC 2527:
6.4.2
RFC 2527:
6.4.3
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.
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
No stipulation.
RFC 2527:
6.5.2
DOEGrids
v2.10: 6.5.2
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
Institutes Capability Maturity Model (SEI-CMM).
No stipulation.
RFC 2527:
6.6
DOEGrids
v2.10: 6.6
RFC 2527:
6.6.1
RFC 2527:
6.6.2
RFC 2527:
6.6.3
This
subcomponent addresses network security-related controls, including firewalls.
DOEGrids will maintain an online CA for issuing
certificates authorized by the DOEGrids RAs.
The DOEGrids PKI servers
are located behind a Cisco Pix Firewall. The entire
server farm will be monitored by ESnet intrusion detection services.
RFC 2527:
6.7
DOEGrids
v2.10: 6.7
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.
RFC 2527: N/A
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.
RFC 2527:
7.1
IGTF Classic: 4 (general)
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
Version Number
X.509 v3.
RFC 2527:
7.1.1
DOEGrids
v2.10: 7.1.1
This section must follow the minimum requirements as stated
in Section 1.1.
Basic Constraints (Critical)
not a CA (default configuration; ASN.1 compiler removes default empty
sequences)
Netscape Certificate Type
SSL Client (all); SSL Server (host or service); secure
e-mail (optional, person)
Key Usage (Critical)
Digital Signature, Non-repudiation, Key Encipherment (all); Data Encipherment
(service only)
Authority Key
Identifier
Subject Alternative Name
dnsName (service certificates)
RFC822name (DN owners e-mail address; can be individual
or group address)
CRL Distribution Points
Certificate Policies OID
RFC 2527:
7.1.2
DOEGrids
v2.10: 7.1.2
No stipulation.
RFC 2527:
7.1.3
DOEGrids
v2.10: 7.1.3
The X.509 character set is case insensitive. But in some
situations, software being used to interpret these fields does interpret the name
forms as case sensitive. To ensure proper operation, relying parties must make
sure the case used in Globus map files matches the case of issued
certificates. Until uniform interpretation of case is deployed, it is strongly
recommended that we follow the case conventions that are used in the examples
below.
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 5 random alphanumeric
characters added for uniqueness. (i.e. John K. Doe 1W2D3):
CN= John K. Doe 1W2D3; 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= george.lbl.gov; 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/george.lbl.gov; OU=Services; DC= doegrids; DC=org
o
CN= FTP/131.243.2.12; OU=Services; DC= doegrids; DC=org
o
CN= george.lbl.gov; OU=Services; DC= doegrids; DC=org
RFC 2527:
7.1.4
DOEGrids
v2.10: 7.1.4
Not supported
RFC 2527:
7.1.5
DOEGrids
v2.10: 7.1.5
OID:
[ESnet].ERmember.DOEGrids.CP-CPS.CPVersionNumber.CPReleaseNumber
RFC 2527:
7.1.6
DOEGrids
v2.10: 7.1.6
No stipulation.
RFC 2527:
7.1.7
DOEGrids
v2.10: 7.1.7
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
RFC 2527:
7.1.9
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
CRL and
CRL entry extensions populated and their criticality.
The CRL is using version 2 extensions for the CRL and
entries. It will contain the CRL number, Critical, and Number. The CRL
extension example:
Extensions:
Identifier: CRL Number - 2.5.29.20
Critical: no
Number: 412
The individual entry on the CRL will include: Serial
Number, Revocation Date, Revocation Reason, and Invalidity Date. Invalidity
Date is the date the relying party should consider the certificate was no
longer valid. This date maybe earlier than the revocation date. The following
is an example of an entry on the DOEGrids CRL:
Serial Number: 0x58D of the certificate
Revocation Date: Wednesday, January 21,
2004 3:56:10 PM PST
Extensions:
Identifier: Revocation Reason -
2.5.29.21
Critical: no
Reason: Superseded
Identifier: Invalidity Date -
2.5.29.24
Critical: no
Invalidity Date: Wed Jan 21 00:00:00
PST 2004
RFC 2527:
7.2.1
DOEGrids
v2.10 2527: 7.2.2
This
subcomponent addresses such topics as the following (potentially by reference
to a separate profile definition, such as the IETF RFC 2560 profile).
RFC 2527:
N/A
Version
of OCSP that is being used as the basis for establishing an OCSP system.
RFC 2527:
N/A
OCSP
extensions populated and their criticality.
RFC 2527:
N/A
The list
of topics covered by the assessment and/or the assessment methodology used to
perform the assessment; examples include WebTrust for CAs and SAS 70.
The DOEGrids PKI is not audited by an outside party. The CA operation may be
reviewed by any cross-certifying organization or potential relying organization
if approved by the PMA. DOEGrids CA operations is audited as part of the
Lawrence Berkeley National Laboratorys FIPS-199 NIST 800-53 compliance audits
on a schedule prescribed by the US Department of Energy. In, addition, DOEGrids CA operations is a component of security and program peer reviews of ESnet, on a
multi-year periodic basis. DOEGrids CA and PKI is also audited by community
members according to the IGTF approved auditing standards, on a multiyear
periodic basis.
RFC 2527:
4.8
IGTF
Classic: 7 (general)
DOEGrids
v2.10 2.7
Frequency
of compliance audit or other assessment for each entity that must be assessed
pursuant to a CP or CPS, or the circumstances that will trigger an assessment;
possibilities include an annual audit, pre-operational assessment as a
condition of allowing an entity to be operational, or investigation following a
possible or actual compromise of security.
RFC 2527:
2.7.1
The
identity and/or qualifications of the personnel performing the audit or other
assessment.
RFC 2527:
2.7.2
The
relationship between the assessor and the entity being assessed, including the
degree of independence of the assessor.
RFC 2527:
2.7.3
RFC 2527:
2.7.4
Actions
taken as a result of deficiencies found during the assessment; examples include
a temporary suspension of operations until deficiencies are corrected,
revocation of certificates issued to the assessed entity, changes in personnel,
triggering special investigations or more frequent subsequent compliance
assessments, and claims for damages against the assessed entity.
RFC 2527:
2.7.5
Who is
entitled to see results of an assessment (e.g., assessed entity, other
participants, the general public), who provides them (e.g., the assessor or the
assessed entity), and how they are communicated.
RFC 2527:
2.7.6
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 CAs
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)
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
RFC 2527:
2.5.1
RFC 2527:
2.5.2
RFC 2527:
2.5.3
Fees for
other services, such as providing access to the relevant CP or CPS.
RFC 2527:
2.5.4
RFC 2527:
2.5.5
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
A
statement that the participant maintains a certain amount of insurance coverage
for its liabilities to other participants.
RFC 2527:
2.3
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
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
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.
Confidentiality
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
The scope
of what is considered confidential information.
RFC 2527:
2.8.1, 2.8.3
The types
of information that are considered to be outside the scope of confidential
information.
RFC 2527:
2.8.2, 2.8.3
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.32.8.7
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.
RFC 2527:
2.8
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
Information
that is considered private within the PKI.
RFC 2527:
2.8.1, 2.8.3
Information
that is not considered private within the PKI.
RFC 2527:
2.8.2, 2.8.3
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
Any
requirements as to notices to, or consent from individuals regarding use or
disclosure of private information.
RFC 2527:
N/A
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
RFC 2527:
2.8.6, 2.8.7
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.
Parts of this document are inspired by [INFN CP],
[GridCP], [EuroPKI], [TrustID], [NCSA], [PAG], and [FBCA].
RFC 2527:
2.9
DOEGrids
v2.10: 2.9
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 CAs 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 CAs 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
RFC 2527: 2.2.1
RFC 2527:
2.2.2
RFC 2527:
2.1.3
RFC 2527: 2.1.4
RFC 2527:
N/A
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
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.
Liability
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
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 partys 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 subscribers 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
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
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:
N/A
Termination
provisions stating circumstances under which the document, certain portions of
it, or its application to a particular participant ceases to remain in effect.
RFC 2527:
N/A
Any
consequences of termination of the document. For example, certain provisions
of an agreement may survive its termination and remain in force. Examples
include acknowledgments of intellectual property rights and confidentiality
provisions. Also, termination may trigger a responsibility of parties to return
confidential information to the party that disclosed it.
RFC 2527:
N/A
This
subcomponent discusses the way in which one participant can or must communicate
with another participant on a one-to-one basis in order for such communications
to be legally effective. For example, an RA may wish to inform the CA that it
wishes to terminate its agreement with the CA. This subcomponent is different
from publication and repository functions, because unlike individual
communications described in this subcomponent, publication and posting to a
repository are for the purpose of communicating to a wide audience of
recipients, such as all relying parties. This subcomponent may establish
mechanisms for communication and indicate the contact information to be used to
route such communications, such as digitally signed e-mail notices, to a
specified address, followed by a signed e-mail acknowledgment of receipt.
RFC 2527:
2.4.2
It will
occasionally be necessary to amend a CP or CPS. Some of these changes will not
materially reduce the assurance that a CP or its implementation provides, and
will be judged by the policy administrator to have an insignificant effect on
the acceptability of certificates. Such changes to a CP or CPS need not
require a change in the CP OID or the CPS pointer (URL). On the other hand,
some changes to a specification will materially change the acceptability of
certificates for specific purposes, and these changes may require corresponding
changes to the CP OID or CPS pointer qualifier (URL).
RFC 2527:
8.1
The
procedures by which the CP or CPS and/or other documents must, may be, or are
amended.
RFC 2527:
8.1
In the
case of CP or CPS amendments, change procedures may include a notification
mechanism to provide notice of proposed amendments to affected parties, such as
subscribers and relying parties, a comment period, a mechanism by which
comments are received, reviewed and incorporated into the document, and a
mechanism by which amendments become final and effective.
RFC 2527:
8.1
The
circumstances under which amendments to the CP or CPS would require a change in
CP OID or CPS pointer (URL).
RFC 2527:
8.1
This
subcomponent discusses procedures utilized to resolve disputes arising out of
the CP, CPS, and/or agreements. Examples of such procedures include
requirements that disputes be resolved in a certain forum or by alternative
dispute resolution mechanisms.
RFC 2527:
2.4.3
This
subcomponent sets forth a statement that the law of a certain jurisdiction
governs the interpretation and enforcement of the subject CP or CPS or
agreements.
Interpretation and Enforcement/Governing Law
0This policy is subordinate to
all applicable U.S. government laws, as well as Department of Energy (DOE)
orders and Lawrence Berkeley National Laboratory management directives.
RFC 2527:
2.4.1
DOEGrids v2.10: 2.4.1
This
subcomponent relates to stated requirements that participants comply with
applicable law, for example, laws relating to cryptographic hardware and
software that may be subject to the export control laws of a given
jurisdiction. The CP or CPS could purport to impose such requirements or may
require that such provisions appear in other agreements.
RFC 2527:
2.4.1
This
subcomponent contains miscellaneous provisions, sometimes called boilerplate
provisions, in contracts. The clauses covered in this subcomponent may appear
in a CP, CPS, or agreements.
RFC 2527:
2.4
An entire
agreement clause, which typically identifies the document or documents
comprising the entire agreement between the parties and states that such
agreements supersede all prior and contemporaneous written or oral
understandings relating to the same subject matter.
RFC 2527:
2.4.2
An
assignment clause, which may act to limit the ability of a party in an
agreement, assigning its rights under the agreement to another party (such as
the right to receive a stream of payments in the future) or limiting the
ability of a party to delegate its obligations under the agreement.
RFC 2527:
N/A
A
severability clause, which sets forth the intentions of the parties in the
event that a court or other tribunal determines that a clause within an
agreement is, for some reason, invalid or unenforceable, and whose purpose is
frequently to prevent the unenforceability of one clause from causing the whole
agreement to be unenforceable.
RFC 2527:
2.4.2
An
enforcement clause, which may state that a party prevailing in any dispute
arising out of an agreement is entitled to attorneys fees as part of its
recovery, or may state that a partys waiver of one breach of contract does not
constitute a continuing waiver or a future waiver of other breaches of
contract.
RFC 2527:
2.4.3
A force
majeure clause, commonly used to excuse the performance of one or more parties
to an agreement due to an event outside the reasonable control of the affected
party or parties. Typically, the duration of the excused performance is
commensurate with the duration of the delay caused by the event. The clause
may also provide for the termination of the agreement under specified
circumstances and conditions. Events considered to constitute force majeure
may include so-called acts of God, wars, terrorism, strikes, natural
disasters, failures of suppliers or vendors to perform, or failures of the
Internet or other infrastructure. Force majeure clauses should be drafted so
as to be consistent with other portions of the framework and applicable service
level agreements. For instance, responsibilities and capabilities for business
continuity and disaster recovery may place some events within the reasonable
control of the parties, such as an obligation to maintain backup electrical
power in the face of power outages.
RFC 2527:
N/A
This
subcomponent is a catchall location where additional responsibilities and
terms can be imposed on PKI participants that do not neatly fit within one of
the other components or subcomponents of the framework. CP and CPS writers can
place any provision within this subcomponent that is not covered by another
subcomponent.
RFC 2527:
N/A
This
section identifies the sections of this CP/CPS document that address the
corresponding requirements set out in IGTFs minimum requirements document
(currently version 4.1-b3) for traditional X.509 Certification Authorities
issuing long-term credentials (the classic profile) [CCA06]. Appropriate
extracts of the document are highlighted in blue
below.
2. General Architecture
There
should be a single Certification Authority (CA) organization per country, large
region or international organization.
Section 1.3
To
achieve sustainability, it is expected that the CAs will be operated as a
long-term commitment by institutions or organizations rather than being bound
to specific projects.
Section 1.1
The CA
structure within each region should not follow the conventional hierarchical
model, but there should be a single end-entity-issuing CA. A wide network of Registration
Authorities (RA) for each CA is preferred.
Sections 1.1 and 4.1.1
The RAs
will handle the tasks of validating the identity of the end entities and
authenticating their requests, which will then be forwarded to the CA. The CA
will handle the actual tasks of issuing CRLs, signing Certificates/CRLS and
revoking Certificates.
Sections 1.3.2, 4.2.1, 9.6.1 and 9.6.2
3. Identity
Any single-subject distinguished
name must be linked to one and only one entity.
Sections 1.3.3 and 3.1.5
Over the entire lifetime of the CA,
it must not be linked to any other entity.
Sections 1.3.3 and 3.1.5
Certificates must not be shared
among end entities.
Section 3.1.5
3.1 Identity Verifying Rules
A PKI CA
must define the role of registration authority (RA), and these registration
authorities are responsible for the identity verifying of all end entities,
such as natural persons and network entities.
Sections 3.2.3 and 4.2.1
In order
for an RA to validate the identity of a person, the subject should contact the
RA face to face and present photo ID and/or valid official documents showing
that the subject is an acceptable end entity as defined in the CP/CPS document
of the CA.
Section 3.2.3
In case
of host or service certificate requests, the RA should validate the identity of
the person in charge of the specific entities, using a secure method. The RA
must ensure that the requestor is appropriately authorized by the owner of the
FQDN or the responsible administrator of the machine to use the FQDN
identifiers asserted in the certificate.
Sections 3.2.3 and 3.2.5
The RA must validate the
association of the certificate-signing request.
Section 3.2.3
The RAs must record and archive all
requests and confirmations.
Section 3.2.3
The CA is responsible for the
continued archival and auditability of these records.
Section 3.2.3
The RA must communicate with the CA with
secure methods that are clearly defined in the CP/CPS (e.g., signed e-mails,
voice conversations with a known person, SSL protected private Web pages that
are bi-directionally authenticated).
Section 3.2.3
The CP/CPS should describe how the RA or
CA is informed of changes that may affect the status of the certificate.
Sections 3.4, 4.2.1, 4.3.2 and 6.1.3
In all cases, the certificate request
submitted for certification must be bound to the act of identity verifying.
Section 3.2.3
3.2 End-entity certificate expiration, renewal and re-keying
For
credentials based on software tokens, credentials should only be re-keyed, not
renewed.
Sections 4.6.1 and 4.7.1
For
those based on hardware tokens, these may be renewed for a period of up to five
years (for equivalent RSA key lengths of 2,048 bits) or three years (for
equivalent RSA key lengths of 1024 bits).
Section 4.6.1
No
credentials can be renewed or re-keyed for more than five years without a form
of identity and eligibility verification, and this procedure must be described
in the CP/CPS.
Sections 3.3.1, 4.6.1, 4.6.3 and 4.7.3
4. Operational Requirements
The CA
computer, where the signing of the certificates will take place, needs to be a dedicated
machine, running no other services than those needed for the CA operations.
Sections 4.3.1, 6.5.1 and 6.7
The CA
computer must be located in a secure environment where access is controlled,
limited to specific trained personnel.
Section 5.1.2
The CA computer may be
completely off-line:
kept disconnected from any kind of networks at all times.
HSM hardware
security key management
Sections 5.1 and 6.7
The CA key must have a minimum
length of 2048 bits.
Section 5.1.2
For CAs
that issue end-entity certificates, the lifetime must be no less than two times
of the maximum life time of an end-entity certificate and should not be more
than 20 years.
Section 6.3.2
The
private key of the CA must be protected with a pass phrase of at least 15
elements that is known only by specific personnel of the Certification
Authority, except in the case of a Hardware Security Management (HSM), where an
equivalent level of security must be maintained.
Sections 6.2.1 and 6.4.1
Copies
of the encrypted private key must be kept on offline mediums in secure places
where access is controlled.
Section 5.1.6, 6.2.4 and 6.2.7
4.2 Certificate Policy and Certification Practice Statement
Identification
Every CA
must have a Certificate Policy and Certification Practice Statement (CP/CPS
Document) and assign it a globally unique object identifier (OID).
Section 1.2
CP/CPS
documents should be structured as defined in RFC 3647.
Section 1
Whenever
there is a change in the CP/CPS, the OID of the document must change and the
major changes must be announced to the accrediting PMA and approved before
signing any certificates under the new CP/CPS.
Sections 1.2, 2.3 and 9.12.3
All the
CP/CPS under which valid certificates are issued must be available on the Web.
Section 2.2
4.3 Certificate and CRL Profile
The accredited authority must
publish a X.509 certificate as a root of trust.
Sections 2.2 and 4.10.1
The CA
certificate must have the extensions keyUsage and basicConstraints marked as
critical.
Section 7.1.2
The
authority shall issue X.509 certificates to end entities based on cryptographic
data generated by the applicant, or based on cryptographic data that can be
held only by the applicant on a secure hardware token.
Sections 6.1.1, 6.1.2, 6.1.7 and 7.1
The EE
keys must be at least 1024 bits long. The EE certificates must have a maximum
lifetime of 1 year plus 1 month.
Sections 6.1.5 and 6.3.2
The
end-entity certificates must be in X.509v3 format and compliant with RFC 3280,
unless explicitly stated otherwise. In the certificate extensions:
a Policy Identifier must be included and
must contain an OID and an OID only
CRL Distribution Points must be included
and contain at least one http URL
keyUsage must be included and marked as
critical
basicConstraints should be included, and
when included it must be set to CA: false and marked as critical
if an OCSP responder, operated as a
production service by the issuing CA, is available, AuthorityInfoAccess must be
included and contain at least one URL
for certificates bound to network
entities, a FQDN shall be included as a dnsName in the SubjectAlternativeName
Sections 6.1.7, 7.1 and 7.1.2
If a commonName
component is used as part of the subject DN, it should contain an appropriate
presentation of the actual name of the end entity.
Section 3.1.2
The CRLs must be compliant with RFC
3280, and are recommended to be version 2.
Section 7.2.1
The
message digests of the certificates and CRLs must be generated by a trustworthy
mechanism, like SHA1 (in particular, MD5 must not be used).
Section 7.1.3
4.4 Revocation
The CA must publish a CRL.
Section 2.2
The CA
must react as soon as possible, but within one working day, to any revocation
request received.
Section 4.9.5
After determining its validity, a
CRL must be issued immediately.
Section 2.3
For CAs
issuing certificates to end entities, the maximum CRL lifetime must be at most
30 days, and the CA must issue a new CRL at least seven days before expiration
and immediately after a revocation.
Sections 2.3 and 4.9.7
The CRLs
must be published in a repository at least accessible via the World Wide Web,
as soon as issued.
Sections 2.2, 4.9.8 and 4.9.9
Revocation
requests can be made by end entities, Registration Authorities and the CA.
Sections 3.4 and 4.9.3
These
requests must be properly authenticated.
Sections 3.4 and 4.9.3
Others
can request revocation if they can sufficiently prove compromise or exposure of
the associated private key.
Sections 3.4 and 4.9.3
4.5 CA Key Changeover
When the
CAs cryptographic data needs to be changed, such a transition shall be
managed; from the time of distribution of the new cryptographic data, only the
new key will be used for certificate signing purposes. The overlap of the old
and new key must be at least the longest time an end-entity certificate can be
valid. The older but still valid certificate must be available to verify old
signaturesand the secret key to sign CRLsuntil all the certificates signed
using the associated private key have also expired.
Section 5.6
5. Site Security
The pass
phrase of the encrypted private key must be kept also on an offline medium,
separated from the encrypted keys and guarded in a safe place where only the
authorized personnel of the Certification Authority have access.
Sections 6.2.1, 6.2.4, 6.2.7 and 6.4.2
6. Publication and Repository Responsibilities
Each authority must publish for its
subscribers, relying parties and for the benefit of distribution by the PMA and
the federation
a CA root certificate or set of CA root
certificates up to a self-signed root;
a http or https URL of the Privacy-Enhanced
Mail (PEM)-formatted CA certificate;
a http URL of the PEM or Distinguished
Encoding Rules (DER)-formatted Certificate
Revocation List;
a http or https URL of the Web page of
the CA, for general information;
the CP and/or CPS documents;
an official contact e-mail address for
inquiries and fault reporting
a physical or postal contact address
Sections 2.1, 2.2 and 4.10.1
The CA
should provide a means to validate the integrity of its root of trust.
Furthermore,
the CA shall provide its trust anchor to a trust anchor repository, specified
by the accrediting PMA, via the method specified in the policy of the trust
anchor repository.
Sections 1.3.5 and 6.1.4
The
repository must be run at least on a best-effort basis, with an intended
continuous availability.
Sections 2.4 and 4.10.2
The
originating authority must grant to the PMA and the Federationby virtue of its
accreditationthe right of unlimited redistribution of this information.
Section 2.2
7. Audits
The CA
must record and archive all requests for certificates, along with all the
issued certificates, all the requests for revocation, all the issued CRLs and
the login/logout/reboot of the issuing machine.
Section 5.4.1
The CA
must keep these records for at least three years. These records must be made
available to external auditors in the course of their work as auditor.
Sections 5.4.3, 5.4.4, 5.5.2 and 5.5.3
Each CA
must accept being audited by other accredited CAs to verify its compliance with
the rules and procedures specified in its CP/CPS document.
Section 8.3
The CA
should perform operational audits of the CA/RA staff at least once per year. A
list of CA and RA personnel should be maintained and verified at least once per
year.
Section 8.1
8. Privacy and Confidentiality
Accredited
CAs must define a privacy and data release policy compliant with the relevant
national legislation.
Sections 9.4, 9.4.2, 9.4.3 and 9.4.7
The CA
is responsible for recording, at the time of validation, sufficient information
regarding the subscribers to identify the subscriber.
Section 3.2.3
The CA
is not required to release such information unless provided by a valid legal
request according to national laws applicable to that CA.
Section 4.9.6
9. Compromise and Disaster Recovery
9.1 Due Diligence
for End Entities
The CA should make a reasonable
effort to make sure that end entities realize the importance of properly
protecting their private data. When using software tokens, users are
responsible for protecting their private key with a strong pass phrase, i.e.,
at least 12 characters long and following current best practice in choosing
high-quality passwords.
Sections 4.1.2, 6.4.1 and 9.6.3
End entities
must request revocation as soon as possible, but within one working day after
detection of loss or compromise of the private key pertaining to the
certificate, or if the data in the certificate are no longer valid.
Sections 4.1.2, 4.9.2 and 9.6.3
EuroPKI: EuroPKI Certificate Policy, Version 1.1 (Draft 4), October
2000
FBCA CP: X.509 Certificate Policy for the Federal Bridge
Certification Authority (FBCA), Version 1.0, December 18, 1999
http://www.cio.gov/fpkipa/documents/FBCA_CP_RFC3647.pdf
GridCP: http://gridcp.es.net/ Global Grid Forum CP
IGTF Classic Profile:
Profile for Traditional X.509 Public Key Certification Authorities with Secured
Infrastructure, Version 4.0
http://www.eugridpma.org/guidelines/IGTF-AP-classic-20050930-4-0.html
INFN CP: http://security.fi.infn.it/CA/CPS/
INFN CA Policy and CPS.
NCSA: National Computational Science Alliance, Certificate
Policy, Version 0.9.1, June 30, 1999
NIST FIPS 140 document: 1999
http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf
OpenSSL: http://www.openssl.org/
PAG: American Bar Associations PKI Assessment Guidelines
("PAG") http://www.abanet.org/scitech/ec/isc/pag/pag.html
Proxy: Tueche, S., et al., Internet X.509 Public Key
Infrastructure Proxy Certificate Profile. 2001, IETF draft.
