Dear members,
I had an action item on me to provide an initial draft for the section
"Safety, Security, and Data Protection Considerations" and I converged
on the following proposal (adding source definitions for the three
references used):
beginning-of-proposal -- format=markdown -->
# References
## Normative References
RFC8259
: T. Bray, Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 8259, DOI 10.17487/RFC8259, December 2017,
## Informative References
GFMCMARK
: _GitHub's fork of cmark, a CommonMark parsing and rendering
GFMENG
: _GitHub Engineering: A formal spec for GitHub Flavored Markdown_,
# Safety, Security, and Data Protection Considerations
Verifiable credential (VC) documents are based on JSON, thus the
security considerations of [RFC8259] apply and are repeated here
as service for the reader:
Generally, there are security issues with scripting languages. JSON
is a subset of JavaScript but excludes assignment and invocation.
Since JSON's syntax is borrowed from JavaScript, it is possible to
use that language's "eval()" function to parse most JSON texts (but
not all; certain characters such as U+2028 LINE SEPARATOR and U+2029
PARAGRAPH SEPARATOR are legal in JSON but not JavaScript). This
generally constitutes an unacceptable security risk, since the text
could contain executable code along with data declarations. The same
consideration applies to the use of eval()-like functions in any
other programming language in which JSON texts conform to that
language's syntax.
In addition, VC documents may be rendered by consumers in various
human-readable formats like HTML or PDF. Thus, for security reasons, VC
producers and consumers SHALL adhere to the following:
* VC producers SHOULD NOT emit messages that contain HTML, even though
GitHub-flavoured Markdown is permitted. To include HTML, source code,
or any other content that may be interpreted or executed by a VC
consumer, e.g. to provide a proof-of-concept, the issuing party SHALL
use Markdown's fenced code blocks or inline code option.
* Deeply nested markup can cause a stack overflow in the Markdown
processor [GFMENG]. To reduce this risk, VC consumers SHALL use a
Markdown processor that is hardened against such attacks. Note: One
example is the GitHub fork of the `cmark` Markdown processor
[GFMCMARK].
* To reduce the risk posed by possibly malicious VC files that do
contain arbitrary HTML (including, for example,
`data:image/svg+xml`), VC consumers SHALL either disable HTML
processing (for example, by using the `--safe` option in the `cmark`
Markdown processor) or run the resulting HTML through an HTML
sanitizer.
* To reduce the risk posed by possibly malicious links within a VC
document (including, for example, `javascript:` links), VC consumers
SHALL either remove all actions from links (for example, by
displaying them as standard text) or render only those actionable
that are known to be safe (for example, determining that via the
media type). VC consumers that are not prepared to deal with the
security implications of formatted messages SHALL NOT attempt to
render them and SHALL instead fall back to the corresponding plain
text messages. As also any other programming code can be contained
within a VC document, VC consumers SHALL ensure that none of the
values of a VC document is run as code. Moreover, it SHALL be treated
as unsafe (user) input.
Additional, supporting mitigation measures like retrieving only VC
documents from trusted sources and check their integrity and
signature before parsing the document SHOULD be in place to reduce
the risk further.
end-of-proposal <---
It is borrowed from the CSAF standard and (obviously) cites the latest
(in effect) JSON RFC.
I personally do not expect consumers of verifiable credential documents
to really render these as HTML or PDF, but then, who would put
a cat into a microwave oven, right?
Notes:
I suggest we simply use the section title
"Safety, Security, and Data Protection Considerations"
instead of the current "Security and Privacy Considerations".
First, because it matches what is in it, and second, because we can.
Privacy is even no concern shared across the ISO / ITU member
states and all recent regulations have "data protection" as goal.
Privacy is a very narrow "Western world" concept changing with every
generation of users and is a concern and very much a "perception",
while data protection is more easily implementable and verifiable.
Any feedback highly appreciated.
Cheers,
Stefan.