Re: Proposal for XML Encryption Syntax and Processing

At 14:40 12/15/2000 -0800, Blair Dillaway wrote:
>We look forward to comments and continuing discussions
>to resolve the open issues identified in this document.

Comments for [1] follow:

[1] 
http://lists.w3.org/Archives/Public/xml-encryption/2000Dec/att-0024/01-XMLEncryption_v01.html

>Non-goals within this specification include:
>·        Ability to encrypt arbitrary sub-portions of an XML document

This might be read as not even permitting element-wise, perhaps, "... beyond 
XML elements."

>·        Elimination of potentially dangerous attribute encryption support

The danger results from the likely value of the attribute, not the attribute 
itself: repetitive and short. Elements could have similar problem. (Kind of 
unfair to note this is the reason attributes are exlcluded, but then in 
section 8 say it's still an open issue that could be solved, where that 
solution could work for attributes too...?)

>2.3 Encrypted Data
>Encrypted Data is a first class object and must be represented as a 
>distinguished XML document fragment

Not sure what "distinguished XML document fragment" means. Does it mean an 
element?

>To meet the needs of key applications, this specification supports 
>encryption of:
>·        An XML Element, including the element tags

Does this mean the octects representing the element starting with the start 
tag and ending with the end tag in the immediate file? Or the octects of the 
UTF-8 encoding of that charcter? (See [1] for Martin's comment of what would 
happen if encoded/encrypted in one format, and the rest of the document 
changes).

[1] http://lists.w3.org/Archives/Public/xml-encryption/2000Dec/0016.html

[Later] Answer: I see in section 4.1 step 3.1 that Martin's concern appears 
to be addressed.

>·        An XML NodeList representing the contents of given XML Element

What is this nodelist? (What datamodel (e.g., DOM, XPath), and serialization?)

[Later] Question: section 4.1 step 3.2, I'm still confused if NodeList is 
meant to mean element content or an abstract node list serialized somehow?

>The Encrypted Data objects are independent and it is not valid to nest 
>these objects, i.e., an Encrypted Data may not be a child of an Encrypted 
>Data.

But can a EncryptedData contain cyphertext, which is an encrypted form of 
another EncryptedData?

>The preferred approach is definition of a method for marking an XML Digital 
>Signature “Signature” element to indicate when the signature has been 
>computed over cipher text.   This would indicate the cipher text should not 
>be decrypted prior to signature verification.  Alternate approaches, such 
>as marking encryptions applied after a signature, are viewed as unworkable 
>since both signatures and encryptions may be applied over external data via 
>references

Given, this proposal doesn't provide these mechanisms, and it makes Hal's 
security recommendation, why not go the whole way. I thought a proposal was 
state that:

>One approach would be, when signing before encrypting, to always encrypt
>the signature block along with the data being encrypted.  This is good for
>two reasons.  First, since the sig can't be verified without decrypting
>the data, you might as well do this.
http://lists.w3.org/Archives/Public/xml-encryption/2000Nov/0064.html

That way, you can always verify the signature you can see as you unwrap 
them. Does this not work because of external references?

>Type is an optional attribute identifying type information about the 
>decrypted content.

Presently it's a token or media type. I'd like it to be a URI for 
consistency with Signature:
http://www.w3.org/2000/11/temp-xmlenc#Element
http://www.w3.org/2000/11/temp-xmlenc#NodeList

>ReferenceList is an element that contains pointers from keys to data 
>encrypted by the keys.  Links in the opposite direction are provided by the 
>EncryptedDataReference elements placed in the KeyInfo element.

Should these be based on XLink?

>3.7 The EncryptedReference element
>The EncryptedReference element provides a way to indicate that data, over 
>which an XML Digital Signature (xmlns:ds) has been computed, was encrypted. 
>In essence, it indicates the data should not be decrypted prior to 
>signature verification.

External elements are not allowed in dsig:Reference. You would have to ask 
that the Signature content model be changed, or put it in the transforms. 
Additionally, does this then presume an implicit transform that if this 
element is not present, then decryption can occur?

8.4 Open Issues
>The alternate proposal is to only allow an EncryptedKey element as a child 
>of a KeyInfo element.

Why not jusr use dsig:KeyInfo, which permits content from anynamespace 
including your own EncryptedKey?

<enc:EncryptedData>
   <dsig:KeyInfo>
     <enc:EncryptedKey/>
   </dsig:KeyInfo>
</enc:EncryptedData>

2. or it's much more elegant to make an enc:KeyInfo an extension of 
dsig:KeyInfo with the extra element?

  <complexType name="KeyInfoType">
   <complexContent>
    <extension base="dsig:KeyInfoType">
     <sequence>
      <element   name="EncryptedKey" type="enc:EncryptedKeyType"/>
     </sequence>
    </extension>
   </complexContent>
  </complexType>



__
Joseph Reagle Jr.
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/

Received on Monday, 8 January 2001 18:08:56 UTC