W3C home > Mailing lists > Public > xml-encryption@w3.org > March 2002

Re: Why is Except limited to local fragments?

From: Joseph Reagle <reagle@w3.org>
Date: Wed, 6 Mar 2002 15:51:07 -0500
Message-Id: <200203062051.PAA13423@tux.w3.org>
To: "Takeshi Imamura" <IMAMU@jp.ibm.com>, merlin <merlin@baltimore.ie>
Cc: "Hiroshi Maruyama" <MARUYAMA@jp.ibm.com>, xml-encryption@w3.org

Ok, this is represented in [1] with some tweaks. 

http://www.w3.org/Encryption/2001/Drafts/xmlenc-decrypt 
$Revision: 1.30 $ on $Date: 2002/03/06 20:50:31 $ GMT by $Author: reagle $ 

On Monday 04 March 2002 10:49, Takeshi Imamura wrote:
> >> We may need a fragment of text to further clarify XPointer support
> >> when it is applied to a different document from the signature.
> >> In such a case, here() is an error and the XPointer initial context
> >> is the root of the new document? We don't have this problem with
> >> XPointers in dsig because they always refer to the same document.
> >
> >I'm not sure I understand this, I'll defer to the authors. <smile/>
>
> Merlin, you are right.  As you say, we should add some text for XPointer
> support.  Can you suggest it?
>
> >> On a separate note, should we profile the decryption transform to
> >> allow non-XML content (output is an octet stream)?
> >
> >We discussed the scenario below in September and Hiroshi suggested we
>
> would
>
> >need a new function:
> >  Instead, we should define a new function that decrypts an
> >  xenc:EncryptedData element with a type other than Element
> >  or Content to an octet stream.  Also we have to state that
> >  when such an xenc:EncryptedData element is being
> >  decrypted, the input to the transform has to be a node-set
> >  that has the xenc:EncryptedData element as the first node.
> >  http://lists.w3.org/Archives/Public/xml-encryption/2001Oct/0000.html
> >
> >As is my tendency I tend not to push for something unless someone says
>
> they
>
> >want it. Hiroshi/Takeshi, is Merlin's usage scenario the same as what
> > you were thinking? If so, would you like to propose some text?
>
> If such a scenario is necessary, we could support it by changing the
> processing rules slightly.  They would be roughly as follows:
>
> Z = decryptIncludedNodes(X, R)
> 1. Select an EncryptedData element within X (say e) that is not
> referenced by any Except element in R, or return X if such e cannot be
> selected. 2. If the value of the Type attribute of e is Element or
> Content, 2.1. Let C be a parsing context of X.
>      2.2. Let Y be decrypt1(X, e, C).  If this function succeeds, replace
> X with Y.
>      2.3. Go to Step 1.
>    Else
>      2.4. Let Y' be decrypt2(X, e).
>      2.5. Return Y'.
>
> Y = decrypt1(X, e, C)
> 1. Let Y' be decrypt2(X, e).
> 2. Wrap Y'in the context of C into an octet stream.
> 3. Parse the octet stream into a node-set.
> 4. Trim the node-set into Y.
> 5. Return Y.
>
> Y' = decrypt2(X, e)
> 1. Convert X into an octet stream.
> 2. Decrypt the element corresponding to e and replace it with the
> resulting octet stream into Y'.
> 3. Return Y'.
>
> Note that the input is still a node-set and the output is a node-set or
> octet stream depending on the input.
>
> Thanks,
> Takeshi IMAMURA
> Tokyo Research Laboratory
> IBM Research
> imamu@jp.ibm.com

-- 

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 Wednesday, 6 March 2002 15:51:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:20 GMT