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

RE: Minor comments on Section 4

From: <edsimon@xmlsec.com>
Date: Thu, 20 Sep 2001 11:13:46 -0400
Message-ID: <3BA68A12000016A1@mail.san.yahoo.com>
To: Blair Dillaway <blaird@microsoft.com>, reagle@w3.org, Takeshi Imamura <IMAMU@jp.ibm.com>, xml-encryption@w3.org
Sounds fine to me,
Ed

-- Original Message --

>You've got my intent.  Apps certainly can't be required to use an
>Encryptor's serializer when present, but many probably will.  Those that
>do shouldn't need to also create their own serializer.
>
>I did a little word smithing, I wanted to work in the notion that an
>Encryptor's serialier may not be suitable for the Application's needs
>consistent with the discussion in 4.3.  How's this sound?
>
>3.1 If the data is an [XML] Element or [XML] Element Content, obtain the
>octets by serializing the data in UTF-8 as specified in [XML].  Note
>that Encryptors are NOT required to implement a serialization algorithm.
>If an Application is using an Encryptor that does not provide a
>serializer, the Application must provide this functionality.  Of course,
>when using an Encryptor that implements a serializer suitable for the
>Application's needs, it need not supply its own.
>
>Blair
>
>-----Original Message-----
>From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com] 
>Sent: Wednesday, September 19, 2001 4:47 PM
>To: Blair Dillaway; reagle@w3.org; Takeshi Imamura;
>xml-encryption@w3.org
>Subject: RE: Minor comments on Section 4
>
>
>I like the direction of your proposed 3.1 wording but I want to tweak it
>so that we don't sound like we are requiring applications to always
>provide a serialization algorithm even if they would only use the
>Encryptor's supplied one (which I don't think is the intention, correct
>me if I'm wrong).  So here goes...
>
>3.1 If the data is an [XML] Element or [XML] Element Content, obtain the
>octets by serializing the data in UTF-8 as specified in [XML].  Note
>that Encryptors are NOT required to implement a serialization algorithm.
>If an Application using an Encryptor that does not provide a
>serialization algorithm, that Application must provide this
>functionality.  Of course, if an Application is using an Encryptor that
>implements a serialization algorithm, that Application need not supply
>its own.
>
>
>Regarding the use of the "Type" attribute, I'm not sure there will
>always be a 1-to-1 correspondence between the Type attribute and the
>serialization algorithm.  For now, let's assume the Type attribute is
>sufficient and only address the issue if it becomes obvious this is not
>the case.
>
>Ed
>
>-- Original Message --
>
>>Ed,
>>
>>My read of the current draft is that there is no REQUIRED serialization
>
>>algorithm for compliant implementations.  Hence, a compliant 
>>implementation need not provide any serialization functionality.  So I

>>don't understand how one can assume the encryptor is going to do this.

>>(FWIW, I happen to agree most implementations will supply serialization
>
>>functionality and most apps with simply use it.  But, unless its 
>>mandatory Section 4 shouldn't assume it.)
>>
>>We've also discussed in Section 4.3 the reasons why App must be allowed
>
>>to handle serialization.  The Encryptor doesn't understand the app 
>>context and might not use the best, or even a useful, serialization 
>>method.
>>
>>I really feel we should expand the language in Step 3.1 along the lines
>
>>I suggested to clarify how this serialization is expected to happen.
>>
>>On your second point, can't the app do this by defining an appropriate

>>type value to be carried in the Type attribute?
>>
>>Blair
>>
>>
>>
>>-----Original Message-----
>>From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com]
>>Sent: Wednesday, September 19, 2001 3:00 PM
>>To: Blair Dillaway; reagle@w3.org; Takeshi Imamura;
>>xml-encryption@w3.org
>>Subject: RE: Minor comments on Section 4
>>
>>
>>
>>Blair wrote
>>
>>>we're ambiguous in Step 3.1 about who is responsible for serializing
>>>the data.
>>>
>>
>>I don't think the text is ambiguous because all the steps starts out 
>>with "the encryptor must:".  Hence all the steps are the Encryptor's 
>>responsibility unless otherwise specified.  Unless there is a good 
>>reason otherwise, I wouldn't want the application to have the handle 
>>the serialization of XML Elements and Content.
>>
>>On a related topic, for non-XML data where we require the application

>>to do the serialization (because the Encryptor can't do arbitrary 
>>serialization), does it make sense to allow the application to provide
>a
>>hint in <EncryptedData> how the the serialization was done?  I'm 
>>thinking of the receiving end, where the Decryptor want's to 
>>de-serialize the data and wants to know how the serialization was done.
>>
>>Ed
>>
>>-----------------------------------------------------------------------
>>-
>>-----------------------
>>Ed Simon
>>XMLsec Inc.
>>
>>Interested in XML Security Training and Consulting services?  Visit 
>>"www.xmlsec.com".
>>
>>
>>
>
>------------------------------------------------------------------------
>-----------------------
>Ed Simon
>XMLsec Inc.
>
>Interested in XML Security Training and Consulting services?  Visit
>"www.xmlsec.com".
>
>
>

-----------------------------------------------------------------------------------------------
Ed Simon
XMLsec Inc.

Interested in XML Security Training and Consulting services?  Visit "www.xmlsec.com".
Received on Thursday, 20 September 2001 11:18:46 UTC

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