Subject: [Anima] which base64 for RFC8366... original!

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Oct 2019 10:48:12 -0400

In answering DISCUSSes on BRSKI, I came up the question of do the
YANG-serialization-to-JSON rules specify which base64 (original
or urlsafe) encoding is to be used for "binary" types?

RFC8366 only references RFC7950, which only peripherally mentions JSON, but it does say:

9.8.2.  Lexical Representation

   Binary values are encoded with the base64 encoding scheme (see
   Section 4 in [RFC4648]).

9.8.3.  Canonical Form

   The canonical form of a binary value follows the rules of "Base 64
   Encoding" in [RFC4648].

but maybe this only applies to XML-serialization.... searching further:

So, why doesn't RFC8366 reference:
    https://datatracker.ietf.org/doc/rfc7951/

6.6.  The "binary" Type

   A "binary" value is represented as a JSON string -- base64 encoding
   of arbitrary binary data.

   The representation is identical to the lexical representation of the
   "binary" type in XML; see Section 9.8 in [RFC7950].

AHA, so it should be original base64, even though the first paragraph is a
bit ambiguous, it does refer to 7950, which is not ambiguous.

I wonder if this is worth an errata clarifying this for RFC8366?

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 22 Oct 2019 17:39:33 +0200

> On Oct 22, 2019, at 16:48, Michael Richardson <[email-masked]> wrote:
> 
> Signed PGP part
> 
> or urlsafe) encoding is to be used for “binary" types?

Legacy (RFC 4648 Section 4 = non-URL-safe, with padding).
Look at the examples, which give it away by always ending in == :-)

>   Binary values are encoded with the base64 encoding scheme (see

There it is.

The YANG-to-JSON rules are in RFC 7951.

6.6.  The "binary" Type

   The representation is identical to the lexical representation of the
   “binary" type in XML; see Section 9.8 in [RFC7950].

So this is legacy, too.

>    https://datatracker.ietf.org/doc/rfc7951/

No idea.

But then, RFC 8366 says

   The voucher artifact is a JSON [RFC8259] document that conforms with
   a data model described by YANG [RFC7950], is encoded using the rules
   defined in [RFC8259], and is signed using (by default) a CMS
   structure [RFC5652].

which is pretty much devoid of meaning.

> I wonder if this is worth an errata clarifying this for RFC8366?

Yes, but maybe the WG should decide first what was intended…

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Wed, 23 Oct 2019 08:26:18 -0400

> which is pretty much devoid of meaning.

Well, it does tell you that the YANG to be serialized.
It whould have reference 7951 though.

    > Yes, but maybe the WG should decide first what was intended…

I'm an author.... we intended for binary stuff to get base64-encoded, but I
don't think any of us quite understood enough about the different flavours.
I would have preferred that RFC7951 had maybe said that it shall be
base64URL, but that base64 shall be tolerated.
It's irksome because JWS specifies base64URL, and the JSON spec is silent.