On 2/13/26 6:06 AM, Michael Richardson wrote:
Robert Moskowitz <[email protected]> wrote:
> On 2/12/26 8:55 AM, Michael Richardson wrote:
>> Robert Moskowitz <[email protected]> wrote: >
>> subjectAltName (SAN) IPv4 (aircraft's 24-bit number prefixed with
>> ZERO)
>>
>> What's that? It does not sound like a v4-address... are just abusing
>> this SAN?
> Yes, I am hacking the 24-bit aircraft number (24AN) into IPv4 space by
> setting the first octet at ZERO. There is no good OID for this thing.
> "Common practice" for many airlines is to put it in CN= in subject.
I think this won't pass IESG.
SAN+otherName+OID you get from FAA or that you assign from your PEN, or from
an IETF arc. Maybe there is one which is shorter (in bytes) than other things.
It will probably never be in an RFC. It has to pass ICAO ACCP (doc
10169, FINALLY Published!)
SAN+otherName+OID is cert bloat. Even with the ICAO OID arc.
> My hack is at least recogonizable over all the different uses of CN= by
> aviation. Plus 24AN is assigned in blocks, of varying sizes, to each
> member state. The size was determined on usage patterns some years
> ago. Thus at the issuer level, IPv4Network could be used and for US it
> would be 0.160.0.0/12 (though probably subdivided for civil and gov
> spaces). Kyrgyzstan has 0.96.16.0/22; and probably does not subdivide
> their space.
uhm, sure, but both IPv4Network and CN= seem like horrible things to do in 2026.
If you weren't so byte-constrained, I'd say just go ask for another /64 from
2001:3x::/32..
Right now the 24-bit Aircraft Number (24AN herein) is a serious PII
issue. Monk and Swift successfully sued FAA, and are now part of the
Privative Number assignment, and FAA is finding all the things broken
with a feature rarely used (other than military, when military bothers
to turn on ABS-B).
At the Sept '25 ICAO congress there were a number of papers (I can
share, these are public) that call for changing 24AN use so it is no
longer PII (the Saudi's suggested encrypting everything like military
systems; non-starter). We really can't replace it in ADS-B with
something bigger, even with the larger Phase Overlay frames (I tried
this in Sept '24; minimum $25B radar systems upgrade in for US. Why
Trump's order to fix aviation radar won't fly either.). But I can add a
level of indirection and tie a DET and 24AN as a FlightID (FlightAware
is going to protest big time, sorry charlie) and those authorized
systems will tie things in at the backends (like airports billing for
usage).
We are having a design call today, and shaping things up for an early
Mar ICAO presentation.
As an aside, there are many OID hacks used in Aviation. By convention.
These are private PKIs, with some "public" bleed-out. In fact in
yesterday's ICAO PKI call (next steps on 10169, including PQC), we
discussed CABForum's change on use of EKU flags. FAA and EUCONTROL said
making these changes will break too many legacy systems that would take
upwards to 10 years to deploy. So we are bifurcating. Aviation private
PKIs need not change. Public facing PKIs (that appear in the Web trust
list) must conform.
One thing none of us can change is Physics. The agencies that control
spectrum usage (FCC for US) say that 1090Mhz band is so wide, live with
it. As long as ADS-B, ACARS, and others use 1090, we have as much data
we can stuff into RTCA defined (and MIT Lincoln Labs had their hand in
this long ago) 120ms packets. With the "old" Montgomery modulation,
that yields 112 bits. And so on.
Lots of dump here, but Physics, cost of components (do you know a civil
aviation ADS-B transponder costs $200,000 US?; when you can build one on
a RPi for ~$600), and politics frame the possibilities.
>> I don't remember if C509 let's us define extensions in pure CDDL/CBOR.
>> I think not...
> Nope. If it is not in 5280, you have to get creative.
That seems a poor thing for Natively-signed(COSE)-C509.
Maybe TBSCertificate CDDL could be extended with "cbor_extensions"
Or maybe there is further tricks we can do with extensionID to create a
C509-only extension registry.
I really need to stop calling this "compact-certificate" X.509 and
encoded in c509. It IS a collection of OIDs extracted from a real X.509
certificate, but they are really just treated as CBOR objects, then
signed with a CBOR sig object. It just happens that the key-owner for
this signing is the X.509 cert issuer, not cert owner.
I will invent a proper name for it on today's call :)
I still don't like the name "Natively signed", because whether people from
DER world will think of DER as "native"... CBOR/COSE is the "new" thing.
(And also, that word is less welcome in RFCs now)
I still think the bifurcation that it causes it not sufficiently explained in
cbor-encoded-cert.
And I really cannot call my sig object the c509-native signature, as
what is being signed is NOT a valid X.509 cert encoded in CBOR. It is a
collection of those OIDs that are needed, operationally, to validate a
signed message.
I will fix my terminology.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =- *I*LIKE*TRAINS*
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
