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.
Encryption with XML-only tools
Lightweight, message-based protocols for XML-based apps
Conceptual extension to Dsig KeyInfo
How and what cleartext info is communicate as part of the encrypted message for recipient-related information.
Example: Message chaining
AES savvy
Basic Set: DSA, 3DES, SHA1, DSA?
Regulatory Considerations: strong crypto. We will go for strongest crypto.
Ensure that XML namespace context is preserved. Big issue.
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 “INCLUDE”: decrypted elements may reference different schema than their parents
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?
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?
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.
Straw man proposal available at http://lists.w3.org/Archives/Public/xml-encryption/2000Aug/att-0001/01-xmlencoverview.html
<EncryptedNode>
base64 stuff representing a node in an XML tree
</EncryptedNode>
<KeyInfo>
<RecipientInfo>
blob of signed data
</KeyInfo>
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.
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>….
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.
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.
Entity references should be expanded before encryption operation
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.
Should we define “ciphers” that both compress and encrypt or should we recommend that a compression function be applied prior to encryption?
Brian and Barb are interim co-chairs.