Re: Minutes of 011119-tele

[ Resulting document: (and questions were I failed to complete the item)
  $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:
>      * 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.


>          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:

>          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
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.       
W3C Policy Analyst      
IETF/W3C XML-Signature Co-Chair
W3C XML Encryption Chair

Received on Wednesday, 28 November 2001 15:05:30 UTC