- From: by way of Joseph Reagle <reagle@w3.org>
- Date: Wed, 28 Nov 2001 15:05:29 -0500
- To: xml-encryption@w3.org
[ Resulting document: (and questions were I failed to complete the item) http://www.w3.org/Encryption/2001/Drafts/xmlenc-core/ $Revision: 1.77 $ on $Date: 2001/11/26 22:08:27 $ GMT by $Author: reagle $ ] On Monday 19 November 2001 16:14, Joseph M. Reagle Jr. wrote: > http://www.w3.org/Encryption/2001/Minutes/011119-tele.html > * Ed Simon > 1. Should the CarriedKeyName attribute really be a child > element? > ACTION Reagle: change to a child element, cc: Merlin/Takeshi > to see if they oppose. Done. > 2. Section 3.5: The ReferenceList Element In the schema > definition, why not use <choice> rather than <sequence>? > ACTION Reagle: change to choice. Done. (Note, I thought it would be useful to group Data and Key References, this move to choice allows them to be inter-mixed.) > * Christian Geuer-Pollmann > 1. (Many editorial comments) Done earlier: [1] http://lists.w3.org/Archives/Public/xml-encryption/2001Nov/0047.html > 2. Should we add a warning into section "3.1 EncryptedType" that > it is not allowed (or could cause problems) if an > EncryptedData element becomes the DocumentElement of a new > Document with @Type="ElementContent" ? > ACTION Reagle: add warning text on this point if it doesn't > already exist, "decrypted content may not be well-formed > XML." As requested in [1], could Christian to propose some text where he thinks this is weak in the spec. > * Takeshi Imamu > Dillaway: agrees with Takeshi, EncryptedKey shouldn't have a > nonce because it can complicate the algorithms. For example, > some algorithms expect particular key sizes that this would > confuse. > ACTION Reagle: remove Nonce attribute from Encrypted Key. The Nonce attributes is actually part of the CipherData structure which is shared by EncryptedData and EncryptedKey. So it's not as easy as simply removing the attribute from EncryptedKey. I'm getting a little rusty on Schema but I don't think there's an easy way to restrict the presence of EncryptedKey's CipherData to be 0. Takeshi, what did you have in mind, a new schema structure, or some text? (Honestly, I still don't understand the problem enough to do the right thing, so specific direction/text would be welcome. For example, with respect to what Blair said on the teleconference, processing step 4.2.3.3 should solve the problem, right? Say I have a key "12345". I want to encrypt it and tend to stick nonces on all my encrypted data for consistency's sake. So now, prior to encryption, I prepend the nonce "89", encrypt the value, and that is now the content of EncryptedKey/CipherData/CipherValue. When I do the reverse, I of course remove the nonce "89" from "8912345" before handing "12345" off to any cryptographic process. I'm not sure what the problem is, or what is "being ignored" in Takeshi's processing...) > 4. "I'm very uncomfortable with allowing the encryption > algorithm to be "understood" between the sender and the > recipient; you should force the sender to be explicit. > Non-explicitness is the cause of very many protocol > failures." > ... > ACTION Reagle: add warning text if there's a place where it > seem approriate, assume they both know and they are wrong. If the element is absent, the encryption algorithm /+must be known by the recipient or the decryption will fail.+/ -- Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature/ W3C XML Encryption Chair http://www.w3.org/Encryption/2001/
Received on Wednesday, 28 November 2001 15:05:30 UTC