Hi David,
And now a stab at something for the privacy, trust and integrity point.
“”
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 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 implementation.
“”
I’m not sure how detailed the description of this need to be but the above paragraph, in my opinion, covers the point raised by the reviewer. We state that
it is not provided internally and give examples of how it can be implemented externally without requiring a specific implementation.
Regards,
Fredrik Estreen
From: Dr. David Filip [mailto:]
Sent: den 28 januari 2015 21:45
To: Felix Sasaki
Cc: Dr. David Filip; ; Robin Cover; Jirka Kosek; Yves Savourel; Estreen, Fredrik
Subject: Re: IESG expert review for the registration request "xliff+xml"
Thanks, Felix,
this helps, however
1) we had RFC3023 before but this had to be replaced with 7303
https://tools.ietf.org/html/rfc7303
It obsoletes RFC3023.
WRT dereferencable URI/IR attributes, I guess all of them are.. should not be too complicated to compile a list of those.
2) skeleton and resource data module can embed (or reference, but this would be covered by what you propose..) pretty much arbitrary data, including executable binaries and images.
3) The reviewer requested that possible embedding of executable code is addressed via SSL etc.? I guess if we had a write up how external methods are used to handle embedded executables should adress 2)?
Can someone provide a write up that would cover 2) and 3)? Fredrik? Yves?
Rgds
dF
Dr. David Filip
=======================
OASIS XLIFF TC Secretary, Editor, and Liaison Officer
LRC | CNGL | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
http://www.cngl.ie/profile/?i=452
mailto:
On Wed, Jan 28, 2015 at 1:10 PM, Felix Sasaki <> wrote:
Hi David, all,
below is some input.
Am 28.01.2015 um 14:02 schrieb Dr. David Filip <>:
Hi all,
IESG has reviewed our provisional media type registration and requested below changes/explanations.
Given that we have only 30 days to provide the amended version, we should look into this immediately and pass a resolution in the meeting of 3rd February.
The reviewer had two types of concern
1) encoding considerations, which seems some misunderstanding that I will hopefully address with Robin
2) which seems more serious, security considerations
The reviewer is not happy with our statement that XLIFF has only standard XML security considerations.
We not only have extensibility, as the reviewer suspects but we also have a few standardized ways how to embed or reference executables, so they require a description how to address related risks externally (or internally, be we do not
have any internal methods to address that IMHO and AFAIK).
I would very much appreciate if a TC member or a group of TC members who have experience with
1) media type registrations: Felix?, Jirka?
2) security handling of embedded executables: Fredrik?, Yves?, Jirka?
This is just my best guess who might be the suspects best suited to address this.. Please do not hesitate to take part even if you are not one of the listed suspects!
drafted the security considerations sections before our next meting, pretty much during this week.
Thanks for your attention
dF
Dr. David Filip
=======================
OASIS XLIFF TC Secretary, Editor, and Liaison Officer
LRC | CNGL | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734
http://www.cngl.ie/profile/?i=452
mailto:
---------- Forwarded message ----------
From: Robin Cover <>
Date: Tue, Jan 27, 2015 at 11:06 PM
Subject: IESG expert review for the registration request "xliff+xml"
To: David Filip <>
Cc: Robin Cover <>
Hi David. Please see the communication below (received today) and the 30-day expectation formulated for a response to the IESG reviewer via the ticket system.
They offer to answer questions, if necessary ("If you have any questions, please don't hesitate to contact us.")
============
Dear Robin,
The IESG-designated expert has reviewed this request and returned the inline comments below. Please reply to this message within 30 days of 27 January with a revised version of the security considerations section and a response to the reviewer's
question about encoding considerations.
If you have any questions, please don't hesitate to contact us.
Best regards,
Amanda Baber
IANA Request Specialist
ICANN
> Name : Robin Cover
> Email :
> MIME media type name : Application
> MIME subtype name : Standards Tree -xliff+xml
> Required parameters : N/A
> Optional parameters :
> N/A
> Encoding considerations : 8bit
This implies the XML only uses charsets such as utf-8, and never utf-16. Are
you sure this is what you want? I don't see anything in the specification that
limits things to utf-8, although the examples are all in utf-8. If
utf-16 and similar charsets can be used this needs to change to binary.
Would write here: "Identical to those of "application/xml" as described in IETF RFC 3023, section 3.2, as applied to an XLIFF document."
> Security considerations :
> All of the security considerations described in RFC 7303
This isn't close to adequate. All RFC 7303 is describe the generic security
considerations for XML; you need to document those that are specific to this
type or explain why there aren't any.
I would write here:
„An XLIFF document may cause arbitrary URIs or IRIs to be dereferenced, via the @@@ add here attributes that allow dereferencing @@@. 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. Arbitrary recursion is possible, as is arbitrarily large memory usage, and implementations may place limits on CPU and memory usage, as well as restricting
access to system-defined functions. XLIFF permit extensions. Hence it is possible that application/xliff+xml may describe content that has security implications beyond those described here.“
This is based on the ITS 2.0 media type registration which was accepted, so it should be OK. You need to fill in one blank.
Best,
Felix
In discussing the security considerations for a media type it is
necessary to cover at least these points:
(1) State whether or not the media type contains active or executable
content. If the media type does contain executable content explain
what measures have been taken to insure that it can be executed
safely, e.g. a sandbox, safe operation set, signed content, etc.
(2) State whether or not the information contained in the media type
needs privacy or integrity services.
(3) If the answer to (2) is yes, elaborate on any privacy or integrity
services the media type itself provides, or if it doesn't provide such
services, explain how they should be provided externally, e.g., through
the use of SSL/TLS.
I don't see anything about executable content in the specification, but this
needs to be written by someone who knows for sure. I also note that XML
vocabularies are sometimes extensible (I didn't see that anywhere but I could
have missed it) and if so that needs to be noted as a source of possible
executable content.
I would expect there to be content of this sort that requires privacy or
integrity protection; it may or may not be appropriate to specify how that
would be provided (e.g., externally with SSL/TLS or internally with XML
signatures/encryption).
> Interoperability considerations :
> Same as interoperability considerations described in RFC 7303; also,
> interoperability requirements are specified throughout the XLIFF specification
> and summarized in its Conformance section
> Published specification :
> (a) XLIFF Version 2.0 (OASIS Standard, 05 August 2014 -
http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/xliff-core-v2.0-os.html ); supported by (b) Media Type Registration Template for
XLIFF Version 2.0 (
http://docs.oasis-open.org/xliff/xliff-media/v2.0/xliff-media-v2.0.html )
> Applications which use this media :
> XLIFF conformant applications, according to the Conformance Section of the
specification (
http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/xliff-core-v2.0-os.html#d0e863
)
> Fragment identifier considerations :
> Generic XML processors will not be able to resolve XLIFF fragment
> identifiers, as the fragment identification syntax is specific for XLIFF and
> has been defined in its Fragment Identification section as of csd03/csprd03 of
> XLIFF Version 2.0.
> Restrictions on usage :
> N/A
> Provisional registration? (standards tree only) :
> YES
> Additional information :
> 1. Deprecated alias names for this type : N/A
> 2. Magic number(s) : N/A
> 3. File extension(s) : xlf
> 4. Macintosh file type code : "TEXT"
> 5. Object Identifiers: N/A
> Note with respect to field "5. Encoding considerations": The same as encoding considerations for application/xml as specified in RFC 7303
> Person to contact for further information :
> 1. Name : Robin Cover
> 2. Email :
> Intended usage : Common
> [No additional comment on "Intended usage"]
> Author/Change controller : Authors: Tom Comerford (), David Filip(
), Yves Savourel (); Change control: OASIS Staff (Robin Cover)
--
Robin Cover
OASIS, Director of Information Services
Editor, Cover Pages and XML Daily Newslink
Email:
Staff bio:
http://www.oasis-open.org/people/staff/robin-cover
Cover Pages: http://xml.coverpages.org/
Newsletter:
http://xml.coverpages.org/newsletterArchive.html
Tel: +1 972-296-1783
