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 Sunday, 25 November 2001 23:56:19 UTC