- From: Marc Briceno <mbriceno@xcert.com>
- Date: Mon, 11 Sep 2000 16:56:41 -0700
- To: xml-encryption@w3.org
- Message-id: <LOBBKNOMMAABENGJIOFGCEKOEKAA.mbriceno@xcert.com>
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)
Attachments
- text/html attachment: XML_Encryption_BoF.htm
Received on Monday, 11 September 2000 20:11:52 UTC