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

Re: More inter samples

From: merlin <merlin@baltimore.ie>
Date: Mon, 11 Mar 2002 23:57:33 +0000
To: reagle@w3.org
Cc: xml-encryption@w3.org
Message-Id: <20020311235733.81D894422C@yog-sothoth.ie.baltimore.com>

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.

So my interpretation of 'Y' in that column is support for DH key
value, support for other key values to match a decryption key,
and no support for private key values. Which is probably not the
intended interpretation.

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.

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.

I'll poke someone for a URL.


>On Monday 11 March 2002 16:38, merlin wrote:
>> Joseph, there's another set of interop samples at
>> lists.w3.org/Archives/Public/xml-encryption/2002Mar/0008.html
>Ok, now listed in:
>  http://www.w3.org/Encryption/2002/02-xenc-interop.html
>> You can put us down for Y across the board, with the
>> caveat that there appears to be a DH interop issue
>> and I'm not sure how much NFC impacts me.
>Ok, now Y down the board. If you'd like the column heading to refer to a 
>Baltimore web page describing the implementation, please let me know.
>> There are two decryption transforms samples in the
>> referenced set; when we nail down our language I'll
>> produce a couple more.
>Great! On Xenc itself, and this transform I'm very interested on getting 
>some ball park performance targets: the Y for the satisfactory performance. 
>I don't need specific numbers for a given implementation but if we can 
>document a high bound on an expectation of decrypting X EncryptedData 
>blocks in a Y size document in Z time, I think that would be very useful -- 
>and help avoid the XPath issue we encountered in xmldsig.
>Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
>W3C Policy Analyst                mailto:reagle@w3.org
>IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature/
>W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/

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 Monday, 11 March 2002 18:57:39 UTC

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