Re: Decryption Transform processing question

r/reagle@w3.org/2002.07.15/14:34:05
>On Friday 12 July 2002 10:45 am, merlin wrote:
>> I attach an edited copy of Joseph's latest version of the
>> document. The changes I have made reflect my reponse to
>> Takeshi's comments below:
>
>Ok, hopefully you and Takeshi are *quickly* converging on something mutually 
>acceptable <smile/>. My particular confusion still petains to:
>
>  o A namespace declaration xmlns="" MUST be emitted with every 
>  apex element that has no namespace prefix and URI as described
>  in Serializing XML (section 4.3.3) of the XML Encryption
>  specification [XML-Encryption].
>  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 
>  associated with the XML namespace [XML] from the parent element.
>
>First, apex node isn't definied, but I otherwise understand the first 
>bullet. (Perhaps you should reference the exc-c14n spec for the 
>definition?) Second, I'm still not sure about this processing required of 
>the xml:foo attributes. Part of my confusion results from the pronouns. How 
>can I replace an element in N that doesn't have a parent? Whose apex 
>elements? and the parent element in which context? This is why an example 
>would be useful.

Consider:

  <Document xml:lang="ie">
    <Foo id="foo-1" />
    <Signature xmlns="&dsig;"> ...
      <Reference URI="#foo-1"> ...
      <Transform Algorithm="&decrypt;XML" /> ...
    </Signature>
  </Document>

The Foo element is an apex node of the signed node set and so when the
decrypt transform performs c14n-with-replacement, it inherits xml:lang.

Later on, this is encrypted:

  <Document xml:lang="ie">
    <EncryptedData Id="foo-1" [[<Foo Id="foo-1" />]] />
    <Signature xmlns="&dsig;"> ...
      <Reference URI="#foo-1"> ...
      <Transform Algorithm="&decrypt;XML" /> ...
    </Signature>
  </Document>

Now, when we do the c14n-with-replacement within the decrypt
transform, the Foo element will not inherit xml:lang correctly
because it is in a different document; as a result, the signature
will break. So we need that patch text.

Here, we've used an ID reference to select an EncryptedData
that is an apex node; transforms could also achieve the same
effect.

In general, there can only be one apex encrypted element for such a case
to work (our parsing-validity requirement), however one can potentially
have multiple apex EncryptedData elements:

  <Body>
    <!-- comment -->
    <Data />
    <!-- comment -->
  </Body>

  Sign /ToBeSigned/descendant::node() | &decrypt;XML

  Could be encrypted so:

  <Body>
    <EncryptedData [[<!-- comment -->]] />
    <EncryptedData [[<Data />]] />
    <EncryptedData [[<!-- comment -->]] />
  </Body>

We can tidy up examples once we nail down the transform specification.

Merlin

Received on Monday, 15 July 2002 15:28:20 UTC