Re: Decryption Transform processing question

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

> 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.

> 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.

Ok.

> 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?

> 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.

> >  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 10:52:55 UTC