Subject: [Cbor] Examples of tag 21,22 and 23?

From: "Lundblade, Laurence" <[email-masked]>
Date: Tue, 11 Oct 2016 19:48:28 +0000

Can someone give some clear and concrete examples of the tags to hint at B64, B64url and B16 encoding?  Perhaps I haven’t done enough work in JSON and web-type apps to know.  Maybe this is trying accommodate translation of some extant JSON protocols into CBOR? If I was doing something new, then I don’t have to be bound by these?

More specifically
 - What would you do with a bstr if you didn’t encode in one of these if you are translating to JSON?   Would you just drop it?
 - What are the data types / use cases where you’d want to use B64url? 
 - Would you agree that B16 should be avoided unless there is some backwards compatibility need?

Thx

LL

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 Oct 2016 23:19:23 +0200

Hi Laurence,

> Can someone give some clear and concrete examples of the tags to hint at B64, B64url and B16 encoding?  Perhaps I haven’t done enough work in JSON and web-type apps to know.  Maybe this is trying a…

RFC 7049 says (Section 2.4.4.2):

   Tags 21 to 23 indicate that a byte string might require a specific
   encoding when interoperating with a text-based representation.  These
   tags are useful when an encoder knows that the byte string data it is
   writing is likely to be later converted to a particular JSON-based
   usage.

So the area of application is interworking with text-based formats (such
as JSON), assuming the (potential) presence of a CBOR-to-JSON converter
or similar.

I you don't have to interwork with JSON legacy, these Tags are not for you.

>  - What would you do with a bstr if you didn’t encode in one of these if you are translating to JSON?   Would you just drop it?

I believe a sane generic CBOR-to-JSON converter (that is not operating
in some strict mode) would encode untagged byte strings as base64url
(without padding), as this is what modern JSON-based protocols tend to
use for byte strings.  (Of course, this conversion loses information,
but that is not avoidable in this case.)

I don't know how to "drop" data in a CBOR to JSON conversion; JSON does
not even have a convenient data replacement indicator (null is pretty
overloaded).

>  - What are the data types / use cases where you’d want to use B64url? 

Imagine that you want to interwork with a JOSE implementation.
(Of course, there now is COSE, but there are JOSE implementations you
might want to talk to.)
You could send all the base64url data that would need to be in a JOSE
object (JWS, outer layer in JWE) as unencoded CBOR byte strings,
trusting the CBOR-to-JSON converter to correctly interpret the Tag 21
you put on the whole CBOR-encoded JOSE structure.
(Of course, this assumes that you are using the JSON form of JWS/JWE,
which most JOSE doesn't.)

>  - Would you agree that B16 should be avoided unless there is some backwards compatibility need?

All of Tag 21 to 23 is either about backward compatibility, about
designing for a mixed CBOR-JSON world, or usually both.

Tag 23: Well, there are some JSON-based protocols that require hex
coding of binary data (e.g., often cryptographic hashes are transferred
in hex, for reasons I don't quite get).

Anecdote 1: When we designed Tag 21 to 23, I was actively looking for
protocols that use base32 in a JSON string environment.  I didn't find
any (just base64url, base64, and hex), so there are no additional tags
for base32 (there would need to be multiple ones because of the large
number of base32 variants, only two of which are even described in RFC4648).
(Anecdote 2: When RFC 6920 was designed, I tried to get base32 into the
"nih" URL scheme.  There were implementer comments that base32 was "too
complicated to implement".  OK....)

Grüße, Carsten

---

From: "Lundblade, Laurence" <[email-masked]>
Date: Tue, 11 Oct 2016 21:41:22 +0000

Thanks for the info.

To be more specific, if one were designing a brand new protocol in CBOR and you wanted it to be easily transformed into JSON, how would you use these tags?   Could you just assume that all bstr items get encoded with B64URL and not even use these tags?  Or maybe to be safe you tag every bstr with 22?

LL

On Oct 11, 2016, at 2:19 PM, Carsten Bormann <[email-masked]> wrote:

> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 12 Oct 2016 08:17:15 +0200

> To be more specific, if one were designing a brand new protocol in CBOR and you wanted it to be easily transformed into JSON, how would you use these tags?   Could you just assume that all bstr items get encoded with B64URL and not even use these tags?  

Again, assuming sane CBOR-to-JSON converters, this is what I would do.

Alternatively/additionally, you could tag the whole structure with Tag
21 (outermost Tag), which is equivalent to prepending single byte with
the value 0xd5.  This would allow a CBOR-to-JSON converter that operates
in a strict mode to make this conversion safely as well.

Note that, in the inverse direction, your CBOR consumer must be prepared
to find text strings where it expects byte strings, and it must convert
them back to byte strings via base64url (a generic JSON-to-CBOR
converter can not do this for you as it doesn't have any hints to go by).

> Or maybe to be safe you tag every bstr with 22?

That is not needed (see above).  (It would be Tag 21 for base64url.)

Grüße, Carsten