RE: key usage - key encipherment or data encipherment

["Simon McMahon" <Simon_McMahon@xxxxxxxxxxxxxxxxx>]

Wen-Cheng Wang's last post looks OK to me but I would drop "RSA" and "content-decryption" from the example. I still don't see how an RSA public key can directly encrypt a private key, unless its heaps smaller, so I dropped that from the example too. 'Private' keys are also 'secret' keys anyway. I didn't change 'dataEncipherment' from Wang's post.

proposed text:
      The keyEncipherment bit is asserted when the subject public key is
      used for enciphering cryptographic keys or keying materials.
      For example, this bit shall be set when a RSA public key is to be
      used for key transport that involves encrypting a secret key.
 
     The dataEncipherment bit is asserted when the subject public key
     is used for directly enciphering raw user data, other than cryptographic
     keys or keying materials, without the use of an intermediate symmetric
     cipher. Note that the use of this bit is extremely uncommon; almost all
     applications use key transport or key agreement to establish shared
     cryptographic keys.

The 'note' at the end of dataEncipherment effectively deprecates this bit but I'm sure it will continue to see many more interoperability issues in the future.

I think that Peter's observation:
  keyEncipherment = ephemeral session key establishment (e.g. SSL).
  dataEncipherment = content-encryption key establishment (e.g. S/MIME).
Is what industry will continue to do regardless of the RFC text since a bit that is there with no obvious use may as well get used for something.

The 'PIN' reference from another post was another good grey area that can justify the use of either bit however the RFC gets worded.

The overloading of the bits to imply security policy for the private key's decryption op is the riskiest use of these bits but will obviously continue too.

The bits, as defined by the RFC, obviously don't matter very much to PKI security which is why no-one could nail down what they actually mean and industry usage varies so widely. They are just an interoperability issue waiting to happen (again).

Simon McMahon.



Simon McMahon

Work: (07) 31311420
Mobile: (043) 2294180




***********************************************************************************
This email, including any attachments sent with it, is confidential and for the sole use of the intended recipient(s).  This confidentiality is not waived or lost, if you receive it and you are not the intended recipient(s), or if it is transmitted/received in error.

Any unauthorised use, alteration, disclosure, distribution or review of this email is prohibited.  It may be subject to a statutory duty of confidentiality if it relates to health service matters.

If you are not the intended recipient(s), or if you have received this email in error, you are asked to immediately notify the sender by telephone or by return email.  You should also delete this email and destroy any hard copies produced.
***********************************************************************************