OASIS XML Localisation Interchange File Format (XLIFF) TC

  • 1.  Fwd: IESG expert review for the registration request "xliff+xml"

    Posted 01-28-2015 13:03
    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:  david.filip@ul.ie ---------- Forwarded message ---------- From: Robin Cover < robin@oasis-open.org > Date: Tue, Jan 27, 2015 at 11:06 PM Subject: IESG expert review for the registration request "xliff+xml" To: David Filip < David.Filip@ul.ie > Cc: Robin Cover < robin@oasis-open.org > 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 : robin.cover@oasis-open.org > 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. > 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. 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 : robin.cover@oasis-open.org > Intended usage : Common > [No additional comment on "Intended usage"] > Author/Change controller : Authors: Tom Comerford ( tom@supratext.com ), David Filip( David.Filip@ul.ie ), Yves Savourel ( ysavourel@enlaso.com ); Change control: OASIS Staff (Robin Cover) -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org 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


  • 2.  Re: IESG expert review for the registration request "xliff+xml"

    Posted 01-28-2015 13:11
    Hi David, all, below is some input. Am 28.01.2015 um 14:02 schrieb Dr. David Filip < David.Filip@ul.ie >: 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:  david.filip@ul.ie ---------- Forwarded message ---------- From: Robin Cover < robin@oasis-open.org > Date: Tue, Jan 27, 2015 at 11:06 PM Subject: IESG expert review for the registration request xliff+xml To: David Filip < David.Filip@ul.ie > Cc: Robin Cover < robin@oasis-open.org > 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 : robin.cover@oasis-open.org > 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 : robin.cover@oasis-open.org > Intended usage : Common > [No additional comment on Intended usage ] > Author/Change controller : Authors: Tom Comerford ( tom@supratext.com ), David Filip( David.Filip@ul.ie ), Yves Savourel ( ysavourel@enlaso.com ); Change control: OASIS Staff (Robin Cover) -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org 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


  • 3.  Re: IESG expert review for the registration request "xliff+xml"

    Posted 01-28-2015 13:45
    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:  david.filip@ul.ie On Wed, Jan 28, 2015 at 1:10 PM, Felix Sasaki < felix@sasakiatcf.com > wrote: Hi David, all, below is some input. Am 28.01.2015 um 14:02 schrieb Dr. David Filip < David.Filip@ul.ie >: 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:  david.filip@ul.ie ---------- Forwarded message ---------- From: Robin Cover < robin@oasis-open.org > Date: Tue, Jan 27, 2015 at 11:06 PM Subject: IESG expert review for the registration request "xliff+xml" To: David Filip < David.Filip@ul.ie > Cc: Robin Cover < robin@oasis-open.org > 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 : robin.cover@oasis-open.org > 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 : robin.cover@oasis-open.org > Intended usage : Common > [No additional comment on "Intended usage"] > Author/Change controller : Authors: Tom Comerford ( tom@supratext.com ), David Filip( David.Filip@ul.ie ), Yves Savourel ( ysavourel@enlaso.com ); Change control: OASIS Staff (Robin Cover) -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org 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


  • 4.  RE: IESG expert review for the registration request "xliff+xml"

    Posted 01-28-2015 14:36




    Hi David, Felix
     
    I’ll start with a stab at listing the extension points and other possible security sensitive areas. I think this should be complete but I encourage others to
    double check if I missed some.
     
    The text proposed by Felix looks good to me but we may need to add a sentence or two due to the additional security considerations arising from the Format Style
    module.
     
    --Direct external reference mechanisms--
     
    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. We do that in the provided
    example even. For custom annotations the same applies but an implementation is not required to process the href 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--
     
    Core
                    * XML Processing Instructions allowed in the documents
                    An implementation is not required to act on processing instructions. The safety of such instructions depend on the implementation that make
    use of them. No PIs are defined in the standard.
     
                    * 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"
    Failure to validate allowed names may increase risk, but due to subfs cannot eliminate it.
     
                    * Allows arbitrary additional attributes for injection into HTML element defined in "fs" attribute by using the "subFs" 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.
     
    Regards,
    Fredrik Estreen
     



    From: Dr. David Filip [mailto:David.Filip@ul.ie]

    Sent: den 28 januari 2015 21:45
    To: Felix Sasaki
    Cc: Dr. David Filip; xliff@lists.oasis-open.org; 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:  david.filip@ul.ie









     

    On Wed, Jan 28, 2015 at 1:10 PM, Felix Sasaki < felix@sasakiatcf.com > wrote:

    Hi David, all,

     


    below is some input.


     



    Am 28.01.2015 um 14:02 schrieb Dr. David Filip < David.Filip@ul.ie >:



     



    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:  david.filip@ul.ie









     

    ---------- Forwarded message ----------
    From: Robin Cover < robin@oasis-open.org >
    Date: Tue, Jan 27, 2015 at 11:06 PM
    Subject: IESG expert review for the registration request "xliff+xml"
    To: David Filip < David.Filip@ul.ie >
    Cc: Robin Cover < robin@oasis-open.org >



    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 :
    robin.cover@oasis-open.org


     


    > 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 :
    robin.cover@oasis-open.org


     


    > Intended usage : Common


    > [No additional comment on "Intended usage"]


     


    > Author/Change controller : Authors: Tom Comerford ( tom@supratext.com ), David Filip(
    David.Filip@ul.ie ), Yves Savourel ( ysavourel@enlaso.com ); Change control: OASIS Staff (Robin Cover)


     


     

    --

    Robin Cover
    OASIS, Director of Information Services
    Editor, Cover Pages and XML Daily Newslink
    Email: robin@oasis-open.org
    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




     





     



     








  • 5.  Re: IESG expert review for the registration request "xliff+xml"

    Posted 01-28-2015 15:04
    Hi David, all, Am 28.01.2015 um 14:44 schrieb Dr. David Filip < David.Filip@ul.ie >: 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. Good point. WRT dereferencable URI/IR attributes, I guess all of them are.. should not be too complicated to compile a list of those. Not sure if you need to be exhaustive.The same for 3: maybe try another round with the IESG and be general? It may not be needed to go into detail a lot. Best, Felix 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:  david.filip@ul.ie On Wed, Jan 28, 2015 at 1:10 PM, Felix Sasaki < felix@sasakiatcf.com > wrote: Hi David, all, below is some input. Am 28.01.2015 um 14:02 schrieb Dr. David Filip < David.Filip@ul.ie >: 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:  david.filip@ul.ie ---------- Forwarded message ---------- From: Robin Cover < robin@oasis-open.org > Date: Tue, Jan 27, 2015 at 11:06 PM Subject: IESG expert review for the registration request xliff+xml To: David Filip < David.Filip@ul.ie > Cc: Robin Cover < robin@oasis-open.org > 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 : robin.cover@oasis-open.org > 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 : robin.cover@oasis-open.org > Intended usage : Common > [No additional comment on Intended usage ] > Author/Change controller : Authors: Tom Comerford ( tom@supratext.com ), David Filip( David.Filip@ul.ie ), Yves Savourel ( ysavourel@enlaso.com ); Change control: OASIS Staff (Robin Cover) -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org 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


  • 6.  Re: IESG expert review for the registration request "xliff+xml"

    Posted 02-03-2015 12:56
    Felix, Fredrik, all, 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. The proposed text is now committed on SVN here: The whole content of the document is pasted here: http://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/mediaTypeRegistration/Security%20considerations%20for%20XLIFF%202.docx 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. Cheers 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:  david.filip@ul.ie On Wed, Jan 28, 2015 at 3:03 PM, Felix Sasaki < felix@sasakiatcf.com > wrote: Hi David, all, Am 28.01.2015 um 14:44 schrieb Dr. David Filip < David.Filip@ul.ie >: 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. Good point. WRT dereferencable URI/IR attributes, I guess all of them are.. should not be too complicated to compile a list of those. Not sure if you need to be exhaustive.The same for 3: maybe try another round with the IESG and be general? It may not be needed to go into detail a lot. Best, Felix 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:  david.filip@ul.ie On Wed, Jan 28, 2015 at 1:10 PM, Felix Sasaki < felix@sasakiatcf.com > wrote: Hi David, all, below is some input. Am 28.01.2015 um 14:02 schrieb Dr. David Filip < David.Filip@ul.ie >: 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:  david.filip@ul.ie ---------- Forwarded message ---------- From: Robin Cover < robin@oasis-open.org > Date: Tue, Jan 27, 2015 at 11:06 PM Subject: IESG expert review for the registration request "xliff+xml" To: David Filip < David.Filip@ul.ie > Cc: Robin Cover < robin@oasis-open.org > 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 : robin.cover@oasis-open.org > 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 : robin.cover@oasis-open.org > Intended usage : Common > [No additional comment on "Intended usage"] > Author/Change controller : Authors: Tom Comerford ( tom@supratext.com ), David Filip( David.Filip@ul.ie ), Yves Savourel ( ysavourel@enlaso.com ); Change control: OASIS Staff (Robin Cover) -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org 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


  • 7.  Re: IESG expert review for the registration request "xliff+xml"

    Posted 02-03-2015 13:52
    Hi David, I am sick and won’t be on the call. In general this looks good. Not sure about the length of the section. If you want to shorten things, some ideas: - leave the separation into modules out, just list the elements and their relevant attributes - leave the explanations out, e.g. all text after  <mrk> via attribute  ref for Term annotations and probably custom annotations Not sure if this part Uses HTML element names as values of attribute „fs““ needs to be here. Above is just informal feedback. If you decide differently that’s OK by me, please go ahead. Best, Felix Am 03.02.2015 um 13:54 schrieb Dr. David Filip < David.Filip@ul.ie >: Felix, Fredrik, all, 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. The proposed text is now committed on SVN here: The whole content of the document is pasted here: http://tools.oasis-open.org/version-control/browse/wsvn/xliff/trunk/mediaTypeRegistration/Security%20considerations%20for%20XLIFF%202.docx 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. Cheers 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:  david.filip@ul.ie On Wed, Jan 28, 2015 at 3:03 PM, Felix Sasaki < felix@sasakiatcf.com > wrote: Hi David, all, Am 28.01.2015 um 14:44 schrieb Dr. David Filip < David.Filip@ul.ie >: 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. Good point. WRT dereferencable URI/IR attributes, I guess all of them are.. should not be too complicated to compile a list of those. Not sure if you need to be exhaustive.The same for 3: maybe try another round with the IESG and be general? It may not be needed to go into detail a lot. Best, Felix 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:  david.filip@ul.ie On Wed, Jan 28, 2015 at 1:10 PM, Felix Sasaki < felix@sasakiatcf.com > wrote: Hi David, all, below is some input. Am 28.01.2015 um 14:02 schrieb Dr. David Filip < David.Filip@ul.ie >: 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:  david.filip@ul.ie ---------- Forwarded message ---------- From: Robin Cover < robin@oasis-open.org > Date: Tue, Jan 27, 2015 at 11:06 PM Subject: IESG expert review for the registration request xliff+xml To: David Filip < David.Filip@ul.ie > Cc: Robin Cover < robin@oasis-open.org > 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 : robin.cover@oasis-open.org > 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 : robin.cover@oasis-open.org > Intended usage : Common > [No additional comment on Intended usage ] > Author/Change controller : Authors: Tom Comerford ( tom@supratext.com ), David Filip( David.Filip@ul.ie ), Yves Savourel ( ysavourel@enlaso.com ); Change control: OASIS Staff (Robin Cover) -- Robin Cover OASIS, Director of Information Services Editor, Cover Pages and XML Daily Newslink Email: robin@oasis-open.org 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


  • 8.  Re: [xliff] Re: IESG expert review for the registration request "xliff+xml"