XML Encryption WG Issues

Joseph Reagle Jr. <reagle@w3.org>

This page links to comments/issues raised on the list during Last Call (October 18 - November 9), and subsequent stages, and their resolution for the Requirements Document, Syntax and Processing, and Decryption Transform for XML Signature. A style sheet declaration is used to not render issues that are considered 'done'. The source of an issue need not be its first instance, it also might reference a cogent description or WG poll. Also, this document may not capture editorial tweaks and errors that were easily and quickly remedied.

Resolutions are expressed as {email,minutes} » (resulting) draft

Issues Raised During Last Call

Source Isssue Resolution

Blake Dournaee

Is the Nonce attribute of type intenger? Reagle: Yes

Christian Geuer-Pollmann

Encrypting IV in ECB Reagle: not comfortable creating our own modes, has this variance been specified elsewhere? Reagle: no consensus to include in core, may be specified externally.
Ed Simon Should the CarriedKeyName attribute really be a child element? ACTION Reagle: change to a child element, cc: Merlin/Takeshi to see if they oppose. » Revision: 1.77
Should we add a warning into section "3.1 EncryptedType" that it is not allowed (or could cause problems) if an EncryptedData element becomes the DocumentElement of a new Document with @Type="ElementContent" ? ACTION Geuer-Pollman: add warning text on this point if it doesn't already exist, "decrypted content may not be well-formed XML." » Added to 4.15.1
Herzberg's comments on Decryption Transform Requests a decrypt:Remove which indicates the identified element should not be part of the Signature. Reagle:I believe this funcationality is addressed directly by xmldsig. » Herzberg: Agrees

Takeshi Imamu

Should a nonce be associated with an EncryptedKey? Reagle: remove Nonce attribute from Encrypted Key.

Ronald Rivest

Does this support "new combined "encryption+integrity" modes of operation Rivest (off list): "Don't worry about "massively redundant data"; a good cipher will encrypt a file containing nothing but zero bits so that you can't tell it from the encryption of a (same-length) file containing nothing but one bits."

: Yes, one can specify the approriate algorithm and identifier.

You have provisions for referring to some elements indirectly (e.g. through a URI), but you may need some way to ensure that what you retrieve is what was intended (e.g. through a hash of the element to be retrieved). Perhaps this is implicitly handled already..." Simon: Protecting the integrity of retrieved ciphertext
There are of modes of encryption that won't fit your model, but which are very useful. For example, "secret-sharing" allows encryption of a document into several pieces, or shares, in such a way that a requisite number of them are required to decrypt/reconstruct the document. Just be sure you don't preclude somehow expansion to handle this sort of thing later on. Dillaway: explored scenario demonstrating nothing prohibits such usage with xenc.
I'm very uncomfortable with allowing the encryption algorithm to be "understood" between the sender and the recipient; you should force the sender to be explicit. Non-explicitness is the cause of very many protocol failures. Reagle: tweaked text, "If the element is absent, the encryption algorithm /+must be known by the recipient or the decryption will fail.+/"

Blake Dournaee

Is Canonical XML really a recommended serialization algorithm; when exactly must one use it? ACTION Eastlake: tweak the c14n in section 5, include exclusive canonicalization as an algorithm » Algorithms Section update

Yongge Wang

Is it possible to change the order of the input to KM so that it will look like: Reagle: no objection » Eastlake: "Reordering of the concatenation feed to the specified Digest Algorithm"

Jiandong Guo

Nonce and Key Wrap Algorithm: "It seems to me that with the key wrap algorithm specified in section 5.6.2, there is no way a nonce can be used, although you may still set up one in the corresponding CipherData element by the document." Eastlake: A nonce is only useful if there is insufficient entropy in the data being encrypted and there is no other way to conduct a dictionary attack by trying the few possible values. The nonce means that you can't just encrypt each possible value and see if you get the cipher text. If your key has insufficient entropy, a nonce won't help. Someone can try decrypting with the few possible key values and test for plain text. The description could be changed to allow a nonce. But I don't actually see any need. Reagle: this is subsequently superceded by the decision to remove nonce.

Christian Geuer-Pollmann

I want it fixed that 168 bit keys are transported in 192 bit form, that's all. Clarify » Algorithms Section update

Blake Dournaee

<AgreementMethod> question. "it doesn't look like XML Encryption actually specifies the logistics to perform the key agreement without also specifying actual encrypted data, which is impossible because the shared key hasn't been generated " Eastlake: I see the AgreementMethod inside KeyInfo to be for cases where, for example, you have retrieved a DH Key for the recipient via XKMS or from some Certificate cache. Since you know your own key, presumably you can calculate an agreed key and use it. » Eastlake: clarifying text.
Susan Lesch Editorial Comments » Revision 1.80

