W3C logo, link to home page XML Encryption WG

Chair: Joseph Reagle


Session I

Note taker: David Wen, dwen@activcard.com with help from jroupas@rsasecurity.com, edited by Joseph Reagle.

Introductions / History / Agenda Bashing. Joseph Reagle.

See attendance.

Proposal: Dropping the Type algorithm for a given key. (20m)

Topic: sections 5.4 (Key Transport), 5.5 (Key Agreement), and 5.6 (Symmetric Key Wrap).


Q: Jim Schaad: there is a need to know the algorithm for bulk encryption, also need to process encrypted key before processing encrypted data. Algorithm is needed for key agreement.

A: Don Eastlake: (no answer for the first comments) encrypted key is the same as encrypted data, so the same requirement applies. Yes, key agreement should keep the algorithm type.

Q: Blair Dillaway: if you don’t know the algorithm how do you know the context of using the key

A: [not answered directly]

Summary by Joseph Reagle: little disagreement to tweak sections 5.4 & 5.6. Action   Eastlake: follow up the alternative to 5.5 and make changes in the document. [Editorial note: We might not have captured the discussion of alternatives.]

Proposal: Nonce attribute. (15m)

Action Eastlake: send proposal. Action Reagle: investigate default state of schema element modification.

Proposal: Requirement to Warn of Surreptitious Forwarding (15m)

Proposal to warn recipients with a message such as "Being the recipient of an encrypted message does not imply that the message was intended for you"

Dillaway and Hallam-Baker made comments on whether it is in scope of XKMS or whether it is a practical security concern. Jim and Fredrick commented that they may be part of the XML-dsig rather than XML-enc. Reagle notes hesitance to alter XML-dsig and this error seems to crop up in the encryption context. Reagle takes informal poll: most feel that the issue does not belong in this WG as it has nothing to do with encryption and do not want the warning statement in the requirements nor the specification.

After further discussion, the group agrees to include a statement akin to, "the presence of encryption does not imply anything about integrity or authenticity of the message" and include a reference to those sections ("see what you sign") of xmldsig; add a sentence in XML-dsig with this recipient issue as an example. Action Reagle: do the edits to xmlenc and xmldsig specs.

Report: Implementation Experience, Takeshi Imamura [slides (pdf, html)]


Reagle: what is the performance like, is DOM, C14N, or the encryption the expensive parts? Group reports that canonicalization is by far the most time consuming process.

Proposal: DigestMethod/DigestValue Removal, Jim Schaad

Schaad: believes Herzberg wanted integrity, and something about the plaintext as it was before encryption. For the same reasons that Finney raised earlier about signature over plaintext, Schaad doesn't like plaintext being in the clear, should be encrypted as part of the CipherData; otherwise it allows for guessing of the original text if insufficient randomness exists.

Group: discussion of earlier approach of having integrity be part of the algorithm URI, people felt this led to too many algorithms identifiers. Present approach not liked for reasons stated.

Reagle: a poll was taken for Jim’s proposal: 5 supported Jim’s proposal and 2 supported the current status. Eastlake suggested the proposal to be further discussion in the list.

Schaad: Proposed this as an optional element: If one wants integrity checks, then provide a new URI. Action Schaad: send proposal for integrity to list within the week with the necessary changes. Otherwise, need a use case (Herzberg engage Schaad in discussion) of the initial problem was, so we can understand the application where it applies (understanding now that it was wanted to have the digest value outside)

(aside): NONCE=number Not used more than ONCE

(aside): need a note not to warn against reusing IV in stream ciphers. (Action Eastlake).

Session II

Note taker: Eric E. Cohen, edited by Joseph Reagle.

Discussion: Processing Rules for XML Data, Ed Simon [sides (ppt, html)]

Should the specification always require "replacement", if not, is it the default behavior?

Ed Simon gave a presentation on processing rules for XML Elements and Content focusing on the necessity of replacement: should it be mandatory or optional? This is a topic that has been discussed on the list.

Is it always necessary to replace the source plain text when encrypting (encryptAndReplace), and always necessary to replace with plain text when decrypting (decryptAndReplace). Should it be a default or mandatory?

Joseph Reagle suggested that the need might be met by changing the specification to say: Data should be replaced or made available to the application.

A Poll was taken of the group on the behaviors. Based on that poll it was determined that:

  1. Taking in octet and deliver encrypted, take in encrypted and deliver octet is Required.
  2. Replace and encrypt will be Recommended (optional).

Blair Dillaway asked about serialization; is it up to the implementor to determine how to serialize: as-is, etc? There was discussion that, at the least, we should provide 'caveats':
don't change context where data lives or you will not be able to restore document.

Discussion continued that we need to agree on how to describe in the document, where we stop (such as, we are not describing XML Encryption support for SOAP). Action Item Dillaway: revisit/review section 4.3 to determine if text is satisfactory or not. InfoSet group providing pushback on this area.

Discuss: Encryption processing model and applications (SOAP) (15m)

Reagle: While we can argue these issues are out of scope we have some responsibility to help people using the spec, identifies three options:

  1. (XML Encryption) create a working group
  2. They (XML Protocol) create a working group
  3. An informal task force

The group opted for the information task force. The volunteers for task force: Blair Dillaway or MS representative, Frederick Hirsch, Dan Ash, Donald Eastlake, Takeshi Imamura.

Review: Algorithms and Compliance Requirements, Don Eastlake (30m)

Donald Eastlake led a discussion through the algorithm section. Joseph Reagle explained that if there was no champion or plan to implement an algorithm, we should strongly consider removing it from the draft.

Review Charter, Milestones, and Schedule (30m), Propose Update:

Patent Disclosures and License

Reagle reminded the group about the IPR disclosure

Last call and Schedule

Reagle asked the group if there are any problems with being at last call presuming we complete all action items resulting from this meeting? No objections.

Reagle proposes:

Requirements Last Call
XML Encryption Last Call
October 2001
XML Encryption Candidate REC
January 2002
XML Encryption Proposed REC

Are there any concerns that the schedule as provided is realistic? No objections to schedule for conference.

Teleconferences Monday, 1 Eastern, every other week or so working well.

Aug 6 is IETF meeting, so we can have the next teleconference call on August 13 (alternating Mondays with DSIG).

Resulting Action Items

  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.
  5. Eastlake: add a note not to warn against reusing IV in stream ciphers.
  6. Dillaway: review section 4.3 on serialization and documentation.
  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.

Joseph Reagle <reagle@w3.org> last revised $Date: 2001/07/31 20:35:28 $ by $Author: reagle $