W3C home > Mailing lists > Public > xml-encryption@w3.org > February 2002

Minutes of 020204-tele.html (last week)

From: Joseph Reagle <reagle@w3.org>
Date: Tue, 12 Feb 2002 09:45:22 -0500
Message-Id: <200202121445.JAA30563@tux.w3.org>
To: xml-encryption@w3.org
Christian just reminded me that I forgot to post the minutes from last 
week's teleconf. (I did link them from the WG page.)

http://www.w3.org/Encryption/2001/Minutes/020204-tele.html


  2002-February-04
  Chair: Joseph Reagle
  Note Taker: Joseph Reagle

Participants

     * Joseph Reagle, W3C
     * Donald Eastlake, Motorola
     * Mike Just, Entrust
     * Blair Dillaway, MS
     * Merlin Hughes, Baltimore
     * (egrets) Christian Geuer-Pollmann, Uni Siegen

Reviewing Previous Items

    1. Eastlake: tweak text.  Remove text saying a nonce prevents CBC IV
       attack?
    2. Eastlake: DH: RFC2631 versus PKCS3
    3. Eastlake:Nonces and IVs: "It is unclear to me what "algorithm
       dependent length" is referring to in the second sentence. 
    6. Eastlake: add real life examples in section 5.5 to illustrate.
       Pending. (Still need that later example?)

Draft

  Pending

    1. [7]Encrypting the IV: Do we encrypt the IV?
       Not enough consensus to include in spec, should be specified
       externally. (First as a seperate document, then maybe in the
       [8]Additional XML Security URIs?)
       Reagle: Is section 5.2 too constraining? I think there is some
       confusion about its interpration, but the intention isn't too
       preclude externally specified algorithms from processing the IV as
       they see fit. I could make a tweak to make this more clear. ACTION
       Eastlake: since Don has change control on section 5 he can review
       this text.
    2. [9]Password Derivation: Is Christian's understanding of what a
       password derivation is accurate? Do we still wish to not specify
       this ourselves?
       Same understanding as the encrypted IV, start off with it being
       externally specified.

      [7] 
http://lists.w3.org/Archives/Public/xml-encryption/2002Jan/0128.html
      [8] 
http://www.ietf.org/internet-drafts/draft-eastlake-xmldsig-uri-02.txt
      [9] 
http://lists.w3.org/Archives/Public/xml-encryption/2002Jan/0117.html

Misc.

  Performance

    1. Reagle: Given our recent brush with performance issues with XPath,
       have folks played with the xmldsig-decryption-transorm? Merlin and
       Blair have played with it, didn't seem to encounter any problems
       at the time.
    2. Reagle: since we are entering CR we could say something about on
       performance?
       Eastlake: wouldn't hurt to say we're interested in feedback about
       performance.
    3. (Since folks are on the call: Reagle asks Merlin about [10]Boyer's
       message, Merlin will respond with some numbers.)
    4. Ok, when Don gives me the section 5 tweaks we'll be ready to
       advance out of CR. Targetted publication of this month.

     [10] 
http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2002JanMar/0098.html


-- 

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 Tuesday, 12 February 2002 09:45:23 GMT

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