Minutes of 011119-tele

http://www.w3.org/Encryption/2001/Minutes/011119-tele.html
                             W3C XML Encryption WG

  2001-November-19
  Chair: Joseph Reagle
  Note Taker: Joseph Reagle [ascii]

Participants

     * Joseph Reagle, W3C
     * Blair Dillaway, Microsoft
     * Ed Simon, XMLsec
     * Christian Geuer-Pollmann, University of Siegen
     * Eric Cohen, PwC

News

Status of documents

     * Last Call ended November 9th. I've sent a nagmail to SOAP, SAML,
       and Schema WGs since I got them to agree to consider the Last
       Call, but they never responded with a date of response -- nor
       comments obviously.

Reviewing Previous Items

    1. Eastlake: add real life examples in section 5.5 to illustrate.
       Pending. Open for re-assignment.
    2. Action Hughes: ( XML Encryption Processing Model) Will investigate
       and send an email on Xerces implementation using XNI, or DOM when
       processing Element or Element Content.
       Pending.

Requirements

   ...

Draft

  Pending

     * 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.
     * Christian Geuer-Pollmann
         1. (Many editorial comments)
         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."
     * Herzberg's comments on Decryption Transform
         1. Requests a decrypt:Remove which indicates the identified
            element should not be part of the Signature.
            Reagle: I believe this functionality is addressed directly by
            XML Signature.
            Telecon participants agree.
     * Takeshi Imamu
         1. Should a nonce be associated with an EncryptedKey? A nonce
            cannot be used for encrypting a key, right? So I just thought
            that, if a user was trying to use a nonce for encrypting a
            key, it would be helpful to warn the user of the illegal use
            of nonce. Our implementation just ignores such a nonce,
            though.
            Reagle: I expect I'm not understanding the issue well, while
            I appreciate the algorithm itself might provide for a nonce,
            how would this redundancy hurt anything?
            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.

   (Section 5)
     * Ronald Rivest
         1. Does this support "new combined "encryption+integrity" modes
            of operation
            Yes, one can specify the approriate algorithm and
            identifier."
         2. "You have provisions for referring to some elements
            indirectly (e.g. through a URI), but you may need some way to
            ensure that what you retrieve is what was intended (e.g.
            through a hash of the element to be retrieved). Perhaps this
            is implicitly handled already..."
            Dillaway: this might be accomplished via a Transform that
            contains a digest within a CipherReference.
            ACTION Simon: send email to a list exploring this scenario.
         3. "There are of modes of encryption that won't fit your model,
            but which are very useful. For example, "secret-sharing"
            allows encryption of a document into several pieces, or
            shares, in such a way that a requisite number of them are
            required to decrypt/reconstruct the document. Just be sure
            you don't preclude somehow expansion to handle this sort of
            thing later on."
            Dillaway: way back when, we decided not to address threshold
            schemes. When Barb Fox asked the question, there was a
            resounding "no." However, I don't have a prolbem with someone
            layering it on top of what we specified.
            Reagle: do we then have some obligation to show how it can be
            done? Is anyone interested in this enough to take that on?
            Dillaway: Might have time in three weeks time.
            Simon: Perhaps we could ask Rivest to point out if it can't
            be done.
         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."
            Reagle: we made SignatureMethod optional in xmldsig...
            Dillaway: Agrees it can be dangerous, but its difficult to
            keep people from doing it in their protocol if they always
            use a particular algorithm, just seems redundant to them
            then.
            Reagle: Do people on this call support any scenarios
            presently where this information isn't sent?
            Dillaway: Not yet, but I can think of a couple of protocol
            scenarios where this is unnecessary overhead.
            ACTION Reagle: add warning text if there's a place where it
            seem approriate, assume they both know and they are wrong.
            Reagle: is there a security problem when it relates to
            signing, where someone signs the ciphertext, but subsitutes a
            different message with different algorith?... Suppose not, as
            we already say if people want to secure plain text, that's
            what they need to sign.
            Simon: someone encrypted a flower, but gets white noise, the
            plaintext should've been signed.
     * Blake Dournaee
         1. Is Canonical XML really a recommended serialization
            algorithm; when exactly must one use it?
            ACTION Eastlake: tweak the c14n in section 5, include
            exclusive canonicalization as an algorithm.
     * Yongge Wang
         1. "Is it possible to change the order of the input to KM so
            that it will look like:"
            ACTION Eastlake: Edit section 5.5 .
     * Jiandong Guo
         1. Nonce and Key Wrap Algorithm: "It seems to me that with the
            key wrap algorithm specified in section 5.6.2, there is no
            way a nonce can be used, although you may still set up one in
            the corresponding CipherData element by the document."
            Defer until Eastlake can respond.
     * Christian Geuer-Pollmann
         1. I want it fixed that 168 bit keys are transported in 192 bit
            form, that's all.
            Defer to Eastlake.
     * Blake Dournaee
         1. <AgreementMethod> question. "it doesn't look like XML
            Encryption actually specifies the logistics to perform the
            key agreement without also specifying actual encrypted data,
            which is impossible because the shared key hasn't been
            generated "
            Defer to Eastlake.

  Resolved

     * Blake Dournaee:
         1. Is the Nonce attribute of type intenger?
            Reagle: Yes.
     * Christian Geuer-Pollmann:
         1. Encrypting IV in ECB
            Eatlake/Dillaway: Use a nonce.

Misc.

     * Reagle: just to repeat, if you know folks from related communities
       that should review our specification, please do a little arm
       twisting.
     * Simon: The MS Web Services Security Language (WS-Security) Draft
       combines xmldsig, xenc, and web protocols/services and is perhaps
       a good source of issues for how these things will work together.

Received on Monday, 19 November 2001 16:14:49 UTC