I took the input from Felix and Fredrik and compiled a docx document summarizing the security considerations. It would be good if we could have a look at this today and vote it through or agree changes and vote it through electronically after the meeting.
I need to sync with Robin on the procedural aspects, but like to have the security considerations okayed by the TC ASAP.
Security considerations for XLIFF 2
Apart from security considerations discussed in RFC 7303,
XLIFF 2 has the following detailed security considerations
Extensibility
XLIFF permits extensions. Hence it is possible
that application xliff+xml may describe content that has security
implications beyond those described here.
Direct
external reference mechanisms
An XLIFF document has a number of attributes of the type URI
or IRI, all of which may be dereferenced and some of them should be
dereferenced. Therefore, the security issues of RFC 3987 Section
8 should be considered. In addition, the contents of resources identified
by file: URIs can in some cases be accessed, processed and returned as
results.
Core
<skeleton>
via attribute "href"
There is no requirement that an implementation dereference and
load the skeleton. But it must be assumed that some do. An implementation is
free to provide any type of resource as the skeleton including executables.
<mrk> via attribute "ref" for Term annotations
and probably custom annotations
For term annotations there may be a risk by downloading or
directing the user to access an external resource. For custom annotations the same
applies but an implementation is not required to process the “ref” attribute on
custom annotations but it must be expected that some will. Especially the term
annotation one may be an issue as a reasonable implementation may just launch
the URI expecting a web browser or vier application to handle it.
Resource Data
Module
<res:source> via attribute "href"
<res:target> via attribute "href"
Both of these may reference executable or otherwise unsafe
external data. Either as a resource that need processing or to present
additional information to the user from a resource of arbitrary type.
Essentially the same considerations as for the term annotation in core applies
here especially for reference material. The intent is to present arbitrary
typed data to the user.
Other potentially
security sensitive constructs
Extension by
arbitrary XML on <file>, <group> and <unit>
Allows embedding of arbitrary XML structures at these points.
Extension by custom
attributes on <xliff>, <file>, <group>,
<unit>,<note>,<mrk> and <sm>
Custom attribute extension is likely not as sensitive as
embedding of arbitrary XML structures and will not in itself pose any threat
except potentially for the implementers of the extension.
Format Style Module
Uses HTML element names as values of attribute "fs"
Validating allowed element names may decrease risk, but due to the
attribute “subfs” cannot eliminate it. Attribute “subFs” allows arbitrary additional attributes for
injection into HTML element defined in the "fs" attribute. This could
be used to inject active content such as _javascript_ into the preview HTML
document or reference external resources. Implementations need to take normal
precautions when rendering, as if rendering an arbitrary page on the web unless
it can know for sure it can trust the document. XLIFF itself does not provide a
facility to communicate trust or protect a document from modification. If such
features are needed they must be implemented external the XLIFF format.
Actual consumable HTML is only produced by implementers of this
modules via XSLT or similar.
Privacy, trust and integrity
XLIFF is a format for localization and
translation, privacy, trust and integrity requirements will widely depend on
the type of content that is being exchanged translating end user manuals for a
dishwasher will have lower privacy requirements than translating clinical tests
results for a pharma company.
The XLIFF format does not offer any
internal mechanisms to provide privacy, convey trust or verify the integrity of
XLIFF documents. If such features are needed varies from case to case.
Implementations that will process documents in cases where one or more of these
features are required need to implement that outside of the XLIFF format.
Transport privacy may for example be provided by SSL/TLS. Storage privacy could
be implemented by encrypting the XLIFF content using XML encryption or some
other appropriate means. Likewise the trust and integrity checks could be
implemented using XML signatures or by some other technology that is
appropriate for the particular implementation.