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

RE: xenc:EncryptedKey/@Type

From: Blair Dillaway <blaird@microsoft.com>
Date: Fri, 11 Jan 2002 14:05:08 -0800
Message-ID: <AA19CFCE90F52E4B942B27D42349637902CDCE8F@red-msg-01.redmond.corp.microsoft.com>
To: <reagle@w3.org>, "Christian Geuer-Pollmann" <geuer-pollmann@nue.et-inf.uni-siegen.de>
Cc: <xml-encryption@w3.org>
Unless I'm missing something, the important issue here is determining the key-encoding used for the encryption key value in the EncryptedKey.  The algorithm that key value is used with is known by checking the EncryptionMethod element of the EncryptedData one is trying to decrypt.

As a simple example, imagine I'm trying to communicate a 3-key 3DES value, i.e, 24-octets long (including parity bits).  By convention, this is typically communicated by simply concatenating the 3, 8-octet, DES key values which are encrytped as a 24-octet quantity.  But, one could decide to encrypt:
	- the key bits, with parity bits removed, as a 21-octet quantity
	- XML representing the value like <KeyValue><TripleDESKeyValue>base64value</TripleDESKeyValue></KeyValue>
Or any number of other encodings.

So the question seems to be do we assume the decryptor implicitly knows the key encoding format used, or do we provide a way to make it explicit?  I don't have a problem in using the 'Type' attribute for this purpose if folks are worried about.  

So an example might look more like
<EncryptedKey Type="TripleDESKeySetWithParityAsBinary">,

I don't think this is necessary for the algorithms included in the spec.  But it may help out folks who introduce new algs.



-----Original Message-----
From: Joseph Reagle [mailto:reagle@w3.org] 
Sent: Friday, January 11, 2002 1:01 PM
To: Christian Geuer-Pollmann
Cc: xml-encryption@w3.org
Subject: Re: xenc:EncryptedKey/@Type


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 17:05:41 GMT

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