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.

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

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!