From 16d8a4dc293689f1bc09c859bd3278bdd5e46fdb Mon Sep 17 00:00:00 2001 From: Manu Sporny Date: Mon, 26 Aug 2024 10:15:16 -0400 Subject: [PATCH] Removing issue markers that have received no feedback. --- index.html | 25 ------------------------- 1 file changed, 25 deletions(-) diff --git a/index.html b/index.html index d614545..e3b5d1e 100644 --- a/index.html +++ b/index.html @@ -2690,31 +2690,6 @@

Transformations

Implementers are advised to consider these sorts of attacks when implementing defensive security strategies.

-

-The VCWG is seeking feedback on normative language that cryptographic suite -implementers need to follow to ensure that they do not utilize data -transformation mechanisms that can map to the same output. That is, given -different inputs for canonicalization scheme #1 and canonicalization scheme #2, -they must not produce the same output value. As an analogy, this is the same -requirement for cryptographic hashing mechanisms and is why those schemes are -designed to be collision resistant. Cryptographic canonicalization mechanisms -have the same requirement. At present, this isn't a problem because the three -expected canonicalization schemes — the Universal RDF Dataset -Canonicalization Algorithm 2015 [[?RDF-CANON]], JSON Canonicalization -Scheme [[?RFC8785]], and a theoretical future base-encoding canonicalization -— have entirely different outputs. -

-

-The VCWG is seeking feedback on whether to explain why modern canonicalization -schemes are simpler than the far more complex XML Canonicalization schemes of -the early 2000s. Some readers seem to be under the impression that all -canonicalization is difficult and has to be avoided at all costs (including costs -to application developers). The WG would like to understand if it would be helpful -to include a section explaining why some simpler data syntaxes (such as JSON) are -easier to canonicalize than more complex data syntaxes (such as XML). -