From nobody Mon Jan 8 10:33:59 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A465D128959 for ; Mon, 8 Jan 2018 10:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9kIFQCjPznz for ; Mon, 8 Jan 2018 10:33:54 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E96C126D46 for ; Mon, 8 Jan 2018 10:33:54 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id b77so5387334itd.0 for ; Mon, 08 Jan 2018 10:33:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pPHGFR35LO1IFBEmzsjP4fruJtO0yJ25yw/a4qjVELE=; b=DsXtlbRUDFG6Ey4KBOL+8FoLRrLoc4E93UVBMh/kxVmFxCOeKhjkZ5RZujIlNY0Gxf CGrZgYxTEuMXe3MlTbYN4AiMRc8snZo0XFQA5dcVetE1HUPK8aA3a9PWXAUypHBPBEra QSM0kub824QSAVWL66BMQG9PvlynvIuVo4GUY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=pPHGFR35LO1IFBEmzsjP4fruJtO0yJ25yw/a4qjVELE=; b=s3Srr0GwgYSQ6jm0aHcjctsuyxwm2oS1sQoqA4tccs73ugL5sDM0unk6LkvcM01mTm h5atrD0JuDBkImPN5saVQ+5f/lLtSQ/EBjy5iF+XHeoNGRa7QS+o5ona08E/oJIm2A49 ozZi75DWrjoM+8cG1O2yD5m99XaAqysJMjy9egWiH4p2hIjrJQMFFr1Axo0qGA1VxGfV XDUJZQXj990KjnbJCkIgH1bhE6mWkLxPPhwMCcEmegOj9LCk+GyYujC1LWI5lqutPrLJ KnZFWt3cN5lvPSLk3ufHIJ47Vp4qrthFboE2t8IYe7F4IvIAsxU7i0Dlrqwcx4tpFAiZ 1oOA== X-Gm-Message-State: AKwxytcFBUD42RW9fge1ToccH2mDDh9b+nwl9NEBEPP++tH7gaSvnAzR 8zECTQkWZZooVF24QTBkbn9/9+meVMxbX7G2av3Jng== X-Google-Smtp-Source: ACJfBougjff6kWI6VkWmvaz4oO8EU4pbLEyC2R3JVAB5MvnIHYuxlLuxPXewWbo9+5G6XmLSm4DScPaGqrpBqM4ZJlQ= X-Received: by 10.36.93.136 with SMTP id w130mr8085884ita.106.1515436432884; Mon, 08 Jan 2018 10:33:52 -0800 (PST) MIME-Version: 1.0 References: <012801d32f2e$a95aaf10$fc100d30$@augustcellars.com> <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> <1FED1F56-93BA-410F-B7C4-E83D31E7CC4E@tzi.org> <5D1F5ECC-C7DA-427F-B8A1-2040EA75FDE6@tzi.org> In-Reply-To: From: Jeffrey Yasskin Date: Mon, 08 Jan 2018 18:33:42 +0000 Message-ID: To: Jeffrey Yasskin Cc: Carsten Bormann , cbor@ietf.org Content-Type: multipart/alternative; boundary="001a1144ad5c43bde80562480a69" Archived-At: Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 18:33:58 -0000 --001a1144ad5c43bde80562480a69 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Now that we're past the holidays, are there more comments on https://github.com/cbor-wg/CBORbis/pull/9? On Fri, Dec 22, 2017 at 3:56 PM Jeffrey Yasskin wrote: > I don't think https://github.com/cbor-wg/CBORbis/pull/9 allows anything > that RFC7049 didn't, which is the meaning I get from "open this up". > > We *could* move this (all of section 3?) to a separate document, but I > haven't seen anyone say that we need to. A downside of moving section 3 t= o > another RFC is that it'll make it harder to find. Someone authoritative > (Francesca?) should just make this call so that we can stop angsting abou= t > it. > > I'm generally happy to change exactly which examples demonstrate that > protocol designers need to think about canonicalization even if they star= t > from the core canonicalization requirements. I'd appreciate a concrete > statement of which examples to use though. > > Once we add floating values, the type of a field matters in defining its > canonicalization. A float64 field only needs to canonicalize NaN. A > float16/float32/float64 field needs to canonicalize to either the smalles= t > or largest type. An int/float field needs to again canonicalize toward or > away from int. A bigint field needs to prefer either a fixed-length > (useful for cryptographic signatures) or the shortest representation. A > decfrac/bigfloat/number field has an even more complex problem. I don't > personally have enough examples of existing canonicalized CBOR-based > protocols to make any confident recommendations here. If the list gives m= e > some, along with the field experience that justifies them, I'm happy to > write them down in my patch. > > Jeffrey > > > On Fri, Dec 22, 2017 at 2:23 PM Carsten Bormann wrote: > >> Hi Jeffrey, >> >> quick reactions after a first skim: >> >> I=E2=80=99m not sure the direction should be to open this up; I think th= e >> recommendations should become more narrow as we learn about the practica= l >> issues. >> >> We could write a separate document on the preferred c14n so we can keep >> this out of the main document. >> >> I don=E2=80=99t think we necessarily want to encourage cross-over betwee= n int and >> float, so I think the =E2=80=9Cshortest float=E2=80=9D rule should be ap= plied independent >> of whether that cross-over is desired. >> >> Why keep the =E2=80=9Cshortest int=E2=80=9D rule less well defined for p= rotocols that use >> bignums? It should apply there as well, i.e., use bignums only for >> integers too large for the major type 0/1 formats. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> >> > On Dec 22, 2017, at 23:13, Jeffrey Yasskin >> wrote: >> > >> > On Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann wrote: >> > On Nov 30, 2017, at 23:14, Jeffrey Yasskin >> wrote: >> > > >> > > Belatedly, I've discovered a user of "canonical" CBOR who's proposin= g >> a different map order than the RFC suggests: >> https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-auth= enticator-protocol-v2.0-rd-20170927.html#message-encoding. >> (Note that this isn't a final standard yet and may change.) >> > >> > I looked at the spec referenced. >> > >> > So they essentially add >> > >> > =E2=80=A2 If the major types are different, the one wi= th the >> lower value in numerical order sorts earlier. >> > >> > as a major sorting rule before the existing RFC 7049 canonicalization >> rules: >> > >> > =E2=80=A2 If two keys have different lengths, the shor= ter one >> sorts earlier; >> > =E2=80=A2 If two keys have the same length, the one wi= th the >> lower value in (byte-wise) lexical order sorts earlier. >> > >> > This is different from simply going for byte-wise lexicographic (memcm= p >> order(*)), which effectively would get us the first rule as the major >> sorting order already, but get rid of the length-based second rule (firs= t >> rule in Section 3.9 of RFC 7049). >> > >> > I=E2=80=99ve come to see the putting the length comparison rule early = in 3.9 as >> a major regression. >> > One of the objectives when designing the CBOR serialization was not to >> repeat one big mistake that ASN.1 BER makes: to make overall lengths of >> complex composite items visible/important in the encoding of the next >> higher composite. >> > Here, we are doing just that. D=E2=80=99oh. >> > >> > > This is justified by the RFC saying that "Those protocols are free t= o >> define what they mean by a canonical format and what encoders and decode= rs >> are expected to do. This section lists some suggestions for such >> protocols." That is (as Jim said), the RFC doesn't specify "canonical" >> CBOR: it just provides an option for higher-level protocols to do so. >> > >> > Right. So the change would be to mention two options for this, the ol= d >> canonical, and the saner (memcmp order) canonical. Now the next step is >> finding names for legacy canonical/saner canonical. We then have to dec= ide >> whether we turn this into a separate document, at Proposed Standard leve= l, >> or believe that adding another suggestion to 3.9 is essentially a bug fi= x >> and can be done in the Standard level document. >> > >> > > The use of a different order in CTAP is going to either force its >> implementers to write custom CBOR encoders and decoders or require the >> generic encoders to take a configuration option for the map order. If th= e >> generic encoders take an option, then it stops being an issue for CBORbi= s >> to suggest a different order. >> > >> > Right. So I think you are saying we get to fix this. >> > >> > I've tried to implement this in >> https://github.com/cbor-wg/CBORbis/pull/9. I defined a core set of rules >> so that other specs can use them by reference, gave several examples of >> protocols that will need to extend the rules, and defined a second set o= f >> rules that match the canonical order that RFC7049 suggested. >> > >> > Do folks like this direction? >> > >> > I don't have a strong opinion about which document should hold the >> canonicalization rules. Can we ask the IESG which they'd prefer? >> > >> > Jeffrey >> >> --001a1144ad5c43bde80562480a69 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Now that we're past the holidays, are there more comme= nts on=C2=A0https://github.com/cbor-wg/CBORbis/pull/9?

On Fri, Dec 22, 2017 at 3:56 PM Jeffrey Yasskin <jyasskin@chromium.org> wrote:
I don't think https://g= ithub.com/cbor-wg/CBORbis/pull/9=C2=A0allows anything that RFC7049 didn= 't, which is the meaning I get from "open this up".=C2=A0

We *could* move this (all of section 3?) to a separat= e document, but I haven't seen anyone say that we need to. A downside o= f moving section 3 to another RFC is that it'll make it harder to find.= Someone authoritative (Francesca?)=C2=A0should just make this call so that= we can stop angsting about it.

I'm generally = happy to change exactly which examples demonstrate that protocol designers = need to think about canonicalization even if they start from the core canon= icalization requirements. I'd appreciate a concrete statement of which = examples to use though.

Once we add floating value= s, the type of a field matters in defining its canonicalization. A float64 = field only needs to canonicalize NaN. A float16/float32/float64 field needs= to canonicalize to either the smallest or largest type. An int/float field= needs to again canonicalize toward or away from int. A bigint field needs = to prefer either a fixed-length (useful for crypt= ographic signatures) or the=C2=A0shortest representation. A decfrac/= bigfloat/number field has an even more complex problem. I don't persona= lly have enough examples of existing canonicalized CBOR-based protocols to = make any confident recommendations here. If the list gives me some, along w= ith the field experience that justifies them, I'm happy to write them d= own in my patch.

Jeffrey


On Fri, Dec 22, 2017 at 2:23 PM Carste= n Bormann <cabo@tzi.or= g> wrote:
Hi Jeffrey,

quick reactions after a first skim:

I=E2=80=99m not sure the direction should be to open this up; I think the r= ecommendations should become more narrow as we learn about the practical is= sues.

We could write a separate document on the preferred c14n so we can keep thi= s out of the main document.

I don=E2=80=99t think we necessarily want to encourage cross-over between i= nt and float, so I think the =E2=80=9Cshortest float=E2=80=9D rule should b= e applied independent of whether that cross-over is desired.

Why keep the =E2=80=9Cshortest int=E2=80=9D rule less well defined for prot= ocols that use bignums?=C2=A0 It should apply there as well, i.e., use bign= ums only for integers too large for the major type 0/1 formats.

Gr=C3=BC=C3=9Fe, Carsten


> On Dec 22, 2017, at 23:13, Jeffrey Yasskin <jyasskin@chromium.org> wrote: >
> On Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann <cabo@tzi.org> wrote:
> On Nov 30, 2017, at 23:14, Jeffrey Yasskin <jyasskin@chromium.org> wrote: > >
> > Belatedly, I've discovered a user of "canonical" CB= OR who's proposing a different map order than the RFC suggests: https://fidoalliance.org/specs/fido-v2.0-rd-20170927/= fido-client-to-authenticator-protocol-v2.0-rd-20170927.html#message-encodin= g. (Note that this isn't a final standard yet and may change.)
>
> I looked at the spec referenced.
>
> So they essentially add
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2= If the major types are different, the one with the lower value in numerica= l order sorts earlier.
>
> as a major sorting rule before the existing RFC 7049 canonicalization = rules:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2= If two keys have different lengths, the shorter one sorts earlier;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2= If two keys have the same length, the one with the lower value in (byte-wi= se) lexical order sorts earlier.
>
> This is different from simply going for byte-wise lexicographic (memcm= p order(*)), which effectively would get us the first rule as the major sor= ting order already, but get rid of the length-based second rule (first rule= in Section 3.9 of RFC 7049).
>
> I=E2=80=99ve come to see the putting the length comparison rule early = in 3.9 as a major regression.
> One of the objectives when designing the CBOR serialization was not to= repeat one big mistake that ASN.1 BER makes: to make overall lengths of co= mplex composite items visible/important in the encoding of the next higher = composite.
> Here, we are doing just that.=C2=A0 D=E2=80=99oh.
>
> > This is justified by the RFC saying that "Those protocols ar= e free to define what they mean by a canonical format and what encoders and= decoders are expected to do.=C2=A0 This section lists some suggestions for= such protocols." That is (as Jim said), the RFC doesn't specify &= quot;canonical" CBOR: it just provides an option for higher-level prot= ocols to do so.
>
> Right.=C2=A0 So the change would be to mention two options for this, t= he old canonical, and the saner (memcmp order) canonical.=C2=A0 Now the nex= t step is finding names for legacy canonical/saner canonical.=C2=A0 We then= have to decide whether we turn this into a separate document, at Proposed = Standard level, or believe that adding another suggestion to 3.9 is essenti= ally a bug fix and can be done in the Standard level document.
>
> > The use of a different order in CTAP is going to either force its= implementers to write custom CBOR encoders and decoders or require the gen= eric encoders to take a configuration option for the map order. If the gene= ric encoders take an option, then it stops being an issue for CBORbis to su= ggest a different order.
>
> Right.=C2=A0 So I think you are saying we get to fix this.
>
> I've tried to implement this in https://github.com= /cbor-wg/CBORbis/pull/9. I defined a core set of rules so that other sp= ecs can use them by reference, gave several examples of protocols that will= need to extend the rules, and defined a second set of rules that match the= canonical order that RFC7049 suggested.
>
> Do folks like this direction?
>
> I don't have a strong opinion about which document should hold the= canonicalization rules. Can we ask the IESG which they'd prefer?
>
> Jeffrey

