>3) Is the motivation for a DataReference in an EncryptedKey
>EncryptionMethod element to allow a processing optimization
>for decryption of all the encrypted elements for that key?
I think so, but I'm still unsure how DataReference and KeyReference
elements are processed during decryption. The draft just says in section
4.2:
>3. If necessary, decrypt the data encryption key.
>Alternatively, retrieve from some local store using
>the provided attributes or implicit binding.
This rule should be more clarified so that we can understand how a
decryption processor finds a key.
Also as described in section 8.3, the draft does not define syntax for
specifying a key, using only key attributes, along with a reference list.
The syntax should be defined in this spec if EncryptedKey element is
allowed to contain an element for a reference list. (The syntax does not
have to be defined, otherwise) But once the syntax is defined, it is
natural that only the syntax is responsible for a reference list and
EncryptedKey element does not contain an element for a reference list. We
would define the following elements:
<EncryptedKey>
<EncryptionMethod>
<KeyInfo>
<CipherText>
</EncryptedKey>
<EncryptionInfo>
<EncryptedKey>
<KeyInfo>
<ReferenceList>
</EncryptionInfo>
Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
E-mail: imamu@jp.ibm.com
From: "Frederick J. Hirsch" <hirsch@caveosystems.com>@w3.org on 2001/01/23
05:53 AM
Please respond to "Frederick J. Hirsch" <hirsch@caveosystems.com>
Sent by: xml-encryption-request@w3.org
To: <xml-encryption@w3.org>
cc:
Subject: XML Encryption questions
I have questions/comments about XML encryption, regarding the draft
XML Encryption Syntax and Processing, Version 1.0 15-December-2000.
1) Is the Initialization Vector (IV) in the Algorithm namespace? (Section
5.2)
Is that what the s0 namespace is implying? Shouldn't the example read:
<s0:IV xmlns:s0='urn:nist-gov:aes-128-cbc'>ABCD</s0:IV>
I'm not sure what I am missing, but an arbitrary namespace does not seem
correct.
2)Section 2.5 on invalid nesting is still unclear to me. Are not the
constraints implied in this section addressed by the schema definitions of
EncryptedKey and EncryptedData in section 3.1? I'm not sure why one would
want
to define the EncryptedData element recursively.
On the other hand, one would want to be able to encrypt elements which have
already been encrypted, but from the discussion on this list that is
allowed.
3) Is the motivation for a DataReference in an EncryptedKey
EncryptionMethod
element to allow a processing optimization for decryption of all the
encrypted
elements for that key?
4) If it is necessary to hide the content type (e.g. in the video example
in
section 5.8) then would the correct alternative be to encrypt the entire
video
element rather than just the referenced content?
5) Why not call the NameKey attribute "KeyName" in the EncryptedKey
element?
KeyName would be consistent with the KeyName element in the EncryptedData
element.
thanks
< Frederick