| CARVIEW |
Minutes W3C XML-Encryption Workshop
San
Francisco, CA
2 November 2000
DRAFT MINUTES
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:
Resulting Action Items:
- Barb Fox: proposals and scenarios for CBC mode and the need for sequence numbers, and for threshold encryption schemes. Due 11/27/00.
- Dave Solo: Scenarios for using XML Encryption with XML Encryption (signed/encrypt, encrypt/sign, etc.)
- Jim Schaad: Brief description of candidate algorithms: Key transport RSA V, key info, key name, padding algorithms, mandatory implemented algorithms. In case of mandatory implemented algorithms, one of each category must be implemented by default. No more than one is mandatory in a particular category is necessary (result after issue brought up by Nimisha, Groove Networks and answered by the group).
- Joseph Reagle: Check with Patent Working Group and look into Protocols Charter (Eric, W3C) about issues on Intellectual Property and Licensing Fees.
- Joseph Reagle: Propose text on validation.
- Joseph Reagle: Update requirements document.
- Joseph Reagle: Move charter forward.
THURSDAY 02 NOVEMBER
9.00 - 9.35: Introduction
- Group, Introductions Around the Room
- Joseph Reagle, Agenda
- Thanks to XCert for hosting
- Volunteers for Minute taking
- Group, Agenda Bashing
9.50 - 10.30: Encryption, Authentication, and Authorization (scribe: Eric Prud'hommeaux)
- Mark Scherling [slides], XCert: Encryption requirements
resulting from proposed
authorization model
[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
- Christian Geuer-Pollmann [slides], Uni-Siegen: Comparison/analysis of encryption and authorization.
[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.
10.30 - 10.45 break
10.45 - 12.50 Requirements (scribe: Marc Briceno)
Applications, Parsers, References, and Protocol -- or lack thereof!
- Steve Wiley, MyProof: Requirements with respect to deployed
parsers, target document fragments, nested encryption, etc.
Requirements with respect to deployed parsers, target document fragments, nested encryptions.
- One of biggest issues:
- Legacy applications. Little latitude to replace original documents.
Requirements
- needs to be able to use detached docs
- needs to be able to use XPath as reference
- Access control issues may not be avoidable.
- How to implement signed receipts for anonymous donations?
Would like to see clear processing rules for encrypting and decrypting.
- We will use nested encryption. Absent good processing rules, the document structure can easily be destroyed.
- If an element and its children are already encrypted, the processing rules should warn the user that she is not getting access to all the data.
Problems due to the use of detached documents
- How to deal with lists of decryption info? After decryption, do you strip the decryption info from the document?
- Level of granularity: so far only have to encrypt seed data for elements, element attributes, and the elements themselves.
[Discussion] Joe Lapp: seemed to have an idea distinguishing between a person to person encryption, versus a complex multiparty system.
- Eric Cohen, PriceWaterHouseCoopers [slides]: XBRL
requirements and lots of questions (process and technical).
XBRL and Encryption
- XBRL is the Extensible Business Reporting Language. It is an XML-based language to represent financial and business reporting information by American Organization of CPA’s and accounting profession around the world.
- Allows the sharing of all information in the business and financial process. Trading partners, accountants, regulators.
- Deliverables: technical specifications. Currently has representation of financial information according to generally accepted accounting practices (GAAP).
- Objective: Speeding up the information pipeline
Underlying technology
- XML-based Instance Document
- XML-based Taxonomy Document
- Not traditional, hierarchical DTD-based instance document. Not element-based, but attribute-based.
Question: Eric (W3C) What’s the relationship between the nested groups
- Nested element
- Parent element
- Group can also be used for tuples in which multiple sets can be grouped together
Question: Eric (W3C) Relationship between data types and XSD
- Made a decision long ago to extend XSD. Will provide more information later.
- Needed child-parent relationship, not child-parent relationship.
Encryption Scenario
- How can public schema customer taxonomy extensions be kept private?
- How to limit general ledger granularity to authorized managers?
Encryption Questions
- How can namespaces be used to control access?
- How can information access limited by levels?
- How do deal with real-time feeds?
- How to deal with patents?
- Do we mandate cipher suites?
- What assumptions do we need to make about processing speed and data size?
- Time/date authentication?
- Encryption and decryption using XSL and other XML-standard tools only?
- Do we need to lock access to attributes as well?
- Thane Plambeck, Verisign [slides]: Verisign requirements for
XML Encryption
Primary applications
- Authentication and Validation
- Payment Services
- Focus of examples will be on payment services real life examples.
Make it easier to build PKI-reliant apps.
Traditional inhibitors
- Complexity inherent to PKI
- Patents, licensing
- Need for special PKI toolkits to perform PKIX logic.
- ASN.1 encoding complexity
How XML helps
- Move away from ASN.1
- Move towards clients with XML runtimes and base crypto only (no ASN.1, no PKIX logic).
- Delegation of trust processing to server-side components.
Goal
- Enable one schema XML for unified payment processing. Already uses "XML Pay" implementation.
XML Pay
- In pilot (Ariba, Amex, others)
- Multiple payment types and payment processors.
- XML-Dsig compatible
- Password-based authorization also possible.
- Between merchant and payment processor, with VeriSign in-between.
Where to add encryption
- Content-only model for encryption is very attractive.
- First choice: encryption of element content (but not element name and attribute).
- Element wise encryption adds complexity.
- Granularity
- Must be down to element level
- Limiting to entire elements would be OK.
- Extending to element content is very attractive.
- Found no requirement for selective attribute 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.
- Mike Wray, Hewlett-Packard [slides]: XML and end-to-end security
.
We need to ensure that similar things encrypted under the same key don't look alike
Questions.
- Reagle: should the standard state to not rely on unauthenticated data? Wray: yes, users should be warned that unauthenticated data cannot be trusted
- Reagle: do you want mandatory algorithm support? Wray: prefers standard, but can work with optional key info.
- Solo: is this an XML Encryption mechanism or payload? Wray: TBD. Dsig support this functionality.
- Barb Fox, Microsoft [sides]: Fire-and-forget encryption.
Requirements
- Need encryption and signature to do anything interesting.
- Should be syntactically aligned with Dsig.
- Must use exclusively XML tools.
- Encryption work retroactively impacts Dsig.
Temptation
- Lose Focus
- Do not build new protocol. Do not define expected recipient behavior.
- Do not get lost in edge cases: multi-party, sub-tree encryption.
- Key management/Trust Management
- Authorization schemes
Q Dave Solo: why is multi-party an edge case?A: need to support multiple recipients, but not pass through workflow.
Proposal
- Restrict an encrypted message to one KeyInfo per recipient.
- Narrow scope of this to WG to "encrypt this node and all its children".
- Punt additional work to Technical Notes and follow-on working groups.
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
- KeyInfo
- Conceptual extension to Dsig KeyInfo
- Dsig syntax alignment
- Algorithms, modes, format
- AES
- Basis set RSA, AES, SHA-1 [remember to mention need for SHA-2, ed.]
- Implementation impact
New requirements
- Transform "Decrypt under Signature" for signed and encrypted documents.
- Impose processing order.
- Partially encrypted subtree
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
- Lots of hard problems
- Basic building block for protocols
- Let’s limit scope
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.
- Owen Roberts, Baltimore [slides]
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.
12.50 - 2.00 lunch
2.00 - 3.30 Proposals (scribe: Joe Latone)
- Ed Simon [slides, (GIF version)]: XML Encryption Syntax and Processing and XmlEncryptor - An XML Encryption Demonstrator: "Presenting an overview on the XML Encryption spec that focuses on encrypting various content. Will also report on techniques for coding XML Encryption in various scenarios (eg. encrypting element, element content, attribute values in DOM and XSLT frameworks)."
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
- Hiroshi Maruyama [slides(pdf)]: Specification of Element-wise XML Encryption and Note on XML Encryption
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.
3.30 - 3.45 break
3.45 - 5:30 Content IV (scribe: Shivaram Mysore)
Speaker - Joseph Reagle, W3C
Scribe - Shivaram Mysore, Sun Microsystems, Inc
Summary of W3C Process
- Informal Meetings
- Workshop
- Birds Of Feather (BOF) Sessions
- Proposal, Beta Requirements
- Call for Participation
- Others
W3C WG "Officers"
- (Team: someone who works for the W3C)
- Chair: responsible for generating consensus over deliverables in a timely manner
- Staff Contact: represents director/team, interface to Tech Report Process
- Editor: ultimately responsible for regular publication of document and tracking changes
- Author: responsible for section of a document and assuring closure of issues raised for that section
Potential Deliverables
- Requirements Document
- EncryptionData and Processing
- DecryptionInfo
- Algorithms
- ?Encryption/Signature Scenarios
- ?Data Model
- ?Canonicalization
- ?A signature transform.
Questions
- How long before the WG starts, and how long would it last? Reagle: ~2-3 months from November is when the WG would officially begin. starts. Then it takes around 6-8 months to complete the Working Draft. Then there is a last call for participation which takes about 2-4 months. Next Working Group Meeting around February 2001 if the WG is approved.
- Schaad: When would teleconferences start? Reagle: The W3C does use teleconferences in order to move quickly on its work, but this won't start until the WG is officially chartered.
- [Later in the day] Geuer-Pollmann: will the WG be open like xmldsig? Reagle: Yes.
Straw Polls on Requirements Document:
- Reagle: on this note of granularity (how specific do we want to be in encrypting
portions of a document): who wants to preclude attribute encryption versus those who want
to encrypt attribute values
11 votes (preclude) / 13 votes (encrypt attributes)
Ok, there's no consensus to make a change from present proposals; needs further discussion.
- Ed Simon: Encrypt Node list within element?
Majority opted for encrypting everything between Start and End Tags
- Reagle: Should we enable others to preserve the validity of the document.
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.
- Reagle: While we wish to not change present parsers (Simon: this was not necessary in my
case) we acknowledge we may have to tweak when necessary.
No objection.
- Reagle: We use URIs for algorithm and namespace Identifiers.
No objection.
- Reagle: Which algorithms should we require for mandatory interop?
[Discussion] ACTION Schaad: send a profile of candidate algorithms (including padding) with recommendations to the list.
- Schaad: do we worry about compression algorithms?
[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.
- Should we invent our own (a compact binary form) or use Canonical XML.
[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.
- Licensing fees: do we want an unencumbered/free license with respect to any claims on
the specification?
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.
- Clark: XPath can cause serious performance be hit: should we consider performance in
implementation specifically with XPath and buffering; Where URI or XPath could be used
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.
- Should an encrypted element in an unencrypted from be Augmented? - Mandatory Canonicalization solves this problem.
Joseph Reagle <reagle@w3.org> Last updated: 19th September 2000.