Re: xenc:EncryptedKey/@Type

On Thursday 03 January 2002 04:51, Christian Geuer-Pollmann wrote:
> In this example, an AES128 content encryption key was wrapped using an
> AES256 key encryption key and the after decrypting the cek using
> kw-aes256 the cek is in it's binary encoding. Maybe it would be good to
> introduce a 3rd possible @Type value like 'binaryKey' ?

I'm not sure how much that tells you. I suppose we have a couple of 
(non-exclusive) options

1. Every encryption algorithm URI identifier should have a 1-to-1 mapping 
with a key structure. I believe this has been our assumption to date. 
However, I'd prefer we didn't go this way because its hard to force 
semantics on the Algorithm URIs of others... To the crypto weenies, are 
there many instances of algorithm identifiers which accept multiple 
structures?
2. I'm  proposing that the Algorithm *can* have a specific/deterministic 
structure, in which case one could:
a. repeat the same (Encryption Method Algorithm URI) in the (EncryptedKey 
Type) .
b. if the (EncryptedKey Type) isn't specified assume the (Encryption Method 
Algorithm URI) is sufficient: 1-to1.
2.1 If it doesn't, one would specify the Algorithm and KeyStructure 
distinctly. For example:
<EncryptedKey Type="someEncryptionAlgorithms128bitKey">
   <EncryptionMethod
        Algorithm="&xenc;someEncryptionAlgorithm" />
3. Prohibit XML structures as the plaintext within EncryptedKey. I think 
Takeshi has already suggested this when I asked him how to Encrypt 
<ds:KeyValue/>, he said it should be Encrypted as a EncryptedData. This 
acknowledged that all key formats are binary today, and that they will 
likely be so in the future. This makes sense when one considers key wraps 
and such, but might preclude XML formats in the future...?

Received on Thursday, 3 January 2002 18:27:28 UTC