RE: Processing <CipherData> (was "RE: CipherReference + Transforms meaning")

Ed,

I also believe that we should leave APIs to each implementer.  As for
XSS4J, it is very experimental and I'm not sure whether its APIs make
sense.  However, I think that decrypt() can be regarded as a method which
provides another behavior overriding a default one, which is provided by
decryptAndReplace(), and in that sense, I don't think that decrypt() is
against the spec.

BTW, I am a little confused about how to use "Element" and "Content" types.
To my understanding, they are used for octet sequences representing element
and element content and extracted from XML documents exactly as they are.
My question is whether they can be used for octet sequences representing
C14Ned, for example, element and element content.  In the above sense, such
use should not be allowed, but in the decryption processing point of view,
it may not make sense to distinguish C14Ned octet sequences from raw ones.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com



From: edsimon@xmlsec.com@w3.org on 2001/06/22 09:50 AM

Please respond to edsimon@xmlsec.com

Sent by:  xml-encryption-request@w3.org


To:   xml-encryption@w3.org
cc:
Subject:  RE: Processing <CipherData> (was "RE: CipherReference +
      Transforms meaning")



Blair,
Sorry, you can't disagree with me this time because (as my original note
says) I'm not pushing any particular position at this time, just curious
about the different possibilities. I certainly agree we don't want to
specify
an API; I just used XSS4J's APIs as an example of how one Toolkit was
designed.

( Don't worry, I'm sure there will be opportunities to disagree in the
future.;-}
)

Regards, Ed

-- Original Message --

>Ed,
>
>I'm going to disagree with you.  I believe XML Enc. Implementations
>should implement the encryption and decryption processing for element
>and element content as previously described in the spec.  This is likely
>to be the most common behavior and I'd like to see us encourage behavior
>that avoids requiring applications to routinely implement their own
>version of this processing.
>
>If you don't like the 'default' characterization, we could just describe
>these as two required processing methods on an equal footing.
>
>I don't believe we should specify how this is implemented from an API
>standpoint.  It could be separate methods or some parameterization on a
>single method.
>
>-----Original Message-----
>From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com]
>Sent: Wednesday, June 20, 2001 5:08 PM
>To: xml-encryption@w3.org
>Subject: RE: Processing <CipherData> (was "RE: CipherReference +
>Transforms meaning")
>
>
>Do we have to declare a default behaviour?  Or should we just say an XML
>Encryption Toolkit can include methods to
>a) decrypt and return the decrypted object
>b) decrypt and replace the <EncryptedData> node with the decrypted
>object if the decrypted object is either an Element or NodeList
>
>An application using the Toolkit will be the one to decide what happens
>to the decrypted data.  XML Encryption can, and should, explaing how to
>encrypt/decrypt XML elements and element content; but, it does not have
>to require that the decrypted version of an <EncryptedData> element
>(Type = Element or NodeList) in an XML instance necessarily, ultimately
>belongs to that XML instance.  That application will know what it wants
>to do with the decrypted node; we don't have to specify a default
>behaviour.  Right?
>
>XSS4J, for example, has two methods: decrypt(<EncryptedData>) and
>decryptAndReplace(<EncryptedData>).
> decrypt() decrypts the <EncryptedData> element and returns an object of
>type Element, NodeList, or InputStream without replacing the
><EncryptedData> node; decryptAndReplace() decrypts the <EncryptedData>
>element and then replaces the <EncryptedData> node with the resulting
>Element or NodeList.
>
>Not having looked at the internals at XSS4J, I don't know what context
>baggage the result of a decrypt(<EncryptedData>) has.  Maybe there are
>some context gotchas like the namespace issues being discussed in XML
>Signature now that are trickier than we think.
>
>I'm not taking a hard and fast position, just curious about the
>different possibilities.  Takeshi, any comments about the functionality
>issues of
>decrypt(<EncryptedData>) that I've overlooked.
>
>Ed
>
>-- Original Message --
>
>>Ed, Takeshi:
>>
>>Ed's example is just one possible case where default replacement of a

>>EncryptedData by the decryped cipher data is not the desired behavior.

