[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: key usage - key encipherment or data encipherment
Hmmm - The person you are writing for is an IT Auditor because there is NO
PKI system that is ever going to be deployed commercially from say 9/11
onward and especially after SOX that is going not have an Auditor's
Approval. That means something I tried to get this WG to think about several
years ago and that was Practice or Use Models for the IP's themselves.
Todd Glassey, CISM, CIFI
----- Original Message -----
From: "Dino Esposito" <alfredo.esposito@xxxxxxxxxxxxx>
To: "Sam Roberts" <sroberts@xxxxxxxxxxxx>
Cc: <ietf-pkix@xxxxxxxx>
Sent: Thursday, May 12, 2005 9:25 AM
Subject: Re: key usage - key encipherment or data encipherment
>
> IMO, the typical reader of a RFC is a technician. Especially for a RFC
> full of PKI jargon.
> If we wanted to write for a layman reader, we should write an encyclopedia
> I think the Pinkas' proposal is quite clear.
>
> Dino Esposito
>
> Sam Roberts wrote:
>
> >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.
>
>>>>************************************************************************
***********
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >
> >
> >
>