Lekensteyn
commented
3 months ago 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
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_dataentries 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.