Re: Decryption Transform processing question

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.


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

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


    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?


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

   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.

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

Received on Thursday, 13 June 2002 17:01:25 UTC