RE: Proposal for XML Encryption Syntax and Processing

Joeseph,

Thanks for the comments. I've provided my take on these issues below.  The
other authors of the proposal may have different opinions.

Blair

> -----Original Message-----
> From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
> Sent: Monday, January 08, 2001 3:09 PM
> To: Blair Dillaway
> Cc: Public XML Encryption List
> Subject: 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."

I agree this wording could be improved.  The intent was to state when
encrypting XML one must encrypt complete nodes and thier children.  For
example, we don't allow one to encrypt just part of a Text node that is a
child of an Element, nor do we allow one to encrypt an Element but not its
children.

> 
> >*        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...?)

Your point is well taken.  I do remain concerned however that one is more
likely to  run into these problems when encrypting only Attribute values.
My primary concern with Attribute encryption is the complexity it introduces
without a clear statement of the value it brings to using applications.

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


I believe this was my wording, and I agree it could be clearer.  Yes, it
refers to a well formed XML 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.

Sounds like there isn't a issue here, but probably need to do some
additional clarification.

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

NodeList - we should have defined this.  It refers to the ordered collection
of Nodes contained within an Element.  In terms of the DOM, its the Nodes
within an Element starting with the first Child and proceeding with a depth
first traversal until all children of the Element have been enumerated.  I'm
pretty sure this crept into the document based on some earlier discussions
on this topic.

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

Yes.  The spec should make this clear.  Jim Schaad answered this question on
the list a little while back.

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


There are a couple concepts mixed in this discussion, I'm not sure I'm
completely following you.  But, I don't believe an encryptor can reliably
determine if data is signed, or even locate the Signature element, given
that signatures may be detached.  That said, if one knows knows the data to
be encrypted is signed and has access to the Signature element, then its
best to encrypt both.


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

I have no objection to making the 'type' a URI.

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

I'd need to go back and review XLink before commenting.  Perhaps those more
knowledgeable in this area can make a recommendation.

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

Good catch.  The transform approach might work, but I'd want to think
through the implications. If computing a signature over an "EncryptedData"
element, then the signer would note this to ensure the verifier knows not to
decrypt first.  It would be implicit the EncryptedData should be decrypted
first if no EncryptedReference exists.

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

that is the alternate proposal.

> 
> <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 Tuesday, 9 January 2001 13:13:13 UTC