Re: Spec/Proposal Draft

Hi Joseph and Blair,

I have some minor comments on [1].  Hope this helps.

Abstract

>The data may be arbitrary binary data, an XML document, or an XML element.
Also the data may be the content of an XML element.

>Otherwise, the enryption element serves as the root of the new document.
"enryption" would be "encryption".


1.3 Versions, Namespaces and Identifiers

>the use of internal entities [XML] or our "enc" XML namespace prefix and defaulting/scoping conventions are OPTIONAL;
It is said that "enc" is used as a prefix, but actually "xenc" is used in section 3.


2.3 Encrypted Key

>The Encrypted Key object always includes the encrypted symmetric key CipherData as a base64 encoded octet sequence.
Both "Encrypted Key object" and "EncryptedKey object" are used for the same object.  Similarly, both "Encrypted Data object" and "EncryptedData
object" are used.

>The latter capability is included primarily to support key update based on existing shared symmetric keys.
This sentence is not clear and should be more clarified with an example.


2.4 Encrypted Data and Key Sharing Object Composition

>As depicted below, ...
There is no figure for this sentence.


>3. Encryption Syntax
This heading would be "Core Encryption Syntax" as described in section 2.

><!ATTLIST schema xmlns:xenc CDATA #FIXED 'http://www.w3.org/2001/02/xmlenc#'>
The default value of this attribute would be "http://www.w3.org/Encryption/2001/03/xmlenc#".


3.1 The EncryptedType

><element name='EncryptionMethod' type='ds:DigestMethodType' minOccurs='0'/>
"ds:DigestMethodType" is used here, but such type is not defined in
[XMLDSIG].  I understand what this mean, but this needs explanation.

>KeyInfo is an optional element, defined by [XMLDSIG], ...
The KeyInfo element used here is defined in this document.


3.2 The CipherData Element

><element ref="ds:transforms" minOccurs="0"/>
"ds:transforms" would be "ds:Transforms".


3.3 The EncryptedData element

>... a KeyName element to indicate a key know by the recipient.
"know" would be "known".

><attribute name='Type' type='uriReference' use='optional'/>
Does this mean the value is like "http://www.w3.org/Encryption/2001/03/xmlenc#Element"?

>2. ElementContent - indicating that the encrypted data represents the content of an XML element (or an entire XML document);
"ElementContent" is not suitable if the data is an entire XML document.  How about defining a new value, "Document", for it?


>3.3 Extensions to ds:KeyInfo Element
"3.3" would be "3.4".

><sequence>
>  <element ref='xenc:KeyRetrievalMethod' minOccurs='0'/>
</sequence>
"KeyRetrievalMethod" may occur zero or more times, so "maxOccurs='unbounded'" has to be specified.  Also the definition of "EncryptedKey" is totally
lacked.


>3.3.1 The EncryptedKey Element
"3.3.1" would be "3.4.1".

><extension base='xenc:EncryptedType'>
>  <sequence>
>    <element ref='xenc:ReferenceList' minOccurs='0'/>
>  </sequence>
>  <attribute name='NameKey' type='string' use='optional'/>
></extension>
The definition of "Recipient" attribute is totally lacked.


>3.3.2 The KeyRetrievalMethod Element
"3.3.2" would be "3.4.2".

>..., except the type attribute is absent since an EncryptedKey element is the only legal result of following the reference.
This differs from the definition, which defines the attribute.


3.5 The ReferenceList Element

>KeyReference elements are used to refer to EncryptedKey objects thata were encrypted ...
"thata" would be "that".


4.1 Encryption

>1. 1. Select the algorithm (and parameters) to be used in encrypting this item.
The number for top items occurs doubly.

>3. 3. Locate the octet sequence to be encrypted.
If the data to be encrypted is an entire document, how is it processed?  The document is also encoded using UTF-8?  If so, an XML declaration which
declare another encoding has to be removed.

>4. 4. 2. If the data being encrypted is an external octet sequence, replace the value with the encrypted result and create an EncryptedData structure
 referencing the encrypted data.
Is it necessary to replace the value with the encrypted result?  If a user
has no write permission to the value, this process will fail.


[1] http://www.w3.org/Encryption/2001/03/12-proposal

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



From: "Joseph M. Reagle Jr." <reagle@w3.org>@w3.org on 2001/03/16 08:17 AM

Please respond to "Joseph M. Reagle Jr." <reagle@w3.org>

Sent by:  xml-encryption-request@w3.org


To:   "XML Encryption WG " <xml-encryption@w3.org>
cc:
Subject:  Spec/Proposal Draft




Blair and I have been working on [1] trying to get it to reflect decisions
made at the FTF, move requirements to the requirements document, and focus
on the organization and normative sections of the document such that we can
quickly close on open issues and publish it as a WG Working Draft. It's
definitely a work in progress, and in some ways a bit rougher, but I hope
its a couple steps in the right direction.

The algorithm section has been removed, and I hope Don and others will be
able to spend some time on that. Also, a lot of text is being merged into a
section 2 (Overview with examples) like in the dsig spec. The text is still
rough and the examples have been removed, but I'm hoping over the next week
we should be able to integrate the examples back in with section 2 in a way
that builds up an understanding in the readers mind -- among the many other
things to do! <smile/>

[1] http://www.w3.org/Encryption/2001/03/12-proposal

__
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 Tuesday, 27 March 2001 02:26:03 UTC