- From: Dournaee, Blake <bdournaee@rsasecurity.com>
- Date: Tue, 27 Nov 2001 15:53:07 -0800
- To: xml-encryption@w3.org
Hello All, I noticed a few inconsistencies with the current XML Encryption work in progress (http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/) I. Consider Section 2.2.2, the second example: [t09] <EncryptedKey Id='EK' xmlns='http://www.w3.org/2001/04/xmlenc#'> [t10] <CarriedKeyName>John Doe</CarriedKeyName [t11] <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> [t12] <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> [t13] <ds:KeyName>John Smith</ds:KeyName> [t14] </ds:KeyInfo> [t15] <CipherData><CipherValue>xyzabc</CipherValue></CipherData> [t16] <ReferenceList> [t17] <DataReference URI='#ED'/> [t18] </ReferenceList> [t19] </EncryptedKey> Notice [t10]. According to the revised <EncryptedKey> schema definition, shouldn't the <CarriedKeyName> element should be after <ReferenceList> and not the first element in the <EncryptedKey> structure? Here is the revised <EncryptedKey> schema definition: Schema Definition: <element name='EncryptedKey' type='xenc:EncryptedKeyType'/> <complexType name='EncryptedKeyType'> <complexContent> <extension base='xenc:EncryptedType'> <sequence> <element ref='xenc:ReferenceList' minOccurs='0'/> <element name='CarriedKeyName' type='string' minOccurs='0'/> </sequence> <attribute name='Recipient' type='string' use='optional'/> </extension> </complexContent> </complexType> II. Consider the explanation of [t09] in Section 2.2.2. The second sentence still reads "The CarriedKeyName attribute", this should be changed to "The CarriedKeyName element." III. This is in regards to the behvaior of <AgreementMethod> and is in response to Donald's previous comment to me (repeated below) <Donald> "If you have done some sort of key agreement outside of XMLENC, then, of course, you could probably just use an KeyInfo that named that key or whatever. I see the AgreementMethod inside KeyInfo to be for cases where, for example, you have retrieved a DH Key for the recipient via XKMS or from some Certificate cache. Since you know your own key, presumably you can calculate an agreed key and use it. You might need to include the recipient's key in the message since they might have several and not know which one you used." </Donald> The reason for my confusion on this issue comes from the fact that XML Encryption only supports asynchronous key agreement (which is what Donald is describing above), and not synchronous or "real time" key agreement (which isn't possible because of the chicken and egg problem mentioned in my previous email). This threw me off because key agreement is often used for synchronous shared secret generation. Can we add a few sentences that clarifies the difference between these? I believe this will prevent people from expecting XML Encryption to support synchronous key agreement. This is an important distinction to make because the text doesn't suggest otherwise. Just an idea. Thanks, Blake Dournaee Toolkit Applications Engineer RSA Security "The only thing I know is that I know nothing" - Socrates -----Original Message----- From: Donald E. Eastlake 3rd [mailto:dee3@torque.pothole.com] Sent: Sunday, November 25, 2001 8:54 PM To: Dournaee, Blake Cc: xml-encryption@w3.org Subject: Re: <AgreementMethod> questions From: "Dournaee, Blake" <bdournaee@rsasecurity.com> Message-ID: <E7B6CB80230AD31185AD0008C7EBC4D202A1B6CD@exrsa01.rsa.com> To: xml-encryption@w3.org Date: Tue, 13 Nov 2001 17:20:58 -0800 >Hello All, > >I have been pondering the <AgreementMethod> element today and have a very >basic question. I am hoping that someone can set me straight on this. > >It seems to me that the <AgreementMethod> has a sort of "chicken and egg" >problem. For example, if I am an originator and I am performing a DH key >exchange with a recipient, it is impossible for me to send the key exchange >information along with encrypted data because the encryption key hasn't yet >been generated. This means that the example in Section 5.5 assumes that a >key has *already* been generated and the <ds:KeyInfo> should point to (or >remind someone of) a previously generated key agreement. But there is a >contradiction (in my mind) because the XML Encryption draft specifies it's >own key derivation function, yet there is no pair of messages for just >performing the key exchange and generating the key. The <ds:KeyInfo> is >defined to be a part of <EncryptedData>. If you have done some sort of key agreement outside of XMLENC, then, of course, you could probably just use an KeyInfo that named that key or whatever. I see the AgreementMethod inside KeyInfo to be for cases where, for example, you have retrieved a DH Key for the recipient via XKMS or from some Certificate cache. Since you know your own key, presumably you can calculate an agreed key and use it. You might need to include the recipient's key in the message since they might have several and not know which one you used. >It appears as if there is a contradiction of sorts in the draft (or some >horrendous misunderstanding on my part). I can live with the fact that the ><AgreementMethod> element is used as a "reminder" to let recipients and >originators know which key was generated (and with a nonce, if possible), >but it doesn't look like XML Encryption actually specifies the logistics to >perform the key agreement without also specifying actual encrypted data, >which is impossible because the shared key hasn't been generated. See above. Thanks, Donald >Thanks, > >Blake Dournaee >Toolkit Applications Engineer >RSA Security > >"The only thing I know is that I know nothing" - Socrates
Received on Tuesday, 27 November 2001 18:48:02 UTC