Subject: Revised: POP section for Roadmap

From: Al Arsenault <[email-masked]>
Date: Mon, 01 Feb 1999 15:29:40 -0500

Okay, based on comments from several people, attached is a revision of the
proposed POP section for the next Roadmap draft.  While Denis had some very
good inputs, I mostly agree with Juergen, and think that the "new mechanisms"
that Denis talked about don't solve all of the problems caused by not doing
POP.  I did modify the "signing keys" section to describe - in words to be put
in the text, or maybe in a footnote, whichever works better - the "new
mechanisms" Denis mentioned, and state that they help to solve part of the
problem.  However, I don't think they solve the whole problem.

Additionally, I separated out use of signing keys in non-repudiation services
vs. authentication services, because I think that the need for POP is lesser in
the latter.

Re:  the key-management example:  I've been told by a couple of reviewers that
this is kind of weak (Dorothy would probably already notice that her key had
been compromised if it had been, and so the fact that she hasn't reported a
problem means it's safe,...), but it's the best I can think of at this point.  

I've also tried to reword a couple of things that were seen as pejorative by
some reviewers. 

At any rate, here's the revision:
1.1     POP 
Proof of Possession, or POP, means that the CA is adequately convinced that the
entity requesting a certificate containing a public key Y has access to the
private key X corresponding to that public key.  

POP is important because it provides an appropriate level of assurance in the
correct operation of the PKI as a whole.  At its lowest level, POP counters the
“self-inflicted denial of service”; that is, an entity voluntarily getting a
certificate that cannot be used to sign or encrypt/decrypt information. 
However, as the following two examples demonstrate, POP also counters less
direct, but more severe, threats:
POP for signing keys: it is important to provide POP for keys used to sign
material, in order to provide non-repudiation of transactions.  For example,
suppose Alice legitimately has private key X and its corresponding public key
Y.  Alice has a certificate from Charlie, a CA, containing Y.  Alice uses X to
sign a transaction T.  Without POP, Mal could also get a certificate from
Charlie containing the same public key, Y.  Now, there are two possible
threats: Mal could claim to have been the real signer of T; or Alice can
falsely deny signing T, claiming that it was instead Mal.  Since no one can
reliably prove that Mal did or did not ever possess X, neither of these claims
can be refuted, and thus the service provided by and the confidence in the PKI
has been defeated.  (Of course, if Mal really did possess X, Alice’s private
key, then no POP mechanism in the world will help, but that is a different
problem.)  

Note that one level of protection can be gained by having Alice, as the true
signer of the transaction, include in the signed information her certificate or
an identifier of her certificate (e.g., a hash of her certificate).  This might
make it more difficult for Mal to claim authorship;  he would have to assert
that he incorrectly included Alice’s certificate, rather than his own. 
However, it would not stop Alice from falsely repudiating her actions. Since
the certificate itself is a public item, Mal indeed could have inserted Alice’s
certificate or identifier into the signed transaction, and thus its presence
does not indicate that Alice was the one who participated in the now-repudiated
transaction. The only reliable way to stop this attack is to require that Mal
prove he possesses X before his certificate is issued.

For signing keys used only for authentication, and not for non-repudiation, the
threat is lower because users may not care about Alice’s after-the-fact
repudiation, and thus POP becomes less important.  However, POP SHOULD still be
done wherever feasible in this environment, by either off-line or on-line
means. 

POP for key management keys:  Similarly, POP for key management keys (that is,
keys used for either key agreement or key exchange) can help to prevent
undermining confidence in the PKI.  Suppose that Al is a new instructor in the
Computer Science Department of a local University.  Al has created a draft
final exam for the Introduction to Networking course he is teaching.  He wants
to send a copy of the draft final to Dorothy, the Department Head, for her
review prior to giving the exam.  This exam will of course be encrypted, as
several students have access to the computer system.  However, a quick search
of the certificate repository (e.g., search the repository for all records with
subjectPublicKey=Dorothy’s-value) turns up the fact that several students have
certificates containing the same public key management key as Dorothy.  At this
point, if no POP has been done by the CA, Al has no way of knowing whether all
of the students have simply created these certificates without knowing the
corresponding private key (and thus it is safe to send the encrypted exam to
Dorothy), or whether the students have somehow acquired Dorothy’s private key
(and thus it is certainly not safe to send the exam).  Thus, the service to be
provided by the PKI  allowing users to communicate with one another, with
confidence in who they are communicating with - has been totally defeated. If
the CA is providing POP, then either no students will have such certificates,
or Al can know with certainty that the students do indeed know Dorothy’s
private key, and act accordingly.

CMP requires that POP be provided for all keys, either through on-line or
out-of-band means.  There are any number of ways to provide POP, and the choice
of which to use is a local matter.  Additionally, a certificate requester can
provide POP to either a CA or to an RA, if the RA can adequately assure the CA
that POP has been performed.  Some of the acceptable ways to provide POP
include:

        Out-of-band means:  
For keys generated by the CA or an RA (e.g., on a token such as a smart card or
PCMCIA card), possession of the token can provide adequate proof of possession
of the private key.

For user-generated keys, another approach can be used in environments where
“key recovery” requirements force the requester to provide a copy of the
private key to the CA or an RA.  In this case, the CA will not issue the
requested certificate until such time as the requester has provided the private
key.  This approach is in general not recommended, as it is extremely risky
(e.g., the system designers need to figure out a way to protect the private
keys from compromise while they are being sent to the CA/RA/other authority,
and how to protect them there), but it can be used. 

        On-line means:
For signature keys that are generated by an end-entity, the requester of a
certificate can be required to sign some piece of data (typically, the
certificate request itself) using the private key.  The CA will then use the
requested public key to verify the signature.  If the signature verification
works, the CA can safely conclude that the requester had access to the private
key.  If the signature verification process fails, the CA can conclude that the
requester did not have access to the correct private key, and reject the
request.

For key management keys that are generated by the requester, the CA can send
use the requested public key, along with the CA’s own private key, to encrypt
some piece of data, and send it to the requester to be decrypted. For example,
the CA can generate some random challenge, and require some action to be taken
after decryption (e.g., “decrypt this encrypted random number and send it back
to me”). If the requester does not take the requested action, the CA concludes
that the requester did not possess the private key, and the certificate is not
issued.  

Another method of providing POP for key management keys is for the CA to
generate the requested certificate, and then send it to the requester in
encrypted form.  If the requester does not have access to the appropriate
private key, the requester cannot decrypt the certificate, and thus cannot use
it. After some period of time in which the certificate is not used, the CA will
revoke the certificate.  (This only works if the certificate is not made
available to any untrusted entities until after the requester has successfully
decrypted it.