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

Re: More inter samples

From: Joseph Reagle <reagle@w3.org>
Date: Thu, 14 Mar 2002 12:55:53 -0500
Message-Id: <200203141755.MAA09219@tux.w3.org>
To: merlin <merlin@baltimore.ie>
Cc: xml-encryption@w3.org
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 
RECOMMENDED.)

> 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.
Received on Thursday, 14 March 2002 12:55:56 GMT

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