Subject: [netmod] base64 versus base64url

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Nov 2014 09:54:59 +0100

Hi,

Balazs rightly pointed out that values of the binary type can potentially appear in RESTCONF’s Request-URI (in the “point” parameter), so it might be prudent to make the encoding URI-safe and use base64url instead of base64. Could this change be done in YANG 1.1?

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 19 Nov 2014 10:05:16 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> Hi,
> 
> Balazs rightly pointed out that values of the binary type can
> potentially appear in RESTCONF’s Request-URI (in the “point”
> parameter), so it might be prudent to make the encoding URI-safe and
> use base64url instead of base64. Could this change be done in YANG
> 1.1?

I don't think it is worth it.  Normal strings are probably much more
common as keys, and they can certainly contain characters that need to
be url encoded.  So solving this for this particular type isn't worth
it.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Nov 2014 10:15:28 +0100

> be url encoded.  So solving this for this particular type isn't worth

Not for normal use, I agree, but don’t forget about bad guys who might put it somewhere intentionally as a Trojan horse. I don’t see any significant compatibility issue if this gap is closed in YANG 1.1.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Nov 2014 10:43:43 +0100

> Balazs rightly pointed out that values of the binary type can potentially appear in RESTCONF’s Request-URI (in the “point” parameter), so it might be prudent to make the encoding URI-safe and use b…

Lada,

I do not think this would pass the backwards compatibility test. RFC
6020 says:

  9.8.2.  Lexical Representation

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

I do not think we can say that this is now something different. I
agree with Martin that other YANG types may contain values that need
url escaping as well.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Nov 2014 11:17:03 +0100

> I do not think this would pass the backwards compatibility test. RFC

The compatibility restriction in the charter is OK: YANG 1.0 modules won’t become invalid.

> agree with Martin that other YANG types may contain values that need

This is true, but for a “binary” value it would be generally harder to spot.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 19 Nov 2014 11:31:42 +0100

> The compatibility restriction in the charter is OK: YANG 1.0 modules won’t become invalid.

The data encoding on the wire would be different - I doubt that this
is what we are chartered to do in YANG 1.1.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 19 Nov 2014 11:45:57 +0100

> is what we are chartered to do in YANG 1.1.

OK, if nobody thinks it is a problem worth solving, we can stick to base64.

Lada