[1]W3C   [2]XML Encryption WG

      [1] http://www.w3.org/
      [2] https://www.w3.org/tmp/Overview.html

  2001-June-11
  Chair: Joseph Reagle
  Note Taker: Joseph Reagle [[3]text]

      [3] https://www.w3.org/010611-tele.html,text

Participants

     * Joseph Reagle, W3C
     * Blair Dillaway, Microsoft
     * Katherine Betz, IBM
     * Donald Eastlake 3rd, Motorola
     * John Velissarios, PricewaterhouseCoopers LLP
     * Ed Simon
     * Jim Schaad, Soaring Hawk Consulting

News

     * No news is good news.

Status of documents

     * Plans: Looking to publish First Spec Working Draft and
       [4]Decryption Transform for XML Signature ASAP.

      [4] http://lists.w3.org/Archives/Public/xml-encryption/2001May/att-0005/01-dt-note.html

Reviewing [5]Previous Items

https://www.w3.org/010319-tele.html

     * Reagle: Still need to change from KeyRetrievalMethod.
     * Reagle: Schema WG is looking into the base64 issue.

Requirements

   ...

Draft

     * Confirmed: [6]move to Element and Content for granularity
       types.
      http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0020.html

     * Confirmed: move to CarriedKeyName
     * Schaad: not comfortable with [7]'Reversable Transforms'
       text. Eastlake: [8]proposal for improved text.
       Simon: I'm the author of the original text mentioning
       'reversible transforms'. My main objective was to clarify
       the contrast between the processing of transforms when
       signing&verifying compared to when encrypting&decrypting.
       Don has suggested the spec just needs to cover transforms
       from the decrypting point of view which is fine with me;
       the implementation gotchas I was discussing can be covered
       in other non-normative material.
       (Takeshi): Canonicalization: not reversible really. Simon:
       While not symmetrically reversible from a character by
       character view, if the the canonicalized version is
       adequate for the application's purposes, all's well. A
       transform only needs to be reversible to the extent you can
       get back the stuff you care about. Since one would not use
       canonicalization if it was important to get back the lost
       info, there is no issue with the use of canonicalization in
       transforms
       Reagle: example seems to be causing confusion by
       specifiying canonicalization and compression, can we use
       different transforms other than base64?
       Dillaway: another examples, use an XPath.
      http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0022.html
      http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0037.html

     * Schaad: [9]Digest[Method/Value] in CipherData introduces
       security weakness?
       There needs to be salt in the plaintext version of the
       data.
       Eastlake: define a nonce with a salt.
       Reagle: could we have the encryption algorithm clean up and
       remove nonces?
       Schaad: then what if you signed it, when do you remove it?
       Schaad: I'd rather see an encryption algorithm, 3DES plus
       this plus in the DigestValue.
       Reagle: Herzberk wanted some "morphable" functionality,
       Ashwood didn't like the combinatorial explosion.
       Action Reagle: propose a poll on the two. Action: Schaad:
       look at Amir's original proposal and engage him on the
       list.
      http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0022.html

     * Herzberg: [10]Proposal for new PlainText element.
       Needs more time on the list.
      http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0035.html

     * Reagle/Schaad: [11]Remove Section 6.2?

     [11] http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0023.html

     Where a symmetric key is shared amongst multiple recipients,
     its encapsulating EncryptedKey should not reference or be
     referenced by other data not intended for all of those
     multiple recipients. (Kind of complex...?)
       Action Reagle: rewrite Section 6.2 and deprecate option 1
     * Schaad: [12]Parity bits in 3DES
       Agreement: put them back in.
      http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0018.html

     * (again) Should we define a streaming mode?
       Eastlake: now in there just to show how it can be done
       since there is interest.
       Reagle: Keep provissionally and ask for implementations.
     * Aswood: [13]Where to put the IV?
       Eastlake: clarified the text that the IV doesn't have to be
       present, or can occur somewhere else than that specified.
       Action Schaad: additionally, add a sentence explaining why
       we placed it as specified.

     [13] http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0011.html

   Misc.
     * Next call on June 25.