Minutes of 020114-tele

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


  2002-January-14
  Chair: Joseph Reagle
  Note Taker: Joseph Reagle

Participants

     * Joseph Reagle, W3C
     * Ed Simon, XMLsec
     * Donald Eastlake, Motorola
     * Katherine Betz, IBM
     * Christian Geuer-Pollmann, Uni Siegen
     * Frederick Hirsch, Zolera

News

Status of documents

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

      [3] http://www.w3.org/Encryption/2001/11/last-call-issues.html

Reviewing [4]Previous Items

    1. [DEL: ACTION Eastlake: Edit section 5.5 . "Is it possible to
       change the order of the input to KM so that it will look like:"
       :DEL]
    2. [DEL: ACTION Dillway: consider Key threshold schemes on top of
       KeyInfo in one week. :DEL]
    3. Eastlake: add real life examples in section 5.5 to illustrate.
       Pending. (Still need that later example?)
    4. 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

     * Section 5 tweaks
         1. ACTION Eastlake: DH: RFC 2631 versus PKCS3
         2. ACTION Eastlake:Nonces and IVs: "It is unclear to me what
            "algorithm dependent length" is referring to in the second
            sentence."
         3. DONE:. Typo in another spec, the RFC will be corrected.
     * Martin Duerst: Are our MIME type URIs supported by IANA?
         1. Reagle: Are peole ok with with the URIs of the form?:
            http://www.isi.edu/in-notes/iana/assignments/media-types/*/
            Generally yes with two caveats:
              1. Certainly better if the URI had an IANA address instead
                 of ISI.
              2. Don notes he prefers his [6]proposal (ietf-draft) for
                 mapping mediatypes into URIs but isn't opposed to the
                 ISI/IANA URI.
         2. Reagle: Regardless of what method we use to represent the
            media-type (URI or text string) do we need two URIs? One for
            higher level types like Content, ElementContent or even the
            ds:Types (PGP, X509, etc). Do we need a MediaType URI?
            Still not sure. ACTION Reagle: write up issue on list and
            talk to TimBL.
     * [7]Joseph Reagle & Christian Geuer-Pollman: How is the Type used
       in EncryptedKey? How to encrypt ds:KeyValue? From what Takeshi
       said, ds:KeyValue would be encrypted with EncryptedData.
       Simon: doesn't see much of a different, but with respect to
       functionlity if its EncryptedData then it's part of the document;
       EncryptedKey you don't have to worry about replacing *back* into
       the document.
       ACTION Reagle: more discussion (continue with Takeshi Imamu) about
       what a "XML encoded" key means (as distinct from a ds:KeyValue)
       and propose some text for the spec explaining when to use
       EncryptedData versus EncryptedKey.
     * [8]Christian Geuer-Pollmann: Encrypting IV in ECB, [9]removing
       nonce, and
         1. Reagle: saw three potential issues on the list:
              1. Remove text saying a nonce prevents CBC IV attack?
                 ACTION Eastlake: tweak text.
              2. Encrypt the IV in ECB: this prevents the "Type B attack:
                 change the underlining plaintext wihtout breaking the
                 encryption."
                 Reagle: let's continue to discuss this, we can always
                 revert to "If you care about integrity, sign it."
              3. Reagle: "Type A attack: breaking the question and
                 revealing the plaintext." Does adding a nonce add
                 randomness to the whole chain of blocks, or only the
                 immediately following one? This confusing seems to be
                 based on two things. The facts that in CBC (a) errors
                 don't propogate very far and (b) if you change the first
                 block all subsequent blocks will change.
                   1. Eastlake: on entropy, assume you have something
                      encrypted and someone is doing a dictionary attack.
                      Adding an encrypted nonce *will* make it harder to
                      attack the whole of the message.
                      Reagle: Christian, are you disagreeing that the
                      nonce is useful, or only redudant?
                      Christian: agrees that the nonce can help with
                      securing the whole chain of blocks (not the just
                      the two following blocks) but feels that is
                      redundant with an IV if you choose a *random* IV.
                      Reagle: If we accept Christian's assertion that a
                      random IV is sufficient for mitigating plain-text
                      attacks, is it acceptable to get rid of the Nonce
                      attribute?
                      Hirsch/Simon/Eastlake: Yes.
                      Reagle: what if the nonce would be used for other
                      algorithms and modes beyond the ones we specify?
                      Eastlake: those can be accomodated via
                      EncryptionMethod's <ANY/> as parameters...
                      Reagle: OK, let's check with crypto experts that
                      random IV is sufficient (no need for nonce), that
                      it mitigates attacks against the whole sequence of
                      chained blocks (and then remove the nonce) and
                      whether encrypting the IV (to protect against "Type
                      B" attack) is useful. But otherwise, be prepared to
                      remove Nonce (unless objection on list and
                      elsewhere).

      [6] http://www.ietf.org/internet-drafts/draft-eastlake-cturi-03.txt
      [7] 
http://lists.w3.org/Archives/Public/xml-encryption/2002Jan/0017.html
      [8] 
http://lists.w3.org/Archives/Public/xml-encryption/2001Nov/0010.html
      [9] 
http://lists.w3.org/Archives/Public/xml-encryption/2002Jan/0040.html

Misc.

     * TBD: [DEL: Next call on January 21, 2002. :DEL]

Received on Monday, 14 January 2002 16:00:48 UTC