W3C logo, link to home page

Minutes W3C XML-Encryption Workshop

San Francisco, CA
2 November 2000


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:

  1. Barb Fox: proposals and scenarios for CBC mode and the need for sequence numbers, and for threshold encryption schemes. Due 11/27/00.
  2. Dave Solo: Scenarios for using XML Encryption with XML Encryption (signed/encrypt, encrypt/sign, etc.)
  3. 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).
  4. Joseph Reagle: Check with Patent Working Group and look into Protocols Charter (Eric, W3C) about issues on Intellectual Property and Licensing Fees.
  5. Joseph Reagle: Propose text on validation.
  6. Joseph Reagle: Update requirements document.
  7. Joseph Reagle: Move charter forward.


9.00 - 9.35: Introduction

  1. Group, Introductions Around the Room
  2. Joseph Reagle, Agenda
    1. Thanks to XCert for hosting
    2. Volunteers for Minute taking
  3. Group, Agenda Bashing

9.50 - 10.30: Encryption, Authentication, and Authorization (scribe: Eric Prud'hommeaux)

  1. 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

  2. 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)

  1. 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.

    1. One of biggest issues:
    2. Legacy applications. Little latitude to replace original documents.


    1. needs to be able to use detached docs
    2. needs to be able to use XPath as reference
    3. Access control issues may not be avoidable.
    4. How to implement signed receipts for anonymous donations?

    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.

  2. Eric Cohen, PriceWaterHouseCoopers [slides]: XBRL requirements and lots of questions (process and technical).

    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

  3. Thane Plambeck, Verisign [slides]: Verisign requirements for XML Encryption

    Primary applications

    Make it easier to build PKI-reliant apps.

    Traditional inhibitors

    How XML helps


    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.

  4. 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


    1. Reagle: should the standard state to not rely on unauthenticated data? Wray: yes, users should be warned that unauthenticated data cannot be trusted
    2. Reagle: do you want mandatory algorithm support? Wray: prefers standard, but can work with optional key info.
    3. Solo: is this an XML Encryption mechanism or payload? Wray: TBD. Dsig support this functionality.
  5. Barb Fox, Microsoft [sides]: Fire-and-forget encryption.



    Q Dave Solo: why is multi-party an edge case?A: need to support multiple recipients, but not pass through workflow.


    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.


    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.

  6. 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)

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.

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

W3C WG "Officers"

  1. (Team: someone who works for the W3C)
  2. Chair: responsible for generating consensus over deliverables in a timely manner
  3. Staff Contact: represents director/team, interface to Tech Report Process
  4. Editor: ultimately responsible for regular publication of document and tracking changes
  5. Author: responsible for section of a document and assuring closure of issues raised for that section

Potential Deliverables

  1. Requirements Document
  2. EncryptionData and Processing
  3. DecryptionInfo
  4. Algorithms
  5. ?Encryption/Signature Scenarios
  6. ?Data Model
  7. ?Canonicalization
  8. ?A signature transform.


Straw Polls on Requirements Document:

  1. 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.

  2. Ed Simon: Encrypt Node list within element?

    Majority opted for encrypting everything between Start and End Tags

  3. 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.

  4. 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.

  5. Reagle: We use URIs for algorithm and namespace Identifiers.

    No objection.

  6. 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.

  7. 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.

  8. 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. 

  9. 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.

  10. 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.

  11. 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.