Re: Minor comments on the spec

Joseph,

>> 3.1
>> The Type attribute is still in the schema.  The attribute should be
moved
>> to the schema of the EncryptedData element.
>> There is no explanation for the EncryptionProperties element.
>> "ElementContent" would be "Content".
>
>Type was moved into EncryptedType since it belonged to EncryptedData and
>EncryptedKey, I forgot to move its text when I did that, but I fixed that
>in the last edit.

Is the Type attribute also needed for the EncryptedKey element?  I could
not find such a description in the spec.

>> 3.2
>> I believe that a nonce value specified using the Nonce attribute is used
>> only when encrypting data (not key).  Is that correct?  If so, that
>> should be explained explicitly.
>
>Tweaked to, " Given that data is often redundant (e.g., XML) and that
>attackers may know the data's structure, applications are RECOMMENDED to
>encrypt data with high entropy, either by its own nature or by use of the
>Nonce attribute."

So should the implementation give a warning when a user is encrypting a key
with a nonce value and/or decrypting a key encrypted with a nonce value?

>> 3.2.1
>> Transform elements and an XPath element in the example have to be
>> prefixed with "ds:".
>
>Ok. BTW, why is Transforms not from ds? Was there a purposeful reason we
>didn't use the following:

Yes.  Please see
http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0015.html

>> 3.4
>> The EncryptedKey element can specify elements not only via the
>> DataReference element but the KeyReference element.
>> I don't understand how the KeyValue element is used.  Is the element
used
>> for containing a key that is not protected?
>
>I removed the reference to KeyValue and rewrote that section, please
review.

Sounds good to me.

>> 3.5
>> Because the URI attribute is optional, the behavior should be noted when
>> the attribute is omitted.
>> Transform and XPath elements in the example have to be prefixed with
>> "ds:".
>
>Do we have any reason why it should be optional? If so, we should defer to
>application context, if not, we should make it mandatory.

I don't see any reason.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com

Received on Monday, 15 October 2001 01:49:34 UTC