XML Encryption WG

2001-April-02
Chair: Joseph Reagle
Note Taker: Joseph Reagle [text]

Participants

• Joseph Reagle, W3C
• Blair Dillaway, Microsoft
• Ed Simon, Entrust
• Shivaram Mysore, Sun Microsystems
• Frederick Hirsch, Zolera
• Katherine Betz, IBM
• Eric E. Cohen, PricewaterhouseCoopers LLP
• Daniel Toth, Ford
• Donald Eastlake 3rd, Motorola
• Mark Scherling, RSA

Status of documents < 5 minutes

• Requirements - Waiting on W3C process to publish as a W3C Working Draft.
• Syntax and Processing - still needs a lot of editing work.

Reviewing Previous Items

1. Eastlake: draft a more complete algorithm section include algorithm profiles and IV checksum cipher text values.

   Pending.

2. Maruyama: update the Encryption/Signature Transform. Update Security Considerations, add a scenario or two (and maybe borrow "enc:DataRef" instead of using "EncryptedReference").

   Pending

3. Maruyama: an email exploring the question of our processing model and the relationship between DOM, Infoset, and serialization and the issue related to using current parsers to get a pointer to a byte where element starting "<" is.

   Pending

4. Reagle: "Review the use of a URI versus an ID and NameKey in an EncryptedKey element?"

   Pending

5. Reagle: Write an email describing options with respect to reuse of dsig KeyInfo.

   Done

6. Reagle: Inform Don Davis of new requirements document when complete and that issue 6.2 was dropped.

   Pending

Requirements

• Amir's request for OEAP: "furthermore using MAC may not be feasible if we use public key encryption and the parties do not (wish to) share a key.... However this does not address the problem for public key encryption; in this what is needed really is plaintext-aware encryption such as RSA-OEAP, already specified for key transport. "
  • Dillaway: Ok with this specification as long as it remains optional.
  • Reagle: I don't recall if at the FTF when we said, "4.2.7 ... at least one encryption + checksum category will be included; AES with SHA1 and 3DES with SHA1" whether it was optional or required to implement?
  • (Group's recollection was that it was optional.)
  • Resolution: if someone specified it, we'll consider it.
  • Also, can anyone provide me a pointer to an OEAP definition in an  RFC?
    • (Eastlake finds RFC2437)
    • (Reagle: I've run into this problem before, is it OAEP or OEAP?

Draft

DSIG schema reuse

• Action: Reagle/Dillaway/(everyone): try to get schema experts to have a look at the 3 options outlined.

Data/Processing Model (Infoset or DOM)

• Reagle: we have to choose a data model, should we do Infoset, DOM, XPath/C14N/ XML Query, etc.? Need to consider what information the data model provides, does it have URIs to identify its structures, and does it have a specified serialization (or we have to do our own?)
• Reagle: One easy issue, I proposed that we encrypt XML documents as a bag of bits with text/xml. Resolution: no opposition.
• DOM or Infoset?
  • Simon: the serialization needs to be reversible.
  • Reagle: DOM Level 3 is supposed to have a serialization method.
  • Dillaway: (later) found DOM Load and Save DOMWriter interface with as-is formatting.
  • Reagle: If we use this, how much of DOM do we have to support? (Similar question to use schema for our structures, does that necessitate complete schema implementation/compliance: hopefully not.) Could we still work with an event based parser?
  • Reagle: Also, minimal c14n from dsig might do the trick?
  • Eastlake: minimal c14n did character and line feed normalization. Also, full canonicalization could be an option?
  • Reagle: no optionality, the application does what it wants (including full Canonical XML) to the XML before it Encrypts. The encryption itself should have a mandatory single/simple serialization method.
  • Reagle: If we went the simple route, do I need to preserve that information (like a namespace from its parents) or not?
  • Simon: Again, the application should tweak the XML as it requires including any namespace normalization prior to encryption.
  • Eastlake: If we take an element and encrypt it, do you need to know what character encoding of it was?
  • Blair: the draft says always convert to UTF-8 prior to encoding, when decrypt put it in its parents form.
  • (Everyone agrees this still sounds like the right approach.)

Security

• Revealing References
  • Group: No advocate for changing syntax yet (plus no specific proposal on table), instead feel this is an application issue people need to be careful with.
  • Simon: encrypting references to hide the fact that the same symmetric key is used sounds like security through obscurity.
  • Dillaway: agree, someone could still try their symmetric key against other EncryptedData objects and see what falls out.
  • Reagle: so what text are we happiest with.
  • Group: supports inclusion of text 3 and 4, while leaning towards 4.
• Signing and Encrypting
  • Reagle: any thoughts on the Wang, Ashwood, Herzberg thread?
  • Group: no comments, will wait for specific proposals resulting from its conclusion.

Misc

• Reagle: Next call on the16th. I will be in Asia April 25 - May 8 for WWW10/W3C-AC and Europe from May 22 -May 29th for XML 2001 Europe. So my productivity and ability to convene teleconferences will be low but discussion can happen on list and I can still have a bridge made available for discussion.
• Reagle: Also, reminder to ourselves to think about FTF in June/July.