W3C home > Mailing lists > Public > xml-encryption@w3.org > September 2001

Re: Minor comments on Section 4

From: <edsimon@xmlsec.com>
Date: Wed, 19 Sep 2001 09:49:12 -0400
Message-ID: <3BA6885700000C7E@mail.san.yahoo.com>
To: reagle@w3.org, Takeshi Imamura <IMAMU@jp.ibm.com>, xml-encryption@w3.org
I think Takeshi's point is that an Encryptor can do the serialization of
XML elements and element content because it understands XML.  However, the
Encryptor will not necessarily understand what serialization is appropriate
for other data, hence serialization falls into the calling application's
realm.  I don't see this as "inconsistent and awkward".

To clarify that step 3.1 of section 4.1 is done by the Encryptor, I would
"obtain the octets resulting from their serialization in UTF-8 as specified
in [XML]" 


"obtain the octets by serializing the data in UTF-8 (as specified in [XML])"


"serialize the data in UTF-8 (as specified in [XML]) to obtain the octets
to be encrypted"

My reason is simply that the present phrasing might sound like the Encryptor
needs to obtain the octets from the application when in fact it generates
the octets itself.


-- Original Message --

>  http://www.w3.o rg/Encryption/2001/Drafts/xmlenc-core/
>  $Revision: 1.52 $
>On Monday 17 September 2001 12:10, Takeshi Imamura wrote:
>> I believe that this serialization should be also done by not the
>> Encryptor but the application.  That is, given data being serialized,
>> Encryptor just calls a serialization module provided by the application.
>> Of course, it should be allowed for the Encryptor to provide original
>> serialization modules for certain types of data.
>This leads me to an issue I originally considered and tried to address

>with edits. Are we placing requirements on an Encryptor, Decryptor, 
>Implementation, and/or Application? (If so, perhaps we should define 
>these). My edits have been to speak to and specify conformance requirements
>over the xmlenc application, and I missed it in this instance. So I've

>moved to "application" as you suggest.
>However, it's still inconsistent awkward...
>> In Section 4.1, step 5.1,
>> "to be encrypted" would be "to be replaced".
>> In Section 4.2, step 1,
>> >Parse the application identified EncryptedType
>> >element to determine the algorithm, parameters and
>> >ds:KeyInfo element to be used. If some information is
>> >omitted, the application must supply it.
>> Because we already do not care whether the input to this step is an octet
>> sequence, "parsing an EncryptedType element" is not always correct and
>> should be revised to another expression.
>"EncryptedType element" is not supposed to indicate the type of the 
>plaintext, but either the EncryptedData or EncryptedKey elements, I will
>4.2 Decryption
>For each EncryptedType derived element, (i.e., EncryptedData or 
>EncryptedKey), to be decrypted :
>1. Parse the element to determine the algorithm, parameters and ds:KeyInfo
>element to be used. If some information is omitted, the application must
>supply it.

Ed Simon
XMLsec Inc.

Interested in XML Security Training and Consulting services?  Visit "www.xmlsec.com".
Received on Wednesday, 19 September 2001 09:54:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:02 UTC