>>This is why I raised the issue of what the mandatory behavior should be
>
>>given the possible combinations of Type attributes and CipherData
>>encodings.
>>
>>I agree with you that we can clarify this with some additional wording.
>
>>I tend to agree with Takeshi that we should decouple a required
>>processing behavior from the Type attribute.  Also, I agree we don't
>>need to introduce another attribute to make this happen.
>>
>>I believe the wording should indicate the default processing behavior

>>when Type is element or element content is as described in the current

>>draft.  But, compliant implementations must allow the application to
>>override this behavior and handle processing themself.  I believe this

>>will provide adequate guidance to tool developers.
>>
>>I suggest the following wording changes:
>>
>>Section 4.1, Step 4.1 - Add to the end
>>   Applications must be allowed to override this default behavior
>such
>>that
>>   the processing described in step 4.2 is applied.
>>
>>Sectin 4.2, Step 4 - replace last sentence with
>>   Applications must be allowed to override this default behavior
>and
>>   handle processing of the decrypted octet sequence.  For
>>decrypted data
>>   not of type element or element content, the decrypted octet
>>sequence is
>>   always the final result and is returned to the using
>>application.
>>
>>-----Original Message-----
>>From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com]
>>Sent: Monday, June 18, 2001 6:37 AM
>>To: xml-encryption@w3.org
>>Subject: RE: Processing <CipherData> (was "RE: CipherReference +
>>Transforms meaning")
>>
>>
>>Actually, I think all that is needed is some minor changes to steps 4

>>of section 4.1 and 4.2 to supplement what Blair has proposed.  I'll
>>suggest wording in the next day or two (today's a beach day!).
>>
>>In fact, with respect to an application's options about encrypting XML

>>elements and content, XSS4J (for example), already has the flexibility

>>needed to implement the scenario I discussed.  My problem with the
>>current spec wording is that it is, subltly, a touch too restrictive.
>>
>>Ed
>>
>>-- Original Message --
>>
>>>
>>>
>>>Ed,
>>>
>>>>One solution is to have a Type media type for XML elements that
>>>>doesn't imply "decrypt AND replace".  Another option, is to say the

>>>>Type attribute simply says what the encrypted content was and not
>>>>have
>>
>>>>a processing
>>>semantic
>>>>behind it; another attribute or parent element would indicate what to
>>do.
>>>
>>>I prefer the second one, but I think that another attribute or
>>>something is not needed in order to indicate what to do.  This is
>>>because each application must know what to do according to the Type
>>>attribute (e.g.,
>>a
>>>decryptor compliant to the XML Encryption spec must know that an
>>>EncryptedData element with a Type attribute "Element" (which may be
>>>contained directly or be specified by a user) is decrypted and
>>>replaced).
>>>
>>>Thanks,
>>>Takeshi IMAMURA
>>>Tokyo Research Laboratory
>>>IBM Research
>>>imamu@jp.ibm.com
>>>
>>>
>>>
>>>From: edsimon@xmlsec.com@w3.org on 2001/06/16 09:47 AM
>>>
>>>Please respond to edsimon@xmlsec.com
>>>
>>>Sent by:  xml-encryption-request@w3.org
>>>
>>>
>>>To:   xml-encryption@w3.org
>>>cc:
>>>Subject:  RE: Processing <CipherData> (was "RE: CipherReference +
>>>      Transforms meaning")
>>>
>>>
>>>
>>>Blair,
>>>I like the gist of your text but I have a scenario I'd like to
>>>present.
>>>
>>>Say, I have a application that synchronizes the content of replicated
>
>>>XML files existing behind firewalls.  Because only a few of the
>>>elements in a file change between updates, I don't want to encrypt and
>
>>>redistribute the entire file.  So my application looks for changes to
>
>>>certain XML elements, and, for each changed element, grabs it,
>>>encrypts
>>
>>>it, packages it into
>>an
>>><EncryptedData> element.  Once it has reviewed all the elements, it
>>>stores the corresponding <EncryptedData> elements a
>>>StuffToBeSynchronized.xml
>>file
>>>and distributes it.
>>>
>>>Though StuffToBeSynchronized.xml has <EncryptedData> elements
>>>containing XML elements, my goal isn't to expand inine its
>>><EncryptedData> elements into plaintext XML elements.  But I still
>>>would like to use the Type attribute to indicate the contained
>>>encrypted data is an XML element.
>>>
>>>One solution is to have a Type media type for XML elements that
>>>doesn't
>>
>>>imply "decrypt AND replace".  Another option, is to say the Type
>>>attribute simply says what the encrypted content was and not have a
>>>processing semantic behind it; another attribute or parent element
>>>would indicate what to do.
>>>
>>>Is this a realistic scenario? If so, what would the Type attribute be
>
>>>set to?
>>>
>>>Regards, Ed
>>>
>>>-- Original Message --
>>>
>>>>Thank you Ed.  Your suggested additions to Section 4.2 look good.
>>>>
>>>>Didn't think I'd get to this today, but here is additional text I
>>>>would like inserted in the other relevant sections.
>>>>
>>>>Section 3.3.  Replace the last sentence with:
>>>>
>>>>Type is an optional attribute identifying type information about the
>
>>>>decrypted content.  This type information plays a key role in the
>>>>behavior of compliant decryptors as decribed in Section 4.2.  If the
>
>>>>EncryptedData element contains data of type element or element
>>>>content, and replaces that data in an XML Document context, it is
>>>>strongly recommended the type attribute be provided.  Without this
>>>>information, the decryptor will be unable to automatically restore
>>>>the
>>
>>>>XML Document to its original clear-text form.
>>>>
>>>>
>>>>Section 4.1.  Under step 4.1, add the sentence:
>>>>
>>>>It is strongly recommended compliant encryptors  insert the optional
>
>>>>Type attribute into EncryptedData with a value of 'Element' or
>>>>'ElementContent' respectively to allow automated document restoration
>
>>>>processing as described in Section 4.2.
>>>>
>>>>
>>>>-----Original Message-----
>>>>From: edsimon@xmlsec.com [mailto:edsimon@xmlsec.com]
>>>>Sent: Friday, June 15, 2001 2:42 PM
>>>>To: Blair Dillaway; Takeshi Imamura
>>>>Cc: xml-encryption@w3.org
>>>>Subject: Processing <CipherData> (was "RE: CipherReference +
>>>>Transforms
>>>>meaning")
>>>>
>>>>
>>>>Blair wrote
>>>>
>>>>>Perhaps I am being unnecessarily concerned about this.  I don't have
>>a
>>>
>>>>>problem with the language you cite, what I have a problem with is
>>>>>the
>>>
>>>>>lack of discussion about the linkage between the OPTIONAL type
>>>>>attribute on EncryptedData and the assumed processing.  I am
>>>>>concerned
>>>
>>>>>about confusion as to what is supposed to happen with various
>>>>>combinations of specifying/not specifying the type and using
>>>>>CipherValue vs CipherReference.
>>>>
>>>>I strongly agree with Blair.
>>>>
>>>>To review, there has been some discussion suggesting that if an
>>>><CipherReference> is being used, there should be an assumption the
>>>>data is not an element or element content, and if <CipherValue> is
>>>>being used, then it is an element or element content.
>>>>
>>>>I would prefer NOT to second guess how applications want to do
>>>>things.
>>>
>>>>There may indeed be apps that prefer to keep encrypted inline XML
>>>>remote (perhaps for authorization/performance reasons), and there may
>
>>>>be some that would rather not have to keep encrypted arbitrary data

>>>>remote from <EncryptedData> elements.
>>>>
>>>>Here's the way I look at it...
>>>>
>>>>The result of processing a <CipherData> element is simply an octet
>>>>stream to be sent to the decryption engine, no semantics are implied.
>
>>>>If <CipherData> contains a <CipherValue> element, obtain the octet
>>>>stream by de-base64ing its content.  If <CipherData> contains a
>>>><CipherReference> element, dereference the value of the URI attribute
>
>>>>and applies the specified transforms (if
>>>>any) to obtain the octet stream.
>>>>
>>>>Once the octet stream has been decrypted, process it based on the
>>>>Type
>>
>>>>attribute of the <EncryptedData> element.  If the Type attribute
>>>>indicates an element or element content, replace <EncryptedData> with
>
>>>>the decrypted element or element content; otherwise, hand the
>>>>application a reference to the octet stream.
>>>>
>>>>[I submit the preceding two paragraphs for inclusion into the spec.]
>>>>
>>>>Ed
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>>
>
>
>
>
>
>

Received on Friday, 22 June 2001 02:35:17 UTC