Re: Fwd: Fwd: [IANA #660606] Request for MIME media type Text/Standards Tree - provenance-notation

Dear all,

I proposed to respond as follows to the reviewer of our 
text/provenance-notation media type request.
Please shout by end of the day, if not suitable.

Thanks,
Luc


We updated the security considerations section by adding the following:

   PROV-N offers an extensibility mechanism, which in turn may introduce 
additional security considerations.
   For example, predicates in extensibility expressions use qualified 
names, mappable to IRIs, and appropriate security
   considerations for IRIs apply too.


We agree with the reviewer that the prov-n language is descriptive, but 
we didn't feel appropriate to state
that such a language did *not* call for the use of sandboxing or other 
techniques.




On 02/25/2013 08:53 PM, Luc Moreau wrote:
> Dear all,
>
> Some formal feedback regarding our text/provenance-notation mime type 
> application.
> It's probably relevant to the xml application.
> Thoughts, comments, suggestions welcome!
>
> Luc
>
>
>
>
> -------- Original Message --------
> Subject:  Fwd: [IANA #660606] Request for MIME media type 
> Text/Standards Tree - provenance-notation
> Resent-Date:  Mon, 25 Feb 2013 20:15:27 +0000
> Resent-From:  <team-prov-chairs@w3.org>
> Date:  Mon, 25 Feb 2013 21:15:02 +0100
> From:  Ivan Herman <ivan@w3.org>
> To:  W3C Chairs of Prov WG <team-prov-chairs@w3.org>
> CC:  Philippe le Hégaret <plh@w3.org>
>
>
>
> Luc, Paul,
>
> something for you. Do not seem to be a big deal, small things that may 
> be handled quickly I guess.
>
> Ivan
>
> ---
> Ivan Herman
> Tel:+31 641044153
> http://www.ivan-herman.net
>
> (Written on mobile, sorry for brevity and misspellings...)
>
>
>
> Begin forwarded message:
>
>> *From:* "Amanda Baber via RT" <iana-mime@iana.org 
>> <mailto:iana-mime@iana.org>>
>> *Date:* 25 February 2013 21:07:23 CET
>> *To:* ivan@w3.org <mailto:ivan@w3.org>, team-media-types@w3.org 
>> <mailto:team-media-types@w3.org>
>> *Subject:* *[IANA #660606] Request for MIME media type Text/Standards 
>> Tree - provenance-notation*
>> *Reply-To:* iana-mime@iana.org <mailto:iana-mime@iana.org>
>>
>> Dear Philippe, all,
>>
>> The IESG-designated expert has reviewed your application and returned
>> the inline comments below. Please reply to this email within 30 days
>> (i.e. by 27 March) with a revised Security Considerations section.
>>
>> If you have any questions, please don't hesitate to contact us.
>>
>> Best regards,
>>
>> Amanda Baber
>> IANA Request Specialist
>> ICANN
>>
>> ===
>>
>>> Name : Philippe Le Hegaret
>>
>>> Email : team-media-types@w3.org <mailto:team-media-types@w3.org>
>>
>>> MIME media type name : Text
>>
>>> MIME subtype name : Standards Tree - provenance-notation
>>
>>> Required parameters : charset — the value of charset must always be 
>>> UTF-8.
>>
>>> Optional parameters :
>>> None
>>
>>> Encoding considerations : 8bit
>>
>>
>>> Security considerations :
>>
>>> PROV-N is a general-purpose language for describing the provenance 
>>> of things;
>>> applications may evaluate given data to infer more descriptions or to
>>> dereference URIs, invoking the security considerations of the scheme 
>>> for that
>>> URI. Note in particular, the privacy issues in [RFC3023] section 10 
>>> for HTTP
>>> URIs. Data obtained from an inaccurate or malicious data source may 
>>> lead to
>>> inaccurate or misleading conclusions, as well as the dereferencing of
>>> unintended URIs. Care must be taken to align the trust in consulted 
>>> resources
>>> with the sensitivity of the intended use of the data.
>>
>>> PROV-N is used to express the provenance of arbitrary application data;
>>> security considerations will vary by domain of use. Security tools and
>>> protocols applicable to text (e.g. PGP encryption, MD5 sum validation,
>>> password-protected compression) may also be used on PROV-N documents.
>>> Security/privacy protocols must be imposed which reflect the 
>>> sensitivity of the
>>> embedded information.
>>
>>> PROV-N can express data which is presented to the user, for example, 
>>> by means
>>> of label attributes. Application rendering strings retrieved from 
>>> untrusted
>>> PROV-N documents must ensure that malignant strings may not be used 
>>> to mislead
>>> the reader. The security considerations in the media type 
>>> registration for XML
>>> ([RFC3023] section 10) provide additional guidance around the 
>>> expression of
>>> arbitrary data and markup.
>>
>>> PROV-N is a language for describing the provenance of things, and 
>>> therefore a
>>> PROV-N document is metadata for other resources. Untrusted PROV-N 
>>> documents may
>>> mislead its consumers by indicating that a third-party resource has 
>>> a reputable
>>> lineage, when it has not. Provenance of PROV-N document should be 
>>> sought.
>>
>>> PROV-N uses qualified names mappable to IRIs as term identifiers.
>>> Applications interpreting data expressed in PROV-N should address 
>>> the security
>>> issues of Internationalized Resource Identifiers (IRIs) [RFC3987] 
>>> Section 8, as
>>> well as Uniform Resource Identifier (URI): Generic Syntax [RFC3986] 
>>> Section 7.
>>
>>> Multiple IRIs may have the same appearance. Characters in different 
>>> scripts
>>> may look similar (a Cyrillic "о" may appear similar to a Latin "o"). A
>>> character followed by combining characters may have the same visual
>>> representation as another character (LATIN SMALL LETTER E followed 
>>> by COMBINING
>>> ACUTE ACCENT has the same visual representation as LATIN SMALL 
>>> LETTER E WITH
>>> ACUTE). Any person or application that is writing or interpreting 
>>> data in
>>> PROV-N must take care to use the IRI that matches the intended 
>>> semantics, and
>>> avoid IRIs that make look similar. Further information about matching of
>>> similar characters can be found in Unicode Security Considerations 
>>> [UNISEC] and
>>> Internationalized Resource Identifiers (IRIs) [RFC3987] Section 8.
>>
>> These security considerations are excellent, especially in regards to 
>> the coverage of trust issues.
>>
>> However, there's something I missed the first time I reviwed this: 
>> Section 5 talks about extensibiity. It should be noted that 
>> extensions may introduce additional security considerations.
>>
>> I also have a change to suggest (not require). Reading the 
>> specification leads me to conclude that the language is entirely 
>> descriptive, not directly executable. Generally speaking executable 
>> languages may call for the use of sandboxing and other techniques, 
>> whereas descriptive languages do not. If I'm correct in this 
>> assesment it might be helpful to point it out.
>>
>>> Interoperability considerations :
>>
>>
>>> Published specification : > PROV-N: The Provenance Notation, Moreau, 
>>> Missier,
>> (eds), Cheney, Soiland-Reyes http://www.w3.org/TR/prov-n/, 2012.
>>
>>> Applications which use this media :
>>> It may be used by any application for publishing provenance 
>>> information. This format is designed to be a human-readable form of 
>>> provenance.
>>
>>> Additional information :
>>
>>> 1. Magic number(s) : The string "document" near the beginning of the 
>>> document.
>>> 2. File extension(s) : provn
>>> 3. Macintosh file type code : TEXT
>>> 4. Object Identifiers: None
>>
>>
>>
>>> Person to contact for further information :
>>
>>> 1. Name : Ivan Herman
>>> 2. Email : ivan@w3.org <mailto:ivan@w3.org>
>>
>>> Intended usage : Common
>>
>>
>>> Author/Change controller : The PROV-N specification is the product 
>>> of the World Wide Web Consortium's Provenance Working Group. The W3C 
>>> has change control over this specification.
>>
>>
>
>

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm