Re: Spec/Proposal Draft

Hi Takeshi,

All suggestions were accepted except those noted belowl.
Resulting URI.
         http://www.w3.org/Encryption/2001/03/22-proposal.html

At 16:25 3/27/2001 +0900, Takeshi Imamura wrote:
> >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.

I'll let someone else propose what is meant by this. (Plus, this section is 
going to be tweaked with examples.)

>2.4 Encrypted Data and Key Sharing Object Composition
>
> >As depicted below, ...
>There is no figure for this sentence.

Yes, section 2 is going to be rewritten with examples integrated back in.

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

ok.

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

It's not part of the spec per se, but more of a topic for discussion as we 
decide how to use the dsig structures, these will be eliminated at some 
point, but right now they are more reminders to me.

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

Yep, once we get our dsig reuse decided, these should get fixed.

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

Ok.

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

Ok.

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

Potentially, (see the email I sent yesterday).
http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0064.html

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

Right.
http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0064.html

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

Ok.

> ><sequence>
> >  <element ref='xenc:KeyRetrievalMethod' minOccurs='0'/>
></sequence>
>"KeyRetrievalMethod" may occur zero or more times, so 
>"maxOccurs='unbounded'" has to be specified.

Now
     <element name='KeyInfo' type='enc:KeyInfoType'/>
     <complexType name='KeyInfoType'>
       <complexContent>
         <extension base='ds:KeyInfoType'>
           <sequence>
             <element ref='enc:KeyRetrievalMethod'
              minOccurs='0' maxOccurs='unbounded'/>

>Also the definition of "EncryptedKey" is totally
>lacked.

?this is section 3.4.1

>The definition of "Recipient" attribute is totally lacked.

Fred noted this and has since been added.

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

Fixed. But we could
1. Use ds:RetrievalMethod and state that its type should always be 
&enc;#EncryptedKey.
2. Use enc:KeyRetrievalMethod and remove the Type all together and have the 
type be implicit.

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

I don't see this anymore (might've been fixed already.)

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

I would argue as I did in
        http://lists.w3.org/Archives/Public/xml-encryption/2001Mar/0064.html
>* Documents: The earlier encryption proposal specified that "For an entire 
>document, the decrypted result will be a list of nodes including the prolog 
>and root element." In this case, we need to support encryption of the 
>Document Information Item, or encrypt XML documents as a bag of octets with 
>Type="http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml"



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

This is kind of philosophical, but when we encrypt, should we speak of 
copying the original document and making the changes, or replacing the 
original document?




__
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 Wednesday, 28 March 2001 17:01:28 UTC