W3C home > Mailing lists > Public > xml-encryption@w3.org > March 2002

Re: More inter samples

From: merlin <merlin@baltimore.ie>
Date: Thu, 14 Mar 2002 18:16:15 +0000
To: reagle@w3.org
Cc: xml-encryption@w3.org
Message-Id: <20020314181615.8AA8C4422C@yog-sothoth.ie.baltimore.com>
>On Monday 11 March 2002 18:57, merlin wrote:
>> On the ds:KeyValue NOT RECOMMENDED front, I think this is an error in
>> the interop matrix and misleading in the spec. We are decrying use of
>> KeyValue to transport the decryption key, but we don't define any private
>> KeyValue elements (as it suggests) in order for this to even be possible;
>> only public keys, and it seems quite reasonable to send across a public
>> to allow the decryptor to select the corresponding private key. More to
>> the point, we specificially define a Diffie Hellman key value that will
>> usually be used in order for key agreement to be performed.
>Good point, the text now reads:
>Support for ds:KeyValue is OPTIONAL and may be used to transport public 
>keys, such as Diffie-Hellman Key Values (section 5.5.1) (Using the literal, 
>unprotected, ds:KeyValue to transport the encryption key is obviously NOT 

I would change the parenthesis to:

  (Including the plaintext decryption key, whether a private key or
  a secret key, is obviously NOT RECOMMENDED.)
It is perfectly valid to send the public encryption key, and ds:KeyValue
can't be used to transport a private key. We just want to point out
that you shouldn't send the plaintext decryption key, however you
choose to do so.

>> In the matrix, I'd suggest breaking out enc:DHKeyValue (OPTIONAL) and
>> dropping ds:KeyValue; it has no current meaning. In the spec, I think
>> the NOT RECOMMENDED is too strong; it's simply not supported by any of
>> our specs. Even stating that it would be NOT RECOMMENDED seems a bit
>> hypothetical; in dsig, we don't state that sending a private KeyValue
>> would be wrong.
>Ok, ds:KeyValue is removed and replaced with enc:DHKeyValue.
>> In terms of performance, I can try and produce some numbers but it
>> really boils down to parsing the encrypted data element, obtaining a key,
>> possibly base-64 decoding the ciphertext, symmetric decryption and then
>> optionally parsing. One could reasonably expect that the latter three
>> steps are more of a platform issue than an xmlenc issue, as is much of
>> the effort in obtaining a key if there is any, and we're not exercising
>> base-64, decryption or parsing in any unusual way, so I'm not sure that
>> there's much to be said.
>Maybe, but I'm trying to avoid a mismatch of expectations as happened with 
>the XPath transform, where someone was able to say, "I expect to be able to 
>do X of these transforms on Y size documents every Z fraction of a second." 
>I want to make sure we're in the right ballpark.

X/Y/Z can't really be expressed for a general environment. It might be
possible to say that performance should be, broadly speaking, linear in
document size (taking into consideration cache and memory constraints),
and within a reasonable constant of performing the relevant operation
(e.g., XML parsing) on the plaintext data.


Baltimore Technologies plc will not be liable for direct,  special,  indirect 
or consequential  damages  arising  from  alteration of  the contents of this
message by a third party or as a result of any virus being passed on.

This footnote confirms that this email message has been swept by
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.
Received on Thursday, 14 March 2002 13:16:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:03 UTC