XML Encryption WG

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

Participants

• Joseph Reagle, W3C
• Blair Dillaway, Microsoft
• Shivaram Mysore, Sun Microsystems
• Frederick Hirsch, Zolera
• Katherine Betz, IBM
• Eric E. Cohen, PricewaterhouseCoopers LLP
• Donald Eastlake 3rd, Motorola
• Mark Scherling, RSA
• John Velissarios, PricewaterhouseCoopers LLP
• John Messing, Law on Line
• Amir Herzberg, NewGenPay

Status of documents < 5 minutes

• Requirements - Published as first W3C Working Draft
• Syntax and Processing - Reagle redid Overview comments on list need response.

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?"

   Done

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

   Done

Requirements

• Now that it's published, please have another look and let me know if I dropped anything on the floor or didn't get it right.

Draft

• Schema reuse: Reagle investigated, looks like we can not use more sophisticated ds:KeyInfo reuse, but instead use the ds:KeyInfo ANY and create "orphaned" elements (KeyRetrievalMethod and EncryptedKey) in the encryption namespace/schema.
• Reagle: Can we move away from KeyRetrievalMethod, and just use dsig's RetrievalMethod with a particular type? (This was the intent of ds:RetrievalMethod).

  <RetrievalMethod URI="http://someKey" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>

  • Dillaway: could be done.
  • Deferred to list for discussion and opposition.
• Thoughts on rewritten section 2?
  • None on the call, though there has been discussion on the list that needs to be addressed.
• Algorithm progress?
  • Eastlake, hopes to post something within the next few days.
• Imamura: Does this mean the KeyRetrievalMethod element must not occur within the KeyInfo element of an EncryptedKey element?
  • Dillaway will send tweaked text to generalize to the list.
• Imamura: Does CipherData include CryptoBinary or a set of Transforms? Reagle: We probably need a new element, what should we call it?
  • Need some new structure, two candidates include
    1. Reagle: Two children of CipherData: Reference and Value.
    2. Eastlake: Two alternatives to replace CipherData: Cipher(Data|Value) and CipherReference

    Deferred to more discussion on list.

• NameKey, should we think of a better name?
  • Herzberg: Make it of the form of (prefix)KeyName (like "friendly")
  • Reagle: where prefix communicates that this is the name of the (symmetric) key encrypted and carried in the EncryptedKey CipherData.
• Processing Model
  • Reagle: Any thoughts on this section? I definitely need feedback.
  • None yet.

Misc

• Reagle: Next call on May 14. Reagle  will be in Asia April 25 - May 8 for WWW10/W3C-AC and Europe from May 22 -May 29th for XML 2001 Europe. So 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.