--001a1144ad5c43bde80562480a69-- From nobody Mon Jan 8 11:59:06 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB730127023 for ; Mon, 8 Jan 2018 11:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.691 X-Spam-Level: X-Spam-Status: No, score=0.691 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qK20YUx5mZdp for ; Mon, 8 Jan 2018 11:59:03 -0800 (PST) Received: from sonic305-21.consmr.mail.ne1.yahoo.com (sonic305-21.consmr.mail.ne1.yahoo.com [66.163.185.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376CE126CD6 for ; Mon, 8 Jan 2018 11:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1515441542; bh=AZ4z2iI1NjbWicIdV9CGhNFXEV/rdizXZSf2J56oc84=; h=Date:From:To:In-Reply-To:References:Subject:From:Subject; b=fftqG0ZCw8xMYaeoqVJFmshPfZwP6nCazhzMSyCny8oKbHMnhAg8SuBc8d7rqgte8QBfWQv3qxwSEk2w6RhkctVlh5lCDyySTlzA2h8Sw35j7YH2S1HS6VQBCAdNZXrJGjP0Uv7gIju9KQE3Z8ES7C01rufZFypIvpaKCCYvJ0b5Etf0EIRUbGYbV0oIIgAaBhnyioOdZDPzGcNtY3XpbL9GHHXztsiNIULj3C5/ejbdMvzBrspunfyXCxr7UJkZqF1W7Hl9lpKPWGWfAf82f3tp2bCZi+9FjzLsIHe6jaWPs25XK3NVutCio4BumpELkF07iYhH5eXE9f8JW51f8A== X-YMail-OSG: skJHp.gVM1l25EaktF87IvMmm.AssIAs_Og4MyMsPMoeZ8urXLZ8ZAlBj_.TUlJ LgsPbMQmCM2m0kqxcxG7zW_Vkz08TQJAO2sVCtSQ_yLtEP2P9hwqklc4ab6EZlsYnZXGMpVBKfKD dXOc9Fi_5yHC_QELCTsd7eTma8UjAKrhfWJ2HEmoXs21nfQniigTeTbip5t4jPsEef3eqf.bZMIR L7Epp9uJoWiiMfOWFd94teO9vsZVL.zKR3WEPdve3Ifh99MVbPtvGQXFuAii9.ceSB8naRv2p5G0 7QtYWY1fooUnfce7hAc4RG8P1nX0DKuGXI57kepUQXdjMOhIE1ngDSY0X_W6bOCNYQwDGwa.PqI7 tBNd_11gXO5NMHcsrb1vzHv0kFS1sSkplSx4PqrRbDjI2NFJsABGcYgRHWZKWilZ3kNvbWLFQbqs 0H6cbIRz9j.7luNTIz9EgEN33Froj9P5ofETWE6Z4k8i5V8iDOPG3F_vzngxRZUFHdY.q5bvjBsQ Tw9KdXNl6T.fFKlSyYS40itphvFEiYld4dFYl3ZA- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Mon, 8 Jan 2018 19:59:02 +0000 Date: Mon, 8 Jan 2018 19:58:58 +0000 (UTC) From: Ravi R To: cbor@ietf.org Message-ID: <1384821169.2802075.1515441538652@mail.yahoo.com> In-Reply-To: <673530107.734857.1515118476388@mail.yahoo.com> References: <673530107.734857.1515118476388.ref@mail.yahoo.com> <673530107.734857.1515118476388@mail.yahoo.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_2802074_1009968584.1515441538648" X-Mailer: WebService/1.1.11150 YMailNorrin Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.108 Safari/537.36 Archived-At: Subject: Re: [Cbor] new types like ip address/mac ... X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jan 2018 19:59:04 -0000 ------=_Part_2802074_1009968584.1515441538648 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable If this is the wrong place to post this - please reply, so i w= ill know.. On Thursday, January 4, 2018, 6:14:36 PM PST, Ravi R wrote: =20 =20 Hi,=C2=A0 =C2=A0 =C2=A0 What would be your recommendation if I want to add= custom data types =E2=80=93 like IP Address, MAC address etc ??=C2=A0Would= you recommend creating a TAG type for each of the custom data types ??=C2= =A0Also, I have another question =E2=80=93 I am considering using CBOR form= at for log file format (logging will be in Binary Format) =E2=80=93 so that= it is extremely fast. There is a problem with this though if the log files= are written to a file and that file could be =E2=80=9Clog rotated=E2=80=9D= . The log rotation will terminate the file and there could be that a single= CBOR object spans across two files. If there is a decode attempt on the fi= le with second half of a CBOR object, then everything can get skewed =E2=80= =93 because the type etc are in the previous file.=C2=A0So, I am thinking o= f adding some sort of BEGIN or END of record indicators =E2=80=93 so that o= ne can recover from a faulty decoding.=C2=A0Please let me know your thought= s on both of these items. Thanks! =20 ------=_Part_2802074_1009968584.1515441538648 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
<resending> If this is the wrong place to post this = - please reply, so i will know..

=20
=20
On Thursday, January 4, 2018, 6:14:36 PM PST, Ravi = R <toravir@yahoo.com> wrote:


Hi,
      What would be your recomm= endation if I want to add custom data types =E2=80=93 like IP Address, MAC = address etc ??
 
Would you recommend creating a TA= G type for each of the custom data types ??
 
Also= , I have another question =E2=80=93 I am considering using CBOR format for = log file format (logging will be in Binary Format) =E2=80=93 so that it is = extremely fast. There is a problem with this though if the log files are wr= itten to a file and that file could be =E2=80=9Clog rotated=E2=80=9D. The l= og rotation will terminate the file and there could be that a single CBOR o= bject spans across two files. If there is a decode attempt on the file with= second half of a CBOR object, then everything can get skewed =E2=80=93 bec= ause the type etc are in the previous file.
 
So, = I am thinking of adding some sort of BEGIN or END of record indicators =E2= =80=93 so that one can recover from a faulty decoding.
 
Please let me know your thoughts on both of these items.
<= br>
Thanks!
------=_Part_2802074_1009968584.1515441538648-- From nobody Mon Jan 8 20:12:42 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E558312711A for ; Mon, 8 Jan 2018 20:12:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htiDpWZW9rzv for ; Mon, 8 Jan 2018 20:12:36 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4B6D126D3F for ; Mon, 8 Jan 2018 20:12:35 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Jan 2018 20:11:03 -0800 From: Jim Schaad To: 'Jeffrey Yasskin' CC: , 'Carsten Bormann' References: <012801d32f2e$a95aaf10$fc100d30$@augustcellars.com> <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> <1FED1F56-93BA-410F-B7C4-E83D31E7CC4E@tzi.org> <5D1F5ECC-C7DA-427F-B8A1-2040EA75FDE6@tzi.org> In-Reply-To: Date: Mon, 8 Jan 2018 20:12:27 -0800 Message-ID: <000b01d38900$111d1400$33573c00$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01D388BD.02FB0C80" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLkcV5/cuYwYNvq7zdAWu7g9fdkoQDl1w1UAkkwjzoCc2JLLgGyH3OJAnAGOCgB7/DF0QHRbgWLAt0pUNwDLGw5BwHCAbzQoJ6OqSA= Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 04:12:40 -0000 ------=_NextPart_000_000C_01D388BD.02FB0C80 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable I did not like the idea of changing the types of items when doing = canonicalization. I want to look just at what is given to me and thus = do not like things like a floating point number may be encoded as an any = of a number of different formats. The choice of what an item is encoded = as in terms of a floating point number is a function of the document = specification and not the canonicalization encoding format. For things = like big numbers, the encoding should not be modified because the = leading characters have been chosen by the application for a specific = reason. Consider the leading padding that is part of a public key in = cryptography where the length of the value is of equal or greater = importance that the fact that is has leading 0 or 0xff bytes. The rules = for mapping between the data model and the encoding are as much up to = the protocol specification as they are for the CBOR specification. It = is possible that a specification will only want to use the 64-bit = floating point number format because it really simplifies the = application even if it makes the encoded format longer. =20 In sort, I do not believe that the rules should be extended beyond how = an encoding works for a single encoded data format. =20 Jim =20 =20 From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Jeffrey Yasskin Sent: Monday, January 8, 2018 10:34 AM To: Jeffrey Yasskin Cc: cbor@ietf.org; Carsten Bormann Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested = Canonicalization =20 Now that we're past the holidays, are there more comments on = = https://github.com/cbor-wg/CBORbis/pull/9? On Fri, Dec 22, 2017 at 3:56 PM Jeffrey Yasskin > wrote: I don't think https://github.com/cbor-wg/CBORbis/pull/9 allows anything = that RFC7049 didn't, which is the meaning I get from "open this up".=20 =20 We *could* move this (all of section 3?) to a separate document, but I = haven't seen anyone say that we need to. A downside of moving section 3 = to another RFC is that it'll make it harder to find. Someone = authoritative (Francesca?) should just make this call so that we can = stop angsting about it. =20 I'm generally happy to change exactly which examples demonstrate that = protocol designers need to think about canonicalization even if they = start from the core canonicalization requirements. I'd appreciate a = concrete statement of which examples to use though. =20 Once we add floating values, the type of a field matters in defining its = canonicalization. A float64 field only needs to canonicalize NaN. A = float16/float32/float64 field needs to canonicalize to either the = smallest or largest type. An int/float field needs to again canonicalize = toward or away from int. A bigint field needs to prefer either a = fixed-length (useful for cryptographic signatures) or the shortest = representation. A decfrac/bigfloat/number field has an even more complex = problem. I don't personally have enough examples of existing = canonicalized CBOR-based protocols to make any confident recommendations = here. If the list gives me some, along with the field experience that = justifies them, I'm happy to write them down in my patch. =20 Jeffrey =20 On Fri, Dec 22, 2017 at 2:23 PM Carsten Bormann > wrote: Hi Jeffrey, quick reactions after a first skim: I=E2=80=99m not sure the direction should be to open this up; I think = the recommendations should become more narrow as we learn about the = practical issues. We could write a separate document on the preferred c14n so we can keep = this out of the main document. I don=E2=80=99t think we necessarily want to encourage cross-over = between int and float, so I think the =E2=80=9Cshortest float=E2=80=9D = rule should be applied independent of whether that cross-over is = desired. Why keep the =E2=80=9Cshortest int=E2=80=9D rule less well defined for = protocols that use bignums? It should apply there as well, i.e., use = bignums only for integers too large for the major type 0/1 formats. Gr=C3=BC=C3=9Fe, Carsten > On Dec 22, 2017, at 23:13, Jeffrey Yasskin > wrote: > > On Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann > wrote: > On Nov 30, 2017, at 23:14, Jeffrey Yasskin > wrote: > > > > Belatedly, I've discovered a user of "canonical" CBOR who's = proposing a different map order than the RFC suggests: = https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-authe= nticator-protocol-v2.0-rd-20170927.html#message-encoding. (Note that = this isn't a final standard yet and may change.) > > I looked at the spec referenced. > > So they essentially add > > =E2=80=A2 If the major types are different, the one = with the lower value in numerical order sorts earlier. > > as a major sorting rule before the existing RFC 7049 canonicalization = rules: > > =E2=80=A2 If two keys have different lengths, the = shorter one sorts earlier; > =E2=80=A2 If two keys have the same length, the one = with the lower value in (byte-wise) lexical order sorts earlier. > > This is different from simply going for byte-wise lexicographic = (memcmp order(*)), which effectively would get us the first rule as the = major sorting order already, but get rid of the length-based second rule = (first rule in Section 3.9 of RFC 7049). > > I=E2=80=99ve come to see the putting the length comparison rule early = in 3.9 as a major regression. > One of the objectives when designing the CBOR serialization was not to = repeat one big mistake that ASN.1 BER makes: to make overall lengths of = complex composite items visible/important in the encoding of the next = higher composite. > Here, we are doing just that. D=E2=80=99oh. > > > This is justified by the RFC saying that "Those protocols are free = to define what they mean by a canonical format and what encoders and = decoders are expected to do. This section lists some suggestions for = such protocols." That is (as Jim said), the RFC doesn't specify = "canonical" CBOR: it just provides an option for higher-level protocols = to do so. > > Right. So the change would be to mention two options for this, the = old canonical, and the saner (memcmp order) canonical. Now the next = step is finding names for legacy canonical/saner canonical. We then = have to decide whether we turn this into a separate document, at = Proposed Standard level, or believe that adding another suggestion to = 3.9 is essentially a bug fix and can be done in the Standard level = document. > > > The use of a different order in CTAP is going to either force its = implementers to write custom CBOR encoders and decoders or require the = generic encoders to take a configuration option for the map order. If = the generic encoders take an option, then it stops being an issue for = CBORbis to suggest a different order. > > Right. So I think you are saying we get to fix this. > > I've tried to implement this in = https://github.com/cbor-wg/CBORbis/pull/9. I defined a core set of rules = so that other specs can use them by reference, gave several examples of = protocols that will need to extend the rules, and defined a second set = of rules that match the canonical order that RFC7049 suggested. > > Do folks like this direction? > > I don't have a strong opinion about which document should hold the = canonicalization rules. Can we ask the IESG which they'd prefer? > > Jeffrey ------=_NextPart_000_000C_01D388BD.02FB0C80 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

I did not = like the idea of changing the types of items when doing = canonicalization.=C2=A0 I want to look just at what is given to me and = thus do not like things like a floating point number may be encoded as = an any of a number of different formats.=C2=A0 The choice of what an = item is encoded as in terms of a floating point number is a function of = the document specification and not the canonicalization encoding = format.=C2=A0 For things like big numbers, the encoding should not be = modified because the leading characters have been chosen by the = application for a specific reason.=C2=A0 Consider the leading padding = that is part of a public key in cryptography where the length of the = value is of equal or greater importance that the fact that is has = leading 0 or 0xff bytes.=C2=A0 The rules for mapping between the data = model and the encoding are as much up to the protocol specification as = they are for the CBOR specification.=C2=A0 It is possible that a = specification will only want to use the 64-bit floating point number = format because it really simplifies the application even if it makes the = encoded format longer.

 

In sort, I = do not believe that the rules should be extended beyond how an encoding = works for a single encoded data format.

 

Jim

 

 

From: CBOR = [mailto:cbor-bounces@ietf.org] On Behalf Of Jeffrey = Yasskin
Sent: Monday, January 8, 2018 10:34 AM
To: = Jeffrey Yasskin <jyasskin@chromium.org>
Cc: = cbor@ietf.org; Carsten Bormann <cabo@tzi.org>
Subject: = Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested = Canonicalization

 

Now that we're past the holidays, are = there more comments on https://github.com/cbor-wg/CBORbis/pull/9?

On Fri, Dec 22, 2017 at 3:56 PM Jeffrey Yasskin <jyasskin@chromium.org> = wrote:

I don't think https://github.com/cbor-wg/CBORbis/pull/9 allo= ws anything that RFC7049 didn't, which is the meaning I get from = "open this up". 

 

We *could* move this (all of section 3?) to a separate = document, but I haven't seen anyone say that we need to. A downside of = moving section 3 to another RFC is that it'll make it harder to find. = Someone authoritative (Francesca?) should just make this call so = that we can stop angsting about it.

 

I'm generally happy to change exactly which examples = demonstrate that protocol designers need to think about canonicalization = even if they start from the core canonicalization requirements. I'd = appreciate a concrete statement of which examples to use = though.

 

Once we add floating values, the type of a field = matters in defining its canonicalization. A float64 field only needs to = canonicalize NaN. A float16/float32/float64 field needs to canonicalize = to either the smallest or largest type. An int/float field needs to = again canonicalize toward or away from int. A bigint field needs to = prefer either a fixed-length (useful for cryptographic signatures) or = the shortest representation. A decfrac/bigfloat/number field = has an even more complex problem. I don't personally have enough = examples of existing canonicalized CBOR-based protocols to make any = confident recommendations here. If the list gives me some, along with = the field experience that justifies them, I'm happy to write them down = in my patch.

 

Jeffrey

 

On Fri, Dec 22, 2017 at 2:23 PM Carsten Bormann <cabo@tzi.org> = wrote:

Hi Jeffrey,

quick reactions after = a first skim:

I=E2=80=99m not sure the direction should be to = open this up; I think the recommendations should become more narrow as = we learn about the practical issues.

We could write a separate = document on the preferred c14n so we can keep this out of the main = document.

I don=E2=80=99t think we necessarily want to encourage = cross-over between int and float, so I think the =E2=80=9Cshortest = float=E2=80=9D rule should be applied independent of whether that = cross-over is desired.

Why keep the =E2=80=9Cshortest = int=E2=80=9D rule less well defined for protocols that use = bignums?  It should apply there as well, i.e., use bignums only for = integers too large for the major type 0/1 = formats.

Gr=C3=BC=C3=9Fe, Carsten


> On Dec 22, = 2017, at 23:13, Jeffrey Yasskin <jyasskin@chromium.org> wrote:
>
> = On Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann <cabo@tzi.org> = wrote:
> On Nov 30, 2017, at 23:14, Jeffrey Yasskin <jyasskin@chromium.org> wrote:
> = >
> > Belatedly, I've discovered a user of = "canonical" CBOR who's proposing a different map order than = the RFC suggests: https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fi= do-client-to-authenticator-protocol-v2.0-rd-20170927.html#message-encodin= g. (Note that this isn't a final standard yet and may = change.)
>
> I looked at the spec = referenced.
>
> So they essentially = add
>
>              =    =E2=80=A2 If the major types are different, the one with = the lower value in numerical order sorts earlier.
>
> as a = major sorting rule before the existing RFC 7049 canonicalization = rules:
>
>              =    =E2=80=A2 If two keys have different lengths, the shorter = one sorts earlier;
>            =      =E2=80=A2 If two keys have the same length, the one = with the lower value in (byte-wise) lexical order sorts = earlier.
>
> This is different from simply going for = byte-wise lexicographic (memcmp order(*)), which effectively would get = us the first rule as the major sorting order already, but get rid of the = length-based second rule (first rule in Section 3.9 of RFC = 7049).
>
> I=E2=80=99ve come to see the putting the length = comparison rule early in 3.9 as a major regression.
> One of the = objectives when designing the CBOR serialization was not to repeat one = big mistake that ASN.1 BER makes: to make overall lengths of complex = composite items visible/important in the encoding of the next higher = composite.
> Here, we are doing just that.  = D=E2=80=99oh.
>
> > This is justified by the RFC saying = that "Those protocols are free to define what they mean by a = canonical format and what encoders and decoders are expected to = do.  This section lists some suggestions for such protocols." = That is (as Jim said), the RFC doesn't specify "canonical" = CBOR: it just provides an option for higher-level protocols to do = so.
>
> Right.  So the change would be to mention two = options for this, the old canonical, and the saner (memcmp order) = canonical.  Now the next step is finding names for legacy = canonical/saner canonical.  We then have to decide whether we turn = this into a separate document, at Proposed Standard level, or believe = that adding another suggestion to 3.9 is essentially a bug fix and can = be done in the Standard level document.
>
> > The use of = a different order in CTAP is going to either force its implementers to = write custom CBOR encoders and decoders or require the generic encoders = to take a configuration option for the map order. If the generic = encoders take an option, then it stops being an issue for CBORbis to = suggest a different order.
>
> Right.  So I think you = are saying we get to fix this.
>
> I've tried to implement = this in https://github.com/cbor-wg/CBORbis/pull/9. I = defined a core set of rules so that other specs can use them by = reference, gave several examples of protocols that will need to extend = the rules, and defined a second set of rules that match the canonical = order that RFC7049 suggested.
>
> Do folks like this = direction?
>
> I don't have a strong opinion about which = document should hold the canonicalization rules. Can we ask the IESG = which they'd prefer?
>
> = Jeffrey

<= /div>
------=_NextPart_000_000C_01D388BD.02FB0C80-- From nobody Mon Jan 8 21:45:16 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E643A124BFA for ; Mon, 8 Jan 2018 21:45:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzmeSijib-Dx for ; Mon, 8 Jan 2018 21:45:11 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0119.outbound.protection.outlook.com [104.47.41.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 682D51200C1 for ; Mon, 8 Jan 2018 21:45:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=i1i4NGAyVbuS72lq2C1wE1/NB6S8Hlw6J1S/0L9MQFo=; b=GslNlOok1PDcHVlYVrfG0BJXDZSXxCuV3zIIqQK+UvKq9oupI1wfiI5NJgdXu5Gmh/POfTtEy5WUeGzF+IKJejBLVAsrlYORezPULj466OIaQXS8kdMjBFJnUiXFTxEuP3gE0r4peo22ULJF1tp8KPfqIeqHWRMMfN/6tE4ziGk= Received: from SN6PR2101MB0943.namprd21.prod.outlook.com (52.132.114.20) by SN6PR2101MB1119.namprd21.prod.outlook.com (52.132.115.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.407.2; Tue, 9 Jan 2018 05:45:08 +0000 Received: from SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::d056:85dd:24c8:9336]) by SN6PR2101MB0943.namprd21.prod.outlook.com ([fe80::d056:85dd:24c8:9336%3]) with mapi id 15.20.0428.002; Tue, 9 Jan 2018 05:45:08 +0000 From: Mike Jones To: 'Jeffrey Yasskin' , Jim Schaad CC: "cbor@ietf.org" , 'Carsten Bormann' Thread-Topic: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization Thread-Index: AQHTPcwDtdWS7sZnB0ilFou4NB6jy6Mt1Y0AgAQxKgCAHmH9AIAAArMAgAAZ+ICAGl1zAIAAobSAgAAZ5UI= Date: Tue, 9 Jan 2018 05:45:08 +0000 Message-ID: References: <012801d32f2e$a95aaf10$fc100d30$@augustcellars.com> <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> <1FED1F56-93BA-410F-B7C4-E83D31E7CC4E@tzi.org> <5D1F5ECC-C7DA-427F-B8A1-2040EA75FDE6@tzi.org> , <000b01d38900$111d1400$33573c00$@augustcellars.com> In-Reply-To: <000b01d38900$111d1400$33573c00$@augustcellars.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [104.208.33.187] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; SN6PR2101MB1119; 7:OesqvOR89aRR8ShyUCqouLWCX+xL416ro6OcP422ImEOmHwlxX4Y+WrZspVTPsHgv6VxXUMDEQE74mRtEVvMPqr1eSJBClx2zKPToZp8f9iN5FcdjLbmSPEHfCl2GD5OK5qFZaeev5c6VkdIX6DW5qnKVjI2qB1e1T39bM4z6IOQHL5rw+heMwLNwLj9frxLBmV0rtlNs3BbZei6kIyNLSY/GADsdcPGgWtjtZMpfL1nH5qmi6CAewJdrPbU8IcY x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 3fab5df6-04cf-4b2b-caac-08d5572424b5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020040)(4652020)(48565401081)(4534070)(4602075)(4627166)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:SN6PR2101MB1119; x-ms-traffictypediagnostic: SN6PR2101MB1119: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040470)(2401047)(8121501046)(5005006)(10201501046)(3231023)(944501110)(93006095)(93001095)(3002001)(6055026)(61426038)(61427038)(6041268)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:SN6PR2101MB1119; BCL:0; PCL:0; RULEID:(100000803120)(100110400114); SRVR:SN6PR2101MB1119; x-forefront-prvs: 0547116B72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(396003)(39380400002)(39860400002)(189003)(199004)(24454002)(86362001)(53936002)(5660300001)(3846002)(6116002)(230783001)(86612001)(14454004)(2950100002)(102836004)(606006)(6346003)(66066001)(7736002)(97736004)(74316002)(5250100002)(2900100001)(6436002)(22452003)(59450400001)(72206003)(3660700001)(93886005)(478600001)(3280700002)(10090500001)(10290500003)(76176011)(110136005)(316002)(54906003)(966005)(6306002)(8936002)(106356001)(236005)(9686003)(54896002)(81156014)(33656002)(68736007)(81166006)(55016002)(25786009)(105586002)(7696005)(53546011)(229853002)(8676002)(4326008)(6506007)(6246003)(2906002)(8990500004)(99286004); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB1119; H:SN6PR2101MB0943.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com; x-microsoft-antispam-message-info: fAdLOMoOmucbaVCwGA6gbr5qHLg63U+VYubVsYdRn3BpGoUYPkKkkauo7peaWF14lAB/IggKOIp5JT2q0CETdA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN6PR2101MB094385E3B32E9868A665B708F5100SN6PR2101MB0943_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3fab5df6-04cf-4b2b-caac-08d5572424b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jan 2018 05:45:08.7424 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB1119 Archived-At: Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jan 2018 05:45:15 -0000 --_000_SN6PR2101MB094385E3B32E9868A665B708F5100SN6PR2101MB0943_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 ________________________________ From: CBOR on behalf of Jim Schaad Sent: Monday, January 8, 2018 8:12:27 PM To: 'Jeffrey Yasskin' Cc: cbor@ietf.org; 'Carsten Bormann' Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canon= icalization I did not like the idea of changing the types of items when doing canonical= ization. I want to look just at what is given to me and thus do not like t= hings like a floating point number may be encoded as an any of a number of = different formats. The choice of what an item is encoded as in terms of a = floating point number is a function of the document specification and not t= he canonicalization encoding format. For things like big numbers, the enco= ding should not be modified because the leading characters have been chosen= by the application for a specific reason. Consider the leading padding th= at is part of a public key in cryptography where the length of the value is= of equal or greater importance that the fact that is has leading 0 or 0xff= bytes. The rules for mapping between the data model and the encoding are = as much up to the protocol specification as they are for the CBOR specifica= tion. It is possible that a specification will only want to use the 64-bit= floating point number format because it really simplifies the application = even if it makes the encoded format longer. In sort, I do not believe that the rules should be extended beyond how an e= ncoding works for a single encoded data format. Jim From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Jeffrey Yasskin Sent: Monday, January 8, 2018 10:34 AM To: Jeffrey Yasskin Cc: cbor@ietf.org; Carsten Bormann Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canon= icalization Now that we're past the holidays, are there more comments on https://github= .com/cbor-wg/CBORbis/pull/9? On Fri, Dec 22, 2017 at 3:56 PM Jeffrey Yasskin > wrote: I don't think https://github.com/cbor-wg/CBORbis/pull/9 allows anything tha= t RFC7049 didn't, which is the meaning I get from "open this up". We *could* move this (all of section 3?) to a separate document, but I have= n't seen anyone say that we need to. A downside of moving section 3 to anot= her RFC is that it'll make it harder to find. Someone authoritative (France= sca?) should just make this call so that we can stop angsting about it. I'm generally happy to change exactly which examples demonstrate that proto= col designers need to think about canonicalization even if they start from = the core canonicalization requirements. I'd appreciate a concrete statement= of which examples to use though. Once we add floating values, the type of a field matters in defining its ca= nonicalization. A float64 field only needs to canonicalize NaN. A float16/f= loat32/float64 field needs to canonicalize to either the smallest or larges= t type. An int/float field needs to again canonicalize toward or away from = int. A bigint field needs to prefer either a fixed-length (useful for crypt= ographic signatures) or the shortest representation. A decfrac/bigfloat/num= ber field has an even more complex problem. I don't personally have enough = examples of existing canonicalized CBOR-based protocols to make any confide= nt recommendations here. If the list gives me some, along with the field ex= perience that justifies them, I'm happy to write them down in my patch. Jeffrey On Fri, Dec 22, 2017 at 2:23 PM Carsten Bormann > wrote: Hi Jeffrey, quick reactions after a first skim: I=92m not sure the direction should be to open this up; I think the recomme= ndations should become more narrow as we learn about the practical issues. We could write a separate document on the preferred c14n so we can keep thi= s out of the main document. I don=92t think we necessarily want to encourage cross-over between int and= float, so I think the =93shortest float=94 rule should be applied independ= ent of whether that cross-over is desired. Why keep the =93shortest int=94 rule less well defined for protocols that u= se bignums? It should apply there as well, i.e., use bignums only for inte= gers too large for the major type 0/1 formats. Gr=FC=DFe, Carsten > On Dec 22, 2017, at 23:13, Jeffrey Yasskin > wrote: > > On Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann > wrote: > On Nov 30, 2017, at 23:14, Jeffrey Yasskin > wrote: > > > > Belatedly, I've discovered a user of "canonical" CBOR who's proposing a= different map order than the RFC suggests: https://fidoalliance.org/specs/= fido-v2.0-rd-20170927/fido-client-to-authenticator-protocol-v2.0-rd-2017092= 7.html#message-encoding. (Note that this isn't a final standard yet and may= change.) > > I looked at the spec referenced. > > So they essentially add > > =95 If the major types are different, the one with the lo= wer value in numerical order sorts earlier. > > as a major sorting rule before the existing RFC 7049 canonicalization rul= es: > > =95 If two keys have different lengths, the shorter one s= orts earlier; > =95 If two keys have the same length, the one with the lo= wer value in (byte-wise) lexical order sorts earlier. > > This is different from simply going for byte-wise lexicographic (memcmp o= rder(*)), which effectively would get us the first rule as the major sortin= g order already, but get rid of the length-based second rule (first rule in= Section 3.9 of RFC 7049). > > I=92ve come to see the putting the length comparison rule early in 3.9 as= a major regression. > One of the objectives when designing the CBOR serialization was not to re= peat one big mistake that ASN.1 BER makes: to make overall lengths of compl= ex composite items visible/important in the encoding of the next higher com= posite. > Here, we are doing just that. D=92oh. > > > This is justified by the RFC saying that "Those protocols are free to d= efine what they mean by a canonical format and what encoders and decoders a= re expected to do. This section lists some suggestions for such protocols.= " That is (as Jim said), the RFC doesn't specify "canonical" CBOR: it just = provides an option for higher-level protocols to do so. > > Right. So the change would be to mention two options for this, the old c= anonical, and the saner (memcmp order) canonical. Now the next step is fin= ding names for legacy canonical/saner canonical. We then have to decide wh= ether we turn this into a separate document, at Proposed Standard level, or= believe that adding another suggestion to 3.9 is essentially a bug fix and= can be done in the Standard level document. > > > The use of a different order in CTAP is going to either force its imple= menters to write custom CBOR encoders and decoders or require the generic e= ncoders to take a configuration option for the map order. If the generic en= coders take an option, then it stops being an issue for CBORbis to suggest = a different order. > > Right. So I think you are saying we get to fix this. > > I've tried to implement this in https://github.com/cbor-wg/CBORbis/pull/9= . I defined a core set of rules so that other specs can use them by referen= ce, gave several examples of protocols that will need to extend the rules, = and defined a second set of rules that match the canonical order that RFC70= 49 suggested. > > Do folks like this direction? > > I don't have a strong opinion about which document should hold the canoni= calization rules. Can we ask the IESG which they'd prefer? > > Jeffrey --_000_SN6PR2101MB094385E3B32E9868A665B708F5100SN6PR2101MB0943_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
+1
From: CBOR <cbor-bounces= @ietf.org> on behalf of Jim Schaad <ietf@augustcellars.com>
Sent: Monday, January 8, 2018 8:12:27 PM
To: 'Jeffrey Yasskin'
Cc: cbor@ietf.org; 'Carsten Bormann'
Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggeste= d Canonicalization
 

