Anders,
It is clear from your 03 draft release that you have not addressed a single
issue I previously raised:
• You still have three distinct kinds of numeric fields requiring
separate management.
• You still separate int and bigint while failing to allow a field to
be explicitly defined as bigint without undergoing your form of numeric
reduction, and int cannot expand to accommodate bigint.
• You continue to claim determinism as a goal while allowing
non-deterministic string encodings of semantically identical values.
• You still permit multiple encodings of zero, which undercuts
determinism.
Additionally, your Acknowledgements state:
> This work was inspired by a CBOR-based project known as Gordian Envelope
> [GORDIAN], pioneered by Wolf McNally and Christopher Allen. This project also
> exploits the ability to hash “raw” (non-wrapped) CBOR data, enabled by the
> use of a deterministic encoding scheme.
Yet:
• You mention Gordian Envelope but give no direct credit to dCBOR,
despite its direct relevance. You also cite Christopher and me by name while
failing to acknowledge our actual prior contributions to deterministic encoding
with CBOR. This may give the mistaken impression that you are creating U-CBOR
*denovo*, when in fact you have been part of the dCBOR conversation in this WG
since its start, and have simply decided to go your own way.
• Your described signature scheme has no meaningful similarity to what
we use in Gordian Envelope, as your approach modifies the signed object by
inserting the signature, while Gordian Envelope maintains fully detached
signatures that can be validated without transformation of the truly “raw”
dCBOR encoding of the signed message.
• So there is no identifiable way in which your work is actually based
on ours in any normative or informative sense.
• I previously advised you that this form of attribution was
inappropriate. You have now released another revision without correcting it,
despite having been made aware. Given your direct involvement in these
discussions, your selective omissions and attributions appear intentional.
• Therefore, I formally request that you remove all references to
myself, Christopher Allen, Blockchain Commons, dCBOR, and Gordian Envelope from
your draft. Any inclusion of our names and work in your document creates a
misleading impression of endorsement, which we do not grant, or at least
intellectual heritage, which we do agree exists.
~ Wolf
> On Mar 16, 2025, at 1:28 AM, Anders Rundgren <[email protected]>
> wrote:
>
> If you ever get tired of having to dress your precious objects in
> base64Url/bstr, or having to dig out the type of an object in JWT/CWT headers
> [*], the following may be worth a look.
>
> In particular
> https://www.ietf.org/archive/id/draft-rundgren-universal-cbor-03.html#name-enveloped-signatures
>
> The 03 version represents a major release.
>
> Enjoy!
> Anders
>
> *] All objects aren't necessarily signed, making this method very specific.
>
>
> -------- Forwarded Message --------
> Subject: New Version Notification for draft-rundgren-universal-cbor-03.txt
> Date: Sun, 16 Mar 2025 01:14:01 -0700
> From: [email protected]
> To: Anders Rundgren <[email protected]>
>
> A new version of Internet-Draft draft-rundgren-universal-cbor-03.txt has been
> successfully submitted by Anders Rundgren and posted to the
> IETF repository.
>
> Name: draft-rundgren-universal-cbor
> Revision: 03
> Title: Universal CBOR (U-CBOR)
> Date: 2025-03-16
> Group: Individual Submission
> Pages: 28
> URL: https://www.ietf.org/archive/id/draft-rundgren-universal-cbor-03.txt
> Status: https://datatracker.ietf.org/doc/draft-rundgren-universal-cbor/
> HTML:
> https://www.ietf.org/archive/id/draft-rundgren-universal-cbor-03.html
> HTMLized: https://datatracker.ietf.org/doc/html/draft-rundgren-universal-cbor
> Diff:
> https://author-tools.ietf.org/iddiff?url2=draft-rundgren-universal-cbor-03
>
> Abstract:
>
> This document defines Universal CBOR (U-CBOR), a strict subset of
> CBOR (RFC 8949) intended to serve as a viable replacement for JSON in
> computationally advanced systems like Internet browsers, mobile
> phones, and Web servers. To foster interoperability, deterministic
> encoding is mandated. Furthermore, the document outlines how
> deterministic encoding combined with enhanced CBOR tools, enable
> cryptographic methods like signing and hashing, to optionally use
> "raw" (non-wrapped) CBOR data as input. This document mainly targets
> CBOR tool developers.
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> CBOR mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
