These minutes are not necessarily a complete capture of the presentations nor discussion. Instead, the goal is to clearly represent the identification of an issue, and the resulting proposals, straw polls, and action items. Four scribes took the minutes which were they tweaked and massaged together by Reagle, upon the final responsibility for any error rests -- since he may have tweaked the original thing incorrectly! However, if you have a question, comment, or correction, just send it on to the list!
Also see:
[A few questions on the particulars of authorization levels.]
Ed Simon: if folks are interested in Authorization work they might consider the PMI forum: Privileged Management Forum
[Discussion about whether the motivating scenario (leaving a node in the clear when its parents are encrypted is merited.]
Lapp: you might have a nested date that should be in the clear.
Prud'hommeaux: or an email address.
[Further discussion about designing the schema appropriately, or re-arranging the tree under a new schema and using subtree encryption so you don't need to worry about this scenario.]
Reagle: is the position of a node from its parents relative or absolute to the root? Geuer-Pollmann: Absolute
Schaad: what about a write-back/insertion, how do you deal with their position information? Geuer-Pollmann: haven't thought this through yet.
Nimishi: does this absolute position release information about its confidential parents? Geuer-Pollmann: potentially, but since spurious nodes can be added, this information can be obfuscated.
Mike Wray: the more granular you get in encryption, the more vulnerable the information becomes to attack. If you use a cipher over attribute names you could figure out the length of the attribute name.
Parez: does this scheme assume every client has same algorithm for public key? Geuer-Pollmann: No. Algorithm can be a URI for any scheme. Parez: how do you add a new client without re-encrypting the node? Geuer-Pollmann: add key material, possibly dynamic. Parez: then every client knows the secret. Geuer-Pollmann: secret is only used once. Wray : transporting shared key to multiple clients : Geuer-Pollmann: Yes, also two clients can collaborate to see more of a document.
Reagle: if we don't want to limit ourselves to elements and attribute values, we need to come away with a comfortable level of generality, this is not easy, but Christian's approach is an interesting exploration of "node" based encryption.
Simon: if you want to encrypt structure, then worrying about validation isn't important any more.
Requirements with respect to deployed parsers, target document fragments, nested encryptions.
Requirements
Would like to see clear processing rules for encrypting and decrypting.
Problems due to the use of detached documents
[Discussion] Joe Lapp: seemed to have an idea distinguishing between a person to person encryption, versus a complex multiparty system.
XBRL and Encryption
Underlying technology
Question: Eric (W3C) What’s the relationship between the nested groups
Question: Eric (W3C) Relationship between data types and XSD
Encryption Scenario
Encryption Questions
Primary applications
Make it easier to build PKI-reliant apps.
Traditional inhibitors
How XML helps
Goal
XML Pay
Where to add encryption
Wants "Encryption Only" specs.
Should look like XML Dsig
Question: Dave Solo: what about signing and encrypting? Answer: danger of separately encrypting each element under the same key.
Q: how do you prevent taking of blob of ciphertext and re-insert it into a subsequent message? (i.e. to reuse an encrypted credit card number). A: has not yet considered issue, since no encryption is currently taking place.
Canonicalization: Prefers enforced use of canonicalized XML even for encryption-only applications.
Q: why bother for encryption? A: just because it is cleaner
Q: Ed Simon. Besides character encoding, you have a reference. Other documents might use different entity reference and get different data. Is reluctant to make canonical XML required.
Q: Ed Simon. Does Verisign have their own XML parser? A: use compiler that maps schema to objects. Application specific.
Q: Lapp: will Verisign change their XML parser? Plambeck: Verisign parser is not relevant outside Verisign. Not an issue.
We need to ensure that similar things encrypted under the same key don't look alike
Questions.
Requirements
Temptation
Q Dave Solo: why is multi-party an edge case?A: need to support multiple recipients, but not pass through workflow.
Proposal
Q Joseph Reagle: what of the element are we encrypting? Subtree with start and end tags?A: align with Dsig.
Q Joseph: can you just encrypt content or do you need to encrypt tags?A: is arguing against encrypting attribute value?
Q: Steve Wiley, Ed Simon: is it node or element?A: element (the discussion was non-structured. The scribe is not certain that he captured the discussion correctly).
Base requirements
New requirements
Q Dave Solo: should output be definition as a Dsig transform. Define the encryption transform as something that can be placed into Dsig. There should be URI that can point to transform. A: agreed
Q Ed Simon: was in original transform. Need reversibility of transform. A Dave Solo: will need two transforms. Encrypt and decrypt.
AES will need Keywrap algorithm. Should be coordinated with S/MIME. WG is working with NSA on the algorithm.
Need threshold system support. Distribution of encrypted content where encrypted content and Keyinfo are shipped separately.
Conclusions
Q Joseph Reagle: could you provide an example for state mechanism? A: need to do cipher block chaining. Where do you hold the IV? Modes need additional info.
Q Mike Wray: chaining requires state
Q Joseph Reagle: if error, decrypt will fail. Which is different from us having to place in mechanism to prevent it from failing.
Q Joseph Reagle: can you provide a scenario for the threshold? A: need to indicate that a key may only be a share, not entire key.
No specific requirements
Interested in providing high-level toolkits, just cares that what goes into the standard is sensible.
Scoping is the biggest challenge.
Let’s get one small spec going rapidly that will a small part of the requirements.
Agreement that we should finish a small chunk of work first that can be delivered.
B: Barb Fox. Once the deliverable goes towards proposed standard, it will become difficult to make changes. Let’s not address protocols and assure alignment with Dsig. It is important to not limit implementation, either.
B Ed Simon: PKCS #7 is unusable until the secure blob is unsecured. Not so in XML. Part of the data can still be used.
B Joseph Reagle: keep Keyinfo in separate parts of the spec?
A Barb Fox: should we split work?
B Young Etheridge: as long as we establish intent up front, we won’t later find that we forgot something that needs to be done.
B Joseph Reagle: requirements document will establish scope.
Clarification: DecryptionInfo is the same as EncryptionInfo in Ed's current (as of 2 Nov 2000) document.
Reagle: Are PIs and comments children? Simon/Eastlake: Yes, they are.
Fox, et al: The spec for encrypted attributes is a "very undone deal." E.g., where should the encrypted attribute value go? Should the manifest always be a child? In any case, the slide should read, "XML Attribute Value Nodes."
Wray, Solo: Sign-then-encrypt or encrypt-then-sign are more subtle than presented. This transform is one of those.
Fox: might need a retroactive DSig requirement in order to get encryption and signature to work together. Also: Need to look at how this is really used, e.g., XML doc, XML message, etc.
ACTION Solo: write up encryption/signature scenario.
Schaad: Note that there was no schema or DTD validation with XMLEncryptor demo. Started with question about the fact that one of today's off-the-shelf parsers could be used.
Clark: What parser call backs would you use? See Fox example(s). The main example has to do with validation. [?] If you want to validate your new DOM tree, then you would need a call back.
Reagle call for straw poll: Are people ok with the encrypted document not conforming to original schema that did not consider specification of encryption?
Simon mention, given that everything is typed in schema, encrypting even element content (e.g., CDATA) will invalidate the instance.
[Discussion]: no vote since confused. ACTION Reagle: propose something on the list.
Schaad: Can we push on the schema group for an encryption specification?
Lapp: A schema is part of a "contract" between the two parties exchanging the document. If they want portions to be encrypted, that should be in the schema.
Reagle: Good point, however we found in xmldsig that we couldn't always presume all schema and instance authors would have enough foresight to design their applications to work with signatures (before signature was even complete!).
Prud'hommeaux: Why not just decrypt it? Schaad: One example, of many, is encryption for access control.
Cohen, Reagle: Should XML encryption work with WAP? Big issue that we shouldn't go into now, though we have to consider "small devices." With respect to WAP, convergence is likely and the next version will be more XML'ish on IPv6.
Shaad: Option for element names and attribute names in the clear, with everything else encrypted. This can be done, but there should be a simpler way to do it
Clarification: Simon is doing data part, Hiroshi is doing the key part.
Clarification: Did not consider encryption of attribute values at the time this presentation was prepared.
Reagle poll: ~12 for EncryptionInfo, ~5 for DecryptionInfo. No one opposed to "CryptionInfo" element (but not clear how serious that proposal is.
Reagle poll: Nobody is opposed to EncryptionPropertyList.
Latone (unvoiced opinion): Why not CryptoInfo/CryptioProperties.
Reagle poll: anyone want to use bi-directional XLink? Or should we stick with <Reference URI="#foo">. Consensus to stay with URI.
Reagle: However, it's starting to get confusing understanding the relationship between these things.
Simon proposes: <EncryptedData DecyrptionInfoURI="foo">...<>. Folks seem to think some qualification of this sort is a good idea.
Solo, Fox, Asthagari: KeyInfo should be more generic and less "protocoly."
Reagle prompted by Ferguson: Goal of spec is that one could implement it well, easily. This is especially important for the not-so-well understood topic of security. However, we won't tell people how to implement.
Ferguson: Voiced concern about how XML security is implemented. Can the WG ensure that it's used properly? Consensus: No, but the WG recognizes that security is unique in several aspects wrt implementation and will take responsibility for writing good notes regarding security attack issues.
Solo, Fox: The issue of sign-then-encrypt versus sign-and-someone-else-encrypts versus encrypt-and someone-else-signs was brought up again. Can we distinguish these cases syntactically?
Wray: Layered processing needs to be specified. This is true for any transformation processing.
Reagle call for volunteer to write use cases on the last two items in this minutes list: Solo volunteered to write up a short note.
Speaker - Joseph Reagle, W3C
Scribe - Shivaram Mysore, Sun Microsystems, Inc
11 votes (preclude) / 13 votes (encrypt attributes)
Ok, there's no consensus to make a change from present proposals; needs further discussion.
Majority opted for encrypting everything between Start and End Tags
Discussion: Action Reagle, sent proposal on text to list about if you want to encrypt the structure, then by definition you aren't too concerned with the original structures (and its DTD/schema). If you do want to encrypt structure, you should design your schema according, created intermediary schemas, or only encrypt CDATA use an external XML document to contain the DecryptionInfo and such.
No objection.
No objection.
[Discussion] ACTION Schaad: send a profile of candidate algorithms (including padding) with recommendations to the list.
[Discussion about whether it would be optionally specified or required.] Many people answer strong NO because of prior experiences in IETF with patent related issues. A few people like the idea, but no consensus to include compression algorithms.
[Discussion] It was agreed that mandatory implementation of Canonicalization, but optional use would be the right thing to do. It was mentioned that Encoding, entities, and namespaces could all be problematic if canonicalization is not used.
Fox: general sentiment is probably ok, but your wording isn't quite right. Needs further work. ACTION Reagle: investigate W3C WG and post summary of issue on the list.
Lapp: Union operations and recursive descent are problems with performance
[Discussion about whether all use of XPath is costly and whether mandatory use of XPath optional features is acceptable.]
Reagle: Ok, don't think we'll resolve this today, let's continue with Motherhood and ApplePie statement that we want good performance wherever possible and keep an eye on this issue as we progress.