Re: Suggestions for requirements ...

At 10:51 10/28/2000 -0700, Steve Wiley wrote:
>Yes, it would be in opposition if it was the same implementation.  The 
>requirement is as you surmised. "one should have the option not to change 
>the original tag structure".  I did not intendthis to be a requirement of 
>XML Encryption.  The requirement is that an implementation should be able 
>to have a requirement and have the ability to implement the requirement 
>"the original document structure not be changed".

Ok, I reflect this in the beta requirements document as:

C XML Encryption applications must not violate the DTD/schema valid of the 
target instance. "We have encountered several applications where the 
customer wishes to encrypt attribute or element CDATA without changing, 
adding, or deleting any XML tags." {MyProof}
1. To satisfy this requirement the document to be encrypted SHOULD be 
referenceable from an external document via XPath. {MyProof}
2. Any "[XPath] feature causes serious performance problems because the 
document must be fully buffered in order to apply the XPath expression." 
{Andy Clark}

>>What exactly do you mean by an encryption/decryption protocol [1]?
>
>A set of rules for encryption and decryption that guarantee the integrity 
>of the document.
>a. The document can be restored to its original pre-encryption form.
>b. That all the information originally encrypted by a single key can be 
>retrieved.  (But not necessarily with that key alone.)

My own understanding of a formal definition of a protocol in this context 
could certainly be improvemed, but in xmldsig parlance (where my mind's been 
most recently engaged) we called that the processing rules.

>The example below shows how information may be hidden by later 
>encryptions.  I believe that the integrity of a document that allows 
>multiple encryptions and multiple encryption keys requires that a precise 
>set of rules and procedures be followed by the entities that are performing 
>encryption or decryption.  I think that this fits the definition of a 
>protocol. Let me know if you differ.

Your application description and scenarios sounds like something XML 
Encryption should be able to support and while I can't argue that doesn't 
involve a protocol, I suspect we'll end up using the word "protocol" for 
something else that might be out of scope (presumptions about state in 
communication, request/respond, etc.)


__
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, 30 October 2000 17:46:34 UTC