[1]W3C   [2]XML Encryption WG

      [1] http://www.w3.org/
      [2] http://www.w3.org/Encryption/2001/Overview.html

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

      [3] http://www.w3.org/Encryption/2001/Minutes/010625-tele.html,text

Participants

     * Joseph Reagle, W3C
     * Blair Dillaway, Microsoft
     * Donald Eastlake 3rd, Motorola
     * Ed Simon
     * Hans Granquist, Verisign
     * Frederick Hirsch, Zolera
     * Eric Cohen, PricewaterhouseCoopers
     * Daniel Toth, Ford

News

     * Registration for FTF closed.
     * Davis's "[4]Sign Then Encrypt" Paper is publically
       available, Reagle will send a proposal for a requirement.

      [4] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

Status of documents

     * Fairly complete editors' draft available, the [5]Technical
       Report version and the Decryption Signature Transform will
       be published tomorrow (Tuesday).

      [5] http://www.w3.org/TR/

Reviewing [6]Previous Items

      [6] http://www.w3.org/Encryption/2001/Minutes/010611-tele.html

     * Reagle: Raised in xmldsig, but also relevant here: Schema
       WG is still looking into the base64 issue -- and I'm
       continuing to pester them.
     * Reagle: Supposed to resolve questions of DigestMethod and
       DigestValue in CipherData. Dependent on Schaad: re-engaging
       Herzberg on list.
     * Eastlake: Proposed using a nonce. (Present in KeyAgreement,
       do we need it more generally? -- Reagle).
       Eastlake: send to a proposal for a nonce attribute to salt
       the data being encrypted if that instance's schema permits
       nonces to be added.

Requirements

   ...

Draft

     * [7]PlainData
       Eastlake: I think he's trying to make it easier to denote
       what should be encrypted -- and make it clear that the
       DigestMethod and DigestValue apply to the plaintext not the
       ciphertext.
       Reagle: I hope it's clear in the spec that DigestValue is
       over the plaintext. Otherwise this seems like an
       application issue to me (how it internally designates which
       sections to process)? I asked him to explain it a bit more
       on the list, so we'll roll this forward.
     * [8]Processing CipherData (what is returned?)
       Simon: it's the octet sequence that you would hand off to
       the encryption sequence. Also, there's the small topic of
       the "default behaviour" with respect to processing (e.g.,
       replacing) EncryptedData in an instance.
       Dillaway: we're not to far off on this, can discuss and go
       through the scenarios at the FTF.
       Simon: also in [9]Takeshi's about the difference between
       octets representing XML and Canonical XML, but we need more
       discussion on the list to properly understand.
     * Reagle: comments on the Latest Algorithm Section?
       Eastlake: not much yet.
     * Reagle: FTF -- since things are running fairly smoothly, we
       should take advantage of the time. I doubt we could do a
       last call and get all comments prior to the face to face
       (since last call implies the WG feels it has addressed all
       issues and has consensus) but we should solicit the wider
       community for comments; and if folks are interested in
       doing early interop, we should get a head start on that as
       well!

      [7] http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0035.html
      [8] http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0087.html
      [9] http://lists.w3.org/Archives/Public/xml-encryption/2001Jun/0091.html

Misc.

     * Next call on July 9.