XML Encryption BoF minutes from Crypto 2000

Below are the ad-hoc minutes from the informal BoF at Crypto 2000. I am sure
that the minutes will be far from complete, since it wasn't until quite a
while into the meeting that the informal notes I took to later on jot my
memory turned into the official minutes. :-)

Sorry for the long delay in posting these minutes, I spent a lot of time in
the air over those last two weeks and also had to finish a very large
requirements document. I am leaving for 10 days of vacation now and will be
happy to answer any and all questions about the document upon my return.

HTML of the original Word document is attached.

-- Marc Briceno <mbriceno@xcert.com>
   http://www.xcert.com
   (925) 274-9300 x 122

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-xmlen
coverview.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
·	Encrypt content and then sign it.
·	Sign then encrypt
·	Straightforward
·	PKCS#7 like syntax
·	Include encryption syntax in signature syntax with transform (as defined
in Ed Simon’s proposal).
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
·	Joseph Reagle to start WG charter process with W3C Advisory Committee
(AC). It will take about 3 months for the WG to be approved. Joseph will
write up requirements. Which may turn out to be contradictory.
·	About 10 attendees agreed to actively participate in the WG.
·	Marc Briceno to send these minutes to the mailing list.
·	Marc Briceno to build and edit requirements document. Will send email to
list soliciting proposals.
·	Ed Simon to work on potential syntax document.
·	Joseph will email those on signup sheet list subscription info.
·	Barb Fox to email Marc Briceno existing requirements info.
·	To hold workshop in Boston in October. (This has changed since the
meeting. –Marc)