[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: key usage - key encipherment or data encipherment
Wrote Denis Pinkas <Denis.Pinkas@xxxxxxxx>, on Thu, May 12, 2005 at 04:44:28PM +0200:
>
> 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.
Hi Denis,
I think this text has the same problem as the current. In other words,
somebody might read it and think "I'm not encrypting a key, I'm
encrypting email, and I'm "transporting" a word document, not a key, so
this isn't the bit I should look for". This is what happens now.
I can't think of appropriate wording, but if the goal is to make it
clear to non-security experts so the bit is used consistently, a little
bit more explanation is needed.
> 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.
This is clear, I think.
Cheers,
Sam
> 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
>
> >Russ
> >
> >At 10:14 PM 5/11/2005, Simon McMahon wrote:
> >
> >>Russ,
> >>
> >>They were calling an 'encrypt' function to encrypt XML data and they
> >>gave it an RSA key (the cert actually) to do it. Of course it
> >>internally made an AES key but they never saw it until the
> >>interoperability issue made them look. From what they saw at the level
> >>they were looking the interpretation was reasonable. When the
> >>transport key is well hidden and simply part of the protocol then it
> >>looks just like RSA is encrypting big slabs of data. If you know that
> >>RSA is bound by the modulus size then you know what is really
> >>happening but not all users of PKI know RSA so well. Why should they?
> >>
> >>Couple this interpretation of key-usage with a dubious decision to
> >>reject encryption requests with certs that dont have key-usage='data
> >>encipherment' and you have an interoperability problem. I say
> >>"dubious" because it is a public key so you cannot enforce usage
> >>policy anyway. The CA could set both flags to fix it, which by the way
> >>was the vendors preferred solution, but its not my CA or their CA and
> >>the CA doesn't do that. Why should they?
> >>
> >>This reference, in my opinion, allows the ambiguous interpretation:
> >>> 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, then this bit shall asserted.
> >>>
> >>> The dataEncipherment bit is asserted when the subject public key
> >>> is used for enciphering user data, other than cryptographic keys.
> >>
> >>In this case the public key is clearly "intended" to be used to
> >>encrypt the XML data but it just doesn't do it directly because it
> >>cant. The term "key management" also has associations with more basic
> >>and explicit key management operations like installing trusted root
> >>certs or secure installation of shared secret keys etc. In this case
> >>it is much less obvious that key management is happening because the
> >>key is bundled with the data. It looks just like the public key is
> >>encrypting the data.
> >>
> >>In my opinion there are 3 cases presented as 2 in the RFC.
> >>1. RSA encrypts data - hardly ever used.
> >>2. RSA implicitly encrypts keys so it can really encrypt bulk data -
> >>common usage.
> >>3. RSA explicitly encrypts keys for explicit key management functions
> >>- common usage.
> >>The current bits separate 1 from 2/3 yet people make the
> >>interpretation that they split the more common 2 from 3 assuming 1 and
> >>2 are the same thing. Knowledge of RSA is required to know that 1 and
> >>2 are different.
> >>
> >>Peter's comment "This bit MUST NOT be set when the intention is to
> >>encipher intermediate cryptographic keys rather than raw user data" is
> >>most relevant in my case. Does PKIX support this clarification?
> >>
> >>In my opinion this problem will not entirely go away by clarifying the
> >>standard because most people dont read it before they implement
> >>something. The two bits are there and as long as they are both there
> >>then the mistake will be made by busy developers. Unenforceable
> >>key-usage policy, to "public" keys, will also continue to be
> >>implemented. People will come looking for clarification once they have
> >>an interoperability issue but by then it is often too late - the issue
> >>usually gets decided by who has the biggest corporate balls. In this
> >>case it wasn't too late so thanks for the assistance.
> >>
> >>If I could recommend a change to the standard then I would suggest
> >>dropping one of the encryption bits and just have a single key-usage =
> >>"encryption". Give it the value the same as "key-encryption" since
> >>this is the common usage.
> >>
> >>Thanks,
> >>
> >>Simon McMahon.
> >>
> >>
> >>Simon McMahon
> >>
> >>Work: (07) 31311420
> >>Mobile: (043) 2294180
> >>
> >>
> >>>>> Russ Housley <housley@xxxxxxxxxxxx> 05/12/05 01:06am >>>
> >>Simon:
> >>
> >>If they are encrypting the XML data directly with the RSA key (which is
> >>very unlikely), then they are correct.
> >>
> >>The traditional way to handle this is to generate a random
> >>content-encryption key (CEK) and then encrypt the XML data with a
> >>symmetric algorithm using the CEK. The CEK is encrypted with the RSA
> >>key from the certificate. Thus, the RSA key is really being used to
> >>encrypt only
> >>symmetric keys.
> >>
> >>Russ
> >>
> >> At 08:33 PM 5/10/2005, Simon McMahon wrote:
> >>
> >>>Hi,
> >>>
> >>>I have had a recent interoperability issue with a application vendor
> >>that >didn't like the key-usage attributes in a cert from a CA vendor's
> >>>certificate. Signing certs work fine, it was an encryption cert that
> >>failed.
> >>>
> >>>CA sets key-usage = "key encipherment".
> >>>Application wants to encrypt some XML data so looks for key-usage =
> >>"data
> >>>encipherment". Reason - because XML is data, not a key.
> >>>
> >>>I believe the application vendor is wrong and I explained that the
> >>RSA key >actually encrypts an AES key so it doesn't directly encrypt
> >>the data but >they want an official "pkix" ruling based on the
> >>standard so can someone >please refer me to a statement in the
> >>standard that clears this up.
> >>>
> >>>Thanks,
> >>>
> >>>Simon McMahon.
> >>>
> >>>
> >>>
> >>>Simon McMahon
> >>>
> >>>Work: (07) 31311420
> >>>Mobile: (043) 2294180
> >>>
> >>>
> >>>
> >>>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.
> >>>*************************************************************************
> >>**********
> >>
> >>
> >>
> >>***********************************************************************************
> >>
> >>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.
> >>***********************************************************************************
> >>
> >
> >
> >
>
--
http://www.certicom.com