RE: key usage - key encipherment or data encipherment

["Stefan Santesson" <stefans@xxxxxxxxxxxxx>]

How about calling the bits "The encryption bit" and "The other
encryption bit" :-)  

Jokes aside, can anyone recall the justification for having 2 different
bits for key and data encryption?

Is there any realistic security threat involved with allowing both
purposes for the same bit?

Stefan Santesson
Program Manager, Standards Liaison
Windows Security
 

> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On Behalf Of Simon McMahon
> Sent: den 13 maj 2005 03:19
> To: Denis.Pinkas@xxxxxxxx; sharon.boeyen@xxxxxxxxxxx;
housley@xxxxxxxxxxxx
> Cc: ietf-pkix@xxxxxxxx
> Subject: RE: key usage - key encipherment or data encipherment
> 
> 
> Sorry but I think this new text is just more jargon and does not
address
> the problem. The problem is that there are 2 bits for encryption
instead
> of 1 so people can make a choice and need direction in that choice,
but
> will still get it wrong anyway, just because they can (Murphy). The
> misunderstanding is that "keyEncipherment" is nearly always the
correct
> choice but sometimes people use "dataEncipherment" because the
transport
> keys are not explicit.
> 
> Note that a new definition of a public key cipher RSA' that internally
> used "RSA+AES" but didn't publish that fact could have RSA' public
keys
> (not RSA keys but internally identical to them) that directly encrypt
> large amounts of data. The transport key just blends into the cipher
text.
> "dataEncipherment" is then the correct bit for the RSA' key but I'll
bet
> people who know its really RSA+AES will use "keyEncipherment" because
that
> is what is really happening.
> 
> The bottom line is that this problem will never go away as long as you
> have two bits whose meanings overlap like these ones do. The bits
should
> be merged because CA's that know about interoperability issues just
set
> both anyway. I would prefer a consolidation these flags and to
deprecate
> "dataEncipherment". That would leave "keyEncipherment" that could be
> renamed to "encipherment". Then there is no confusion because there is
no
> choice anymore.
> 
> Anyway, back to the text...
> 
> Why did the "private" key creep into this description? "Private" keys
are
> also "secret". By the way, how does a public key encrypt a private
key? It
> is impossible, at least with RSA without a symmetric key in there,
unless
> the private key is a lot smaller. The latest proposed text example
> specifies "content-decryption" now but symmetric keys exchanged this
way
> can also be for encryption too. Also, the symmetric key encrypted by
the
> public key was in fact an encryption key when the originator used it.
> 
> Proposed rewording preserving both bits:
> "
> The keyEncipherment bit is asserted when the subject public key is
used
> for transport of a secret key or data encryption using an intermediate
> secret key. For example, when a public key is to be used to encrypt a
> secret cipher key that will encrypt some data or key, then this bit
shall
> asserted.
> 
> The dataEncipherment bit is asserted when the subject public key is
used
> for directly enciphering user data other than cryptographic keys.
> "
> 
> Proposed rewording with only one bit:
> "
> The dataEncipherment bit is deprecated. If asserted then this bit now
has
> the same meaning as keyEncipherment. The keyEncipherment bit is
renamed to
> "encipherment" and is asserted when either of the previous bits were
> asserted. Whenever a public key is used to encrypt data or keys then
this
> bit shall be asserted.
> "
> 
> Regards,
> 
> Simon McMahon.
> 
> 
> 
> Simon McMahon
> 
> Work: (07) 31311420
> Mobile: (043) 2294180
> 
> 
> >>> Sharon Boeyen <sharon.boeyen@xxxxxxxxxxx> 05/13/05 05:44am >>>
> I like the proposed text also. My only suggestion is could we add
> "symmetric" in the sentence for dataEncipherment, so it would read
"...
> without the use of an intermediate symmetric key." I don't feel
strongly
> about this but do think it helps with the clarity.
> 
> Cheers,
> Sharon
> 
> -----Original Message-----
> From: owner-ietf-pkix@xxxxxxxxxxxx
[mailto:owner-ietf-pkix@xxxxxxxxxxxx]
> On
> Behalf Of Russ Housley
> Sent: Thursday, May 12, 2005 11:22 AM
> To: Denis Pinkas
> Cc: ietf-pkix@xxxxxxxx
> Subject: Re: key usage - key encipherment or data encipherment
> 
> 
> 
> Denis:
> 
> Thanks.  I think you suggestion improves the text.
> 
> Russ
> 
> At 10:44 AM 5/12/2005, Denis Pinkas wrote:
> >Russ,
> >
> >>Since we are working on an update to RFC 3280, I propose the
following
> >>revisions to these descritions.
> >
> >>      The keyEncipherment bit is asserted when the subject public
key is
> >>      used for key transport.  For example, when an RSA key is to be
> >>      used for key management by encrypting a symmetric content-
> encryption
> >>      key, then this bit shall asserted.
> >>      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.
> >
> >Thank you for this strawman proposal. I would rather propose:
> >
> >       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 public RSA 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 key.
> >
> >Reasons:
> >
> >a) "Key transport" is not explicit enough. The purpose is to encipher
> >either a private key or a secret key.
> >
> >b) The example is not clear enough: "RSA key" can be a private key or
a
> >public key, hence why "public" has been added.
> >
> >c) The key that is communicated is a decryption key rather than an
> >encryption key, hence why "content-encryption" has been changed into
> >"content-decryption".
> >
> >d) The example has been extended to cover the case of an asymmetric
> >cipher
> >as well.
> >
> >e) In the last statement, the intermediate key would not necessarily
be
> >a
> >symmetric cipher, hence why "symmetric" has been deleted. Also
"cipher"
> >has been replaced by "key'.
> >
> >Note that the current text from X.509 is:
> >
> >   c) keyEncipherment: for enciphering keys or other security
> information,
> >      e.g. for key transport;
> >
> >   d) dataEncipherment: for enciphering user data, but not keys or
other
> >      security information as in c) above;
> >
> >Denis
> 
> 
>
************************************************************************
**
> *********
> 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.
>
************************************************************************
**
> *********
> 
>