» 20011206.html

Martin Duerst Are our MIME type URIs supported by IANA? Reagle: www.isi.edu is a bit odd, but it's the best we have IMHO and IANA refers to it.
Martin Duerst There should be a requirement that says that encryption should work (in the sense that you get the original stuff back after decription) under Infoset-preserving transformations of the XML that contains the encrypted pieces. [This makes sure that when encrypting XML, it has to be in a defined encoding (as it currently is).] Reagle uses Dürst's text
There needs to be a requirement to use NFC when converting from a legacy encoding to UTF-8 when encrypting. This should be very much the same as in XML Signature, Section 6.5, last two paragraphs. There should also be something like the last paragraph before section 7.1 Reagle: Agreed » Dürst
In section 4.2 Decryption, in step 4.3, the wording 'replace' ... 'by the UTF-8 encoded characters' may easily be misunderstood. After decryption, there will be a byte stream with characters encoded in UTF-8, but the replacement operation has to make sure that the appropriate character encoding conversion (transcoding) is applied. As an example, if the decrypted element or element content is inserted into a DOM, there has to be a conversion from UTF-8 to UTF-16. This should be made clear. Reagle: Agreed » Dürst
There needs to be some text about security risks associated with UTF-8. Assume that somebody knows that the encrypted text is Old Italic. In this case, UTF-8 uses four bytes per characters, and three of them are always the same, and the top two (or three if there are no numbers) bits of the last byte are also always the same. There is probably some chance that this will make it easier to break the encryption. This should clearly be mentioned in the Security section, with maybe an advice that compression can help (but then it has to be possible to apply compression before encryption, might be good to have an example of this). I'm not an expert to assess the exact extent of this risk, so please use your expertize in this field. There are other, somewhat less extreme examples than old Italic, but the the point is the same. Rivest (off list): "Don't worry about "massively redundant data"; a good cipher will encrypt a file containing nothing but zero bits so that you can't tell it from the encryption of a (same-length) file containing nothing but one bits."
URI -> anyURI/IRI: According to the Character Model, you have to make sure that wherever you use URIs, non-ASCII characters are allowed, and that conversion to ASCII only is done as late as possible. You already have this right in the Schema, by using anyURI, but you should make it clear in the text. Reagle: Agreed » Dürst
In 2.2.1, 'media type URI' is mentioned, but there is neither an explanation nor a reference. In addition, it would be good to check/explain that this can include parameters (such as charset). Reagle: reverted back to xmldsig style attributes.
2.1.5 forbids the encription of only part of EncryptedData or EncryptedKey. I don't see any particular reason for forbidding this, except to make some XML Schema issues easier. But I think it would be extremely valuable for the WG and the spec to do this exercise and to show how the Schema has to be changed to allow this. This is important because allowing encryption in places where it's not provided in some existing schema is something that applications using the spec will have to do a lot, and it's a good thing to work out (some of the) details. Even if this is not changed for EncryptedData or EncryptedKey, there should be an extended discussion of how to change a schema to work with encryption. Reagle: ...Though trying to design a schema such that its instance is *arbitrarily* encryptable while remaining schema valid is an exercise in complexity and some futility... Regardless, we made this decision because we had no good reason to make the application processing any more complex than we had to.
XP:David Orchard A scenarios document would be useful. Reagle: Agreed. In response to comment I created a list in August and proposed a scenario but not other contributions. Consquently, this is an optional deliverable and not critical path. Also, use cases have been exchanged on the list and substantive technical discussion has followed. Also, use cases have been discussed.
David Orchard "There is a clear case where the contents are not valid according to the content-type or the namespace names of the document, and it seems reasonable that XMLE should proscribe what should happen in that case." and suggests, "In that case, the root element would be XMLE and the content-type would be application/xenc+xml" Reagle: Requested counter-direction from TimBL or TAG as this is contrary to my understanding, has many unresolved questions, and is not the action item I accepted.
Christian Geuer-Pollmann & Takeshi Imamura what does the xenc:EncryptedKey/@Type attribute tell me? ( Reagle: This relates to the question of what one should expect when one decrypts the key, always the literal value or sometimes an XML structure as well? How should one encrypt ds:KeyValue?) Imamura: "prohibit encrypting an XML structure containing a key, not to prohibit encoding a key in XML and then encrypting it as binary". Also agrees to Type being used as further specifier of Key format.
Christian Geuer-Pollmann Can we encrypt a parts of a text node? Earlier discussion we said it was not a requirement, but the present spec permits it. Reagle: We didn't want to go out of our way to enable someone to parts of element content. But as you note, we didn't have to do anything special to enable it -- follows naturally from our spec and XML1.0 -- and some might find it useful. So unless we find and instance where this someone does have a pragmatic problem with it, I don't think we should complicate the spec in order to prohibit.
Dan Lunz and Christian Geuer-Pollman (1) No need for nonce and IV Reagle: nonce removed.
SAML:Joe Pato "SAML determined that given the number of participants in the TC who were directly working with the W3C on developing XML ENC, it is not necessary for the TC to provide independent feedback to the W3C."
Schema:Michael Sperberg-McQueen "I am aware that late comments are less convenient to deal with, and I regret our inability to get a full review done for you now. But since we haven't, I think it would be unrealistic to ask you to delay the progression of the document any further on our account."
Jiandong Guo Inconsistency with RFC 2631 and PKCS3. Eastlake: editorial tweak.
Christian Geuer-Pollmann "I want to use #kw-aes256 for wrapping an RSA private key, and the AES 256 bit key should be derived from a user-supplied pass phrase..." Reagle: no consensus to include in core, may be specified externally.
Joseph Reagle Support for xml:lang and xml:space (xml:base?) in EncryptedType? Reagle: only agreement to add to EncryptionProperties, but not EncryptedType.

