I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Section 2.2: UTF-32 has four potential serializations, of which only two (UTF-32BE and UTF-32LE) are given names in in [UNICODE]. Support for the various serializations varies widely, and security concerns about their use have been raised. - It would be good to have a reference for the security concerns, or perhaps a little more discussion. Section 3 Other MIME agents will not be XML-aware, and thus cannot know anything about the XML encoding declaration. Not only do they lack one of the three sources of information about encoding, they are also less likely to be aware of or responsive to this spec. - it may be useful to discuss how an XML-unware MIME agent will handle the XML documents. e.g. do they usually pass the document through unaltered? Do they mangle the document, changing it's meaning? Are there recommendations for what they should do? Some MIME agents, such as proxies and transcoders, both consume and produce MIME entities. - it may be use to have recommendations for what MIME agents should do (or not) when they want to proxy XML messages, without examining them. Section 10 Security considerations will vary by domain of use. For example, XML medical records will have much more stringent privacy and security considerations than XML library metadata. Similarly, use of XML as a parameter marshalling syntax necessitates a case by case security review. - it would be good to make recommendations here. e.g. standards for XML medical records SHOULD have limitations on which external XML libraries can be used. A few paragraphs earlier, this section has the following text: Thus, the security of any XML document is vitally dependent on all of the documents recursively referenced by that document. - the only way to ensure security of XML records is to control which documents they reference. This doesn't matter much for some situations, where the possible attacks are minor. It can matter enormously for more critical situations, like medical records. XML may also have some of the same security concerns as plain text. Like plain text, XML can contain escape sequences that, when displayed, have the potential to change the display processor environment in ways that adversely affect subsequent operations. Possible effects include, but are not limited to, locking the keyboard, changing display parameters so subsequent displayed text is unreadable, or even changing display parameters to deliberately obscure or distort subsequent displayed material so that its meaning is lost or altered. Display processors SHOULD either filter such material from displayed text or else make sure to reset all important settings after a given display operation is complete. - I would suggest changing the SHOULD to a MUST. The display processor MUST by default filter such material, or be sure to reset all settings. The filter MAY be administratively controlled. i.e. the user can turn it off. As such, the ability to program keys SHOULD be blocked either by filtering or by disabling the ability to program keys entirely. - the same comment as above applies here However, even non- recursive expansions may cause problems with the finite computing resources of computers, if they are performed many times. For example, consider the case where XML-entity A consists of 100 copies of XML-entity B, which in turn consists of 100 copies of XML-entity C, and so on. - it would be good to make specific recommendations here. e.g. XML processors SHOULD administratively limit the number of XML entities they will process from one document. This limitation SHOULD be configurable. Where possible, the XML processors may also prompt the end user when this limit is reached, to see if they should continue processing the document.