I did not like the idea of changing the types of ite= ms when doing canonicalization.  I want to look just at what is given = to me and thus do not like things like a floating point number may be encod= ed as an any of a number of different formats.  The choice of what an item is encoded as in terms of a floating point numb= er is a function of the document specification and not the canonicalization= encoding format.  For things like big numbers, the encoding should no= t be modified because the leading characters have been chosen by the application for a specific reason.  Consider = the leading padding that is part of a public key in cryptography where the = length of the value is of equal or greater importance that the fact that is= has leading 0 or 0xff bytes.  The rules for mapping between the data model and the encoding are as much up to the = protocol specification as they are for the CBOR specification.  It is = possible that a specification will only want to use the 64-bit floating poi= nt number format because it really simplifies the application even if it makes the encoded format longer.

 

In sort, I do not believe that the rules should be e= xtended beyond how an encoding works for a single encoded data format.

 

Jim

 

 

From: CBOR [mailto:cbor-bounces@ietf.org] = On Behalf Of Jeffrey Yasskin
Sent: Monday, January 8, 2018 10:34 AM
To: Jeffrey Yasskin <jyasskin@chromium.org>
Cc: cbor@ietf.org; Carsten Bormann <cabo@tzi.org>
Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggeste= d Canonicalization

 

Now that we're past t= he holidays, are there more comments on h= ttps://github.com/cbor-wg/CBORbis/pull/9?

On Fri, Dec 22, 2017 at 3:56 PM Jeffrey Yasskin <= jyasskin@chromium.org> wrot= e:

I don't think https://github.com/cbor-wg/CBORbis/pull/9 allows anything that RFC= 7049 didn't, which is the meaning I get from "open this up". = ;

 

We *could* move this (all of section 3?) to a separa= te document, but I haven't seen anyone say that we need to. A downside of m= oving section 3 to another RFC is that it'll make it harder to find. Someon= e authoritative (Francesca?) should just make this call so that we can stop angsting about it.

 

I'm generally happy to change exactly which examples= demonstrate that protocol designers need to think about canonicalization e= ven if they start from the core canonicalization requirements. I'd apprecia= te a concrete statement of which examples to use though.

 

Once we add floating values, the type of a field mat= ters in defining its canonicalization. A float64 field only needs to canoni= calize NaN. A float16/float32/float64 field needs to canonicalize to either= the smallest or largest type. An int/float field needs to again canonicalize toward or away from int. A big= int field needs to prefer either a fixed-length (useful for cryptographic signatures) or the short= est representation. A decfrac/bigfloat/number field has an even more comple= x problem. I don't personally have enough examples of existing canonicalize= d CBOR-based protocols to make any confident recommendations here. If the list gives me some, along with the field expe= rience that justifies them, I'm happy to write them down in my patch.

 

Jeffrey

 

On Fri, Dec 22, 2017 at 2:23 PM Carsten Bormann <= cabo@tzi.org> wrot= e:

Hi Jeffrey,

quick reactions after a first skim:

I=92m not sure the direction should be to open this up; I think the recomme= ndations should become more narrow as we learn about the practical issues.<= br>
We could write a separate document on the preferred c14n so we can keep thi= s out of the main document.

I don=92t think we necessarily want to encourage cross-over between int and= float, so I think the =93shortest float=94 rule should be applied independ= ent of whether that cross-over is desired.

Why keep the =93shortest int=94 rule less well defined for protocols that u= se bignums?  It should apply there as well, i.e., use bignums only for= integers too large for the major type 0/1 formats.

Gr=FC=DFe, Carsten


> On Dec 22, 2017, at 23:13, Jeffrey Yasskin <jyasskin@chromium.org> wrote: >
> On Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann <cabo@tzi.org> wrote:
> On Nov 30, 2017, at 23:14, Jeffrey Yasskin <jyasskin@chromium.org> wrote: > >
> > Belatedly, I've discovered a user of "canonical" CBOR w= ho's proposing a different map order than the RFC suggests: https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-authent= icator-protocol-v2.0-rd-20170927.html#message-encoding. (Note that this= isn't a final standard yet and may change.)
>
> I looked at the spec referenced.
>
> So they essentially add
>
>                 =95 If th= e major types are different, the one with the lower value in numerical orde= r sorts earlier.
>
> as a major sorting rule before the existing RFC 7049 canonicalization = rules:
>
>                 =95 If tw= o keys have different lengths, the shorter one sorts earlier;
>                 =95 If tw= o keys have the same length, the one with the lower value in (byte-wise) le= xical order sorts earlier.
>
> This is different from simply going for byte-wise lexicographic (memcm= p order(*)), which effectively would get us the first rule as the major sor= ting order already, but get rid of the length-based second rule (first rule= in Section 3.9 of RFC 7049).
>
> I=92ve come to see the putting the length comparison rule early in 3.9= as a major regression.
> One of the objectives when designing the CBOR serialization was not to= repeat one big mistake that ASN.1 BER makes: to make overall lengths of co= mplex composite items visible/important in the encoding of the next higher = composite.
> Here, we are doing just that.  D=92oh.
>
> > This is justified by the RFC saying that "Those protocols ar= e free to define what they mean by a canonical format and what encoders and= decoders are expected to do.  This section lists some suggestions for= such protocols." That is (as Jim said), the RFC doesn't specify "canonical" CBOR: it just provides an option for= higher-level protocols to do so.
>
> Right.  So the change would be to mention two options for this, t= he old canonical, and the saner (memcmp order) canonical.  Now the nex= t step is finding names for legacy canonical/saner canonical.  We then= have to decide whether we turn this into a separate document, at Proposed Standard level, or believe that adding another sugge= stion to 3.9 is essentially a bug fix and can be done in the Standard level= document.
>
> > The use of a different order in CTAP is going to either force its= implementers to write custom CBOR encoders and decoders or require the gen= eric encoders to take a configuration option for the map order. If the gene= ric encoders take an option, then it stops being an issue for CBORbis to suggest a different order.
>
> Right.  So I think you are saying we get to fix this.
>
> I've tried to implement this in https://github.com/cbor-wg/CBORbis/pull/9. I defined a core set of rule= s so that other specs can use them by reference, gave several examples of p= rotocols that will need to extend the rules, and defined a second set of ru= les that match the canonical order that RFC7049 suggested.
>
> Do folks like this direction?
>
> I don't have a strong opinion about which document should hold the can= onicalization rules. Can we ask the IESG which they'd prefer?
>
> Jeffrey

