William E. Johnston, Senior Scientist
Information and Computing Sciences Division
Lawrence Berkeley National Laboratory
1 Cyclotron Rd., B50B-2239, Berkeley, CA 94720
firstname.lastname@example.org; voice: 510-486-5014; fax: 510-486-6363
DEPARTMENT OF ENERGY
TELECOMMUNICATIONS SECURITY MANUAL
PUBLIC KEY CRYPTOGRAPHY AND
General comment 1:
The overall scope of the document, for the purposes stated in Section 1 seem appropriate. However, there will be many uses for PKI in the DOE scientific community, and many of them have less stringent identity and operational requirements.
Many organizations will be deploying PKI, with CA issuance of certificates being done automatically from the personnel database records, etc., to support authenticated corporate e-mail, timecard submission, etc. This sort of use of PKI is an important enterprise efficiency function and should be encouraged (both because of operational efficiency and because it trains people in the use of PKI). There is a need for different grades of certificates, and these will probably be issued by different CAs. High grade certificates supporting functions such as you list below will be required, as will the lower grade certificates that are the electronic equivalent of a personnel database record entry. I point this out mostly because I think that this document should acknowledge that there are other uses of PKI that will be (and are already becoming) common in DOE.
General comment 2:
I feel that there is a general confusion in this document about the role of encrypting data for long-term privacy vs. the use of the keys associated with a PK certificate. Most of the use of PKI in the scientific environment will be for identity authentication for access control and for short-term encryption (i.e. for the time that information is in transit through public systems e.g. in e-mail or over public networks e.g. as in the Webs use of SSL for confidential browser-Web server communication). Most people, at least at this point, are not doing long-term data encryption, e.g. for data on their local hard disks. Such encryption is typically done with symmetric algorithm keys that are generated and managed outside of the mechanisms of a PKI. So, when you talk about key escrow, etc. I think that you need to make your model much clearer. E.g. who generates the symmetric encryption keys, how are they managed, how is escrow actually accomplished when the key generation has nothing to do with the CA, etc.
This chapter shall apply to DOE Certification Authorities or Certification Authorities operated on behalf of the DOE that:
Re: "sensitive unclassified information for which the data owner requires encryption protection" do you mean that "sensitive unclassified information" has a formal definition, and that this data should be encrypted (under what circumstances?) or that any such data (again a definition is needed it is not in your definitions section) that is encrypted must rely on the certificates described here? (If so, what is the reliance on PKI c.f. comment 2.)
Information in this chapter concerning the use of public key cryptography does not imply or provide access control to computers or other systems, and does not constitute implicit authority in business applications.
This should be made clearer. E.g.:
A public-key certificate, together with the policy of the issuing CA, establishes a level of assurance in the binding of a human identity to a public key, and a level of operational formalism associated with protecting the integrity of the certificate and the user identity token (the stored private key). There is no implicit authority for ANY purpose associated with the PK certificate. Such authority is always established through other mechanisms, and the PKI just provides the mechanisms for assuring that a computer client application is truly representing the human identity that it claims to be.
6.2 Use of Approved Cryptographic Algorithms and Software
Cryptographic algorithms, software implementations, and computing methods used for public key encryption, digital signatures, cryptographic hash functions, key exchange, and other security functions performed by a CA, RA, or EE shall be compliant with applicable Federal Information Processing Standards (FIPS) requirements or as otherwise approved by the DOE PCA. Use of software cryptographic modules for EEs is permitted if specified in the certificate policies and certification practices statements. However, if available, hardware must be used to produce the signatures by the PCA and the CAs responsible for operating and maintaining the DOE system. The PCA may waive this requirement on a case-by-case-basis for specific applications.
Again, c.f. Comment 2: This is unclear. Every invocation of software that uses the public-private keys of the user (EE) or the EEs correspondent, etc., including many functions outside of the scope of the CA (e.g. secure channels set up by Web client-servers, things like SSH used for system administration, etc.) uses "software cryptographic modules". However, if you are talking just about things like PKCS-12 software that specifically manages the private key of the PK pair associated with your certificate instead of using a smart-card like device for this purpose, then you should say that.
Comment: Many things in the paragraph are unclear.
Are you talking about the EE private component of the PK pair (c. f. comment 2 again)?
Will PK pairs be issued separately for signature and encryption? Will there be separate policies for these? (Do you intend to escrow signing keys? Most people say "no", but I think that they probably should be escrowed however only for recovery when people loose their PIN codes, which will happen all the time.)
Most bulk data encryption is done with symmetric keys (e.g. DES) that have nothing to do with a CA. Do you expect the CA to manage these keys as well? (That is a significant departure from the usual scope of a CA.)
All government information can be accessed by the local authorized DOE authorities for official business in accordance with established procedures.
Comment: Is this an "Emergency Key Recovery" circumstance? I dont think so. This is a policy-based use of the EEs keys for routine business practice and the distinction should be clearly made.
Comment: The scope of this section ("Requirements for Certificate Policies") is not consistent with the definition of CP given in Section 3. It mixes CP, CPS, PCA policy and operations domains.
7.3 Assurance Level
Assurance level is an indication of the general level of trust that is placed in a certificate as specified in the certificate policies. This trust is based on the identity of the user, the level of
Comment: re: "This trust is based on the identity of the user" actually the trust is based on the procedures used to establish the identity of the user. The true identity (veracity of birth certificates, drivers licenses, passports, etc. that are used to establish identity before a certificate is issued) is usually a different matter.
protection provided to the private key component, and the quality of the CA program as defined
Comment: the term "CA program" is not defined. "CA operation" is probably better.
by the certification practice statement. The assurance level is intended to provide a consistent framework throughout the DOE public key system upon which services or security features may be built.
Cross-certification is a mechanism by which two CAs exchange certificates to implement a trusted relationship. Cross-certification is intended to simplify certificate paths for efficiency (i.e., shorter verification paths). This differs from the strict hierarchy model wherein trust is passed down along branching certificate paths. PKI management at DOE is organized as a hierarchy for administration purposes. For operational purposes, cross certification allows the establishment of a network of trust relationships among approved CAs inside and outside DOE. Cross-certification outside DOE creates a significant risk for the CA as well as the other users of PKI at DOE and for that reason requires DOE PMA approval.
Comment: You have begged the big issue here: What are the procedures for cross certifications? What do you require for the mechanisms for out-of-band exchange of the CA certificates that precedes the signing of some other CAs certificate by your CA? Or are you assuming that all cross certification can be done by following certificates chains up to a DOE CA in order to establish validity of the public key?
I also think that cross certification will be common for "low assurance" CAs so that secure e-mail can be exchanged among, e.g., scientific collaborators at universities, in industry, etc. (If you dont do cross certification as we usually do not do now then what you are doing is trusting the certificate directory server with the same trust that you place in a CA, but without any of the assurances. (It is easy to spoof a directory server or replace the CAs certificate.)
7.5 Directory Service
The DOE public key directory will be based on the X.500 directory concept or other directory concepts that foster compatibility. It will initially consist of a collection of local directories, managed by CAs, that cooperate to create a DOE public key data base of information. The information in the directory is collectively known as the Directory Information Base. Entity access rights will be based upon their function within the PKI. Each entity in the directory is
Comment: re: "access rights" access to what? The directory itself?
considered an object and all objects are defined by a set of entries recognized as public key certificates bound to the entity. The directory service will allow any entity to access certificates in order to verify the electronic signatures of another entity regardless of the CA that issued the certificate. The directory service shall also store the most recent CRL developed by the CA. The DS shall authenticate all entities attempting to modify certificates and CRLs. Only CAs may create or update their own entries.
Comment: re: "Only CAs may create or update their own entries" what are "own entries"? Are you talking about a directory service that is the agent of the CA (the usual circumstance, since managing the CAs certificates is intimately tied up with a directory server in most CA products), in which case you are referring to the certificate of the CA itself, or are you talking about some centralized directory server that has certificates of many CAs, in which case you are talking about all of the certificates issued by a given CA. ???
Access to the system running the service shall be strictly controlled and limited to the appropriate personnel.
PCA audits will be concerned with criteria that could affect the integrity of the entire PKI, such as, but not limited to-
comment: cross-certification in regard to procedure? Scope of cross certifications?