I will bring folks attention to the fact that STIX 2.1 has recently introduced language/i18n translation options and given the likely similar nature to vulnerability assessment having both original language and translated versions of those
vulnerabilities I suggest we consider looking at how STIX2.1 did language.
Its similar to Option B but at a-per-object level and a separate object for translated versions of it.
For example the following shows an original object (a campaign) defined in En and translated versions of that object in DE & FR:
{
"type": "campaign",
"id": "campaign--12a111f0-b824-4baf-a224-83b80237a094",
"lang": "en",
"created": "2017-02-08T21:31:22.007Z",
"modified": "2017-02-08T21:31:22.007Z",
"name": "Bank Attack",
"description": "More information about bank attack"
}
{
"type": "language-content",
"id": "language-content--b86bd89f-98bb-4fa9-8cb2-9ad421da981d",
"created": "2017-02-08T21:31:22.007Z",
"modified": "2017-02-08T21:31:22.007Z",
"object_ref": "campaign--12a111f0-b824-4baf-a224-83b80237a094",
"object_modified": "2017-02-08T21:31:22.007Z",
"contents":
{
"de": {
"name": "Bank Angriff 1",
"description": "Weitere Informationen über Banküberfall"
},
"fr": {
"name": "Attaque Bank 1",
"description": "Plus d'informations sur la crise bancaire"
}
}
}
Suggest that vulnerability assessment object level is treated similar to STIX2.1 instead of an entire JSON document.
regards
Allan
From: <
csaf@lists.oasis-open.org> on behalf of Jamison Day <
jday@lookingglasscyber.com>
Date: Wednesday, May 2, 2018 at 1:28 PM
To: Eric Johnson <
eric@tibco.com>, "csaf@lists.oasis-open.org" <
csaf@lists.oasis-open.org>, "Omar Santos (osantos)" <
osantos@cisco.com>
Subject: Re: [csaf] CSAF JSON Schema - specifying the language of the document?
+1 on option B.
Note:
If “lang”: is to be an optional document-level attribute, I suggest we clearly state a specification default language (of “en"?). Requiring “lang”: is ok too, but likely places more burden
on the majority of people using the spec.
____________________________
Jamison M. Day, Ph.D.
Distinguished Data Scientist
Lookingglass Cyber Solutions, Inc.
303.968.0139 mobile
lookingglasscyber.com
This electronic message transmission contains information from LookingGlass Cyber Solutions, Inc. which may be attorney-client privileged, proprietary and/or confidential. The information in this
message is intended only for use by the individual(s) to whom it is addressed. If you believe that you have received this message in error, please contact the sender, delete this message, and be aware that any review, use, disclosure, copying or distribution
of the contents contained within is strictly prohibited.
On May 2, 2018 at 1:23:35 PM, Omar Santos (osantos) (
osantos@cisco.com ) wrote:
Thank you very much for your time and help on this! I agree on your suggestion (option B), but will let others comment. You are absolutely correct, this was a consequence of auto-conversion
from XML that uses the "xml:lang" attribute.
Regards,
Omar Santos
PSIRT, Security Research and Operations
Cisco Systems, Inc.
Email:
os@cisco.com PGP Key: 0x3AF27EDC
From:
<
csaf@lists.oasis-open.org> on behalf of Eric Johnson <
eric@tibco.com>
Date: Wednesday, May 2, 2018 at 1:31 PM
To: "csaf@lists.oasis-open.org" <
csaf@lists.oasis-open.org>
Subject: [csaf] CSAF JSON Schema - specifying the language of the document?
One of the sample documents we have includes snippets like this:
"document_title": {
"lang": "en",
"text": "Red Hat Bug Fix Advisory: Red Hat OpenShift Container Platform 3.9 RPM Release Advisory"
},
[Example 1]
This makes sense as a consequence of conversion from XML that uses the "xml:lang" attribute. However, it maps poorly to JSON, where
what was a simple "string" element containing a title now becomes an object with two properties.
The other document looks like this:
"document_title": "Cisco IOS and IOS XE Software Smart Install Remote Code Execution Vulnerability",
[Example 2]
(Curiously, unlike an XML Schema equivalent, JSON Schema actually makes it straightforward to support both these cases, but it does
not seem desirable.)
The current CVRF 1.2 specification includes the use of "xml:lang" attributes in a few places in examples, but does not specify anything
about those attributes. At a minimum, I would hope we would indicate best practices, such as including it only once at the top of the document.
I see several possibilities for how to deal with language indicators:
A - Do nothing - take all indication of language choice out of the JSON format. Leave it to the usage context (for example, HTTP language
headers, file name patterns, metadata file stored with JSON files.)
B - Indicate an (optional or required?) language choice for the entire document.
C - Support use of language indicators consistently throughout, wherever there is a string value that could be appropriately translated, also include an indication of language. This option looks like Example 1.
D - Support the use of multiple translations for every string value. A possible implementation of this is:
"document_title": {
"en": "Red Hat Bug Fix Advisory: Red Hat OpenShift
Container Platform 3.9 RPM Release Advisory"
"fr": "Avis de correction de bogue de Red Hat: Avis
de lancement de RPM de la plate-forme de conteneurs Red Hat OpenShift 3.9"
"de": "Red Hat Bug Fix-Hinweis: Red Hat OpenShift
Container Platform 3.9 Versionshinweise für RPM"
},
(Bad translations courtesy of Google Translate, please forgive me if you speak one of those languages.)
My suggestion is option B - only one language specified for the entire document. This would be consistent with CVRF, which doesn't mention
it, and therefore implies just one is expected.
Any objections to my changing the example JSON instances to reflect option B, and change the schema to match?
Eric.