--_000_SN6PR2101MB094385E3B32E9868A665B708F5100SN6PR2101MB0943_-- From nobody Tue Jan 9 22:25:02 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DD691200B9 for ; Tue, 9 Jan 2018 22:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2dKNJ1NDQ5V for ; Tue, 9 Jan 2018 22:24:59 -0800 (PST) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC72A126CC4 for ; Tue, 9 Jan 2018 22:24:58 -0800 (PST) Received: by mail-io0-x22a.google.com with SMTP id i143so21198549ioa.3 for ; Tue, 09 Jan 2018 22:24:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gYdhTwcs8xeGtIWjt9uthz+Aq2AxCVMcOZaYw1r2bMw=; b=ggJ6m9tX+L2eJasdvC+1HoAxDAbcOwifc89PGMSj2nrO76QTYkk5T8/tt+cw1wzre2 ZOXZlnXzs/0jTiSpFeDgBt/ZQVgaXNxyOotCpl2xucHkHCA/KCO94ksWsNbRDOq/8OpG jiS084IcYnJDVk/lKa5pvANPDuYg3PRQuJr6w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gYdhTwcs8xeGtIWjt9uthz+Aq2AxCVMcOZaYw1r2bMw=; b=lFQtNovt7ZVaxgF/ae7gYJBZVGRVXHhjD5sYxO71md6EEp7aoDkIqAcn04llbM+1e/ 4kAp8je4TYjTiXgV/qaP1sTVWRdg21dSFHtjzBUUg8ZinmANuyEx3GtVTmJr1tGyR3Ow fOulxj2iMDmrb3Ej/m4nj7TaQJsKPlpcJx0DQZkc8xP3Oqq/UgEGoyCCytEKkJO1WjoE kzTEoxswZcaKfNhiSbt7as0ExIoQIChVfyJfGFZtujb69ZTmzT8K2HWtqeOyNGu4EhbO 2rWRBizJtqxDkLp19wm/78VCu78duXSdRNtwGli21CKvWEa+PiXO5zCRlN1lgCbhIJXB pmfg== X-Gm-Message-State: AKGB3mKWi4WnpDsab7dNtVZYBgj/u246Xg2uWP+IDjacrK7BRLzDlOqV QAgt5QKOg7qwE+g0vvCRaJB8pOh9YQ3OnmJaWrUBKQ== X-Google-Smtp-Source: ACJfBovXbuEdtEcltj7nqwlV7s2uy+QVTnBaLgPQi4TddkMOqPn0kGSbEl8uQepQkGUuBYpf6k5UXdDK6KeeS/whT7A= X-Received: by 10.107.183.149 with SMTP id h143mr18380305iof.166.1515565497711; Tue, 09 Jan 2018 22:24:57 -0800 (PST) MIME-Version: 1.0 References: <012801d32f2e$a95aaf10$fc100d30$@augustcellars.com> <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> <1FED1F56-93BA-410F-B7C4-E83D31E7CC4E@tzi.org> <5D1F5ECC-C7DA-427F-B8A1-2040EA75FDE6@tzi.org> <000b01d38900$111d1400$33573c00$@augustcellars.com> In-Reply-To: <000b01d38900$111d1400$33573c00$@augustcellars.com> From: Jeffrey Yasskin Date: Wed, 10 Jan 2018 06:24:45 +0000 Message-ID: To: ietf@augustcellars.com Cc: Jeffrey Yasskin , cbor@ietf.org, Carsten Bormann Content-Type: multipart/alternative; boundary="94eb2c0cd28c20863105626617be" Archived-At: Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 06:25:02 -0000 --94eb2c0cd28c20863105626617be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Does that mean you support the PR as-is, without the changes Carsten suggested? On Mon, Jan 8, 2018 at 8:12 PM Jim Schaad wrote: > I did not like the idea of changing the types of items when doing > canonicalization. I want to look just at what is given to me and thus do > not like things like a floating point number may be encoded as an any of = a > number of different formats. The choice of what an item is encoded as in > terms of a floating point number is a function of the document > specification and not the canonicalization encoding format. For things > like big numbers, the encoding should not be modified because the leading > characters have been chosen by the application for a specific reason. > Consider the leading padding that is part of a public key in cryptography > where the length of the value is of equal or greater importance that the > fact that is has leading 0 or 0xff bytes. The rules for mapping between > the data model and the encoding are as much up to the protocol > specification as they are for the CBOR specification. It is possible tha= t > a specification will only want to use the 64-bit floating point number > format because it really simplifies the application even if it makes the > encoded format longer. > > > > In sort, I do not believe that the rules should be extended beyond how an > encoding works for a single encoded data format. > > > > Jim > > > > > > *From:* CBOR [mailto:cbor-bounces@ietf.org] *On Behalf Of *Jeffrey Yasski= n > *Sent:* Monday, January 8, 2018 10:34 AM > *To:* Jeffrey Yasskin > *Cc:* cbor@ietf.org; Carsten Bormann > *Subject:* Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested > Canonicalization > > > > Now that we're past the holidays, are there more comments on > https://github.com/cbor-wg/CBORbis/pull/9? > > On Fri, Dec 22, 2017 at 3:56 PM Jeffrey Yasskin > wrote: > > I don't think https://github.com/cbor-wg/CBORbis/pull/9 allows anything > that RFC7049 didn't, which is the meaning I get from "open this up". > > > > We *could* move this (all of section 3?) to a separate document, but I > haven't seen anyone say that we need to. A downside of moving section 3 t= o > another RFC is that it'll make it harder to find. Someone authoritative > (Francesca?) should just make this call so that we can stop angsting abou= t > it. > > > > I'm generally happy to change exactly which examples demonstrate that > protocol designers need to think about canonicalization even if they star= t > from the core canonicalization requirements. I'd appreciate a concrete > statement of which examples to use though. > > > > Once we add floating values, the type of a field matters in defining its > canonicalization. A float64 field only needs to canonicalize NaN. A > float16/float32/float64 field needs to canonicalize to either the smalles= t > or largest type. An int/float field needs to again canonicalize toward or > away from int. A bigint field needs to prefer either a fixed-length > (useful for cryptographic signatures) or the shortest representation. A > decfrac/bigfloat/number field has an even more complex problem. I don't > personally have enough examples of existing canonicalized CBOR-based > protocols to make any confident recommendations here. If the list gives m= e > some, along with the field experience that justifies them, I'm happy to > write them down in my patch. > > > > Jeffrey > > > > On Fri, Dec 22, 2017 at 2:23 PM Carsten Bormann wrote: > > Hi Jeffrey, > > quick reactions after a first skim: > > I=E2=80=99m not sure the direction should be to open this up; I think the > recommendations should become more narrow as we learn about the practical > issues. > > We could write a separate document on the preferred c14n so we can keep > this out of the main document. > > I don=E2=80=99t think we necessarily want to encourage cross-over between= int and > float, so I think the =E2=80=9Cshortest float=E2=80=9D rule should be app= lied independent > of whether that cross-over is desired. > > Why keep the =E2=80=9Cshortest int=E2=80=9D rule less well defined for pr= otocols that use > bignums? It should apply there as well, i.e., use bignums only for > integers too large for the major type 0/1 formats. > > Gr=C3=BC=C3=9Fe, Carsten > > > > On Dec 22, 2017, at 23:13, Jeffrey Yasskin > wrote: > > > > On Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann wrote: > > On Nov 30, 2017, at 23:14, Jeffrey Yasskin > wrote: > > > > > > Belatedly, I've discovered a user of "canonical" CBOR who's proposing > a different map order than the RFC suggests: > https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-authe= nticator-protocol-v2.0-rd-20170927.html#message-encoding. > (Note that this isn't a final standard yet and may change.) > > > > I looked at the spec referenced. > > > > So they essentially add > > > > =E2=80=A2 If the major types are different, the one wit= h the > lower value in numerical order sorts earlier. > > > > as a major sorting rule before the existing RFC 7049 canonicalization > rules: > > > > =E2=80=A2 If two keys have different lengths, the short= er one > sorts earlier; > > =E2=80=A2 If two keys have the same length, the one wit= h the > lower value in (byte-wise) lexical order sorts earlier. > > > > This is different from simply going for byte-wise lexicographic (memcmp > order(*)), which effectively would get us the first rule as the major > sorting order already, but get rid of the length-based second rule (first > rule in Section 3.9 of RFC 7049). > > > > I=E2=80=99ve come to see the putting the length comparison rule early i= n 3.9 as > a major regression. > > One of the objectives when designing the CBOR serialization was not to > repeat one big mistake that ASN.1 BER makes: to make overall lengths of > complex composite items visible/important in the encoding of the next > higher composite. > > Here, we are doing just that. D=E2=80=99oh. > > > > > This is justified by the RFC saying that "Those protocols are free to > define what they mean by a canonical format and what encoders and decoder= s > are expected to do. This section lists some suggestions for such > protocols." That is (as Jim said), the RFC doesn't specify "canonical" > CBOR: it just provides an option for higher-level protocols to do so. > > > > Right. So the change would be to mention two options for this, the old > canonical, and the saner (memcmp order) canonical. Now the next step is > finding names for legacy canonical/saner canonical. We then have to deci= de > whether we turn this into a separate document, at Proposed Standard level= , > or believe that adding another suggestion to 3.9 is essentially a bug fix > and can be done in the Standard level document. > > > > > The use of a different order in CTAP is going to either force its > implementers to write custom CBOR encoders and decoders or require the > generic encoders to take a configuration option for the map order. If the > generic encoders take an option, then it stops being an issue for CBORbis > to suggest a different order. > > > > Right. So I think you are saying we get to fix this. > > > > I've tried to implement this in > https://github.com/cbor-wg/CBORbis/pull/9. I defined a core set of rules > so that other specs can use them by reference, gave several examples of > protocols that will need to extend the rules, and defined a second set of > rules that match the canonical order that RFC7049 suggested. > > > > Do folks like this direction? > > > > I don't have a strong opinion about which document should hold the > canonicalization rules. Can we ask the IESG which they'd prefer? > > > > Jeffrey > > --94eb2c0cd28c20863105626617be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Does that mean you support the PR as-is, without the chang= es Carsten suggested?

On= Mon, Jan 8, 2018 at 8:12 PM Jim Schaad <ietf@augustcellars.com> wrote:

I did not li= ke the idea of changing the types of items when doing canonicalization.=C2= =A0 I want to look just at what is given to me and thus do not like things = like a floating point number may be encoded as an any of a number of differ= ent formats.=C2=A0 The choice of what an item is encoded as in terms of a f= loating point number is a function of the document specification and not th= e canonicalization encoding format.=C2=A0 For things like big numbers, the = encoding should not be modified because the leading characters have been ch= osen by the application for a specific reason.=C2=A0 Consider the leading p= adding that is part of a public key in cryptography where the length of the= value is of equal or greater importance that the fact that is has leading = 0 or 0xff bytes.=C2=A0 The rules for mapping between the data model and the= encoding are as much up to the protocol specification as they are for the = CBOR specification.=C2=A0 It is possible that a specification will only wan= t to use the 64-bit floating point number format because it really simplifi= es the application even if it makes the encoded format longer.

=C2=A0

= In sort, I do not believe that the rules should be extended beyond how an e= ncoding works for a single encoded data format.

=C2=A0

Jim=

=C2=A0

=C2=A0

F= rom: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Jeffrey Yasskin
= Sent: Monday, January 8, 2018 10:34 AM
To: Jeffrey Yasskin &l= t;jyasskin@chrom= ium.org>
Cc: cbor@ietf.org; Carsten Bormann <cabo@tzi.org>
Subject: Re: [Cbor] [cor= e] draft-ietf-cbor-7049bis - Change suggested Canonicalization

=C2=A0

Now that we're past the= holidays, are there more comments on=C2=A0https:= //github.com/cbor-wg/CBORbis/pull/9?

On Fri, Dec 2= 2, 2017 at 3:56 PM Jeffrey Yasskin <jyasskin@chromium.org> wrote:

= =C2=A0

Hi Jeffrey,

quick reactions after a first skim:

I=E2= =80=99m not sure the direction should be to open this up; I think the recom= mendations should become more narrow as we learn about the practical issues= .

We could write a separate document on the preferred c14n so we can= keep this out of the main document.

I don=E2=80=99t think we necess= arily want to encourage cross-over between int and float, so I think the = =E2=80=9Cshortest float=E2=80=9D rule should be applied independent of whet= her that cross-over is desired.

Why keep the =E2=80=9Cshortest int= =E2=80=9D rule less well defined for protocols that use bignums?=C2=A0 It s= hould apply there as well, i.e., use bignums only for integers too large fo= r the major type 0/1 formats.

Gr=C3=BC=C3=9Fe, Carsten


&g= t; On Dec 22, 2017, at 23:13, Jeffrey Yasskin <jyasskin@chromium.org> wrote:
&= gt;
> On Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann <cabo@tzi.org> wrote:
> O= n Nov 30, 2017, at 23:14, Jeffrey Yasskin <jyasskin@chromium.org> wrote:
> = >
> > Belatedly, I've discovered a user of "canonical&= quot; CBOR who's proposing a different map order than the RFC suggests:= https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-clien= t-to-authenticator-protocol-v2.0-rd-20170927.html#message-encoding. (No= te that this isn't a final standard yet and may change.)
>
>= ; I looked at the spec referenced.
>
> So they essentially add<= br>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0=E2=80=A2 If the major types are different, the one with the lower value= in numerical order sorts earlier.
>
> as a major sorting rule = before the existing RFC 7049 canonicalization rules:
>
>=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If two key= s have different lengths, the shorter one sorts earlier;
>=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If two keys h= ave the same length, the one with the lower value in (byte-wise) lexical or= der sorts earlier.
>
> This is different from simply going for = byte-wise lexicographic (memcmp order(*)), which effectively would get us t= he first rule as the major sorting order already, but get rid of the length= -based second rule (first rule in Section 3.9 of RFC 7049).
>
>= I=E2=80=99ve come to see the putting the length comparison rule early in 3= .9 as a major regression.
> One of the objectives when designing the = CBOR serialization was not to repeat one big mistake that ASN.1 BER makes: = to make overall lengths of complex composite items visible/important in the= encoding of the next higher composite.
> Here, we are doing just tha= t.=C2=A0 D=E2=80=99oh.
>
> > This is justified by the RFC sa= ying that "Those protocols are free to define what they mean by a cano= nical format and what encoders and decoders are expected to do.=C2=A0 This = section lists some suggestions for such protocols." That is (as Jim sa= id), the RFC doesn't specify "canonical" CBOR: it just provid= es an option for higher-level protocols to do so.
>
> Right.=C2= =A0 So the change would be to mention two options for this, the old canonic= al, and the saner (memcmp order) canonical.=C2=A0 Now the next step is find= ing names for legacy canonical/saner canonical.=C2=A0 We then have to decid= e whether we turn this into a separate document, at Proposed Standard level= , or believe that adding another suggestion to 3.9 is essentially a bug fix= and can be done in the Standard level document.
>
> > The u= se of a different order in CTAP is going to either force its implementers t= o write custom CBOR encoders and decoders or require the generic encoders t= o take a configuration option for the map order. If the generic encoders ta= ke an option, then it stops being an issue for CBORbis to suggest a differe= nt order.
>
> Right.=C2=A0 So I think you are saying we get to = fix this.
>
> I've tried to implement this in https://github.c= om/cbor-wg/CBORbis/pull/9. I defined a core set of rules so that other = specs can use them by reference, gave several examples of protocols that wi= ll need to extend the rules, and defined a second set of rules that match t= he canonical order that RFC7049 suggested.
>
> Do folks like th= is direction?
>
> I don't have a strong opinion about which= document should hold the canonicalization rules. Can we ask the IESG which= they'd prefer?
>
> Jeffrey

<= /div>
--94eb2c0cd28c20863105626617be-- From nobody Tue Jan 9 23:10:08 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 894F1126D46 for ; Tue, 9 Jan 2018 23:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L_8wOU6juDty for ; Tue, 9 Jan 2018 23:10:04 -0800 (PST) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A13124BFA for ; Tue, 9 Jan 2018 23:10:03 -0800 (PST) Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Jan 2018 23:08:29 -0800 From: Jim Schaad To: 'Jeffrey Yasskin' CC: , 'Carsten Bormann' References: <012801d32f2e$a95aaf10$fc100d30$@augustcellars.com> <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> <1FED1F56-93BA-410F-B7C4-E83D31E7CC4E@tzi.org> <5D1F5ECC-C7DA-427F-B8A1-2040EA75FDE6@tzi.org> <000b01d38900$111d1400$33573c00$@augustcellars.com> In-Reply-To: Date: Tue, 9 Jan 2018 23:09:53 -0800 Message-ID: <003001d389e2$04eef620$0ecce260$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0031_01D3899E.F6CF5FA0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLkcV5/cuYwYNvq7zdAWu7g9fdkoQDl1w1UAkkwjzoCc2JLLgGyH3OJAnAGOCgB7/DF0QHRbgWLAt0pUNwDLGw5BwHCAbzQAjX2JiUBgGPA+KCCohGA Content-Language: en-us X-Originating-IP: [73.180.8.170] Archived-At: Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 07:10:08 -0000 ------=_NextPart_000_0031_01D3899E.F6CF5FA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable No. =20 Look at what is at line 1328 in the diff and that is exactly what I am = talking about as should not be done. =20 Jim =20 =20 From: Jeffrey Yasskin [mailto:jyasskin@chromium.org]=20 Sent: Tuesday, January 9, 2018 10:25 PM To: ietf@augustcellars.com Cc: Jeffrey Yasskin ; cbor@ietf.org; Carsten = Bormann Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested = Canonicalization =20 Does that mean you support the PR as-is, without the changes Carsten = suggested? On Mon, Jan 8, 2018 at 8:12 PM Jim Schaad > wrote: I did not like the idea of changing the types of items when doing = canonicalization. I want to look just at what is given to me and thus = do not like things like a floating point number may be encoded as an any = of a number of different formats. The choice of what an item is encoded = as in terms of a floating point number is a function of the document = specification and not the canonicalization encoding format. For things = like big numbers, the encoding should not be modified because the = leading characters have been chosen by the application for a specific = reason. Consider the leading padding that is part of a public key in = cryptography where the length of the value is of equal or greater = importance that the fact that is has leading 0 or 0xff bytes. The rules = for mapping between the data model and the encoding are as much up to = the protocol specification as they are for the CBOR specification. It = is possible that a specification will only want to use the 64-bit = floating point number format because it really simplifies the = application even if it makes the encoded format longer. =20 In sort, I do not believe that the rules should be extended beyond how = an encoding works for a single encoded data format. =20 Jim =20 =20 From: CBOR [mailto:cbor-bounces@ietf.org = ] On Behalf Of Jeffrey Yasskin Sent: Monday, January 8, 2018 10:34 AM To: Jeffrey Yasskin > Cc: cbor@ietf.org ; Carsten Bormann > Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested = Canonicalization =20 Now that we're past the holidays, are there more comments on = = https://github.com/cbor-wg/CBORbis/pull/9? On Fri, Dec 22, 2017 at 3:56 PM Jeffrey Yasskin > wrote: I don't think https://github.com/cbor-wg/CBORbis/pull/9 allows anything = that RFC7049 didn't, which is the meaning I get from "open this up".=20 =20 We *could* move this (all of section 3?) to a separate document, but I = haven't seen anyone say that we need to. A downside of moving section 3 = to another RFC is that it'll make it harder to find. Someone = authoritative (Francesca?) should just make this call so that we can = stop angsting about it. =20 I'm generally happy to change exactly which examples demonstrate that = protocol designers need to think about canonicalization even if they = start from the core canonicalization requirements. I'd appreciate a = concrete statement of which examples to use though. =20 Once we add floating values, the type of a field matters in defining its = canonicalization. A float64 field only needs to canonicalize NaN. A = float16/float32/float64 field needs to canonicalize to either the = smallest or largest type. An int/float field needs to again canonicalize = toward or away from int. A bigint field needs to prefer either a = fixed-length (useful for cryptographic signatures) or the shortest = representation. A decfrac/bigfloat/number field has an even more complex = problem. I don't personally have enough examples of existing = canonicalized CBOR-based protocols to make any confident recommendations = here. If the list gives me some, along with the field experience that = justifies them, I'm happy to write them down in my patch. =20 Jeffrey =20 On Fri, Dec 22, 2017 at 2:23 PM Carsten Bormann > wrote: Hi Jeffrey, quick reactions after a first skim: I=E2=80=99m not sure the direction should be to open this up; I think = the recommendations should become more narrow as we learn about the = practical issues. We could write a separate document on the preferred c14n so we can keep = this out of the main document. I don=E2=80=99t think we necessarily want to encourage cross-over = between int and float, so I think the =E2=80=9Cshortest float=E2=80=9D = rule should be applied independent of whether that cross-over is = desired. Why keep the =E2=80=9Cshortest int=E2=80=9D rule less well defined for = protocols that use bignums? It should apply there as well, i.e., use = bignums only for integers too large for the major type 0/1 formats. Gr=C3=BC=C3=9Fe, Carsten > On Dec 22, 2017, at 23:13, Jeffrey Yasskin > wrote: > > On Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann > wrote: > On Nov 30, 2017, at 23:14, Jeffrey Yasskin > wrote: > > > > Belatedly, I've discovered a user of "canonical" CBOR who's = proposing a different map order than the RFC suggests: = https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-authe= nticator-protocol-v2.0-rd-20170927.html#message-encoding. (Note that = this isn't a final standard yet and may change.) > > I looked at the spec referenced. > > So they essentially add > > =E2=80=A2 If the major types are different, the one = with the lower value in numerical order sorts earlier. > > as a major sorting rule before the existing RFC 7049 canonicalization = rules: > > =E2=80=A2 If two keys have different lengths, the = shorter one sorts earlier; > =E2=80=A2 If two keys have the same length, the one = with the lower value in (byte-wise) lexical order sorts earlier. > > This is different from simply going for byte-wise lexicographic = (memcmp order(*)), which effectively would get us the first rule as the = major sorting order already, but get rid of the length-based second rule = (first rule in Section 3.9 of RFC 7049). > > I=E2=80=99ve come to see the putting the length comparison rule early = in 3.9 as a major regression. > One of the objectives when designing the CBOR serialization was not to = repeat one big mistake that ASN.1 BER makes: to make overall lengths of = complex composite items visible/important in the encoding of the next = higher composite. > Here, we are doing just that. D=E2=80=99oh. > > > This is justified by the RFC saying that "Those protocols are free = to define what they mean by a canonical format and what encoders and = decoders are expected to do. This section lists some suggestions for = such protocols." That is (as Jim said), the RFC doesn't specify = "canonical" CBOR: it just provides an option for higher-level protocols = to do so. > > Right. So the change would be to mention two options for this, the = old canonical, and the saner (memcmp order) canonical. Now the next = step is finding names for legacy canonical/saner canonical. We then = have to decide whether we turn this into a separate document, at = Proposed Standard level, or believe that adding another suggestion to = 3.9 is essentially a bug fix and can be done in the Standard level = document. > > > The use of a different order in CTAP is going to either force its = implementers to write custom CBOR encoders and decoders or require the = generic encoders to take a configuration option for the map order. If = the generic encoders take an option, then it stops being an issue for = CBORbis to suggest a different order. > > Right. So I think you are saying we get to fix this. > > I've tried to implement this in = https://github.com/cbor-wg/CBORbis/pull/9. I defined a core set of rules = so that other specs can use them by reference, gave several examples of = protocols that will need to extend the rules, and defined a second set = of rules that match the canonical order that RFC7049 suggested. > > Do folks like this direction? > > I don't have a strong opinion about which document should hold the = canonicalization rules. Can we ask the IESG which they'd prefer? > > Jeffrey ------=_NextPart_000_0031_01D3899E.F6CF5FA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

