Re: More inter samples

r/reagle@w3.org/2002.03.14/12:55:53
>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.)

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.

Merlin


-----------------------------------------------------------------------------
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.
   http://www.baltimore.com

Received on Thursday, 14 March 2002 13:16:21 UTC