Hi Carsten,
Thank you for your reply. Comments are in line.
On 15. Oct 2023, at 18:10, Denis<denis.i...@free.fr> wrote:
Hi Brian and Orie,
In the "old days", such problem did not existed. The prime example is using
ASN.1 / DER where the decoder can first know the full size of the message
using two or more bytes after the first byte that must contain the value 30
(SEQUENCE). Then after, the server was knowing which ASN.1 sequence to receive
and the decoder was able to check whether the whole sequence was or was not
conformant to an ASN.1 description identified using an OID.
The nested embedded lengths in BER/DER could be wonderfully exploited by
attackers by making them inconsistent with each other;
It is quite easy to verifier that the full length of DER encoded signed
sequence fits with the size of the other TLV structures contained in it.
It there is no fit, then an error shall be returned by the decoder and
the decoding shall immediately stop. At this stage, there is no need to
know where
the signature value and other information have been placed. Once the
length of the full structure has been verified against the length
of the other TLV structures, using a *parser*, the data structure can be
checked against the syntax of the language.
However, checking that a data structure is well-formed is not enough.
When using ASN.1/ DER, it is possible to check whether the whole
sequence is or is not conformant to an ASN.1 description identified
using an OID.
This processing can be done automatically using an appropriate *decoder*.
they were a prime reason that there were so many CVEs in the ASN.1 space.
CVEs = ?
If a "bad" decoder is being used, then anything can happen, but not if
using a "good" decoder.
Modern representation formats usually do not repeat this mistake.
(If selective skipping is really important, CBOR enables that by using
“embedded CBOR”.)
So the whole sequence could be decoded safely without the need to check or not
that the sequence was correctly signed.
There seems to be an assumption in this discussion that an attacker somehow
can’t produce valid signatures.
*Some* bugs in the representation format implementation may be harder to
exploit with such a requirement, but it is not a panacea.
From my side, there is no such assumption whether or not an attacker
can or cannot produce valid signatures. This was an argument raised by Orie.
As an example, all claims in a JWT are optional and, /for a given
application context,/ there is no automated way to check which claims
must be present.
*Validation *of an instance document *against a **schema *is
conceptually a separate operation from *parsing*. For complex
structures, using a *validator *
to validate an instance document***against a **schema *would be useful.
While it is well known that a JSON object only need a parser to be decoded and
not also a schema, using a schema with a parser
might be a solution to consider, but I fear this is opening a can of worms.
Outside of the IETF, the use of schemas for JSON has been considered. There may
be good reasons why the IETF has not considered
such a possibility, but I don't know these reasons.
IETF has two data definition languages to choose from: YANG and CDDL.
Both can describe data models that can be represented in CBOR or JSON.
I would expect us to use one of them, just as I’d expect ABNF to be used for
text-based formats.
This response does not respond to my question which was about the use of
schemas for JSON.
RFC 7950 (i.e., "The YANG 1.1 Data Modeling Language") considers
encoding rules (7.7.8. XML Encoding Rules) *but not decoding rules*.
It only considers using XML for the encoding ... which is not really
compact. Fortunately, XSD (i.e., XML Schema Definition) defines
constraints
on the structure and content of documents of that type, above and beyond
basic syntactical constraints. However, YANG or CDDL are unrelated
to XSD.
RFC 8610 (i.e., Concise Data Definition Language (CDDL) to express
Concise Binary Object Representation (CBOR) and JSON Data Structures)
enables automatic checking of CBOR data items for data format
compliance. Structures can be *generated *using CDDL, but can't be
*validated *
against CDDL. RFC 8610 does not enable an *automatic validation* of CBOR
data items against an expected schema, in the same way
as this is possible using either ASN.1 / DER or XSD.
AFAIK, within the IETF, there is no similar document like a "JSON Schema
Definition".
Outside the IETF, there is :
https://json-schema.org/learn/getting-started-step-by-step#validate
Such tools, called *validators, *might need to be considered.
Denis
Grüße, Carsten
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