No.

 

Look at what = is at line 1328 in the diff and that is exactly what I am talking about = as should not be done.

 

Jim

 

 

From: = Jeffrey Yasskin [mailto:jyasskin@chromium.org]
Sent: Tuesday, = January 9, 2018 10:25 PM
To: = ietf@augustcellars.com
Cc: Jeffrey Yasskin = <jyasskin@chromium.org>; cbor@ietf.org; Carsten Bormann = <cabo@tzi.org>
Subject: Re: [Cbor] [core] = draft-ietf-cbor-7049bis - Change suggested = Canonicalization

 

Does that mean you support the PR as-is, = without the changes Carsten suggested?

On Mon, Jan 8, 2018 at 8:12 PM Jim Schaad <ietf@augustcellars.com> = wrote:

I did not = like the idea of changing the types of items when doing = canonicalization.  I want to look just at what is given to me and = thus do not like things like a floating point number may be encoded as = an any of a number of different formats.  The choice of what an = item is encoded as in terms of a floating point number is a function of = the document specification and not the canonicalization encoding = format.  For things like big numbers, the encoding should not be = modified because the leading characters have been chosen by the = application for a specific reason.  Consider the leading padding = that is part of a public key in cryptography where the length of the = value is of equal or greater importance that the fact that is has = leading 0 or 0xff bytes.  The rules for mapping between the data = model and the encoding are as much up to the protocol specification as = they are for the CBOR specification.  It is possible that a = specification will only want to use the 64-bit floating point number = format because it really simplifies the application even if it makes the = encoded format longer.

 <= /o:p>

In sort, I = do not believe that the rules should be extended beyond how an encoding = works for a single encoded data format.

 <= /o:p>

Jim

 <= /o:p>

 <= /o:p>

From:= CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Jeffrey = Yasskin
Sent: Monday, January 8, 2018 10:34 AM
To: = Jeffrey Yasskin <jyasskin@chromium.org>
Cc: cbor@ietf.org; = Carsten Bormann <cabo@tzi.org>
Subject: Re: [Cbor] = [core] draft-ietf-cbor-7049bis - Change suggested = Canonicalization

 <= /o:p>

Now that we're = past the holidays, are there more comments on https://github.com/cbor-wg/CBORbis/pull/9?

On Fri, Dec = 22, 2017 at 3:56 PM Jeffrey Yasskin <jyasskin@chromium.org> = wrote:

I don't = think https://github.com/cbor-wg/CBORbis/pull/9 allo= ws anything that RFC7049 didn't, which is the meaning I get from = "open this up". 

 <= /o:p>

We *could* = move this (all of section 3?) to a separate document, but I haven't seen = anyone say that we need to. A downside of moving section 3 to another = RFC is that it'll make it harder to find. Someone authoritative = (Francesca?) should just make this call so that we can stop = angsting about it.

 <= /o:p>

I'm = generally happy to change exactly which examples demonstrate that = protocol designers need to think about canonicalization even if they = start from the core canonicalization requirements. I'd appreciate a = concrete statement of which examples to use = though.

 <= /o:p>

Once we add = floating values, the type of a field matters in defining its = canonicalization. A float64 field only needs to canonicalize NaN. A = float16/float32/float64 field needs to canonicalize to either the = smallest or largest type. An int/float field needs to again canonicalize = toward or away from int. A bigint field needs to prefer either a fixed-length (useful for cryptographic signatures) or = the shortest representation. A decfrac/bigfloat/number field = has an even more complex problem. I don't personally have enough = examples of existing canonicalized CBOR-based protocols to make any = confident recommendations here. If the list gives me some, along with = the field experience that justifies them, I'm happy to write them down = in my patch.

 <= /o:p>

Jeffrey=

 <= /p>

On Fri, Dec = 22, 2017 at 2:23 PM Carsten Bormann <cabo@tzi.org> = wrote:

Hi = Jeffrey,

quick reactions after a first skim:

I=E2=80=99m = not sure the direction should be to open this up; I think the = recommendations should become more narrow as we learn about the = practical issues.

We could write a separate document on the = preferred c14n so we can keep this out of the main document.

I = don=E2=80=99t think we necessarily want to encourage cross-over between = int and float, so I think the =E2=80=9Cshortest float=E2=80=9D rule = should be applied independent of whether that cross-over is = desired.

Why keep the =E2=80=9Cshortest int=E2=80=9D rule less = well defined for protocols that use bignums?  It should apply there = as well, i.e., use bignums only for integers too large for the major = type 0/1 formats.

Gr=C3=BC=C3=9Fe, Carsten


> On Dec = 22, 2017, at 23:13, Jeffrey Yasskin <jyasskin@chromium.org> wrote:
>
> = On Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann <cabo@tzi.org> = wrote:
> On Nov 30, 2017, at 23:14, Jeffrey Yasskin <jyasskin@chromium.org> wrote:
> = >
> > Belatedly, I've discovered a user of = "canonical" CBOR who's proposing a different map order than = the RFC suggests: https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fi= do-client-to-authenticator-protocol-v2.0-rd-20170927.html#message-encodin= g. (Note that this isn't a final standard yet and may = change.)
>
> I looked at the spec = referenced.
>
> So they essentially = add
>
>              =    =E2=80=A2 If the major types are different, the one with = the lower value in numerical order sorts earlier.
>
> as a = major sorting rule before the existing RFC 7049 canonicalization = rules:
>
>              =    =E2=80=A2 If two keys have different lengths, the shorter = one sorts earlier;
>            =      =E2=80=A2 If two keys have the same length, the one = with the lower value in (byte-wise) lexical order sorts = earlier.
>
> This is different from simply going for = byte-wise lexicographic (memcmp order(*)), which effectively would get = us the first rule as the major sorting order already, but get rid of the = length-based second rule (first rule in Section 3.9 of RFC = 7049).
>
> I=E2=80=99ve come to see the putting the length = comparison rule early in 3.9 as a major regression.
> One of the = objectives when designing the CBOR serialization was not to repeat one = big mistake that ASN.1 BER makes: to make overall lengths of complex = composite items visible/important in the encoding of the next higher = composite.
> Here, we are doing just that.  = D=E2=80=99oh.
>
> > This is justified by the RFC saying = that "Those protocols are free to define what they mean by a = canonical format and what encoders and decoders are expected to = do.  This section lists some suggestions for such protocols." = That is (as Jim said), the RFC doesn't specify "canonical" = CBOR: it just provides an option for higher-level protocols to do = so.
>
> Right.  So the change would be to mention two = options for this, the old canonical, and the saner (memcmp order) = canonical.  Now the next step is finding names for legacy = canonical/saner canonical.  We then have to decide whether we turn = this into a separate document, at Proposed Standard level, or believe = that adding another suggestion to 3.9 is essentially a bug fix and can = be done in the Standard level document.
>
> > The use of = a different order in CTAP is going to either force its implementers to = write custom CBOR encoders and decoders or require the generic encoders = to take a configuration option for the map order. If the generic = encoders take an option, then it stops being an issue for CBORbis to = suggest a different order.
>
> Right.  So I think you = are saying we get to fix this.
>
> I've tried to implement = this in https://github.com/cbor-wg/CBORbis/pull/9. I = defined a core set of rules so that other specs can use them by = reference, gave several examples of protocols that will need to extend = the rules, and defined a second set of rules that match the canonical = order that RFC7049 suggested.
>
> Do folks like this = direction?
>
> I don't have a strong opinion about which = document should hold the canonicalization rules. Can we ask the IESG = which they'd prefer?
>
> = Jeffrey

<= /div>
------=_NextPart_000_0031_01D3899E.F6CF5FA0-- From nobody Wed Jan 10 07:38:38 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32AB812D864 for ; Wed, 10 Jan 2018 07:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmGtVTVe0QEZ for ; Wed, 10 Jan 2018 07:38:33 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C14B512751F for ; Wed, 10 Jan 2018 07:38:33 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id f190so16662787ita.5 for ; Wed, 10 Jan 2018 07:38:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=v7sIWT7S1KxSWez84jD3/J/CKa17urgS5IqnlSEb3tw=; b=mO/DfUpaeNk+Vd5X+6gO7uJLQTh3ELcRvjPx2/PIuQDz7mDFIICokrtel/biBV6Uo6 h4cFNto/dwIxeL1+7DKUQfRPr3K9ymVXELkB5uULmwO3cHfUNKPJN+Qr9s0qta/yEABm HTBNGRCB95QSglT3kOuS71XWm3vTB5uqpQWEI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=v7sIWT7S1KxSWez84jD3/J/CKa17urgS5IqnlSEb3tw=; b=OutJPxEFz2pnUj2uWyds1ffOOkV0La/9OQldAljQtUCIzcFk6EFpBBU5/F8DL7iONC E/nvEiH8mSVTccI2aY55/ymGIoHZyBaGObQluJjvx0He/FyyzkyhDXF5XNqL5l+ILIZw piieom5j8VC39ZtLFGlVze5GR6TFw1jtTnp6+XaYiV2QqJ6L4oh3q452shp84IeIPUte q0LGOTJ+i0zA32flG7xzULQJPxdLgVDPB0ybra7ApwBC3DixTCdGvyWg4vWqrLTd15Rb 2ugK/mpqwB7lKw56RcFi19VP0dftqnsXynVqRrqSTeCOkaQNQ3AO3pZ2cneOQfWBUnxs t9fQ== X-Gm-Message-State: AKGB3mK4boHX14/3ndr/AWPv5nJAnaHv3JyI+Tlz+q3DJdUZf+84YFxY PN3BMoTG08YN6JE9x/+s/1YAHQS8eH0B0Bx0Vxhx/IDEUlM= X-Google-Smtp-Source: ACJfBoufkZrQbmzT5dZ8df3+9LLkmfphm8AZBplNlaHiibeKfX01Aydrq4JEeFNNkjbnninGfq4BNMR6Wy0wMPkgKDw= X-Received: by 10.36.31.196 with SMTP id d187mr18182295itd.96.1515598712392; Wed, 10 Jan 2018 07:38:32 -0800 (PST) MIME-Version: 1.0 References: <012801d32f2e$a95aaf10$fc100d30$@augustcellars.com> <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> <1FED1F56-93BA-410F-B7C4-E83D31E7CC4E@tzi.org> <5D1F5ECC-C7DA-427F-B8A1-2040EA75FDE6@tzi.org> <000b01d38900$111d1400$33573c00$@augustcellars.com> <003001d389e2$04eef620$0ecce260$@augustcellars.com> In-Reply-To: <003001d389e2$04eef620$0ecce260$@augustcellars.com> From: Jeffrey Yasskin Date: Wed, 10 Jan 2018 15:38:19 +0000 Message-ID: To: ietf@augustcellars.com Cc: Jeffrey Yasskin , cbor@ietf.org, Carsten Bormann Content-Type: multipart/alternative; boundary="001a11449666e04f6c05626dd281" Archived-At: Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jan 2018 15:38:37 -0000 --001a11449666e04f6c05626dd281 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Line 1328 is not part of any of the defined canonicalization rules. It's an example of a rule a document specification might choose to layer on top, as your message anticipates. You might be saying that no document specification should have int/float fields that would be able to represent the same information two ways? Otherwise, the document specification absolutely needs to pick one of the representations for a given data value in order to have a canonical representation. Jeffrey On Tue, Jan 9, 2018 at 11:10 PM Jim Schaad wrote: > No. > > > > Look at what is at line 1328 in the diff and that is exactly what I am > talking about as should not be done. > > > > Jim > > > > > > *From:* Jeffrey Yasskin [mailto:jyasskin@chromium.org] > *Sent:* Tuesday, January 9, 2018 10:25 PM > *To:* ietf@augustcellars.com > *Cc:* Jeffrey Yasskin ; cbor@ietf.org; Carsten > Bormann > *Subject:* Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested > Canonicalization > > > > Does that mean you support the PR as-is, without the changes Carsten > suggested? > > On Mon, Jan 8, 2018 at 8:12 PM Jim Schaad wrote: > > I did not like the idea of changing the types of items when doing > canonicalization. I want to look just at what is given to me and thus do > not like things like a floating point number may be encoded as an any of = a > number of different formats. The choice of what an item is encoded as in > terms of a floating point number is a function of the document > specification and not the canonicalization encoding format. For things > like big numbers, the encoding should not be modified because the leading > characters have been chosen by the application for a specific reason. > Consider the leading padding that is part of a public key in cryptography > where the length of the value is of equal or greater importance that the > fact that is has leading 0 or 0xff bytes. The rules for mapping between > the data model and the encoding are as much up to the protocol > specification as they are for the CBOR specification. It is possible tha= t > a specification will only want to use the 64-bit floating point number > format because it really simplifies the application even if it makes the > encoded format longer. > > > > In sort, I do not believe that the rules should be extended beyond how an > encoding works for a single encoded data format. > > > > Jim > > > > > > *From:* CBOR [mailto:cbor-bounces@ietf.org] *On Behalf Of *Jeffrey Yasski= n > *Sent:* Monday, January 8, 2018 10:34 AM > *To:* Jeffrey Yasskin > *Cc:* cbor@ietf.org; Carsten Bormann > *Subject:* Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested > Canonicalization > > > > Now that we're past the holidays, are there more comments on > https://github.com/cbor-wg/CBORbis/pull/9? > > On Fri, Dec 22, 2017 at 3:56 PM Jeffrey Yasskin > wrote: > > I don't think https://github.com/cbor-wg/CBORbis/pull/9 allows anything > that RFC7049 didn't, which is the meaning I get from "open this up". > > > > We *could* move this (all of section 3?) to a separate document, but I > haven't seen anyone say that we need to. A downside of moving section 3 t= o > another RFC is that it'll make it harder to find. Someone authoritative > (Francesca?) should just make this call so that we can stop angsting abou= t > it. > > > > I'm generally happy to change exactly which examples demonstrate that > protocol designers need to think about canonicalization even if they star= t > from the core canonicalization requirements. I'd appreciate a concrete > statement of which examples to use though. > > > > Once we add floating values, the type of a field matters in defining its > canonicalization. A float64 field only needs to canonicalize NaN. A > float16/float32/float64 field needs to canonicalize to either the smalles= t > or largest type. An int/float field needs to again canonicalize toward or > away from int. A bigint field needs to prefer either a fixed-length > (useful for cryptographic signatures) or the shortest representation. A > decfrac/bigfloat/number field has an even more complex problem. I don't > personally have enough examples of existing canonicalized CBOR-based > protocols to make any confident recommendations here. If the list gives m= e > some, along with the field experience that justifies them, I'm happy to > write them down in my patch. > > > > Jeffrey > > > > On Fri, Dec 22, 2017 at 2:23 PM Carsten Bormann wrote: > > Hi Jeffrey, > > quick reactions after a first skim: > > I=E2=80=99m not sure the direction should be to open this up; I think the > recommendations should become more narrow as we learn about the practical > issues. > > We could write a separate document on the preferred c14n so we can keep > this out of the main document. > > I don=E2=80=99t think we necessarily want to encourage cross-over between= int and > float, so I think the =E2=80=9Cshortest float=E2=80=9D rule should be app= lied independent > of whether that cross-over is desired. > > Why keep the =E2=80=9Cshortest int=E2=80=9D rule less well defined for pr= otocols that use > bignums? It should apply there as well, i.e., use bignums only for > integers too large for the major type 0/1 formats. > > Gr=C3=BC=C3=9Fe, Carsten > > > > On Dec 22, 2017, at 23:13, Jeffrey Yasskin > wrote: > > > > On Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann wrote: > > On Nov 30, 2017, at 23:14, Jeffrey Yasskin > wrote: > > > > > > Belatedly, I've discovered a user of "canonical" CBOR who's proposing > a different map order than the RFC suggests: > https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-authe= nticator-protocol-v2.0-rd-20170927.html#message-encoding. > (Note that this isn't a final standard yet and may change.) > > > > I looked at the spec referenced. > > > > So they essentially add > > > > =E2=80=A2 If the major types are different, the one wit= h the > lower value in numerical order sorts earlier. > > > > as a major sorting rule before the existing RFC 7049 canonicalization > rules: > > > > =E2=80=A2 If two keys have different lengths, the short= er one > sorts earlier; > > =E2=80=A2 If two keys have the same length, the one wit= h the > lower value in (byte-wise) lexical order sorts earlier. > > > > This is different from simply going for byte-wise lexicographic (memcmp > order(*)), which effectively would get us the first rule as the major > sorting order already, but get rid of the length-based second rule (first > rule in Section 3.9 of RFC 7049). > > > > I=E2=80=99ve come to see the putting the length comparison rule early i= n 3.9 as > a major regression. > > One of the objectives when designing the CBOR serialization was not to > repeat one big mistake that ASN.1 BER makes: to make overall lengths of > complex composite items visible/important in the encoding of the next > higher composite. > > Here, we are doing just that. D=E2=80=99oh. > > > > > This is justified by the RFC saying that "Those protocols are free to > define what they mean by a canonical format and what encoders and decoder= s > are expected to do. This section lists some suggestions for such > protocols." That is (as Jim said), the RFC doesn't specify "canonical" > CBOR: it just provides an option for higher-level protocols to do so. > > > > Right. So the change would be to mention two options for this, the old > canonical, and the saner (memcmp order) canonical. Now the next step is > finding names for legacy canonical/saner canonical. We then have to deci= de > whether we turn this into a separate document, at Proposed Standard level= , > or believe that adding another suggestion to 3.9 is essentially a bug fix > and can be done in the Standard level document. > > > > > The use of a different order in CTAP is going to either force its > implementers to write custom CBOR encoders and decoders or require the > generic encoders to take a configuration option for the map order. If the > generic encoders take an option, then it stops being an issue for CBORbis > to suggest a different order. > > > > Right. So I think you are saying we get to fix this. > > > > I've tried to implement this in > https://github.com/cbor-wg/CBORbis/pull/9. I defined a core set of rules > so that other specs can use them by reference, gave several examples of > protocols that will need to extend the rules, and defined a second set of > rules that match the canonical order that RFC7049 suggested. > > > > Do folks like this direction? > > > > I don't have a strong opinion about which document should hold the > canonicalization rules. Can we ask the IESG which they'd prefer? > > > > Jeffrey > > --001a11449666e04f6c05626dd281 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Line 1328 is not part of any of the defined canonicalizati= on rules. It's an example of a rule a document specification=C2=A0might= choose to layer on top, as your message anticipates.

