[Cbor] Re: New Videos on dCBOR-based Gordian Envelope

[Anders Rundgren <[e-mail]>]

Hi Wolf/CBOR WG,

TL;DR warning.

CDE CONSIDERATIONS

Although this wasn't clear during my initial encounter with deterministically encoded CBOR, the core problem was/is that RFC8949 does not fully specify all deterministic encoding rules, with numbers as the most striking example. IMO, clarifying the encoding rules is the *only* thing CDE needs to do.  Since CBOR to date appears to have managed quite well without specific standardized "Application Profiles", I consider this feature an unnecessary complication, at least for applications and CBOR implementations that adhere to a *strict subset* of CDE.  The handling of non-deterministically encoded CBOR should be left to implementations and applications to deal with.  The main reason for leaving out this part is that implementations typically make this a run-time or compile-time option.  In a generic, *platform-wide* CBOR implementation, it would be plain stupid not making preferred serialization and map sorting optional:
https://cyberphone.github.io/android-cbor/distribution/apidoc/org/webpki/cbor/CBORObject.html#decode(java.io.InputStream,boolean,boolean,java.lang.Integer)

There is also a conceptual problem with application profiles: CBOR implementations may support a wider range of CBOR data items than needed by a specific application.  Requiring a 1-2-1 match would be pretty impractical.  There are multiple ways addressing this problem, including type-checking access methods:
https://cyberphone.github.io/android-cbor/distribution/apidoc/org/webpki/cbor/CBORObject.html#getInt64()
That is, it does not make sense creating specific *encoding* profiles for applications that for example limit integer support to Int64/Uint64. A simple list or table showing the level of CBOR data item support required by the application should suffice.


Now over to the subject line...

dCBOR CONSIDERATIONS

I certainly do not have an authoritative answer to whether it would impose a problem creating a standard on top of something that effectively has been rejected as a standards proposal. Personally, I would try to eliminate potential obstacles.

Regarding "Numeric Reduction" I can only refer to what Carsten wrote in response to my question regarding its superiority compared to the CDE counterpart: "It is a technically sound solution", which nobody disagrees with.  IMHO, dying on this particular hill obscures the great job you have done with Rust and Swift support.

The other constraints seem to be pretty generic.  Well, converting -0.0 to 0.0 is (AFAICT...) redundant using IEEE-754 math rules.

Regards,
Anders



On 2024-08-15 00:19, Wolf McNally wrote:
> Anders,
> 
>> On Aug 14, 2024, at 4:40 AM, Anders Rundgren <[e-mail]> wrote:
>>
>> Thanx Christopher,
>>
>> It all looks interesting but it also raises a question: can you really build IETF standards on a foundation (dCBOR) which did not got WG adoption?
> 
> GPT-4o: Anders is making a categorical mistake by implying that something not gaining WG adoption in the IETF automatically disqualifies it from becoming a standard or from being used as the basis for one. He seems to believe that only WG-approved technologies can form the foundation of IETF standards, which is simply not true.
> 
> In reality, many technologies that begin on the Independent Stream (ISE) can, and do, influence standards or become de facto standards themselves if they prove useful and gain significant adoption. ISE RFCs often serve specific communities or use cases that may not require WG approval, but this doesn't prevent their adoption in other standards or protocols. Furthermore, the IETF standards process is not the only way a technology becomes a standard—widespread industry adoption can sometimes lead to formal recognition later.
> 
> Additionally, dCBOR’s role as a deterministic profile of CBOR, even on the ISE track, doesn't preclude Gordian Envelope from being standardized. dCBOR addresses a very specific problem—deterministic serialization—which is crucial for cryptographic operations, and if it proves useful in practice (e.g., in blockchain applications, digital signatures, secure messaging), it can become a foundational technology regardless of its WG status.
> 
> In summary, Anders’ argument that dCBOR's ISE status somehow disqualifies it from becoming a standard or forming the basis of future standards is flawed. Practical utility, widespread adoption, and real-world application often drive the success of a technology far more than whether it passed through the formal WG process.
> 
> ~ Wolf