Note taker: David Wen, [email protected] with help from [email protected], edited by Joseph Reagle.
See attendance.
Topic: sections 5.4 (Key Transport), 5.5 (Key Agreement), and 5.6 (Symmetric Key Wrap).
Discussion:
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.]
Action Eastlake: send proposal. Action Reagle: investigate default state of schema element modification.
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.
Questions:
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.
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).
Note taker: Eric E. Cohen, edited by Joseph Reagle.
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:
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.
Reagle: While we can argue these issues are out of scope we have some responsibility to help people using the spec, identifies three options:
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.
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.
Note: the Stream encryption section is the only section using KeySize child. Need to keep section and child, even if Diffie-Hellman is removed in the future.
Action Reagle: change algorithm identifiers to &xenc;#tripledes.
People are generally happy with Symmetric Key Wrap although they are unsure if they will ever use it.
[ Correction:] "I believe Mike Just and I [Frederick Hirsch] questioned whether Symmetric key wrap should be required or recommended. I am not sure that it should be required. The argument is that it will be necessary for efficient protocol encryption, but if I have applications which are not of that nature that would not be a requirement. Perhaps the minutes should reflect that question, even though it sounded like this may need to be required for interoperability."
Jim Schaad asked how you test interoperability on this. He suggested removing recommended and optional. Blair Dillaway offered that it is important only to sender.
Action Eastlake: Remove the mandatory key words from the section.
The group decided to change the type / content of OAEP parameters to base 64.
5.6.3 needs references to real stuff when it goes public per Don.
Don also says 5.9 may need to move to another section with changes.
Reagle reminded the group about the IPR disclosure
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:
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).