Yo= u might be saying that no document specification should have int/float fiel= ds that would be able to represent the same information two ways? Otherwise= , the document specification absolutely needs to pick one of the representa= tions for a given data value in order to have a canonical representation.
Jeffrey

On Tue, Ja= n 9, 2018 at 11:10 PM Jim Schaad <ietf@augustcellars.com> wrote:

No.

=C2=A0

Look at wh= at is at line 1328 in the diff and that is exactly what I am talking about = as should not be done.

=C2= =A0

Jim

=C2=A0

=C2=A0

From: Jeffrey Y= asskin [mailto:j= yasskin@chromium.org]
Sent: Tuesday, January 9, 2018 10:25 P= M
To: ietf@augustcellars.com
Cc: Jeffrey Yasskin <jyasskin@chromium.org>= ; cbor@ietf.org; Car= sten Bormann <cabo@tzi= .org>
Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis -= Change suggested Canonicalization

=C2=A0

Does that mean you support the PR as-is, without the chan= ges Carsten suggested?

On= Mon, Jan 8, 2018 at 8:12 PM Jim Schaad <ietf@augustcellars.com> wrote:

I di= d not like the idea of changing the types of items when doing canonicalizat= ion.=C2=A0 I want to look just at what is given to me and thus do not like = things like a floating point number may be encoded as an any of a number of= different formats.=C2=A0 The choice of what an item is encoded as in terms= of a floating point number is a function of the document specification and= not the canonicalization encoding format.=C2=A0 For things like big number= s, the encoding should not be modified because the leading characters have = been chosen by the application for a specific reason.=C2=A0 Consider the le= ading padding that is part of a public key in cryptography where the length= of the value is of equal or greater importance that the fact that is has l= eading 0 or 0xff bytes.=C2=A0 The rules for mapping between the data model = and the encoding are as much up to the protocol specification as they are f= or the CBOR specification.=C2=A0 It is possible that a specification will o= nly want to use the 64-bit floating point number format because it really s= implifies the application even if it makes the encoded format longer.

=C2=A0

In sort, I do not believe that the rules should be extended beyond h= ow an encoding works for a single encoded data format.

=C2=A0

Jim

=C2=A0

=C2=A0

From: CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Jeffrey Ya= sskin
Sent: Monday, January 8, 2018 10:34 AM
To: Jeffre= y Yasskin <jy= asskin@chromium.org>
Cc: cbor@ietf.org; Carsten Bormann <cabo@tzi.org>
Subject: Re:= [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization<= u>

=C2=A0

Now that we'r= e past the holidays, are there more comments on=C2=A0h= ttps://github.com/cbor-wg/CBORbis/pull/9?

On Fri, = Dec 22, 2017 at 3:56 PM Jeffrey Yasskin <jyasskin@chromium.org> wrote:<= /u>

I don't thin= k h= ttps://github.com/cbor-wg/CBORbis/pull/9=C2=A0allows anything that RFC7= 049 didn't, which is the meaning I get from "open this up".= =C2=A0

=C2=A0<= /u>

We *could* move this (all of secti= on 3?) to a separate document, but I haven't seen anyone say that we ne= ed to. A downside of moving section 3 to another RFC is that it'll make= it harder to find. Someone authoritative (Francesca?)=C2=A0should just mak= e this call so that we can stop angsting about it.

<= div>

=C2=A0

I'm generally happy to change exactly which examples demonstr= ate that protocol designers need to think about canonicalization even if th= ey start from the core canonicalization requirements. I'd appreciate a = concrete statement of which examples to use though.

=

=C2=A0

Once we add floating values, the type of a field matters in defi= ning its canonicalization. A float64 field only needs to canonicalize NaN. = A float16/float32/float64 field needs to canonicalize to either the smalles= t or largest type. An int/float field needs to again canonicalize toward or= away from int. A bigint field needs to prefer either a fixed-length (useful for cryptographic signatures) or the=C2=A0sh= ortest representation. A decfrac/bigfloat/number field has an even more com= plex problem. I don't personally have enough examples of existing canon= icalized CBOR-based protocols to make any confident recommendations here. I= f the list gives me some, along with the field experience that justifies th= em, I'm happy to write them down in my patch.

=C2=A0

Jeffrey

=C2=A0

On Fri, Dec 22, 2017 at 2:23 PM Carsten Bormann <cabo@tzi.org> wrote:<= /p>

H= i Jeffrey,

quick reactions after a first skim:

I=E2=80=99m no= t sure the direction should be to open this up; I think the recommendations= should become more narrow as we learn about the practical issues.

W= e could write a separate document on the preferred c14n so we can keep this= out of the main document.

I don=E2=80=99t think we necessarily want= to encourage cross-over between int and float, so I think the =E2=80=9Csho= rtest float=E2=80=9D rule should be applied independent of whether that cro= ss-over is desired.

Why keep the =E2=80=9Cshortest int=E2=80=9D rule= less well defined for protocols that use bignums?=C2=A0 It should apply th= ere as well, i.e., use bignums only for integers too large for the major ty= pe 0/1 formats.

Gr=C3=BC=C3=9Fe, Carsten


> On Dec 22, = 2017, at 23:13, Jeffrey Yasskin <jyasskin@chromium.org> wrote:
>
> On= Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann <cabo@tzi.org> wrote:
> On Nov 30, 2017= , at 23:14, Jeffrey Yasskin <jyasskin@chromium.org> wrote:
> >
> &= gt; Belatedly, I've discovered a user of "canonical" CBOR who= 's proposing a different map order than the RFC suggests: htt= ps://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-authentica= tor-protocol-v2.0-rd-20170927.html#message-encoding. (Note that this is= n't a final standard yet and may change.)
>
> I looked at t= he spec referenced.
>
> So they essentially add
>
>= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If = the major types are different, the one with the lower value in numerical or= der sorts earlier.
>
> as a major sorting rule before the exist= ing RFC 7049 canonicalization rules:
>
>=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If two keys have differe= nt lengths, the shorter one sorts earlier;
>=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If two keys have the same l= ength, the one with the lower value in (byte-wise) lexical order sorts earl= ier.
>
> This is different from simply going for byte-wise lexi= cographic (memcmp order(*)), which effectively would get us the first rule = as the major sorting order already, but get rid of the length-based second = rule (first rule in Section 3.9 of RFC 7049).
>
> I=E2=80=99ve = come to see the putting the length comparison rule early in 3.9 as a major = regression.
> One of the objectives when designing the CBOR serializa= tion was not to repeat one big mistake that ASN.1 BER makes: to make overal= l lengths of complex composite items visible/important in the encoding of t= he next higher composite.
> Here, we are doing just that.=C2=A0 D=E2= =80=99oh.
>
> > This is justified by the RFC saying that &qu= ot;Those protocols are free to define what they mean by a canonical format = and what encoders and decoders are expected to do.=C2=A0 This section lists= some suggestions for such protocols." That is (as Jim said), the RFC = doesn't specify "canonical" CBOR: it just provides an option = for higher-level protocols to do so.
>
> Right.=C2=A0 So the ch= ange would be to mention two options for this, the old canonical, and the s= aner (memcmp order) canonical.=C2=A0 Now the next step is finding names for= legacy canonical/saner canonical.=C2=A0 We then have to decide whether we = turn this into a separate document, at Proposed Standard level, or believe = that adding another suggestion to 3.9 is essentially a bug fix and can be d= one in the Standard level document.
>
> > The use of a diffe= rent order in CTAP is going to either force its implementers to write custo= m CBOR encoders and decoders or require the generic encoders to take a conf= iguration option for the map order. If the generic encoders take an option,= then it stops being an issue for CBORbis to suggest a different order.
= >
> Right.=C2=A0 So I think you are saying we get to fix this.
= >
> I've tried to implement this in https://github.com/cbor-wg/CB= ORbis/pull/9. I defined a core set of rules so that other specs can use= them by reference, gave several examples of protocols that will need to ex= tend the rules, and defined a second set of rules that match the canonical = order that RFC7049 suggested.
>
> Do folks like this direction?=
>
> I don't have a strong opinion about which document sho= uld hold the canonicalization rules. Can we ask the IESG which they'd p= refer?
>
> Jeffrey

--001a11449666e04f6c05626dd281-- From nobody Wed Jan 17 12:18:24 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8669E12DB6B for ; Wed, 17 Jan 2018 12:18:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V91mMAmnZoGe for ; Wed, 17 Jan 2018 12:18:22 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDA512D7E6 for ; Wed, 17 Jan 2018 12:18:21 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w0HKIIW4022667 for ; Wed, 17 Jan 2018 21:18:18 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zMJLf3XhnzDWtB; Wed, 17 Jan 2018 21:18:18 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 537913096.7525229-b32d7b9e8e93e5ecf098cad7b87ca3b2 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 17 Jan 2018 21:18:17 +0100 Message-Id: <8BB7B3B3-5F7D-48D5-A1BE-3F9C51FDCF27@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Cbor] cbor.me availability X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2018 20:18:23 -0000 For those who are wondering about the availability of cbor.me: we have = had a few outages already this year. It turns out that the haphazard diagnostic notation parser I threw = together in the cbor-diag gem can=E2=80=99t quite handle multi-megabyte = instances of diagnostic notation. I need to debug this; while I do so = please don=E2=80=99t send two-to-nine (or larger :-) megabyte diagnostic = notation files in its direction=E2=80=A6 Thank you. (You can always install cbor-diag locally if the availability problem = bothers you: gem install cbor-diag =E2=80=A6 and then convert for example with diag2cbor.rb foo.diag >foo.cbor but this still has the same performance bug=E2=80=A6) Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Jan 17 15:10:21 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4939312EACC for ; Wed, 17 Jan 2018 15:10:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ti6kwI2IeN6w for ; Wed, 17 Jan 2018 15:10:20 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5D412EAB9 for ; Wed, 17 Jan 2018 15:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w0HNAGhS014137 for ; Thu, 18 Jan 2018 00:10:16 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zMN944b2jzDWv4; Thu, 18 Jan 2018 00:10:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <8BB7B3B3-5F7D-48D5-A1BE-3F9C51FDCF27@tzi.org> Date: Thu, 18 Jan 2018 00:10:15 +0100 X-Mao-Original-Outgoing-Id: 537923414.831793-a3fc2b72443df4653c7f5623b349e4da Content-Transfer-Encoding: quoted-printable Message-Id: References: <8BB7B3B3-5F7D-48D5-A1BE-3F9C51FDCF27@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [Cbor] cbor.me availability X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jan 2018 23:10:21 -0000 On Jan 17, 2018, at 21:18, Carsten Bormann wrote: >=20 >=20 > It turns out that the haphazard diagnostic notation parser I threw = together in the cbor-diag gem can=E2=80=99t quite handle multi-megabyte = instances of diagnostic notation. I need to debug this I did. =F0=9F=92=AB=F0=9F=98=B5 cbor-diag 0.5.2 no longer has quadratic behavior (blush). I fixed a bug with handling \uNNNN in the process. (None of these were bugs in my code, but I was able to find = workarounds.) You may want to do a gem update cbor-diag to get those fixes locally. (The diagnostic notation parser in cbor-diag still isn=E2=80=99t a = performance champion: cbor.me chews about 10 s on every megabyte, so = please do process those multi-megabyte files locally. But at least = sending one to cbor.me doesn=E2=80=99t result in a complete DoS any = more.) Gr=C3=BC=C3=9Fe, Carsten From nobody Thu Jan 18 05:27:39 2018 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E836412421A; Thu, 18 Jan 2018 05:27:35 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: cbor@ietf.org, cbor-chairs@ietf.org, francesca.palombini@ericsson.com, aamelnikov@fastmail.fm X-Test-IDTracker: no X-IETF-IDTracker: 6.69.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151628205590.32116.6009206632868698399.idtracker@ietfa.amsl.com> Date: Thu, 18 Jan 2018 05:27:35 -0800 Archived-At: Subject: [Cbor] cbor - New Meeting Session Request for IETF 101 X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jan 2018 13:27:36 -0000 A new meeting session request has just been submitted by Francesca Palombini, a Chair of the cbor working group. --------------------------------------------------------- Working Group Name: Concise Binary Object Representation Maintenance and Extensions Area Name: Applications and Real-Time Area Session Requester: Francesca Palombini Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: artarea dispatch core ace anima t2trg suit 6tisch Second Priority: saag dtn sacm lpwan httpbis dots lwig roll Third Priority: detnet dnsop People who must be present: Alexey Melnikov Joe Hildebrand Francesca Palombini Resources Requested: Special Requests: Early in the week (Monday/Tuesday) would help, so participants can join the meeting and then move to the OCF meeting in Prague. Please also avoid any IoT related BOFs that might come up. --------------------------------------------------------- From nobody Mon Jan 22 06:59:03 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 799DD1200E5 for ; Mon, 22 Jan 2018 06:59:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gJ6gbqtfrGx for ; Mon, 22 Jan 2018 06:58:59 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20290127058 for ; Mon, 22 Jan 2018 06:58:58 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id m136so335304pga.12 for ; Mon, 22 Jan 2018 06:58:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=aJr8pENLT6t9Q1uTlHZ/WZxxhEDO3fUgWRMa0Nw80Bo=; b=fEtxBbFnkQtT6jbOu2VkcEh+B/qiQ7yrjo2OL6VDnqKiAM0K42nvqcp1VKZZQ7JA2Q NG8mtx1HP9e/Ep/clKBepxnUBns9gJ3pmM4CFjrWWpQtu6FNnzUOBgm2lpUY2pp1hFEs l+z3cfM0MCuYi6Yee6ygIfC27s+s82ZMNSk7o= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=aJr8pENLT6t9Q1uTlHZ/WZxxhEDO3fUgWRMa0Nw80Bo=; b=tAMQrZ6yQTXPZV7l1w5AyDBtN+ocRxjy+uH1krt95gW+BUJ66khyb3thIxirvRhA1z wN8N3uc4pWzQSaPFqE9kT00VOiMUK3PP7jDUDS6ZmnaNRTTPC/v21wccTv+ib7oJrSHd P72CM7GCzhXhQNgXXcnCKNx72jMdy1Z/MGIIK6i5PWPXHVwxhH0Ryjk17STDzTBm4uBn cs4vag5z1z81JnNG1UMb5oloQMoTH207+p4Ha85WIhY35nSfd+CWNOmg+g+3etwayT8F kN2wE7T4OnRpkw1v7CQsNk/J8qwU2s9yPmwTlF8juZMF1J5MEmdJHePVgTD+VAY93URJ TRzQ== X-Gm-Message-State: AKwxytdJV4HtboRIZA7d8acQezsnP9nwjsfDbSpse4vqVv1GOyzjoD4W cIBc2vP6Z+tJ08c+Xrkmgngdia8YF3twapuAnBhyK6wjVXQ= X-Google-Smtp-Source: AH8x227znHON38t/bR/LoP/0cilINP6j+xYWBWLBh2SJY6MiGtk0FyrGYULaEz4f4AGu+zkWOiGWbBjICoDCEj18Ubg= X-Received: by 2002:a17:902:8215:: with SMTP id x21-v6mr3820318pln.381.1516633137458; Mon, 22 Jan 2018 06:58:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.236.137.144 with HTTP; Mon, 22 Jan 2018 06:58:56 -0800 (PST) From: Franziskus Kiefer Date: Mon, 22 Jan 2018 15:58:56 +0100 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="00000000000069d0aa05635eabf7" Archived-At: Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jan 2018 14:59:01 -0000 --00000000000069d0aa05635eabf7 Content-Type: text/plain; charset="UTF-8" Hi all, I was wondering if there's progress on this and PR 9. The sorting of canonicalized CBOR maps came up as an issue in the Webauthn standardization. The consensus there is to use CTAP sorting everywhere [1], which is incompatible with canonical CBOR sorting. I see that changing the sorting section is problematic given that this has been implemented by people already. But I wonder if it would make sense to add the CTAP sorting as a second option so that both are at least documented in the same place. Cheers, Franziskus [1] https://github.com/w3c/webauthn/pull/731 --00000000000069d0aa05635eabf7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

I was wondering if t= here's progress on this and PR 9.

The sorting = of canonicalized CBOR maps came up as an issue in the Webauthn standardization. The consensus there is to use=20 CTAP sorting everywhere [1], which is incompatible with canonical CBOR sort= ing.

I see that changing the sorting section is pr= oblematic given that this has been implemented by people already. But I won= der if it would make sense to add the CTAP sorting as a second option so th= at both are at least documented in the same place.

=
Cheers,
Franziskus

