XML Encryption BoF at Crypto 2000

2000-08-24

Interim Acting Chair: Barb Fox

Reason for starting XML Encryption WG

Now that the XML signature work (XMLDsig) is mostly complete, the time has come to look at XML encryption.

Encryption is the second building block for security protocols.

Initial Agenda

Market Requirements

Encryption with XML-only tools

Lightweight, message-based protocols for XML-based apps

Technical Requirements

KeyInfo

Conceptual extension to Dsig KeyInfo

How and what cleartext info is communicate as part of the encrypted message for recipient-related information.

State Management in Support of Key Management Issues

Example: Message chaining

Dsig syntax alignment

Algorithms, modes, and formats

AES savvy

Basic Set: DSA, 3DES, SHA1, DSA?

Regulatory Considerations: strong crypto. We will go for strongest crypto.

Namespace context

Ensure that XML namespace context is preserved. Big issue.

Implementation issues

Parser Input

Decryption of an element may expose a subtree

Efficient parsing may require a call-back mechanism to prevent needing to re-parse the entire tree.

Schema addition

Schema “INCLUDE”: decrypted elements may reference different schema than their parents

Discussion

We may need to have two schemas for validation: before decryption and after encryption. Application may not want to have to decrypt to validate encrypted blob.

Which working groups and specs will this effort depend on?

 

Joseph Reagle

How to start a WG at the W3C:

BoF, create Note (straw man proposal) call for participation in October.

Noticed the following issues:

 

1. Can we write one schema that permits portions to be encrypted, or must we

write as many schema as possible varied encrypted instances, or must the XML

instance be well-formed only?

2. Signed and Encrypting: Sign then Encrypt. (Is the Encryption subject

signed as well: Sign/Encrypt/Sign?)

3. Which way does the reference between the KeyInfo and the EncryptedContent

point?

4. Philosophical/Design Issue: we should not have any expectation that we

will be able to tell people how to write their schema with respect to

Encryption.

5. Canonicalization?: How heavy need it be? Must we worry about namespace

context? A binary canonical form has the potential of being efficient, need

it be XML? Compression?

 

Brian LaMachia

XMLDsig recap

Last call for comments on Dsig due right now on Dsig list. http://www.w3c.org/signature

Currently white space is significant. One can write a transform to strip out the white space before signing.

XML Encryption Syntax and Processing

Straw man proposal available at http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/att-0001/01-xmlencoverview.html

Simple Example

<EncryptedNode>

base64 stuff representing a node in an XML tree

</EncryptedNode>

<KeyInfo>

<RecipientInfo>

blob of signed data

</KeyInfo>

Open questions

 

Should there be a pointer from the Encrypted Key Information (EKI) to the Encrypted Nodes (EN)? What about traffic analysis issues? There seems to be disagreement. This appears to be a good issue for the WG to address.

For some video applications, one may need to have an IV per blob. Especially for applications that need frequent resynch. Not a problem for most video applications. They can live with losing a few frames.

However, blobs may need to get decrypted out of order. Some applications will need an IV per blob. Still, most applications will not require this.

Node encryption (Ed Simon, Entrust)

Some users may need to access some elements, but not others. Suggestion: allow for encryption of just the contents of the element, not the name of the element

Example: hospital records

<root>

<patient>

<name>

<address>

<diagnosis>

</patient>

Much discussion ensued. (I am confused why one can’t just apply one level of indirection by creating an additional tag describing the content outside the encrypted blob)? We need to debate this more in the upcoming WG.

Potential suggestion: insert <name><EncryptedNode type=element>….

Element-wise XML Encryption (Takeshi Imamura, IBM Research)

Motivators

Intermediary may need to access non-sensitive contents of a document

When non-sensitive contents need to be modified for specific purposes

Access control policy requires certain parts of a document are readable only be privileged users.

Requirement

Element-wise (node-wise?) confidentiality

Well-formed encrypted document

Information set preservation

Independence from encryption algorithm

Flexible key delivery mechanism

Independence from outer context for decryption

Can be validated by receiver

Can be validated by intermediary [does this imply that a signature is applied outside the encryption envelope, ed]

Confidentiality of content model

Compression [why is this the job of the encryption processing? Aren’t there any compression transforms available, ed]?

Provided various examples

Wants to separate non-encrypted payloads <body>  from encrypted payloads <head>.

Granularity should be at element, attribute, text, comment, etc.

Integration with XML Signature
Canonicalization

Entity references should be expanded before encryption operation

Known plaintext attacks

E.g. if DTD is given, attackers can know an element to be encrypted starts with a particular tag name. Good reason to not use stream ciphers.

Usual issue that we can’t compress after encryption

Should we define “ciphers” that both compress and encrypt or should we recommend that a compression function be applied prior to encryption?

 

Who wants to be Chair?

Brian and Barb are interim co-chairs.

Action Items