Re: Encryption: Decryption Transform for XML Signature

Joseph,

>> We don't persist in the use of the element, and if you and others think
>> so, we can change it to another.
>
>I've changed it to Except (and use the algorithm identifier URI as the
>namespace for the element), and I'm much happier with that now that I
think
>about it, if others aren't, please say so. The example now looks like:

If we define a new element like Except, we'd like to change the URI
attribute to Idref or something like that.  If we do so, the following
restriction on the value of the attribute is not necessary:

>The value of the URI attribute of the enc:DataReference element
>MUST be a non-empty same-document URI reference [URI]
>(i.e., a number sign ('#') character followed by a fragment identifier)
>and identify an enc:EncryptedData element.

>> >Also, is X in either function always the whole document, or can it be
>> > some subset?
>>
>> X is always the whole document.
>
>[Definition: Let X be a node-set representation /+of an XML document. +/
>Let e be the first element node in X. A parsing context of X consists of
>the following items: ...

Sorry, I was wrong.  X may not be a whole document because X can be
filtered by the previous transform.

>> I'm sorry, but this sentence may be a little confusing.  Our question is
>> whether this transform should support types other than Element or
>> Content, such as image/gif.  In that case, we have to change the
>> processing rules.
>
>What is the scenario? Even if you have an image/gif in the XML, it will be
>encoded and will likely be available as Element Content ...?

Suppose a scenario where Alice signs an external image/gif, but she also
knows that the image/gif will be encrypted to an EncryptedData element, and
so adds the decryption transform.  The current processing rules don't fit
the scenario.

>How is this wrapping performed? (This is also related to my confusion
about
>steps 1/4 of serialization/parsing). Since it's octets, I presume one is
>pre/post-pending the octet representations of UTF-8 encoded characters of
>the document type declaration and dummy elements?

Yes, you're right.

>Also, when I do the
>actual decryption, I'm finding the offset into the octets and processing
>that data, right? Or are you re-parsing it (or finding the SAX event) to
>find the actual CipherData?

I think that it's difficult to find the offset without using an XML
processor.  So usually the octets will be re-parsed.

>Why can't we do this? (Is this a limit of Encryption or DOM?) I'm not
>concerned about the creation of the new node-set Y, but of the
>serialization/parsing. Particularly the serialization as we already know
>c14n is a very expensive process and we will have to do this for every e
in
>R. One might be able to perform an optimization such that if there are 3
>elements (e) in R, when decrypt(X,e,C) is called each time it re-uses the
>serialization of X from the first pass... Since C might be different for
>each e, I don't think anything else can be saved between iterations...

Because an XPath node-set consists of nodes in a document and does not have
any concept to import nodes from other documents.  As for serialization,
C14N isn't required because a parsing context is always added.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com

Received on Thursday, 20 September 2001 12:45:49 UTC