Dillaway proposed text, Reagle included it in the latest proposal.
Done: first draft accomplished, WG should comment.
Done: Decryption Transform for XML Signature, WG should comment.
Done: Takeshi reports he believes we should maintain the octet processing model, though it may make DOM/Infoset based implementations more tricky.
Dillaway: also believes this is the right approach.
Herzberg: how to address the signing of a message over which portions of which will be subsequently encrypted (both signature and encryption are by the author). This is a follow-up to earlier threads on security of encrypted&signed text, where the signature should not leak information about the plaintext now purposefully obscured by the encryption.
Reagle: Let's continue this discussion on the list (and also look at Decryption Transform for XML Signature.)
Action Reagle: respond.
Action: Reagle check with Schaad, otherwise no opposition.
Reagle: I created a CipherReference and CipherValue as children of CipherData for expositional convenience.
Dillaway and Simon support this, Don still prefers option 2 (not needing the extra level of nesting) but it isn't a show-stopper issue.
Not much more discussion on the list, let's decide one way or the other: CarriedKeyName.
Reagle: Isn't this a dsig issue, should we specify processing behavior for elements in the dsig namespace?
Action Eastlake: will post message to xmldsig list.