Further simplifications

[gselander]

The current encoding mechanism is a trade-off between encoded certificate size and code complexity. It has been suggested by @xipki remove some special cases for a cleaner design:

• Name (e.g. in Issuer & Subject)

1. Page 6: common name consisting of even-number of lowercase hex letters
2. Page 6: common name consisting of EUI-64 MAC address
3. Page 6: Name consisting only of a common-name attribute, except case 1 and 2.

• Extensions:

4. Extensions contains only one Extension keyUsage (Page 7).

There is no obvious right or wrong here. Comments are welcome.

[xipki]

I raised an issue (#140) before to discuss this before, and agreed not to change the special cases, since we do not want to change the syntax.

In the next version (-10), the C509 certificate types 0 and 1 are increased to 2 and 3 respectively. This allows us to do more improvements, even with syntax change, e.g. removing the special cases above.

[gselander]

I raised an issue (#140) before to discuss this before

Yes, and I think it should remain an issue pending more input.

In the next version (-10), the C509 certificate types 0 and 1 are increased to 2 and 3 respectively.

Those new numbers were only introduced to gracefully handle early adoption of the draft. That change does not warrant any change in design, but arguments about complexity do, as may other input.

[gselander]

Side notes.

1. CBOR encoding of MAC addresses:
   https://www.rfc-editor.org/rfc/rfc9542.html#name-cbor-tags

2. CBOR encoding of IPv6 addresses:
   https://datatracker.ietf.org/doc/html/rfc9164#name-ipv6

[gselander]

Some of the authors discussed this issue. We don't have enough input to make a change. These special cases were introduced based on previous assessments of relevant optimizations. If we are reconsidering them then we would need more input. Please give an example how complicated this can be. Further proposals for encoding or combining these special cases are also welcome!

[gselander]

Note above updated with examples:

1. CBOR encoding of MAC addresses:
   https://www.rfc-editor.org/rfc/rfc9542.html#name-cbor-tags

Example:
EUI-48: "F8-16-3E-FF-FE-60-02-17"
CBOR diagnostic: 48(h'F8163E600217')
CBOR:
D8 30 # tag(48)
46 # bytes(6)
F8163E600217 #

2. CBOR encoding of IPv6 addresses:
   https://datatracker.ietf.org/doc/html/rfc9164#name-ipv6

Example:
IPv6: 2001:0db8:1234:deed:beef:cafe:face:feed
CBOR diagnostic: 54(h'20010db81234deedbeefcafefacefeed')
CBOR:
D8 36 # tag(54)
50 # bytes(16)
20010DB81234DEEDBEEFCAFEFACEFEED #

One byte gained with the current bespoke encoding. Is this sufficient motivation?

The only use of "bytes" in
Name = [ * Attribute ] / text / bytes
is for EUI-64/48, IPv6 addresses (arbitrary byte strings), and the empty byte string (null).

For EUI and IP-addresses there are CBOR tags 48, 52, 54 which has more clear semantics. Do we need generic byte strings?

If we replace "bytes" in the definition of "Name" with certain CBOR tagged items, we can replace the empty byte string h'' with the empty text string "".