Re: Decryption Transform processing question

Hi Joseph,

r/reagle@w3.org/2002.06.13/17:01:23
>On Wednesday 12 June 2002 06:09 pm, merlin wrote:
>> Here is a quick bash at a more formal specification of what I
>> propose, taking into account what I believe you have suggested.
>
>Hi Merlin, this looks promising, I've provided some comments below and look 
>forward to reading Takeshi's and others' comments.
>
>
>    1.3.2 Processing Model of Binary-Mode Decryption Transform
>   The input to this transform is a node set N. The parameter to this
>   transform is a set of exception URIs E. The output is a node set O,
>   computed as follows:
>
>
>As an aside, you're using a slightly different set of tokens to identify 
>things, in some places conflicting with previous tokens. In the end we 
>should harmonize their usage across the specs.

Right; I just picked tokens from the air as I needed them.

>    1. Dereference each exception URI e, from E, in the context of the
>       owner document of the input node set N, resulting in the location
>       sets x[e].
>
>
>A location set is like an XPath node-set but includes points and ranges 
>[1]. The present text speaks of, "not referenced by any dcrpt:Except 
>elements." Is your intent just to be specific, or to purposefully permit 
>ranges?

My intent is to purposefully permit exactly the same processing
as XMLDSIG[1]; more text or an explicit reference is obviously
needed.

[1] http://www.w3.org/TR/xmldsig-core/#sec-Same-Document

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

Support for dereferencing #foo into a decrypted node set is
a hack that is necessary for autosuperdecryption to work
in the limited (but probably prevalent) case of barename
XPointer exceptions.

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.

>[1] http://www.w3.org/TR/xptr/#dt-locset
>
>   Algorithm Identifier
>          [9]http://merlin.org/xml-decrypt#XML
>
>Have you ever looked at merlin.org? <smile/>
>
>    1.4.2 Processing Model of XML-Mode Decryption Transform
>
>    6. Canonicalize the input node set N according to C14N (with
>       comments); but, in place of any EncryptedData element d, from any
>       D[i], and its descendants, canonicalize the decrypted node set
>       o[d]. Let the resulting octet stream be C.
>          + Canonicalization of replacement node sets must be augmented
>            as follows:
>               o An xmlns="" declaration must be emitted with every apex
>                 element that has a null prefix and namespace URI.
>               o If a node set is replacing an element from N whose
>                 parent element is not in N, then its apex elements must
>                 inherit attributes from the xml namespace.
>
>So this accounts for the "target context" problems with default namespaces 
>and xml:lang/xml:base?

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.

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.

>    1.4.3 Example of XML-Mode Decryption Transform
>   Much of the encrypted data and signature are elided. The Except
>       Note that part of the second node set has been super-encrypted.
>     * After this decryption stage, two new EncryptedData have been
>       revealed. However, the first matches a barename XPointer exception
>       URI and so is not considered further; hence, D[1] contains just
>       the EncryptedData element d[data-2]. This is decrypted again,
>       resulting in the following node set o[data-2]:
>
>
>This is because the barename XPointer is interprated relative to the input 
>document?

It only works because we have a hack that barename XPointers
can select EncryptedData elements in decrypted node sets.
Interpretation relative to the input document only occurs once
for the initial round of decryption. After that we don't try
and reinterpret exceptions because full XPointers will be
thoroughly broken; they will have been formulated with the
expectation that they would be interpreted in the unencrypted
document, not in small fragments thereof.

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

>   or if an exceptional super-encrypted
>   EncryptedData is referenced by a non-barename XPointer.
>
>"#secret-1" is also a bare-name XPointer [3], right? I'm probably confusing 
>myself, but I think some same-document references *are* bare-name XPointers.

The different between bare name XPointers and full XPointers
is that bare name XPointers should still hold the same
meaning in a serialized/reparsed document subset, whereas
any other kind will probably not. So, we can hack support for
resolving bare name XPointers into the decrypted node sets,
but if we try and resolve full XPointers then it is quite
likely we'll start picking out the wrong things. For example,
if I have Exception #/1/1 then when I sign, this means the
first child of the document element. Upon verification I will
first interpret this in much the same way. If, however, I then
recursively try interpreting it in the decrypted node sets,
I'll start excepting the wrong things. So we restrict ourselves
to reinterpreting barename XPointers.

>[2] http://www.ietf.org/rfc/rfc2396.txt
>4.2. Same-document References
>A URI reference that does not contain a URI is a reference to the
>current document.  In other words, an empty URI reference within a
>document is interpreted as a reference to the start of that document,
>and a reference containing only a fragment identifier is a reference
>to the identified fragment of that document.
>[3] http://www.w3.org/TR/xptr/#bare-names
>A bare name stands for the same name provided as the argument of 
>id()
>
>   However, applications MAY solve some of these
>   super-encryption problems through the use of encryption properties
>   that identify exceptional super-encrypted elements, how same-document
>   references from the encrypted data should be resolved, and to which
>   signature such encryption properties apply. However, details of such a
>   solution are beyond the scope of this specification.
>
>Since we don't specify it, I wouldn't even mention it.

Probably best.

merlin

Received on Thursday, 13 June 2002 18:58:20 UTC