- From: Joseph Reagle <reagle@w3.org>
- Date: Thu, 7 Mar 2002 12:25:01 -0500
- To: merlin <merlin@baltimore.ie>
- Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org
On Wednesday 06 March 2002 16:31, merlin wrote: > It might be prudent to require that, if an enc:EncryptedData is present > with a non-XML Type attribute, then it must be the (sole root element of > the input | only enc:EncryptedData in the input). Otherwise, operation > is ambiguous; we don't define an order for performing decryptions, > and the current language will return the data from the first non-XML > ciphertext processed. I'm not sure what you mean by "operation is ambiguous" and "don't define an order for performing decryptions." I think I understand your point: it's difficult to envision someone having: <foo> <EncryptedData MimeType="msword"/> <EncryptedData MimeType="png"/> </foo> but there might be one... and then with respect to the "only encEncryptedData in the input", I think the input could have more than one EncryptedData, but that input less those excepted would have to be equal to one? > Also, text that I'd suggest adding about the Except URI would be along > the lines of: > > When dereferencing Except URIs, the application MUST behave as if the > root document node of the input node set is used to initialize the > XPointer evaluation context, even if this node is not part of the node > set. Unlike XML-Signature, the URI may be evaluated against a different > document from the signature document. If the input is a different > document then, as per the XPointer spec, use of the here() function is an > error. Ok: http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt.html#processing $Revision: 1.32 $ -- 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 Thursday, 7 March 2002 12:25:10 UTC