- From: merlin <merlin@baltimore.ie>
- Date: Tue, 16 Jul 2002 16:36:49 +0100
- To: xml-encryption@w3.org
r/reagle@w3.org/2002.07.15/15:10:07 >On Monday 15 July 2002 02:43 pm, merlin wrote: >> I agree that greater detail would aid interoperability; however, I'm >> not sure how to express the details. How about: >> >> 4.3.2 A Decrypt and Replace Implementation (Non-normative) >> >> Where X is the [XPath] node set corresponding to an XML document >> and e is an EncryptedData element node in X. >> >> 1. Decrypt e in the context of its parent node as specified in the >> Decryption Implementation (section 4.3.1) yielding Y, an [XPath] >> node set. >> 2. Include Y in place of e and its descendants in X. >> >> The actual implementation of step 2 is outside the scope of this >> document; however, the result MUST be equivalent to replacing e with >> the octet stream resulting from its decryption in the serialized form >> of X and reparsing the document. >> >> I'm not so keen on the old 'Z' text because we're specifying >> a function that has the express purpose of mutating X, not >> returning a new node set. > >That's fine with me, my question then is with respect to this serialization, >do you care *how* it is serialized? (Is this necessarily Canonical XML?) C14n isn't necessarily right because it will not output entity declarations. I was hoping to punt to the serialized form that X was constructed from; but, of course, there may not have been an original serialized form. Actually, that's a problem: Our defined wrapping (emit entity declarations) cannot be implemented on DOM; DOM does not expose that information. Is it really necessary? Could we assume/require that serialized/encrypted XML does not use entity references and strip that text from the spec? In that case, c14n would be fine, presuming that X isn't a weird node-set, and life would be easier. Merlin
Received on Tuesday, 16 July 2002 11:37:22 UTC