W3C home > Mailing lists > Public > xml-encryption@w3.org > November 2001

xmlenc Call 13:00 EST 20011203

From: Joseph Reagle <reagle@w3.org>
Date: Wed, 28 Nov 2001 16:22:14 -0400
To: "XML Encryption WG " <xml-encryption@w3.org>
Message-Id: <20011128202215.22599B5@policy.w3.org>

Check up on previous action items and continue discussion on 3 threads.

DATE AND TIME

Monday, 13:00 EST (1pm) 03-Dec-01.
Call Tobin bridge (+1-617-252-7000)

BACKGROUND

The Overview URL for this group is at:
        http://www.w3.org/Encryption/2001/
 
Status of documents

     * Working through last call. Reagle created a Last Call Issues
       document for tracking.

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.
    3. ACTION Reagle: add warning text on this point if it doesn't
       already exist, "decrypted content may not be well-formed XML."
       REDIRECT: Chrisitan will provide some text since he's best aware
       of the source of confusion.
    4. ACTION Simon: send email to a list exploring scenario of Rivest's
       "what you retrieve is what you intended to retrieve."
    5. ACTION Eastlake: Edit section 5.5 . "Is it possible to change the
       order of the input to KM so that it will look like:"
    6. [DEL: ACTION Eastlake: tweak the c14n in section 5, include
       exclusive canonicalization as an algorithm. :DEL]
    7. [DEL: ACTION Eastlake.I want it fixed that 168 bit keys are
       transported in 192 bit form, that's all. :DEL]
    8. [DEL: ACTION Reagle: change to a child element, cc: Merlin/Takeshi
       to see if they oppose. :DEL]
    9. [DEL: Section 3.5: The ReferenceList Element In the schema
       definition, why not use <choice> rather than <sequence>? :DEL]
       [DEL: ACTION Reagle: change to choice. :DEL]
  Pending

     * 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.
     * 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.
     * 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.
Received on Wednesday, 28 November 2001 15:22:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:19 GMT