Reagle: presents Introduction
Reagle: presents a number of quick/easy issues for consideration:
Resolution: Only base64 encoding is required (not hex). [Reagle]
Resolution: If anyone is an advocate of specifying encryption with a corresponding integrity algorithm, please write up a proposal - the workgroup is amenable to it, but it is not required. Commentary: (Later in the meeting we decided to make an authentication code a requirement as part of the encryption algorithm definitions, along with incorporating the IV definition). The action item to write the first draft of this section was taken by Don Eastlake. The goal of including an authentication code with the encryption is to ensure the integrity of the encryption and decryption process. This is especially relevant for symmetric key encryption. An XML signature over an entire document including encrypted elements might not be appropriate. An example is encrypting the payload of a transaction an ensuring the integrity of the decryption (different content is not substituted for example) - the rest of the protocol may not require the same integrity if delivery is achieved [Cohen].
Resolution: Use consistent terminology in the specification, consistent with InfoSet where suitable. [Reagle]. Use "Element information item" for element and "child" for element content. Commentary: Use of terminology may have implications for processing, having implications of DOM or lighter weight approach, depending on serialization for example so we should be sure of the terminology implications on implementation [Dillaway].
Note: The issue was raised on how to write schemas for post-encrypted instances. As discussed at the workshop and noted in the Requirements, it is generally the responsibility of the application using encryption, but approaches include subclassing schemas [Simon], or automatically generating the post-encryption schema [Reagle].
Resolution: In security considerations, the choice of the URI for encrypted content shouldn't leak information [Reagle]. This is consistent with the view that URIs are supposed to be long term identifiers.
Note: The issue was raised on how to process arbitrary XML fragments [Maruyama]. Synthetic InfoSets may be applicable [Reagle].
Agreement: KeyInfo would be the right place to put additional optional information relative to a key, such as expiration/caching information [Reagle]. Caching might be required for a key [Farrell] but this is security context management, basically out of the scope of this specification [Solo].
Action Item: Review the use of a URI versus an ID and NameKey in an EncryptedKey element [Reagle] Commentary: Assume you have two messages - message 1 followed by message 2. How do you refer to the key for message 1 from message 2 without having to process message 1 again - this is the rationale for an Id. Alternative is to have both URI and URN [Reagle].
Note: If you have an element in a document which is encrypted with two keys, for two recipients, how upon decryption do you ensure that element is only placed into the document once? [Reagle] A similar issue is encrypting different forms of the same content (e.g. audio version, text version) and using a single version in the document upon decryption [Dillaway]. The group assumed that this is application specific.
Note: The processing implementation will need to be different for EncryptedKey versus EncryptedData since there is no Type URI in EncryptedKey. It could be useful if the definitions were more similar, but one may also do the indirection in EncryptedData [Farrell]
Resolution: The encryption algorithm initialization vector (IV) should not be specified as an element within the EncryptionMethod but rather be treated as part of the Algorithm definition, which should specify how the IV is initialized and conveyed as part of the CipherText element. Consensus was that there is no real need for explicit IV chaining support for applications.
Action Item: An associated action item is that the specification needs algorithm definitions in the algorithm section to define how algorithms which require an initialization vector initialize the vector and how they convey it in the CipherText element. AES is one such algorithm.
Action Item: Security considerations section should note IV considerations, if any remain.
Commentary: The alternative of defining the IV explicitly in the EncryptionMethod has issues, including:
The group noted that by removing the IV element this addressed an earlier problem raised regarding the use of hardware cryptographic devices. An alternative to embedding the IV in the CiphertText element is to treat the IV as an attribute [Reagle] but it is more efficient if you do not always need to parse XML [Simon/Dillaway].
Resolution: Do not require the EncryptedKey element to support multiple recipients. (Open Issue #1 in 15-Dec-00 XML Encryption Syntax and Processing Draft) Commentary: Supporting the multiple recipient option is not essential and the following concerns were raised:
This discussion led to the general question of how to know which encrypted data is for you [Solo]. Placing an attribute on the EncryptedKey would address this, with the implementation advantage that this is the 1st element parsed [Dillaway]. There is no maximum length on an attribute in the XML specification [Reagle] so it should be possible to have long attribute values encoding information such as a certificate [Solo]. Implementations should be able to handle long attributes (100s of bytes).
Agreement: Make EncryptedKey a child of KeyInfo Action Item: Address namespace and schema issues raised when making EncryptedKey a child of KeyInfo. [Reagle] Commentary: We might need to revisit this if there are major implementation issues [Farrell], but we will not revisit unless there are major problems [Reagle]. We need to ensure that we do not break the existing Digital Signature implementation [Farrell]. There are ways to do this, for example, schema allows redefinition of namespaces with the caveat that anything valid in the redefined namespace should be valid in the original [Reagle].
XKMS would like EncryptedKey to be in KeyInfo, allowing delegated processing [Hallam-Baker].
The question was raised whether we should attempt to limit recursion with processing rules [Hirsch]. The answer is no, especially since we cannot predict the workflow and the different people who will need to unwrap content [Gilbert]. It is possible to show pathological cases for pointer chasing as well [Dillaway].
The implied semantics of KeyInfo, involving only one key, is consistent with making EncryptedKey a child of KeyInfo [Solo].
Regarding whether the KeyInfo RetrievalMethod will be able to reference into KeyInfo EncryptedKey [Dan], the answer is yes.
(Discussion of these issues not in the slides was in the ealier session.
Currently XML Encryption only encrypts elements or element content.
It does not provide a way to mark that an element's external referenced data as encrypted.
Should we provide a uniform way for an application to know that an element attribute value or referenced external data has been encrypted (2 issues)?
Example: <video src="secret.mpg" alt="Alien spaceship in hanger at Area 51."/>
EncryptedDataManifest proposal: Put in an EncryptedDataManifest attribute which points to element (probably child) with encrypted stuff...
XSLT Transform proposal: transform attributes to elements and then use element encryption. Very flexible (probably permits partial element content encryption). Requires reversal transform. Heavy weight implementation burden. No detailed example proposal exists yet.
What to do?
Reagle: Find the XSLT transform unsatisfying, even if end-points can reverse the transform, that intermediate state won't be useful to network intermediaries.
Dillaway: There are very limited cases where intermediaries could be happy despite missing attributes.
Hallam-Baker: Do you believe you can take pre-existing schema, encrypt, and then send data through unmodified systems? It won't work. Any player can validate XML passing through and it will generally fail after modification.
Simon: Generally you need to make a new schema if you add signatures and/or do encryption. Do we really need attribute value encryption? Price Waterhouse wants it. Others do.
Dave Solo: We don't need it. You can always restructure your data to use elements.
Hallam-Baker: Soap [emerging standard for XML remote procedure call] doesn't use attributes hardly at all.
Eric: Is W3C willing to say elements are the way to go and deprecate attributes?
Reagle No. "Simple XML" has been proposed, which does not have attributes, but we have to live with Elements and Attributes since they are in XML 1.0. At encryption workshop we had a 50-50 split on the question of whether it was worthwhile to be able to encrypt attribute values. Would like to put it in requirements and see what reaction is. Maybe it can be an optional to implement feature. It is nice if XML with parts encrypted is of some use to intermediate systems.
Simon: Shelve this problem, get experience with current element only mechanisms, see if hard demand for attribute value encryption actually develops.
Hirsch: Concerned because attributes are small, typically with values from a from limited set, thus subject to easier cryptographic attack, concerned about making attribute encryption official.
Reagle You can have small elements from a limited value set also. This is a class of problem we have to solve regardless of whether we speak of elements or attributes.
Dillaway: Repeated element names are also a potential cryptographic weakness.
John Messing: Why do people want to encrypt some attribute values instead of an entire element?
Reagle (Gave an example with a person attribute most of which was not sensitive but had a Social Security Number attribute whose value was sensitive.)
Hallam-Baker: Should we be concerned about encrypting the same data multiple times? Cryptographers say just use a strong enough crypto system that this is not a problem.
Resolution: Do not add requirement for attribute encryption for now. Continue in Simon's proposal of continue exploring.
Simon: There are various possibilities for how to handle the attribute and remote data encryption problem. We need more feedback.
Gilbert Palz: Attacks on known element names can be a problem.
Simon: Schema tells you element names anyway if you didn't otherwise know them..
Reagle Weird XML exists. Need strong enough crypto.
Jeremy: What is time impact on the development of the standard of adding attribute encryption?
Simon: It's easy to do. But we shouldn't do unless it is required.
Reagle: Hard to say what the time impact would be.
Richard: We should promote good design. If attribute encryption leads to bad design, we shouldn't support it.
Reagle: XML has attributes and they are not going away.
Dillaway: Attributes are encrypted as part of elements when the element is encrypted. You can solve the SSN example: just make it an element...
Reagle There are legacy things. You need to support them. When we designed DSig, we didn't care that much and used attributes sometimes because DTDs have better attribute value type declarations. Other designers will also be subject to a variety of factors pushing their designs in different directions. We can not assume they will abandon attributes just because Encryption says that would be a good idea.
Simon: I like the transforms idea and hope someone will come up with an example specification of it.
Reagle: We'll see if people will be able to get along without attribute encryption.
Combining signature and encryption. How does recipient figure out how to unwrap this since you can sign/encrypt partial data and in any order. We could (1) say this is an application problem and out of scope, (2) say that when data is encrypted then its signature is also so all signatures you can see can be validated (fails for detached signatures), (3) capture the order of processing (3B) keep XML structure of processing steps but you can't insert this into the XML without breaking signatures (PHB) (3C) create elements like <signThenEncrypt> <exposedSignature> <hiddenSignature>, (6) during signature transform processing do specified decrypt.
[Type in Requirments, 6.1.A should say encryption and signature (not decryption)]
Hiroshi Maruyama: You can have a mixture of signed stuff encrypted before/after signing.
Options considered include:
Solo: Must always have decrypt transform...
Reagle Yes, should be that way.
Maruyama: Closed systems don't need this because they know what to do.
John Messing: I can sign and my signature can be encrypted and later decrypted and verified? Is it the signer or application level which makes these decisions?
Ed Simon: We are not yet talking about encryption of Signature element but encryption of the data signed. Due to use of hashes in DSig, you can sign both the encrypted and unencrypted versions of data.
Maruyama: In XML, there is no clear concept of parsing a node-set. So in our implementation we wrap them in <Dummy></Dummy>. Canonicalization is a good way to serialize, preserves namespaces, produces UTF-8.
Simon/Reagle Canonicalization can serialize node list but for signatures doesn't need to put back in document.
Dillaway: Some will want namespace context embedded in their CipherText, some will not.
Reagle: We need some scenarios.
Maruyama/Dillaway: You need to do decryptions one at a time because they may reveal data where decryption is to be blocked elsewhere.
Solo: This can effect checksum/integrity.
Reagle: Suggest we continue work on Hiroshi proposal as a separate specification.
Solo: Process question: What happens to independent specification if it end up being more or less mandatory?
Reagle: If useful and recommended within the Encryption Standard, that should do it...
Dillaway: Failures to verify signature by those who have not implemented it will quickly lead to adoption.
Solo: I'm concerned about failures due to encountering this undefined Transform...
Reagle: I don't think it will be a problem.
Signature Order: A signature gives some clue to data signed so it should be encrypted (or at least the digest value should) with data.
But there are problems because you don't always know about the Signature.
Dillaway: You need to scan for encrypted stuff within what you are going to sign including EncryptedKey elements.
ACTION: Add scenarios to document.
David: How to deal with protection against modification of ciphertext?
Farrel: Provide limited way to do things. Problem is trying to solve things universally.
Reagle: Someone should make a proposal.
Pilz: We seem to be over-specifying. Parties/applications usually know what's going on and don't need a special feature.
Reagle: They can ignore the feature if they don't' need it.
(Issue of encryption+MAC is resolved later.)
Announcements: Hallam-Baker: There will be a BoF at 6pm after this meeting on XKMS, how to process KeyInfo elements.
Maruyama: Demo of sample XML encryption. A Java implementation. Showed various APIs. Uses a serialization that tries, as much as possible, to preserve the surface string. XML encrypted is wrapped in a Dummy element to preserve the namespace context.
Simon: Do you use the DOM import node function.
Maruyama: Yes.
Reagle What about canonicalization versus serialization.
Simon: Don't need to canonicalize, just serialize.
Reagle: Possible change of context into which ciphertext decrypted argues for preservation of namespace context, etc.
Simon/Eastlake/Reagle: It could be desired either way. Some uses will want to preserve context, some will not.
Maruyama: It is very hard with current parsers to get a pointer to byte where element starting "<" is and specification text says you supposed to start string substitute there.
Dillaway: Light weight readers (SAX) does tell you this information.
Simon: This problem effects any application that changes one element to another, not just en/decryption.
Reagle (find and read text in Infoset specification)
Maruyama: I wrote this to cause decrypted material to be "parsed in context" as much as possible. I can try to rewrite it to be more implementable.
Reagle OK, send me email with the new text.
Dave Solo: What about EncryptedKey elements. If decryption is to restore things, shouldn't they be automatically deleted?
Eastlake: I think they should not be removed by default.
Reagle. I agree.
Solo: Proposal: if you have nested EncryptedKeys they are removed when EncryptedData is processed, otherwise they are retained. Resolution: agreed.
Reagle: Let's review, there is one use of the Transform element in KeyRetrieval and one in CipherText: just so you can transform external data source before decrypting.
Reagle: Transforms not used between the encrypted output and parsing, is this ok?
Resolution: Consensus seems to be yes, we don't need transforms as part of (de/en)cryption data.
Reagle: How then do we specify choices such as canonicalization, compression and such?
Eastlake/Simon: You need to do right thing before encryption, not after decrypt. Examples are handling White space and namespaces.
Dillaway: It makes things to bulk expand name spaces. It should be an encryptor option.
Eastlake: OK
Dillaway: Compression may be a problem
Reagle We could recommend that compressed stuff by wrapped in <compression/> but then how do you indicate you want a literal <compression/> element?
Resolution (Solo): These questions are for the compression working group :).
No need to register new mime type for encrypted non-xml. Type is in the EncryptedData optionally.
Resolution: We are using the Infoset model.
URI and/or ID fragment reference support? DataReference will have fragments with XPointers. Maybe should deprecate fragments and allow transforms?
Reagle Should we require support for XPath/XPointer?
Pilz: Transforms don't seem valuable.
You don't use XPath to specify data to encrypt. You do that by replacing it. But can use it for KeyReference, which points from key to data that is encrypted.
Resolution: Recommend use of URIs with fragments/IDs(barename XPointers) and nothing more complex than that.
No additional Transforms added to specification.
Security (not functionality) of order of signature/encryption: can do either way. Address in Security Considerations section.
Solo: Appellations should default to "sign encapsulating & encrypt" in absence of other considerations.
Eastlake: "In the absence of other considerations, you should sign and then encrypt for better confidentiality."
Algorithms: AES Mandatory?
Resolution: Yes and 3DES mandatory also..
Similarly for AES Key Encryption.
Add algorithm category for Encryption with Checksum. Both AES and 3DES with SHA-1.
Reagle: presents on questions of transform features, Algorithm support, Syntax (element names, schema structures, etc.), and closing logistics.
Area: Algorithms and Structures. Could be another document or incorporated. Need to develop a list of the algorithms.
Jeremy Epstein: has problems with wording that AES is required and triple-DES is optional; concerned with interoperability. Phillip Hallam believes that picking up AES is nominal. Stephen Farrell believes AES is a must. Don Eastlake and David Solo also offered a few thoughts. David thinks that from a toolkit point of view, having both mandatory would be a good idea, with a possible future revision dropping 3DES out.
Resolution: Group decided to make both mandatory.
Regarding IDEA: concerns with patents. No one advocated IDEA, IDEA is removed from requirements.
RSA-v1.5 should be mandatory. RSA-OEAP is retained as mandatory.
ECIES advocates: None. Resolution: drop from requirements.
ECDH advocates: None. (Also, Elliptic Curve technologies may be encumbered.) Resolution: drop from requirements.
Diffie-Hellman is the only, and optional, key agreement algorithm. Any proposal for change? Resolution: status is unchanged.
No oppositions as presently specified, although no one is able to describe AES KeyWrap and saying it is mandatory if this spec comes out before that spec is a challenge. Resolution: qualification of "AES KeyWrap from the NSA is mandatory -- when its completely specified." is retained in Requirements.
We will do some integrity, such as a checksum, combined with the encryption; at least one encryption + checksum category will be included; AES with SHA1 and 3DES with SHA1; see earlier discussion on IV as part of <CipherText>; encryption with an MDC
Should C14N be required to implement but optional to use? David Solo asks if it affects interoperability; if it doesn't affect recipient, we don't need to comment on it at all? Is it an "originator issue"?
Scenario, if we take an element with an entity where that entity is defined as "Alice", encrypt it, and now that entity is defined as being equal to "Bob", which value should the entity reference in the encrypted element take? (Some feel Alice, some feel Bob.)
Ed Simon disagrees with canonicalization for encryption. Dan Guinan: Is it acceptable for two toolkits to generate two different answers?
Reagle: we will differ on this question for now as we await Maruyama's email on processing model. Also, we're fortunate in that if an application wants to do various normalizations (such as namespace declarations in childrens that inherited those Information Set items, it can/should do so.)
No advocates, no change.
Unclear what it means, strike from requirements.
David Solo: Placeholder suggested for Hiroshi's proposed signature/encryption transform; Agreed.
Reagle: need a volunteer to take a first stab at a more complete specification of the algorithm section. Don Eastlake volunteers.
4.3.2 "Should we support encryption of keying material to multiple recipients within a single EncryptedKey element? " Resolution: consider a "hint" attribute at encrypted key level so you know what is meant for you. Dillard volunteers to move this, EncryptedKey, KeyInfo information forward.
Reagle: does requirement 5.1.3 on the plain text attack make sense. Resolution: strike 5.1.3
5.2 no issues
5.3 Integrity - no changes
6.1 Should we define a structure that sits outside an EncryptedData by which you assert "this key was used to encrypt the following Referents. {prop3: open issue 3}. Resolution: no (not now.)
6.2 Don Davis had concern about encrypting with an author attribute, and that attribute implied integrity. Ed Simon; signing hash of plaintext and crypt-result was a solution. Action Reagle: send a Don Davis an email when we have draft requirements and proposal.
No issues.
Reagle: many things called Reference, kind of confusing, let's make a list of what we're talking about and draw a diagram so we understand the directions.
Dillaway:
encrypted data to internal data - Nesting
encrypted data to external data - cipher URI
| From/To | Encrypted Key | Encrypted Data | Internal Data | External Data |
| Encrypted key | KeyReference | DataReference | ||
| Encrypted data | KeyRetrievalMethod | Nesting | cipher URI |
No other substantive items in agenda shown.
Teleconferences: due to international nature (though difficult to accommodate Asia/Pacific regardless) should be mid-day eastern.
Propose: Monday 1-2 EST W3C will offer facilities (should conflict with Tuesdays SAML 12-2 EST)
F2F in 3-4 months June/July. Will announce 8 weeks in advance.