W3C home > Mailing lists > Public > xml-encryption@w3.org > June 2002

Re: XML decryption transform number 13

From: Takeshi Imamura <IMAMU@jp.ibm.com>
Date: Mon, 10 Jun 2002 20:05:37 +0900
To: merlin <merlin@baltimore.ie>
Cc: xml-encryption@w3.org
Message-ID: <OFCEF9B919.EBAEDC07-ON49256BD4.0027153D@LocalDomain>


I'm sorry for the tardy reply.

>>I feel that concatenating the plaintexts is weird.  What kind of scenario
>>are you supposing?
>Any scenario in which multiple encrypted binary documents are
>covered by a signature. E.g: multiple classfiles encrypted in
>an XML document.
>Or, more pragmatically, to do otherwise is to needlessly
>restrict the transform. If applications don't want this feature
>then they can just cover a single binary EncryptedData at
>a time. We lose nothing by supporting this.


>>This looks good, but I think that it is a little redundant.  The
>>wrapping/parsing/trimming is required only for the plaintext resulting
>>an EncryptedData element node which is the first node in the node-set,
>>hence that for the other plaintexts could be omitted.
>I'm not sure I understand. It could be unnecessary if we
>serialized the input node set, with EncryptedData replaced by
>their plaintext, and then wrapped/parsed/trimmed this (the
>one-phase processing I was describing earlier). However,
>in the case of the algorithm I described (#13) this won't
>work; canonicalizing the input node set doesn't necessarily
>provide the context to parse the XML fragments. Which is a
>separate issue that I have with the XML spec.

Are you talking about general entities?  If so, you are right.  It will not

>Regardless, I revamped my understanding of Type processing,
>and came to the conclusion that wrap/parse/trim should
>not be a part of this spec. In the revised spec (version 2)
>the output of decrypting an EncryptedData, in accordance with
>the definition of its Type, should be a node set, which we
>then then canonicalize in place of the EncryptedData.

Is [1] the revised spec?  wrap/parse/trim seems to be a part of it...

>We could define the &decrypt;XML as accepting either a node
>set or an octet stream as the result of Type processing. A
>node set would be canonicalized, an octet stream would be
>inserted directly.
>However, I think this makes Type-based processing somewhat
>redundant, and would require us to impose on the XML encryption
>spec that encrypted XML MUST be parseable in the context of
>its canonicalized parents; that is, WITHOUT access to general
>entities. I think the latter would be a good thing (placing
>that requirement on type Element or Content). However,
>I don't like acceptance of an octet stream; we have typing,
>and I think that we should just requires node sets that we
>can use directly. It seems aesthetically pleasing to me: The
>&decrypt;XML transform requires that EncryptedData produce XML
>(node sets).

I'm not sure why accepting both a node-set and octet stream makes
processing redundant because the node-set will be canonicalized anyway.
However, I don't have any objection to accepting only a node-set.

[1] http://lists.w3.org/Archives/Public/xml-encryption/2002Jun/0000.html

Tokyo Research Laboratory
IBM Research
Received on Monday, 10 June 2002 07:05:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:09 UTC