XML Encryption WG

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 Last Call Issues document for tracking.

Reviewing Previous Items

1. ACTION Eastlake: Edit section 5.5 . "Is it possible to change the order of the input to KM so that it will look like:"
2. ACTION Dillway: consider Key threshold schemes on top of KeyInfo in one week.
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 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.

• 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.

• Christian Geuer-Pollmann: Encrypting IV in ECB, 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).

Misc.

• TBD: Next call on January 21, 2002.