Comments of

William E. Johnston, Senior Scientist

Information and Computing Sciences Division

Lawrence Berkeley National Laboratory

1 Cyclotron Rd., B50B-2239, Berkeley, CA 94720

wejohnston@lbl.gov; voice: 510-486-5014; fax: 510-486-6363

http://www-itg.lbl.gov

Comments on:

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 Web’s 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.

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

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.

Again, c.f. Comment 2: This is unclear. Every invocation of software that uses the public-private keys of the user (EE) or the EE’s 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.)

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.

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.

Comment: the term "CA program" is not defined. "CA operation" is probably better.

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 CA’s 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 don’t 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 CA’s certificate.)

Comment: re: "access rights" – access to what? The directory itself?

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 CA’s 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. ???

comment: cross-certification in regard to procedure? Scope of cross certifications?