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

Re: xenc:EncryptedKey/@Type

From: Joseph Reagle <reagle@w3.org>
Date: Fri, 11 Jan 2002 16:00:40 -0500
Message-Id: <200201112100.QAA02502@tux.w3.org>
To: Christian Geuer-Pollmann <geuer-pollmann@nue.et-inf.uni-siegen.de>
Cc: xml-encryption@w3.org
On Friday 11 January 2002 15:40, Christian Geuer-Pollmann wrote:
>   "XML Encryption implementations MUST support TRIPLEDES
>    wrapping of 168 bit keys and may optionally support
>    TRIPLEDES wrapping of other keys.
>
> We allow "other" keys. Same for kw-aesxxx. But XML structured keys
> wouldn't be wrapped using SymmetricKeyWrap but by using
> BlockEncryptionAlgorithms, right? I mean from my 'feeling',
> SymmetricKeyWrap is for 'binary' keys while BlockEncryptionAlgorithms are
> for 'wrapping' XML structured keys.

I'm not trying to address a binary versus XML thing here. The last sentence 
just mean that while one could use syntax like the following if one didn't 
use an EncryptedMethod Algorithm Identifier that was bound to a key 
structure:

<EncryptedKey Type="someEncryptionAlgorithms128bitKey">
   <EncryptionMethod
     Algorithm="&xenc;someEncryptionAlgorithm" />

My question was that none of the algorithms in *this* spec fall into that 
class: they do *not* need this sort of structure because we provide 
algorithm identifiers that are capture both with the algorithm 
(tripledes/aes), key sizes (and potentially IV) and the mode (cbc).

(But, we can't expect the whole world to necessarily follow this convention 
so its good to have this provision of a Type on the EncryptedKey).

(I agree with your "feeling" but unless I misunderstand you, that wasn't my 
point...?)



-- 

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/
Received on Friday, 11 January 2002 16:00:58 UTC

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