Re: xenc:EncryptedKey/@Type

Hm, but how can I decide in which format a particular key is? Let's look at 
an example:

<EncryptedData>
   <EncryptionMethod
        Algorithm="&xenc;aes128-cbc" />
   ...
</EncryptedData>
<EncryptedKey>
   <EncryptionMethod
        Algorithm="&xenc;kw-aes256" />
   ...
</EncryptedKey>

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' ?

But what happens if I encrypt an XML-encoded PGP content encryption key:

<EncryptedData>
   <EncryptionMethod
        Algorithm="http://www.openpgp.org/#xml-key" />
   ...
</EncryptedData>
<EncryptedKey Type="&xenc;Element">
   <EncryptionMethod
        Algorithm="&xenc;aes128-cbc" />
   ...
</EncryptedKey>

From what I see now, the xenc:EncryptedKey/@Type attribute is not used for 
all possible key types which are described in our current spec because all 
'wrappable' keys are in their binary representation. Problems could arise 
if we try to encrypt a structure like

<PGPData>
<PGPKeyPacket>
A.REALLY.LARGE.PACKET.A.REALLY.LARG
E.PACKET.A.REALLY.LARGE.PACKET.A.RE
ALLY.LARGE.PACKET.A.REALLY.LARGE.PA
CKET.A.REALLY.LARGE.PACKET.
</PGPData>
<PGPKeyPacket>

using #rsa-oaep-mgf1p cause this can probably only wrap 127 or 255 bytes 
(depending on your keys modulus).

--On Mittwoch, 2. Januar 2002 16:59 -0500 Joseph Reagle <reagle@w3.org> 
wrote:

> I'm not opposed to the plaintext of EncryptedKey being some literal key
> corresponding to the EncryptionMethod algorithm. But my concerns on that
> front are:
>
> o Loss of generality.
>
> o Are we sure that there is a correspondance between EM Algorithms and
> key  structures? I don't believe so. In those instances where this is the
> case,  I'd recommend repeating the algorithm URI in the EncryptedKey
> Type, *or*  stating that absent the EncryptedKey Type, the algorithm
> method is  sufficient to also give the format.
>
> And the spec already says:
>
> o "2.2.2 EncryptedKey (ReferenceList, ds:RetrievalMethod, CarriedKeyName)
> [t15] ... (Note, an EncryptedKey's EncryptionMethod is the algorithm used
> to encrypt these octets and does not speak about what type of octets they
>  are.)"
>
> o "4.1.2.2 ... The result may then be a child of ds:KeyInfo"
>
>
> On Wednesday 02 January 2002 16:06, Christian Geuer-Pollmann wrote:
>> Hm, this would mean that some assumtions are possibly no longer valid: It
>> was decided that the Nonce attribute is not available for
>> xenc:EncryptedKey because we encrypt high-entropy things like raw
>> cryptographic keys. Question: If we encrypt XML text which contains
>> high-entropy data, do we need a xenc:EncryptedKey/@Nonce attribute?
>>
>> Additionally, the algorithms section will become much more complicated:
>> Block Encryption algorithms like tripledes-cbc, aesXXX-cbc, would have to
>> be used to encrypt keys -- or should we use wrap algorithms like
>> kw-tripledes and kw-aesXXX to wrap XML-encoded keys?
>>
>> And - if we go to the very end - a PGPKey is nothing else like an RSA,
>> DH, IDEA or TwoFish key which all have a binary representation. AND - if
>> we look in the XML Signature implementations - until now, nobody
>> implemented the PGP things...

Received on Thursday, 3 January 2002 04:38:29 UTC