Lijun,
Thanks! This is just what I need. Though sigAlgorithm is in the
Issue's DET as the SuiteID (rfc9374). So if needed, I can save 1 byte. :)
Back to my writing. The deadline is, well a deadline!
Back in my early automotive days, the saying was: "Job 1 is a wall, you
will hit it". You NEVER wanted to be on critical path. All your bosses
up to Lee Iacocca (my Chrysler days working on the Jeep Cherokee) saw
that you were holding things up! I, personally, was on critical path
once for ~15min. Yes, it was watched that closely....
Not our IT tech team. My job on that team. Sheesh! PERT charting was
the Devil's tool.
Bob
On 2/12/26 3:00 AM, Lijun Liao wrote:
Robert,
If outside the C509 context, one of the most compact format could be:
[
syntax-version: 1 byte
sigAlgorithm + subjectPublicKeyAlgorithm: 1 byte
notBefore: days since t (e.g. t = 2026-01-01T00:00:00 UTC): 1 + max
2 byte
notAfter: days since notAfter: 1 + max 2 byte
issuer's DET: IPv6, 1 + max 16 byte
aircraft's DET: IPv6, 16 byte): 1 + max 16 byte
aircraft’s number: 1 + 3 byte
subjectPublicKeyValue: 1 + 32 byte
issuerSignature: 1 + 64 byte
]
Such a certificate has max 144 bytes (1152 bits), you need 3 pieces of
385-bit to transport this certificate.
:)
Lijun
On 12. Feb 2026, at 00:24, Robert Moskowitz <[email protected]>
wrote:
Lijun,
Take a look at this test cert pem:
-----BEGIN CERTIFICATE-----
MIIBlzCCAUmgAwIBAgIUIBchL50BW8ZvGvYJnwmKpXlkG/wwBQYDK2VwMF0xCzAJ
BgNVBAYTAlVTMSgwJgYDVQQKDB9GZWRlcmFsIEF2aWF0aW9uIEFkbWluaXN0cmF0
aW9uMSQwIgYDVQQDDBtGQUFfSURNU19EUklQX0lTU1VJTkdfQ0FfUjEwHhcNMjYw
MTEyMDAwMDAwWhcNMjYwMTI1MjM1OTU5WjAAMCowBQYDK2VwAyEAPXOiNhov+OFn
GQsQCnnaoXhM65jj+wiX6MOpzXo6RIGjeDB2MB8GA1UdIwQYMBaAFDzbFPZvFLEx
5Kd+uFUwnAKSfhZsMBcGA1UdEgQQMA6CDGhkYS5kcmlwLm5ldDAbBgNVHREEFDAS
hxAgAQAzy4AgBc1wj8n299KUMB0GA1UdDgQWBBS0w3g5XGbr4O50uZgUj04/w45y
ozAFBgMrZXADQQAa99YqyLmDjTxbPnhlOE+AaNfeSuK3EjeFB4gI4lfFTYo6JJFq
JcRBXWOtXbkdFW1rRxmCxUIZL1b9/qZidIEL
-----END CERTIFICATE-----
DISCLAMER: This is a TEST cert from a TEST CA. No commitment by FAA
in this is what they are or plan on doing. For example, it does not
contain any of the FAA's policy OIDs (and they have a bunch of them).
It is kind of what may be actually used, but way to big to send
in-band. It will be in the DNS per rfc9688. This one does not have
the SAN IPv4, but you can figure out what that is.
Anyway what I am trying is to subset this cert's c509 to only have:
* Validity dates
* issuerAltName (IAN) IPv6 (issuer's DET per rfc9374)
* subjectAltName (SAN) IPv6 (aircraft's DET per rfc9374)
* subjectAltName (SAN) IPv4 (aircraft's 24-bit number prefixed with
ZERO)
* Aircraft's EdDSA25519 public key
And a specific CBOR sig of only these fields, not the cert's sig.
This much info allows for DNS lookup of the full certs for Internet
connect systems. For non-connected systems that have the Issuer's
cert (and back to root) cached, they can validate this object and use
its PK to validate the TESLA signed key.
So, this is the challenge.
I have to live within what the CivilAviationAuthorities (e.g. FAA)
will do for aircraft certs. Have those available, but only send a
small piece over the air.
Not your "normal" c509 cert work. But then, for starters, I have to
deal with CAAs following the ICAO CP for big winged things.
:)
On 2/11/26 5:25 PM, Lijun Liao wrote:
Robert,
If you use C509 certificate, one solution is:
c509CertificateType: 1 byte
certificateSerialNumber: 1 + n bytes (for n bytes bitint)
issuerSignatureAlgorithm: 1 byte
issuer: CN=issuer’s DET (1 + k bytes: k=len(IPv6))
validityNotBefore: 1 + 4 bytes
validityNotAfter: 1 + 4 bytes
subject: DET=aircraft’s DET (1 + k bytes: k=len(IPv6))
subjectPublicKeyAlgorithm: 1 bytes
subjectPublicKey: 1 + 32 bytes
extensions: 8 bytes
SAN: aircraft’s IPv4 DET:
issuerSignatureValue: 1 + 64 bytes
Count it together, you need sum = 122 + n + k + k bytes.
Let n = 8, k = 16, then sum = 162 bytes = 1296 bits = 3 * 385 + 141
bits.
Cheer
Lijun
On 11. Feb 2026, at 16:32, Robert Moskowitz
<[email protected]> wrote:
I have to squeeze only those fields into as few 385-bit pieces to
validate a TESLA Key Disclouser.
Ugh.
So "all" I need from the aircraft full certificate (ignore all
those policy OIDs and other odds and ends!) is:
* Validity dates
* issuerAltName (IAN) IPv6 (issuer's DET per rfc9374)
* subjectAltName (SAN) IPv6 (aircraft's DET per rfc9374)
* subjectAltName (SAN) IPv4 (aircraft's 24-bit number prefixed
with ZERO) - note I have not figured out any better/smaller OID
(in subject or SAN) for the 24-bit aircraft number. Using IPv4
is a hack at best.
* Aircraft's EdDSA25519 public key
* CBOR sig of these by issuer's EdDSA25519 key
Note that the issuer DET's SuiteID provides the algorithm for the
signature.
I am trying to use cbor.me to expand some test cbor c509 certs to
get sizes, but I am not good enough with cbor to figure this out.
Plus that sig would probably be a "regular" cbor object signature,
not the c509 sig.
I am under a deadline with a bunch of other writing that this is
just one important part, so any help is greatly appreciated.
Each 385-bit message costs 120ms of channel capacity. The fewer
the better...
Bob
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
COSE mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
COSE mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