Issues Raised in Candidate REC

Source Isssue Resolution
Merlin Hughes Decryption Transform: should it be able to decrypt binary data? WG Agreed » Takeshi's text. Reagle: afraid to change algorithm identifier since it might break existing namespaces.
Jiandong Guo The mgf1p text and identifier is confusing. Reagle: Should we change the text or URI? Text agreed to » Eastlake text. Reagle: given an objection to changing the identifier, we won't change it.
Takeshi Imamura Typos in the schema lead to ambigous content. Reagle: fixed. (No change to NS since correction doesn't invalidate previous instances.)
Merlin Hughes Where does the requirement for NFC come from? For consistency with xmldsig, can't we say that input must already be in NFC? Reagle: agreed.
Joseph Reagle Proposes a conformance section. No dissent.
Joseph Reagle Decryption Transform: this references a member only email by Tobin. Hughes and Imamura propose appendix.
Aleksey Sanin Why is EncryptionMethod optional in xenc, but required in dsig? Should be requied in xenc too. Reagle: agree it is inconsistent, but no harm done and no consensus to change.
Jiandong Guo Should we permit optional syntax with a default semantic? (defalut algorithms for key agreement?) Reagle: I oppose this, as it is counter to the conventions of xmldsig and xenc.
Blair Dillaway Schema: ambigous content. Reagle: fixed.
Aleksey Sanin The block enryption padding is different than that specified in RFC1423. Reagle: inconvenient, but there are reasons, and we have interop on the present text.
Aleksey Sanin How do you prevent a denial of service attack whereby someone creates an instance which arbitrarily recurses? Reagle: added security consideration.

Should the two hash algorithms used within RSA-OAEP be able to be specified independently? Eastlake/Reagle: "What we have does work, and it might not be the best format for future parameters but that bridge can be crossed when encountered. (A new identifier/namespace and all the parameters desired can be proposed.)" Gindin dissents.
Reagle What to do with the two AES dependencies which are IETF drafts? (We in-line the text we are concerned with, is that good enough?) Eastlake: should be good enough. » Reagle: added tweaks to make this clear.
Ari Kermaier Decryption transform: questions about the processing rules and the example in Appendix A. Imamura: clarifies. Kermaier still has question. A number of questions/proposals about the decrption transform prompt a rewrite of that specification and a subsequent 2nd CR.

Issues Raised in Second Candidate REC

Source Isssue Resolution
Takeshi/Hughes/Reagle Is the matter of OPTIONAL full XPointers in <Except URI="..."/> one of the xmldsig profile or interop? Reagle: [Agrees with Merlin.] The implementation requirement is to ensure the text is well written and to show some evidence of support for the feature. I can't forsee any interop problems arising from this (we're just borrowing from xmldsig) and the fact that there were enough (optional) full XPointers implementations in xmldsig is more relevant to whether we include them here than whether we get more implementations in the XENC WG.
Ari Kermaier Inconsistent exposition of when xmlns="" should be emmitted. Merlin: provides clarification and new text.. Reagle: incorporates into spec, everyone is happy.

Joseph Reagle <reagle@w3.org

Last $Revision: 1.46 $ by $Author: reagle $ on $Date: 2002/04/30 16:06:04 $ GMT