Handling of unrecognized identifiers

[dennisjackson]

As noted by Ilari in #18, there's a possible ambiguity with the use of three byte identifiers in this draft. Although currently three byte cert_data entries are not possible with X509, this could hypothetically change.

I can see a few options:

a) Since there is currently no valid 3-byte cert_data payload when using X.509 certs, require compression to fail if any 3-byte payload is seen. Then decompression can fail if any unrecognized 3-byte payload is seen. This effectively 'reserves' all three byte length sequences for this draft.

b) Require compression to fail if 3-byte payload passed to the compression algorithm would clash with an identifier in the scheme. Then decompression can safely ignore any unrecognised 3-byte identifier - since it was present in the original uncompressed Certificate message.

c) As in b) but 'reserve' some space of identifiers, e.g. 3 bytes beginning 0xff etc.

I slightly prefer b) or c) although this is additional implementation complexity for a code path which is likely to never be used in practice.

[Lekensteyn]

While reading through the current -01 draft, I was surprised to see this ambiguity:

Unrecognized three-byte identifiers are ignored.

I would be in favor of (a) which is also simple. By definition, the DER encoding of an X.509 certificate is longer than three bytes: https://www.rfc-editor.org/rfc/rfc5280#section-4.1