[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: key usage - key encipherment or data encipherment




I also hesitate to accept the term "key transport", which will
result in over-narrowing down the usage scope of the
keyEncipherment bit. As Arshad pointed out, sometimes
the intention is not to transport the encrypted symmetric key
to anywhere. Besides, it is often that the handshake protocol
is not simply a "key transport" process; it is more often be
a more complex "key exchange" process. For example,
the SSL handshake protocol names it as "key exchange"
instead of "key transport". Would it be valid for a SSL server
cert to be asserted with that keyEncipherment bit?
To avoid the possible dispute on the definition of
similar terms, I would like to suggest to drop the term "key
transport" from the definition of the key usage bit. (However,
I think it is OK to use "key transport" as an example to
explain the the definition of the key usage bit.

I also think it is strange to positively list "private keys" and
"secret keys" as the only two possible types of keys that can
be encrypted by the subject public key? What if someday
another type of keys is invented and need to be encrypted by
the subject public key? Why not simply use the term
"cryptographic keys"? I believe the term  "cryptographic keys"
is general enough to cover any types of keys.

My other concern is that the current definition of the key
usage bit seems to only allow the subject public key be
used for enciphering "keys". However, we must note that
it is more often that modern handshake protocols actually
use the subject public key for enciphering "keying materials"
instead of the "real keys". For example,  the
pre-master-secret in the SSL hadnshake protocol is not
yet a "real key"; it is actually be a "keying material" that
can be used to derive "real shared secret keys" between
the client and the server. Therefore, I suggest that we
should take the possibility of enciphering "keying materials"
instead of the "real keys" into account.

Here I propose to revise the definitions of this two key usage
bits as follows:

     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 symmetric
     content-decryption key or an asymmetric private 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.

Wen-Cheng Wang


Arshad Noor wrote:

I am afraid, this still does not provide sufficient clarity.

Some questions that I cannot answer, based on reading the text
below (although I know the answers from practice) are:

1) Whose private key am I encrypting with the public key?  Mine?
   Hopefully not, because if this were the only copy of my private
   key, what am I going to use to decrypt the cipher-text with?
   While this may appear as a ridiculous notion, the point is that
   the text does not clarify this question.

2) What if I'm not using the certificate for key transport?  I may
   have issued a certificate to a database that generates symmetric
   keys to encrypt database content, and then stores the encrypted
   symmetric key within the same database with the cipher-text. I'm
   not transporting the symmetric key anywhere, so should I be using
   the keyEncipherment bit or the dataEncirpherment bit?

In my opinion, the confusion arises because the two bits perform
the same function: encipherment (as Simon McMahon pointed out in
an earlier posting), but for different purposes.

There is a certain simplicity to having just one encipherment bit,
letting applications decide what they want to encrypt with the
certificate's public-key and letting them codify it in *their*
protocols - as S/MIME does - or through EKU's.

Arshad Noor
StrongAuth, Inc.


Russ Housley wrote:

There has been a whole lot of discussion about these paragraphs. Since some of the discussion has not been CCed to the PKIX mail list, I am posting the resulting words.

     The keyEncipherment bit is asserted when the subject public key is
     used for enciphering private or secret keys, i.e., for key transport.
     For example, this bit shall be set when a RSA public key is to be
     used for encrypting a symmetric content-decryption key or an
     asymmetric private key.

    The dataEncipherment bit is asserted when the subject public key
    is used for directly enciphering raw user data 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 a symmetric key.

I hope we a re close to closure on this one....

Russ