- From: Joseph Reagle <reagle@w3.org>
- Date: Tue, 18 Sep 2001 17:07:29 -0400
- To: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org
[Result 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, the > 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". OK. > 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 tweak: 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.
Received on Tuesday, 18 September 2001 17:07:32 UTC