XML Encryption WG

2001-May-15
Chair: Joseph Reagle
Note Taker: Joseph Reagle [text]

Participants

• Joseph Reagle, W3C
• Blair Dillaway, Microsoft
• Frederick Hirsch, Zolera
• Katherine Betz, IBM
• Eric E. Cohen, PricewaterhouseCoopers LLP
• Donald Eastlake 3rd, Motorola
• Mark Scherling, RSA
• John Velissarios, PricewaterhouseCoopers LLP
• Ed Simon,
• "Rags" Srinivas
• Cicy Guiney(?), Baltimore
• Dan Toth, Ford
• Mimi Tran, Verisign
• Amir Herzberg, NewGenPay
• David Stern, Intel
• David Solo, Citigroup

News

• Reagle: will post logistics of July 20th FTF later today. There's the possibility of a XKMS Workshop on July 19th, but the deadline for making that announcement is this Thursday, so if everything isn't ready by then, a later date will be considered.

Status of documents

• Plans: First Spec Working Draft mid-June; also a Requirements Last Call at the same time. Might be able to publish Decryption Transform for XML Signature then as well.

Reviewing Previous Items

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

   Dillaway proposed text, Reagle included it in the latest proposal.

2. Eastlake: draft a more complete algorithm section including algorithm profiles and IV checksum cipher data values.

   Done: first draft accomplished, WG should comment.

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

   Done: Decryption Transform for XML Signature, WG should comment.

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

   Done: Takeshi reports he believes we should maintain the octet processing model, though it may make DOM/Infoset based implementations more tricky.

   Dillaway: also believes this is the right approach.

Requirements

• Support for signing plaintext and ciphertext via <HashOfRandomized> .

  Herzberg: how to address the signing of a message over which portions of which will be subsequently encrypted (both signature and encryption are by the author). This is a follow-up to earlier threads on security of encrypted&signed text, where the signature should not leak information about the plaintext now purposefully obscured by the encryption.

  Reagle: Let's continue this discussion on the list (and also look at Decryption Transform for XML Signature.)

• Kudos and Comments on XML Encryption Requirements working draft (Miller)

  Action Reagle: respond.

Draft

• Can we move away from KeyRetrievalMethod towards RetrievalMethod with a particular type? (Not much more discussion on the list, let's decide one way or the other.)

  Action: Reagle check with Schaad, otherwise no opposition.

• 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

  Reagle: I created a CipherReference and CipherValue as children of CipherData for expositional convenience.

  Dillaway and Simon support this, Don still prefers option 2 (not needing the extra level of nesting) but it isn't a show-stopper issue.

• NameKey: needs a better name. Candidates include "FriendlyKeyName" (discussed on last call), "CarriedKeyName" (now proposed by Reagle), or "NamedKeySelection" or "KeyIndex" (proposed by Hirsch).

  Not much more discussion on the list, let's decide one way or the other: CarriedKeyName.

• Farrell: Is whitespace in KeyName significant? Simon: strip the trailing and beginning white space, but otherwise you should be careful.

  Reagle: Isn't this a dsig issue, should we specify processing behavior for elements in the dsig namespace?

  Action Eastlake: will post message to xmldsig list.

• Dillaway: distinction between Element and children not really necessary. Trying to simplify, not a strong proposal. Reagle, investigate, option of renaming itself.

Misc.

• Next call on June 11.
• Reagle will be in Europe from May 22 -May 29th for XML 2001 Europe. dsig/xenc presentation on Friday.
• Simon will be giving a tutorial earlier in the week.