--00000000000069d0aa05635eabf7-- From nobody Wed Jan 24 12:04:34 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CADD9127871 for ; Wed, 24 Jan 2018 12:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypnjCdmaMtgO for ; Wed, 24 Jan 2018 12:04:30 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B5AB12700F for ; Wed, 24 Jan 2018 12:04:30 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w0OK4QVO001317 for ; Wed, 24 Jan 2018 21:04:26 +0100 (CET) Received: from [192.168.217.114] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zRbjQ1lzlzDWyS; Wed, 24 Jan 2018 21:04:26 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 538517064.36983-0330cfcd6cf6f1a712f7515504075a3c Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 24 Jan 2018 21:04:25 +0100 Message-Id: <276C1041-F1C9-426B-BAF6-89D2BFC3A8F8@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Cbor] CDDL: Solving the regexp issue X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jan 2018 20:04:33 -0000 At IETF 100, we had a another discussion about regular expressions. I don=E2=80=99t think we went home with a clear idea of how to solve = this problem. Giving up and just not doing regular expression in the first version of = CDDL certainly was one choice. But, since, there has been time to analyze the issue some more. Here is a proposal for addressing the regexp issue: = https://cbor-wg.github.io/cddl/matching/draft-ietf-cbor-cddl.html#rfc.sect= ion.3.8.3 Why use XSD REs? * There is a valid normative reference for them. * There is precedent for using XSD REs in IETF specifications, e.g. in = YANG (RFC 7950). * They actually have been designed for the kind of use we are employing = them for (albeit in an XML context). * There are no undesirable UTF-16 droppings in XSD REs, as there would = have been in JavaScript REs. The solution proposed works quite well and allows us to have a = reasonable .regexp in the 1.0 CDDL RFC. (It is just a tad less straightforward to implement than PCRE was. Oh = well.) We can always add more controls for other RE types later. (This also = provides a powerful incentive to continue coupling REs with the main = extension point for the CDDL language: controls.) Gr=C3=BC=C3=9Fe, Carsten From nobody Sat Jan 27 23:47:11 2018 Return-Path: X-Original-To: cbor@ietf.org Delivered-To: cbor@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCFAC124F57; Sat, 27 Jan 2018 23:47:05 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: cbor@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.70.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151712562585.21955.10629085472385940719@ietfa.amsl.com> Date: Sat, 27 Jan 2018 23:47:05 -0800 Archived-At: Subject: [Cbor] I-D Action: draft-ietf-cbor-cddl-01.txt X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 07:47:06 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Concise Binary Object Representation Maintenance and Extensions WG of the IETF. Title : Concise data definition language (CDDL): a notational convention to express CBOR data structures Authors : Henk Birkholz Christoph Vigano Carsten Bormann Filename : draft-ietf-cbor-cddl-01.txt Pages : 55 Date : 2018-01-27 Abstract: This document proposes a notational convention to express CBOR data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-cbor-cddl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-cbor-cddl-01 https://datatracker.ietf.org/doc/html/draft-ietf-cbor-cddl-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-cbor-cddl-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Jan 28 00:04:46 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A96E129C6B for ; Sun, 28 Jan 2018 00:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqbMIa6TI9xc for ; Sun, 28 Jan 2018 00:04:42 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8806812D7ED for ; Sun, 28 Jan 2018 00:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w0S84dcM012064 for ; Sun, 28 Jan 2018 09:04:39 +0100 (CET) Received: from [192.168.217.102] (p5DC7EAF5.dip0.t-ipconnect.de [93.199.234.245]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zTlY32RKxzDXj3; Sun, 28 Jan 2018 09:04:39 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=utf-8 X-Mao-Original-Outgoing-Id: 538819477.117588-f6951193b592bd9856a45e82b607d40e Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Sun, 28 Jan 2018 09:04:38 +0100 Message-Id: <0B50B134-C844-4FBC-851B-BFDBF53E275F@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Cbor] draft-ietf-cbor-cddl-01: approaching WGLC? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jan 2018 08:04:45 -0000 We just submitted draft-ietf-cbor-cddl-01: Htmlized: https://tools.ietf.org/html/draft-ietf-cbor-cddl-01 Diff: = https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-cbor-cddl-01.txt draft-ietf-cbor-cddl-01 addresses the following issues: * Creation of (and pointing to) a freezer document with all the things that would be nice to have but won't make it into the initial RFC (https://tools.ietf.org/html/draft-bormann-cbor-cddl-freezer-00) * Creation of Appendix C for a concise definition of the matching rules (and ABNF became Appendix B) [as seen here before] * Using XSD2 regexps instead of PCRE (possibly breaking change for those specifiations that use regexps!) [as seen here before] * Add a minimal "cut" proposal to solve the requirement identified in the "Validation of maps" thread. (There might be some minimal breakage here in a small number of specifications, too!) * Get rid of some cobwebs (e.g., Appendix A has been dissolved into the pertinent subject sections). * Many other editorial fixes (e.g., we have reordered 2.1 a bit, making the weird example less prominent); some RFC 7322 style guide fixes. Not yet addressed: * Issue #4 (ABNF for hex floats); unless someone has some ABNF handy we could steal, we'll need some more quality time with tools to create a validated patch for this. * A few editorial comments in the document itself (some of which probably now can just be ticked off as wontfix). Apart from that issue #4, this should empty the list of "must have" technical changes. (The WG may of course be of a different opinion...) It also makes it a good time to send in editorial comments (on github or directly to the authors!) if you want them fixed before WGLC. The plan is to have the -02 with those final changes out within the next four weeks so we still have time to finish the WGLC before London. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jan 30 04:02:09 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F06412E887 for ; Tue, 30 Jan 2018 04:02:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pXH5oX8y8K4q for ; Tue, 30 Jan 2018 04:02:06 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0321712EA62 for ; Tue, 30 Jan 2018 04:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id w0UC1OYx022958 for ; Tue, 30 Jan 2018 13:01:24 +0100 (CET) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3zW4jJ55JpzDWjG; Tue, 30 Jan 2018 13:01:24 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Carsten Bormann In-Reply-To: <0B50B134-C844-4FBC-851B-BFDBF53E275F@tzi.org> Date: Tue, 30 Jan 2018 13:01:24 +0100 X-Mao-Original-Outgoing-Id: 539006483.508901-ae885a10f665e087f4080f92a4c15495 Content-Transfer-Encoding: quoted-printable Message-Id: <40E1A87D-E9EA-4A55-AB55-10960A3F33E9@tzi.org> References: <0B50B134-C844-4FBC-851B-BFDBF53E275F@tzi.org> To: cbor@ietf.org X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [Cbor] Hexfloats (Re: draft-ietf-cbor-cddl-01: approaching WGLC?) X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jan 2018 12:02:09 -0000 On Jan 28, 2018, at 09:04, Carsten Bormann wrote: >=20 > Not yet addressed: >=20 > * Issue #4 (ABNF for hex floats); unless someone has some ABNF handy > we could steal, we'll need some more quality time with tools to > create a validated patch for this. Looking at C99 (ISO 9899), plus some simplifying, yields: hexfloat =3D "0x" (*HEXDIG "." 1*HEXDIG) / (1*HEXDIG ["."]) "p" exponent C99 allows 0x.fp0 or 0xf.p0, which is a bit out of character for the rest of CDDL (which does not allow .3 or 3.); so I'd further simplify this to: hexfloat =3D "0x" 1*HEXDIG ["." 1*HEXDIG] "p" exponent Note that this allows fewer ways of writing hexfloats than C99, but all of them would retain their C99 semantics (which we would then simply reference). I notice that the current production for exponent (which are decimal even in C99 hexfloats) is a bit too liberal at the moment, allowing for 1.1e0b00111000 :-), but not 0.3e+05, so maybe we should also turn that into a more specific: exponent =3D ["+"/"-"] 1*DIGIT Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Jan 30 17:03:44 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD94D13145B for ; Tue, 30 Jan 2018 17:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.009 X-Spam-Level: X-Spam-Status: No, score=-2.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MekcNWmetkgy for ; Tue, 30 Jan 2018 17:03:40 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0044512D878 for ; Tue, 30 Jan 2018 17:03:38 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id t22so13556746ioa.7 for ; Tue, 30 Jan 2018 17:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=cDM4wMnBBIae26W0d2HwTzAtdVwPWI4IDPUcV5JOBqw=; b=nYHajrLqeQ+yN4Xu1DgdwU4Ggw+lVzNTOs5xk1teeDTQdPyk5hyukXvl8gcaPsn3ui oiZTliAjQjU1emvbpq4Z8JXeAkJj+KB8Xf1mu3GrqxUim5KrfyQMMG3TbzAje9XF6cMq Fhk/KIPzlhiMKlQd4CJqU8GRVbq5k01mYyYYTiQaVds5x6uiMNO62hjQeIoiBsmF9jw+ 8vrZxwPhkrTfQUP3ns4rJVofnSzy9CXdKItRMZbtEcQcJYaWAI8xwgFfktJjLkv1rIAp 9T83+8uLSLPYJbqYq3dVwKc9dhHxX4m59OoZ7mfxzAZsTEZr595AtavliKqeUM65PsHH HhMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cDM4wMnBBIae26W0d2HwTzAtdVwPWI4IDPUcV5JOBqw=; b=nVdqhoCXfzJZghTpnfq+jhE8iuUZV+ZMcKseO0Aa1hbl4PMf/i8xumSUrOJ8X/ADM0 oQPk9OajpOix8FhpG91jJo2sUFMwN6DAa0X3sg1CT8CWzsgv3H2zmKcBTUscRjQWvypl E8924KBn/62NeKqFCvEbmSuIm+fW+pmbv5CI/EQ3CT3aQH6uFaUTD2e+4yUFIXanMLew krkewZUsyRoLLZJKrG6vHjehZFvn+h/wh8DpE0V+0nfV26paGqaA1kNUNeFXTNtfcJtp 6PfTyUTYY2X1QlVSU04MehKgK0/xsfMctWIlijF0+HgHV7rnIHn+EBmCHDTl+46+/R+7 OHnA== X-Gm-Message-State: AKwxytd8Dqampy+dDQXtXD+22ePR372eilv4hqwzAVzd2NUwyDPMDsEz PxaQs1V3o5IqCnzicXn6N2UtFkkbYtKwUESmvUGcSGjvtn8= X-Google-Smtp-Source: AH8x227GbT5L9puRRXXe6bZYBMrh0/oY+5VTlnv8TwN53WV/RA1CIS38KTsTyNih1Wnljk6HIzWSVniot4pyTAaLxIM= X-Received: by 10.107.169.94 with SMTP id s91mr797767ioe.83.1517360617673; Tue, 30 Jan 2018 17:03:37 -0800 (PST) MIME-Version: 1.0 From: Jeffrey Yasskin Date: Wed, 31 Jan 2018 01:03:23 +0000 Message-ID: To: cbor@ietf.org Content-Type: multipart/alternative; boundary="001a114634f09d98b60564080cdb" Archived-At: Subject: [Cbor] Specifying more in terms of data models? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 01:03:42 -0000 --001a114634f09d98b60564080cdb Content-Type: text/plain; charset="UTF-8" https://github.com/cbor-wg/CBORbis/pull/12 uses the "data model" section more throughout the spec and resolves a conflict between that section and the Numerics section. Do y'all think this is a good direction? Jeffrey --001a114634f09d98b60564080cdb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
htt= ps://github.com/cbor-wg/CBORbis/pull/12 uses the "data model"= section more throughout the spec and resolves a conflict between that sect= ion and the Numerics section. Do y'all think this is a good direction?<= br>

