What is/was SEC#1 ECC public key leading octet 0x01 for?

In the SEC#1 elliptic curve cryptography standard, the encoding of the public key involve a leading octet:

• 00h: The public key is the point at infinity.
• 02h, 03h: The public key is the compressed point.
• 04h: The public key contain both x and y coordinates.

What is (or was) the value 01h for? Had there been other values defined for ECC?

I don't know for sure, I can only bring additional intel, and a theory.

This convention already existed in ANS X9.62-1998, section 4.3.6 Point-to-Octet-String Conversion, which also assigns $$06$$ and $$07$$ to indicate another 'hybrid' encoding method. Just like in compressed form, the parity of the format indicator encodes a quantity. Quoting:

The octet string representation of the point at infinity $$\mathcal O$$ shall be a single zero octet $$PC = 00$$. (…)
If the compressed form is used (…) Assign the value $$02$$ to the single octet $$PC$$ if $$\tilde y_p$$ is 0, or the value $$03$$ if $$\tilde y_p$$ is 1. (…)
If the uncompressed form is used (…) Assign the value $$04$$ to the single octet $$PC$$. (…)
If the hybrid form is used (…) Assign the value $$06$$ to the single octet¹ if $$\tilde y_p$$ is 0, or the value $$07$$ if $$\tilde y_p$$ is 1. (…)

So my theory is that bit 0 of the identifier $$PC$$ is reserved for an additional bit in formats where that makes sense, with the format itself encoded in the other bits of PC. Thus $$01$$ and $$05$$ are unassigned, because there is no additional bit to be coded for the point at infinity or when using uncompressed form.

Notice that the point at infinity is not a valid public key in ECDSA, and would be a lousy one.

¹ sic: the mention $$PC$$ is missing.

• Coincidentally, today's XKCD is about the razor.
– fgrieu
Nov 13 at 13:18
• Although by 2002 rfc3279 (for point(s) in a PKIX certificate) allowed only compressed and uncompressed, not hybrid. (It did retain the X9.62 explicit parameters for a custom (Weierstrass) curve group, which rfc5480 in 2009 removed.) Nov 13 at 22:44