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

Re: Decryption Transform processing question

From: merlin <merlin@baltimore.ie>
Date: Sat, 15 Jun 2002 01:59:26 +0100
To: reagle@w3.org
Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org
Message-Id: <20020615005926.7BA4544264@yog-sothoth.ie.baltimore.com>

>On Thursday 13 June 2002 06:57 pm, merlin wrote:
>> >Also, by derefencing in the context of the owner document, is this
>> >how you get your exception of "#secret-1" (which was super-encrypted) to
>> >work?
>> Not really. Dereferencing in the context of the owner document
>> is to express that the input may be from the same document as
>> the signature (same-document signature reference) or from a
>> different document (external signature reference). Exception
>> references, which have the appearance of same-document URIs,
>> should actually be evaluated in the context of this document,
>> not the signature document. So, although Except #foo may
>> look like it is excepting an element in the _signature_
>> document with ID foo; it is actually excepting an element in
>> the _signed_ document with ID foo.
>Ok, this is then the same thing as the present text of the CR:
>       When dereferencing
>      dcrpt: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

Yep. My text on exceptions is vestigial.

>> We don't repeatedly dereference exceptions into each decrypted
>> node set; we dereference them once into the input document
>> (because when the signature was generated, that was what
>> they were built for) and then we have a hack that #foo can
>> be dereferenced into a decrypted node set.
>This hack is given by your text:
>    4. Let the set Di+1 be all element nodes in any
>    replacement node set o.d with the namespace URI
>    &xenc; and local name EncryptedData,
>    that are not identified by a barename ID reference from any
>    exception URI in E.
>    5. Repeat steps 3 and 4 for i ? i+1 while
>    Di+1 is non-empty; i.e., as long as new, unexceptional 
>    super-encrypted EncryptedData are identified.
>I understand.

We might also apply the same hack for dereferencing URIs out of
decrypted node sets, which would make more superencrypted cases
work better. For barename references resolved during processing
of EncryptedData in decrypted node sets, we would specify to
iteratively try dereferencing in the outer parents. However,
things would get ugly.

>> Yes and no. The xmlns="" is to cope with the same problem
>> for which we added the xmlns="" text to the xmlenc spec;
>> we are serializing data that will be textually wrapped
>> and so we have to overcome the textual wrapping / default
>> namespace problem.
>> The other part is to overcome the c14n xml inheritance.
>> Consider:
>>   <Document xml:foo="bar">
>>     <SignedInfo Id="signed-info" ... />
>>     <Signature ... URI="#signed-info" ... xml-decrypt#XML ... />
>>   </Document>
>> When I first sign this, c14n inherits the xml:foo attribute
>> into the SignedInfo element. Consider the following encrypted
>> form:
>>   <Document xml:foo="bar">
>>     <EncryptedData Id="signed-info" ... />
>>     <Signature ... URI="#signed-info" ... xml-decrypt#XML ... />
>>   </Document>
>> Serialization of the SignedInfo element will not have
>> included the xml:foo attribute. When we decrypt this,
>> the resulting node set will not have the xml:foo
>> attribute in an ancestor; and, if we c14n the resulting
>> node set without the above augmentation text, things
>> will fail.
>I'm not sure I follow. Presuming we're using c14n and don't do any extra 
>xml:foo processing, after decryption we'll have something just like we did 
>originally as a result of your step 6.
>   <Document xml:foo="bar">
>     <SignedInfo Id="signed-info" ... />
>     <Signature ... URI="#signed-info" ... xml-decrypt#XML ... />
>   </Document>
>Step 7 reparses this and provides it as a node-set.
>Then according to xmldsig, if the last transform provides a node-set, then 
>c14n. The Signature should work, right?

With c14n, when I first start out the node set will be:
  [Document xml:foo="bar"]
    <SignedInfo Id="signed-info" ... />
    [Signature .../]

Here, [] means parts out of the node set. When c14n hits
the SignedInfo, it will result in:
  <SignedInfo xml:foo="bar" Id="signed-info" ... />

At verification time, we'll find this situation:
  [Document xml:foo="bar"]
    <EncryptedData Id="signed-info" ... />
    [Signature .../]

The EncryptedData has a replacement, which is the following
node set:
    <SignedInfo Id="signed-info" ... />

When I'm serializing the main node set, I immediately
hit a replaced element so I jump to the new node set
and it has no xml: attribute ancestors so it fails.

As a result, if we are to use c14n as the canonicalization
algorithm at the end of this transform, we need to inherit
those xml attributes as specified in my text.
>> Unfortunately my solution is broken because if the signer uses
>> exclusive c14n, then things break with this fix in place. I
>> think that we'll just have to specify this as a case that
>> will break if regular c14n is used and I can drop that xml
>> attribute text.
>I'd prefer we not use this text, and if we don't, I think it should work in 
>either case, exc-c14n, or c14n *if* the ancestorial context doesn't change 
>while the fragment was in its encrypted form, as it should be.

My clarification that my solution is broken is itself
broken. The solution works fine because we specify that
regular c14n is done by this transform at the end,
prior to reparsing.

>> >  1.5 Limitations
>> >   Super-encryption MAY cause problems if a super-encrypted
>> > EncryptedData uses same-document references,
>> >
>> >Such as URI="" or URI="#bar" [1]. You use this successfully in
>> > "#secret-1"?
>> The actual EncryptedData elements don't use same-document
>> references. If an EncryptedData uses a same-document
>> RetrievalMethod or CipherReference and is superencrypted
>> then it probably can't be superdecrypted.
>Well, in the specification we should provide examples of all of these 
>things to make it clear.


Received on Friday, 14 June 2002 21:00:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:09 UTC