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

[Carsten Bormann <[e-mail]>]

> On Oct 22, 2019, at 16:48, Michael Richardson <[e-mail]> wrote:
> 
> Signed PGP part
> 
> 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?

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

> 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]).

There it is.

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

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].

So this is legacy, too.

> 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/

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