Re: Minor comments on the spec

[Don, note that I've edited section 5, and much of the bibliography.

  http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/
  new revision: 1.60
]

On Friday 12 October 2001 6:47, Takeshi Imamura wrote:
> Hi,
>
> I have some minor comments on [1].  Hope these help.

Thank you!

> 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.

> 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."

> 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:


  <element name='CipherReference' type='xenc:CipherReferenceType'/>
   <complexType name='CipherReferenceType'>
       <sequence>
         <element ref='ds:Transforms' minOccurs='0'/>
       </sequence>
       <attribute name='URI' type='anyURI' use='required'/>
   </complexType>

> 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.

> 3.4.1
> The identifier of the EncryptedKey element would be
> "http://.../xmlenc#EncryptedKey".

Ok.

> 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.

> 3.6
> "RetrievalMethod" would be "Reference".
> The EncryptionProperties element can contain information items not only
> on the EncryptedData element but the EncryptedKey element.

Ok.

> 5
> In Section 5, a term "encryption application" is used for an
> implementation of the spec.  It is very confusing and should be changed
> to
> "implementation" or something.

Ok, I've tried to tweak this and the REQUIREMENT tokens to be a bit more 
consistent in use. Also (Don) is the whitespace in some of the base64 
encoded examples purposeful, or a result of my editor?

Don, I also added a reference to [CMS-Wrap], should we change the excerpted 
text as well? 

[CMS-Wrap] 
http://www.ietf.org/internet-drafts/draft-ietf-smime-key-wrap-01.txt

> 5.2
> No padding algorithm is specified.  I suppose the PKCS5 padding, but is
> that correct?
>
> 5.4
> The key type is given not only by the EncryptionMethod element of the
> EncryptedKey element but that of the EncryptedData element.
> The 2nd paragraph is confusing.  It would be as follows: "Key Transport
> algorithms may optionally be used to encrypt data in which case their
> identifiers appear as Algorithm attributes to EncryptionMethod elements
> that are children of EncryptedData.  Because they use public key
> algorithms, Key Transport algorithms are not efficient for the transport
> of any amounts of data significantly larger than *a*symmetric keys."

Don?

> 5.4.1
> "CipherData" in the example would be "CipherValue".

Ok.

> 5.4.2
> The DigestMethod element in the example has to be prefixed with "ds:".

Ok.

> 5.6.2
> "168" in the step 1 of the wrapping algorithm would be "192".

Ok.

> 5.7
> I think that it has been decided that the message digest algorithm is not
> used in the CipherData element.

s/are used/can be used/

-- 
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 Friday, 12 October 2001 20:11:47 UTC