XML Encryption WG

2001-August-20
Chair: Joseph Reagle
Note Taker: Joseph Reagle [text]

Participants

• Joseph Reagle, W3C
• Blair Dillaway, Microsoft
• Katherine Betz, IBM
• Donald Eastlake 3rd, Motorola
• Ed Simon, XMLSec
• Eric Cohen, PricewaterhouseCoopers

News

• No news is good news.

Status of documents

• We'd like to go to last call, need to finish up a few of these issues.

Reviewing Previous Items

From FTF minutes.

1. Eastlake: follow up the alternative to 5.5 and make changes in the document.
2. Eastlake: send proposal on nonce.Reagle: investigate default state of schema element modification.
3. Reagle: do the edits to xmlenc and xmldsig specs to address "surreptitious forwarding"
4. Schaad: on DigestMethod/DigestValue send proposal for integrity to list within the week with the necessary changes. Action Eastlake: given Schaad's abense, send an email with this proposal.
5. Eastlake: add a note to warn against reusing IV in stream ciphers.
6. Dillaway: review section 4.3 on serialization and documentation. (Dillway will post this text as part of section 4 proposal this week.)
7. Reagle: convene informal enc+soap task force.
8. Reagle: update document where name 3DES is used to TripleDES in both places referenced to get around number as first character. (e.g. http://www.w3.org/2001/04/xmlenc#3des-cbc)
9. Eastlake: remove the mandatory key words from the section on Canonicalization.
10. Eastlake: change the type / content of OAEP parameters to base 64.
11. Eastlake: add real life examples in section 5.5 to illustrate.

Requirements

...

Draft

• XML Encryption Processing Model

  Some trickyness, for example, how to deal with a nodelist (without any parent element). The likely options include some fairly complex processing, or keeping it simple.

  Folks lean towards keeping it simple and letting the application figure out how to deal with it before (and if) the decrypted data needs to be parsed.

  Action Dillaway: tweak section 4.0 to represnt his understanding/proposal of recent discussions.

• Nonce: if we can't expect to change the content, do we need it to be part of the processing?

  Two options:

  1. Encode the presense and length of a nonce within the encoded CipherValue.
  2. Represent it with XML in the CipherData Structure.

  Simon, earlier understanding that option 1 was more efficient.

  Dillaway: but I'd like the default to be no nonce is expected.

  Reagle: then you need something in the XML telling you regardless, and if we do that, why not just include the length as well?

  Simon: why not represent it in XML, if people have problems will change.

  Action Reagle: make it a declaration within CipherData using Eastlake's nonce proposal text where necessary.

• Last Words on "Encrypt-then-Sign" issue

  Call: text is acceptable.

Misc.

• Next call on September 10, 2001.