Client identifier in 103 270

[Andy Buckingham]

Hello,

In Section 9.2 of TS 103 270 v1.4.1 (2022-05) we define the client identifier format as:

A client identifier is a string of between 16 and 128 characters, drawn from the allow characters:

[a-zA-Z0-9]

In Section 9.3.3 it is then stated:

• the credentials are defined in the "token68" syntax defined in IETF RFC 7235 [14], section 2.1, with the value computed from the client identifier string. 

RFC 7235 states:

     token68        = 1*( ALPHA / DIGIT /

                          "-" / "." / "_" / "~" / "+" / "/" ) *"="

   The token68 syntax allows the 66 unreserved URI characters

   ([RFC3986]), plus a few others, so that it can hold a base64,

   base64url (URL and filename safe alphabet), base32, or base16 (hex)

   encoding, with or without padding, but excluding whitespace

   ([RFC4648]).

My understanding therefore is that 9.2 overrides, or rather, restricts further the definition of token68, to limit to only alphanumeric characters and define a min and max length which does not exist in RFC 7235. I’m wondering if this should be more clearly explained in a future update to the spec, as if you dive in to 9.3.3 it may give the impression you can use characters forbidden in 9.2.

In addition, whereas token68 (or, rather, the subset base64url) is supported in common crypto libraries, generating only a-zA-Z0-9 in a reasonably (cryptographically) random way is left as a more complicated exercise for the developer. Not a significant concern, but I assume the desire to reference token68 was initially added to try and make this easier?

We could make token68 consistently the defined character set in 9.2, retain the 16/128 character limits, but this would only be backwards compatible for those generating tokens. Anyone parsing tokens based on the current spec should fail a valid token68 token where it contains -, ., _, ~, + or /.

Therefore, I think we’d have to keep it as it is and potentially remove the reference to token68 for clarity.

Has anyone else experienced any issues with this, or thoughts on how we might improve this section of the spec without breaking backwards compatibility?

Regards,

Andy.

[Byrion Smith]

Hi Andy,

 

In case it helps, that set of characters is known as Base62, which might help to clarify the spec.

https://en.wikipedia.org/wiki/Base62

Thanks,

Byrion

--
You received this message because you are subscribed to the RadioDNS developers group. RadioDNS is at http://radiodns.org/
To post to this group, send email to
radiodns-...@googlegroups.com
To unsubscribe from this group, send email to
radiodns-develo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/radiodns-developers?hl=en
---
You received this message because you are subscribed to the Google Groups "RadioDNS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to radiodns-develo...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/radiodns-developers/D11D0DAE-2858-49D5-8209-D8A69D36F514%40radiodns.org.