Subject: Some term ambiguous on PKIX Roadmap

From: ÀÌµ¿È£ <[email-masked]>
Date: Fri, 23 Apr 1999 15:25:33 +0900

INTERNET DRAFT                PKIX Roadmap              26 February 1999

      For key management keys that are generated by the requester, the
      CA can send the user 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.)

-------------------------------------------------------------------------

      Above is 31page of PKIX Roadmap.
   
      What CA's own private key above context means?
      CA's private key is so meaningless to send to a new requester?
      Can I interpret it as somewhat like a session key?
      And encrypt the session key with the requester's public key..
      If the requester really have a corresponding private key, 
      he can get the session key.
      Is my interpretation right?

---

From: Alfred Arsenault <[email-masked]>
Date: Fri, 23 Apr 1999 21:37:56 -0400

<snip>
      requester to be decrypted.  
<snip>

<snip>

________________________________

Yes, your interpretation is right.  The paragraph in the Roadmap is in
error; it should say something like

For key management keys that are generated by the requester, the
      CA can use the requested public key to encrypt some piece of data,
and send it to the
      requester to be decrypted.  

___________________________

Depending on which encryption algorithm you're using, the encryption
might involve both the requested key, and the CA's private key; the
decryption would thus involve both the private key that matches the
requested public, and the CA's public.  Unfortunately, we didn't say
that very well.  It will be fixed in the next draft.

			Al Arsenault

--- These are my opinions, and do not necessarily represent those of my
employer or of any other organization with which I have a relationship.