Jeffrey
--001a114634f09d98b60564080cdb-- From nobody Tue Jan 30 19:18:46 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5A2131933 for ; Tue, 30 Jan 2018 19:18:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wycc6YLMyW8j for ; Tue, 30 Jan 2018 19:18:43 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07D3C131931 for ; Tue, 30 Jan 2018 19:18:40 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id u1so8943574pgr.0 for ; Tue, 30 Jan 2018 19:18:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:organization:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=STUKtLuFKUgK9h0KP7VKSGBMHlaZINJ7tRNAxn+emHY=; b=pOK2Sfag+JkOmgg0Q11zlR1p20SeMwajKS+lfEuXrWYFnM6Pjh8kszk7piKBJuYUSV uCK57bXuX//XLHwfs4JRMSTAta+iUeNFw3+XKM/GiWpS+al3NErSgLUCLO7goZ1Ouxnn aevg83Aez2gpbsD8YUh/VXR52vcbBMPiossuCPKddYwxXhyna44uUjA0bcFT6VgrjwG5 2JRthFus8S087gpsYiltKcJqUt747VEOOksjvaUrQPxkHW07keTYKHZaUfMGQHONhUkd CWlhGK+safEVHdLd8boZU4P4WFIJ4JHbE4JdJccqvmHY0pzJN5kmOgAg7x41z+kMac3/ 6hDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=STUKtLuFKUgK9h0KP7VKSGBMHlaZINJ7tRNAxn+emHY=; b=Z5RZ89e0GtBEF1OfYyD4tFFdIP5dM7k7TVL40QqWh7QK4anENAKlKG6wf+65NhJRmt h9f1quYNAT4qf2QTQ6FWnvDrnGkHLwWi80lGRVBa574Dcoe7C0yjcpd4AcHNwIKje22I PxJx/svJOIfW4z8iF/oi4n5O/DxZL4lM717dA7k3vGavAh3qSDA1yPkgJb5sx8KRTPXV 3jmSXZdiDxisYeKe/HDiuqf+vuUdqXEr2pHNw2fhWN1TyLW0nt5nRPnc4EcP0byMafgg GlO2bsEeSfVFXsIVWCPhn6TEIt18qL1mrWyJnceohVGjCoG4xXbzQZXfKyqGAgIv/2KA EJsA== X-Gm-Message-State: AKwxyte6q26ZCFDQnhtYg2dS5zWXl2pK00ZoYM55EihnC0w5xWfyoQwQ 34pI1ANttswMw73dU/yjiBat7Q== X-Google-Smtp-Source: AH8x227qiEEv0R/lZ6KTdYyp9gH8F03KT+lBaPKI7mAapHO4a3SAEtjd5GWcB5rdsrGhRiIR6emHZg== X-Received: by 10.98.163.131 with SMTP id q3mr31521863pfl.87.1517368719346; Tue, 30 Jan 2018 19:18:39 -0800 (PST) Received: from ?IPv6:2406:e001:3ff5:1:28cc:dc4c:9703:6781? ([2406:e001:3ff5:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id b68sm34021573pfg.159.2018.01.30.19.18.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Jan 2018 19:18:38 -0800 (PST) To: Carsten Bormann , cbor@ietf.org References: <0B50B134-C844-4FBC-851B-BFDBF53E275F@tzi.org> From: Brian E Carpenter Organization: University of Auckland Message-ID: Date: Wed, 31 Jan 2018 16:18:41 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <0B50B134-C844-4FBC-851B-BFDBF53E275F@tzi.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Cbor] draft-ietf-cbor-cddl-01: approaching WGLC? X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 03:18:45 -0000 On 28/01/2018 21:04, Carsten Bormann wrote: > We just submitted draft-ietf-cbor-cddl-01: I've looked through the changes and think this is in good shape (ignoring the hex float issue, where I have no opinion). So going for a WGLC before the IETF meeting sounds like a good plan. Regards Brian From nobody Wed Jan 31 11:03:04 2018 Return-Path: X-Original-To: cbor@ietfa.amsl.com Delivered-To: cbor@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F42051200C1 for ; Wed, 31 Jan 2018 11:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.008 X-Spam-Level: X-Spam-Status: No, score=-2.008 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHClS-NOkJM8 for ; Wed, 31 Jan 2018 11:02:57 -0800 (PST) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7C6612D853 for ; Wed, 31 Jan 2018 11:02:56 -0800 (PST) Received: by mail-it0-x22b.google.com with SMTP id 196so805242iti.5 for ; Wed, 31 Jan 2018 11:02:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Po32IuySzIEAMCKtGwfweEru+bCTwGGrrYn2xeFGKVk=; b=XfB7UYkSSgCzSTFy4+LZ0vmI7AFU2VBriYPhI3K+xCCJfYAz6OYLaDNmuBm2030I+5 RIBT6KeypPr3OU1NPpJJx0Z/DZ8p8jaVOKZHD0NO4cMYjcs2iI5bpsuof7SPwAXFZQIx 1Divx2HFqwm4lpOe6lyOHp3GGNnzycr2i0xkQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Po32IuySzIEAMCKtGwfweEru+bCTwGGrrYn2xeFGKVk=; b=MLwEjZDKdk8sxAZDnPivQxgzB39pTQ8vNrAz02x/KHPRvC0gLZ3g3jeJLyFI3ZYLbv pcU6zULiaCLjROoizoIhuqJGRohytMhIHx9wBy9j2ZdieO/5VyyKgGdCcpx/B+HDG7Br 34YVibj+N2jzrGRs4lUE5ruICPda5xToetMMyY9D14VkJnyVyan5FMowKGEfxw3HMICj yeFKvB6dvnqE8r4r9Agwqfuc4/6qTyLOZ1+l3AGc6jMUu6WrghFZ+VkTy9iy4JNtmgUx f+cNxS9RiOJ86ccfEXiHtClymb0q92F7HCYBswVsJ5Tqq0wEGD9CKBhH7JCxWfZ88kZ8 pzVw== X-Gm-Message-State: AKwxytc/YHk9ux9dCgyR0V4To2Z4/uHfJ5xNFYnrplLOu9lUg0xS77Ln GMeSDl6Fiq1q0FZqkhEWmbwR/2tvqgkKUxkiOfrZnA== X-Google-Smtp-Source: AH8x225oG7KmTw/zUBYs8UEWN0p7vybZL/DQrUeqeDuQ2Rmj/izq1ciFRDHhYq2Jh85aaCtcfV9D7njwqoLvEedUoSk= X-Received: by 10.36.93.136 with SMTP id w130mr38647186ita.106.1517425375709; Wed, 31 Jan 2018 11:02:55 -0800 (PST) MIME-Version: 1.0 References: <012801d32f2e$a95aaf10$fc100d30$@augustcellars.com> <7C19E4CE-32E2-44B2-BD44-1BAA48190674@tzi.org> <013a01d32fcb$ac8cede0$05a6c9a0$@augustcellars.com> <1FED1F56-93BA-410F-B7C4-E83D31E7CC4E@tzi.org> <5D1F5ECC-C7DA-427F-B8A1-2040EA75FDE6@tzi.org> <000b01d38900$111d1400$33573c00$@augustcellars.com> <003001d389e2$04eef620$0ecce260$@augustcellars.com> In-Reply-To: From: Jeffrey Yasskin Date: Wed, 31 Jan 2018 19:02:42 +0000 Message-ID: To: Jeffrey Yasskin Cc: ietf@augustcellars.com, cbor@ietf.org, Carsten Bormann Content-Type: multipart/alternative; boundary="001a1144ad5c7ee4080564172014" Archived-At: Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested Canonicalization X-BeenThere: cbor@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Concise Binary Object Representation \(CBOR\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jan 2018 19:03:02 -0000 --001a1144ad5c7ee4080564172014 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd like to get at least the change to canonicalization merged, even if there's still some disagreement about the examples. I think I've heard two conflicting pieces of advice w.r.t. the examples though: In https://www.ietf.org/mail-archive/web/cbor/current/msg00322.html, Carsten appears to prefer that the canonicalization rules say to use the shortest encoding of both floats and bignums, while in https://www.ietf.org/mail-archive/web/cbor/current/msg00326.html Jim appears to prefer that cbor-based protocols be able to define their canonicalization to use only 64-bit floats and fixed-width bignums. I've uploaded https://github.com/cbor-wg/CBORbis/pull/13 to omit all changes to the float example and the description of tag canonicalization. Does anyone object to merging just that part? Thanks, Jeffrey On Wed, Jan 10, 2018 at 7:38 AM Jeffrey Yasskin wrote: > Line 1328 is not part of any of the defined canonicalization rules. It's > an example of a rule a document specification might choose to layer on to= p, > as your message anticipates. > > You might be saying that no document specification should have int/float > fields that would be able to represent the same information two ways? > Otherwise, the document specification absolutely needs to pick one of the > representations for a given data value in order to have a canonical > representation. > > Jeffrey > > On Tue, Jan 9, 2018 at 11:10 PM Jim Schaad wrote= : > >> No. >> >> >> >> Look at what is at line 1328 in the diff and that is exactly what I am >> talking about as should not be done. >> >> >> >> Jim >> >> >> >> >> >> *From:* Jeffrey Yasskin [mailto:jyasskin@chromium.org] >> *Sent:* Tuesday, January 9, 2018 10:25 PM >> *To:* ietf@augustcellars.com >> *Cc:* Jeffrey Yasskin ; cbor@ietf.org; Carsten >> Bormann >> *Subject:* Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested >> Canonicalization >> >> >> >> Does that mean you support the PR as-is, without the changes Carsten >> suggested? >> >> On Mon, Jan 8, 2018 at 8:12 PM Jim Schaad wrote= : >> >> I did not like the idea of changing the types of items when doing >> canonicalization. I want to look just at what is given to me and thus d= o >> not like things like a floating point number may be encoded as an any of= a >> number of different formats. The choice of what an item is encoded as i= n >> terms of a floating point number is a function of the document >> specification and not the canonicalization encoding format. For things >> like big numbers, the encoding should not be modified because the leadin= g >> characters have been chosen by the application for a specific reason. >> Consider the leading padding that is part of a public key in cryptograph= y >> where the length of the value is of equal or greater importance that the >> fact that is has leading 0 or 0xff bytes. The rules for mapping between >> the data model and the encoding are as much up to the protocol >> specification as they are for the CBOR specification. It is possible th= at >> a specification will only want to use the 64-bit floating point number >> format because it really simplifies the application even if it makes the >> encoded format longer. >> >> >> >> In sort, I do not believe that the rules should be extended beyond how a= n >> encoding works for a single encoded data format. >> >> >> >> Jim >> >> >> >> >> >> *From:* CBOR [mailto:cbor-bounces@ietf.org] *On Behalf Of *Jeffrey >> Yasskin >> *Sent:* Monday, January 8, 2018 10:34 AM >> *To:* Jeffrey Yasskin >> *Cc:* cbor@ietf.org; Carsten Bormann >> *Subject:* Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested >> Canonicalization >> >> >> >> Now that we're past the holidays, are there more comments on >> https://github.com/cbor-wg/CBORbis/pull/9? >> >> On Fri, Dec 22, 2017 at 3:56 PM Jeffrey Yasskin >> wrote: >> >> I don't think https://github.com/cbor-wg/CBORbis/pull/9 allows anything >> that RFC7049 didn't, which is the meaning I get from "open this up". >> >> >> >> We *could* move this (all of section 3?) to a separate document, but I >> haven't seen anyone say that we need to. A downside of moving section 3 = to >> another RFC is that it'll make it harder to find. Someone authoritative >> (Francesca?) should just make this call so that we can stop angsting abo= ut >> it. >> >> >> >> I'm generally happy to change exactly which examples demonstrate that >> protocol designers need to think about canonicalization even if they sta= rt >> from the core canonicalization requirements. I'd appreciate a concrete >> statement of which examples to use though. >> >> >> >> Once we add floating values, the type of a field matters in defining its >> canonicalization. A float64 field only needs to canonicalize NaN. A >> float16/float32/float64 field needs to canonicalize to either the smalle= st >> or largest type. An int/float field needs to again canonicalize toward o= r >> away from int. A bigint field needs to prefer either a fixed-length >> (useful for cryptographic signatures) or the shortest representation. A >> decfrac/bigfloat/number field has an even more complex problem. I don't >> personally have enough examples of existing canonicalized CBOR-based >> protocols to make any confident recommendations here. If the list gives = me >> some, along with the field experience that justifies them, I'm happy to >> write them down in my patch. >> >> >> >> Jeffrey >> >> >> >> On Fri, Dec 22, 2017 at 2:23 PM Carsten Bormann wrote: >> >> Hi Jeffrey, >> >> quick reactions after a first skim: >> >> I=E2=80=99m not sure the direction should be to open this up; I think th= e >> recommendations should become more narrow as we learn about the practica= l >> issues. >> >> We could write a separate document on the preferred c14n so we can keep >> this out of the main document. >> >> I don=E2=80=99t think we necessarily want to encourage cross-over betwee= n int and >> float, so I think the =E2=80=9Cshortest float=E2=80=9D rule should be ap= plied independent >> of whether that cross-over is desired. >> >> Why keep the =E2=80=9Cshortest int=E2=80=9D rule less well defined for p= rotocols that use >> bignums? It should apply there as well, i.e., use bignums only for >> integers too large for the major type 0/1 formats. >> >> Gr=C3=BC=C3=9Fe, Carsten >> >> >> > On Dec 22, 2017, at 23:13, Jeffrey Yasskin >> wrote: >> > >> > On Sun, Dec 3, 2017 at 6:15 AM Carsten Bormann wrote: >> > On Nov 30, 2017, at 23:14, Jeffrey Yasskin >> wrote: >> > > >> > > Belatedly, I've discovered a user of "canonical" CBOR who's proposin= g >> a different map order than the RFC suggests: >> https://fidoalliance.org/specs/fido-v2.0-rd-20170927/fido-client-to-auth= enticator-protocol-v2.0-rd-20170927.html#message-encoding. >> (Note that this isn't a final standard yet and may change.) >> > >> > I looked at the spec referenced. >> > >> > So they essentially add >> > >> > =E2=80=A2 If the major types are different, the one wi= th the >> lower value in numerical order sorts earlier. >> > >> > as a major sorting rule before the existing RFC 7049 canonicalization >> rules: >> > >> > =E2=80=A2 If two keys have different lengths, the shor= ter one >> sorts earlier; >> > =E2=80=A2 If two keys have the same length, the one wi= th the >> lower value in (byte-wise) lexical order sorts earlier. >> > >> > This is different from simply going for byte-wise lexicographic (memcm= p >> order(*)), which effectively would get us the first rule as the major >> sorting order already, but get rid of the length-based second rule (firs= t >> rule in Section 3.9 of RFC 7049). >> > >> > I=E2=80=99ve come to see the putting the length comparison rule early = in 3.9 as >> a major regression. >> > One of the objectives when designing the CBOR serialization was not to >> repeat one big mistake that ASN.1 BER makes: to make overall lengths of >> complex composite items visible/important in the encoding of the next >> higher composite. >> > Here, we are doing just that. D=E2=80=99oh. >> > >> > > This is justified by the RFC saying that "Those protocols are free t= o >> define what they mean by a canonical format and what encoders and decode= rs >> are expected to do. This section lists some suggestions for such >> protocols." That is (as Jim said), the RFC doesn't specify "canonical" >> CBOR: it just provides an option for higher-level protocols to do so. >> > >> > Right. So the change would be to mention two options for this, the ol= d >> canonical, and the saner (memcmp order) canonical. Now the next step is >> finding names for legacy canonical/saner canonical. We then have to dec= ide >> whether we turn this into a separate document, at Proposed Standard leve= l, >> or believe that adding another suggestion to 3.9 is essentially a bug fi= x >> and can be done in the Standard level document. >> > >> > > The use of a different order in CTAP is going to either force its >> implementers to write custom CBOR encoders and decoders or require the >> generic encoders to take a configuration option for the map order. If th= e >> generic encoders take an option, then it stops being an issue for CBORbi= s >> to suggest a different order. >> > >> > Right. So I think you are saying we get to fix this. >> > >> > I've tried to implement this in >> https://github.com/cbor-wg/CBORbis/pull/9. I defined a core set of rules >> so that other specs can use them by reference, gave several examples of >> protocols that will need to extend the rules, and defined a second set o= f >> rules that match the canonical order that RFC7049 suggested. >> > >> > Do folks like this direction? >> > >> > I don't have a strong opinion about which document should hold the >> canonicalization rules. Can we ask the IESG which they'd prefer? >> > >> > Jeffrey >> >> --001a1144ad5c7ee4080564172014 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to get at least the change to canonicalizatio= n merged, even if there's still some disagreement about the examples.
I think I've heard two conflicting pieces of advice w= .r.t. the examples though:

In=C2=A0https://www.i= etf.org/mail-archive/web/cbor/current/msg00322.html, Carsten appears to= prefer that the canonicalization rules say to use the shortest encoding of= both floats and bignums, while in=C2=A0https://www.ietf.org/mail-archive= /web/cbor/current/msg00326.html Jim appears to prefer that cbor-based p= rotocols be able to define their canonicalization to use only 64-bit floats= and fixed-width bignums.

I've uploaded https://github.com/cbor-wg= /CBORbis/pull/13 to omit all changes to the float example and the descr= iption of tag canonicalization. Does anyone object to merging just that par= t?

Thanks,
Jeffrey

<= div>


On = Wed, Jan 10, 2018 at 7:38 AM Jeffrey Yasskin <jyasskin@chromium.org> wrote:
Line 1328 is not part of any of the defin= ed canonicalization rules. It's an example of a rule a document specifi= cation=C2=A0might choose to layer on top, as your message anticipates.
=
You might be saying that no document specification should ha= ve int/float fields that would be able to represent the same information tw= o ways? Otherwise, the document specification absolutely needs to pick one = of the representations for a given data value in order to have a canonical = representation.

Jeffrey

On Tue, Jan 9, 2018 at 11:10 PM Jim Schaad <ietf@augustcellars.com> wro= te:

No.

=C2=A0

Look at what is at line 132= 8 in the diff and that is exactly what I am talking about as should not be = done.

=C2=A0

Jim

=C2=A0=

=C2=A0

From: Jeffrey Yasskin [mailto:jyasskin@chromium.or= g]
Sent: Tuesday, January 9, 2018 10:25 PM
To: ietf@augustcellars= .com
Cc: Jeffrey Yasskin <jyasskin@chromium.org>; cbor@ietf.org; Carsten Bormann <cabo@tzi.org>
= Subject: Re: [Cbor] [core] draft-ietf-cbor-7049bis - Change suggested C= anonicalization

= =C2=A0

D= oes that mean you support the PR as-is, without the changes Carsten suggest= ed?

On Mon, Jan 8, 2018 a= t 8:12 PM Jim Schaad <ietf@augustcellars.com> wrote:

I did not like the id= ea of changing the types of items when doing canonicalization.=C2=A0 I want= to look just at what is given to me and thus do not like things like a flo= ating point number may be encoded as an any of a number of different format= s.=C2=A0 The choice of what an item is encoded as in terms of a floating po= int number is a function of the document specification and not the canonica= lization encoding format.=C2=A0 For things like big numbers, the encoding s= hould not be modified because the leading characters have been chosen by th= e application for a specific reason.=C2=A0 Consider the leading padding tha= t is part of a public key in cryptography where the length of the value is = of equal or greater importance that the fact that is has leading 0 or 0xff = bytes.=C2=A0 The rules for mapping between the data model and the encoding = are as much up to the protocol specification as they are for the CBOR speci= fication.=C2=A0 It is possible that a specification will only want to use t= he 64-bit floating point number format because it really simplifies the app= lication even if it makes the encoded format longer.

=C2=A0

In sort, I= do not believe that the rules should be extended beyond how an encoding wo= rks for a single encoded data format.

=C2=A0

Jim

=C2=A0

=C2=A0=

From:<= /b> CBOR [mailto:cbor-bounces@ietf.org] On Behalf Of Jeffrey Yasskin
Sent:= Monday, January 8, 2018 10:34 AM
To: Jeffrey Yasskin <jyasskin@chromium.o= rg>
Cc: cbor@ietf.org; Carsten Bormann <cabo@tzi.org>
Subject: Re: [Cbor] [core] dr= aft-ietf-cbor-7049bis - Change suggested Canonicalization

=

=C2=A0

Now that we're past the holida= ys, are there more comments on=C2=A0https://github.com= /cbor-wg/CBORbis/pull/9?<= u>

On Fri, Dec 22, 2017 at 3= :56 PM Jeffrey Yasskin <jyasskin@chromium.org> wrote:

I don't think https://github.co= m/cbor-wg/CBORbis/pull/9=C2=A0allows anything that RFC7049 didn't, = which is the meaning I get from "open this up".=C2=A0

=C2=A0

=

We *could* move this (all of section 3?) to a separa= te document, but I haven't seen anyone say that we need to. A downside = of moving section 3 to another RFC is that it'll make it harder to find= . Someone authoritative (Francesca?)=C2=A0should just make this call so tha= t we can stop angsting about it.

=C2=A0

I'm = generally happy to change exactly which examples demonstrate that protocol = designers need to think about canonicalization even if they start from the = core canonicalization requirements. I'd appreciate a concrete statement= of which examples to use though.

=C2=A0

Once we= add floating values, the type of a field matters in defining its canonical= ization. A float64 field only needs to canonicalize NaN. A float16/float32/= float64 field needs to canonicalize to either the smallest or largest type.= An int/float field needs to again canonicalize toward or away from int. A = bigint field needs to prefer either a fixed-length (u= seful for cryptographic signatures) or the=C2=A0shortest representat= ion. A decfrac/bigfloat/number field has an even more complex problem. I do= n't personally have enough examples of existing canonicalized CBOR-base= d protocols to make any confident recommendations here. If the list gives m= e some, along with the field experience that justifies them, I'm happy = to write them down in my patch.

=C2=A0

Jeffrey

=C2=A0

On Fri, Dec 22= , 2017 at 2:23 PM Carsten Bormann <cabo@tzi.org> wrote:

Hi Jeffrey,

qu= ick reactions after a first skim:

I=E2=80=99m not sure the direction= should be to open this up; I think the recommendations should become more = narrow as we learn about the practical issues.

We could write a sepa= rate document on the preferred c14n so we can keep this out of the main doc= ument.

I don=E2=80=99t think we necessarily want to encourage cross-= over between int and float, so I think the =E2=80=9Cshortest float=E2=80=9D= rule should be applied independent of whether that cross-over is desired.<= br>
Why keep the =E2=80=9Cshortest int=E2=80=9D rule less well defined f= or protocols that use bignums?=C2=A0 It should apply there as well, i.e., u= se bignums only for integers too large for the major type 0/1 formats.
<= br>Gr=C3=BC=C3=9Fe, Carsten


> On Dec 22, 2017, at 23:13, Jeff= rey Yasskin <= jyasskin@chromium.org> wrote:
>
> On Sun, Dec 3, 2017 at= 6:15 AM Carsten Bormann <cabo@tzi.org> wrote:
> On Nov 30, 2017, at 23:14, Jeffrey = Yasskin <jyas= skin@chromium.org> wrote:
> >
> > Belatedly, I'= ;ve discovered a user of "canonical" CBOR who's proposing a d= ifferent map order than the RFC suggests: https://fidoalliance.or= g/specs/fido-v2.0-rd-20170927/fido-client-to-authenticator-protocol-v2.0-rd= -20170927.html#message-encoding. (Note that this isn't a final stan= dard yet and may change.)
>
> I looked at the spec referenced.<= br>>
> So they essentially add
>
>=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If the major types are = different, the one with the lower value in numerical order sorts earlier.>
> as a major sorting rule before the existing RFC 7049 canonic= alization rules:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=E2=80=A2 If two keys have different lengths, the short= er one sorts earlier;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0=E2=80=A2 If two keys have the same length, the one with t= he lower value in (byte-wise) lexical order sorts earlier.
>
> = This is different from simply going for byte-wise lexicographic (memcmp ord= er(*)), which effectively would get us the first rule as the major sorting = order already, but get rid of the length-based second rule (first rule in S= ection 3.9 of RFC 7049).
>
> I=E2=80=99ve come to see the putti= ng the length comparison rule early in 3.9 as a major regression.
> O= ne of the objectives when designing the CBOR serialization was not to repea= t one big mistake that ASN.1 BER makes: to make overall lengths of complex = composite items visible/important in the encoding of the next higher compos= ite.
> Here, we are doing just that.=C2=A0 D=E2=80=99oh.
>
&= gt; > This is justified by the RFC saying that "Those protocols are= free to define what they mean by a canonical format and what encoders and = decoders are expected to do.=C2=A0 This section lists some suggestions for = such protocols." That is (as Jim said), the RFC doesn't specify &q= uot;canonical" CBOR: it just provides an option for higher-level proto= cols to do so.
>
> Right.=C2=A0 So the change would be to menti= on two options for this, the old canonical, and the saner (memcmp order) ca= nonical.=C2=A0 Now the next step is finding names for legacy canonical/sane= r canonical.=C2=A0 We then have to decide whether we turn this into a separ= ate document, at Proposed Standard level, or believe that adding another su= ggestion to 3.9 is essentially a bug fix and can be done in the Standard le= vel document.
>
> > The use of a different order in CTAP is = going to either force its implementers to write custom CBOR encoders and de= coders or require the generic encoders to take a configuration option for t= he map order. If the generic encoders take an option, then it stops being a= n issue for CBORbis to suggest a different order.
>
> Right.=C2= =A0 So I think you are saying we get to fix this.
>
> I've = tried to implement this in https://github.com/cbor-wg/CBORbis/pull/9. I de= fined a core set of rules so that other specs can use them by reference, ga= ve several examples of protocols that will need to extend the rules, and de= fined a second set of rules that match the canonical order that RFC7049 sug= gested.
>
> Do folks like this direction?
>
> I don= 't have a strong opinion about which document should hold the canonical= ization rules. Can we ask the IESG which they'd prefer?
>
>= Jeffrey

--001a1144ad5c7ee4080564172014--