RE: What's in a EncryptedKeys' CipherData?

Blair is no correct.

If you process an EncryptedKey block, what you get at the end is something
of type OctetString.  In my opinion this is good news not bad.  For one
thing it makes the use of keyed hashes easier in one respect, the key for
the hash does not have to match the length of some random (and extrainious)
symetric cipher algorithm.

I think this is desired behavior and should not be changed.

jim

> -----Original Message-----
> From: xml-encryption-request@w3.org
> [mailto:xml-encryption-request@w3.org]On Behalf Of Blair Dillaway
> Sent: Friday, April 06, 2001 3:11 PM
> To: Joseph M. Reagle Jr.
> Cc: jimsch@exmsft.com; XML Encryption WG
> Subject: RE: What's in a EncryptedKeys' CipherData?
>
>
> My apologies, I misunderstood you point.
>
> The EncryptedKey element contains all the information
> you need to properly decrypt the CipherData and
> obtain the octet sequence for the raw key material.
> But you are correct in that you don't know what to
> do with this until you go to decrypt an EncryptedData
> and discover what its EncryptionMethod is.
>
> In general, I don't see that this creates any problems.
> All keys look like octet sequences of random bits until
> you plug them into a specific algorithm for use.
>
> The one case where someone might care is if they want
> to cache keys inside some hardware device that supports
> multiple algorithms.  If they recieved an EncryptedKey
> to cache for later use with EncryptedData, then they
> couldn't load the key into the device until the
> first EncryptedData arrives.
>
> Do folks think this is an issue we need to address?
>
> Blair
>
>
>
>
> -----Original Message-----
> From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
> Sent: Friday, April 06, 2001 2:48 PM
> To: Blair Dillaway
> Cc: jimsch@exmsft.com; XML Encryption WG
> Subject: RE: What's in a EncryptedKeys' CipherData?
>
>
> At 14:23 4/6/2001 -0700, Blair Dillaway wrote:
> >Well no.  Either you know the EncryptionMethod for the EncryptedKey
> >implicitly
> >or else it is provided by the EncryptionMethod element within the
> >EncryptedKey element. EncryptionMethod information for an
> EncryptedData
> >isn't relevant.
>
> Yes it is. (I think). If I want to know of what type of data that raw
> octet
> set (when decrypted from within an EncryptedKey is), I have to go
> elsewhere.
>
> I now realize were my confusion from this and NameKey is coming from.
>
> If I have an EncryptedData that is relying upon and EncryptedKey,
> consider
> the symmetric key secured in that EncryptedKey. That set of octets has
> some
> properties.
>
> (octets)
>     --name--> NameKey element of the parent EncryptedKey
>     --type--> EncryptionMethod of a referring EncryptedData
>
> The tricky bit is when you look at the proposed structures,
> some of the
> elements/attributes (like KeyInfo) are used to convey
> information about
> that
> data object (EncryptedData and EncryptedKey) and others are used to
> convey
> information about a resource to which to they relate (but
> doesn't become
>
> revealed until they are processed.)
>
>
> __
> 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 Saturday, 7 April 2001 00:34:06 UTC