W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2001

XML Encryption Comments

From: Dournaee, Blake <bdournaee@rsasecurity.com>
Date: Tue, 27 Nov 2001 15:53:07 -0800
Message-ID: <E7B6CB80230AD31185AD0008C7EBC4D202A1B749@exrsa01.rsa.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:19 GMT