Actually we have demonstrated that 8 randomly generated bytes may have
collisions.
If you check out rfc9374, sec 9.5, I discuss the real risk of collisions
in the hash-generated right 8 bytes of the IPv6 DET. We manage this in
the registration (draft-ietf-drip-registries, sec 6) by rejecting
duplicate DETs. First-come-first-serve; typically the public keys are
different, but the hashes collide.
So here there is a real risk of serial number duplication, but the
subjectKey will be different. That is what I am pinning uniqueness on.
Here serial number is because. this whole effort is because there are a
few parties in the drone-to-drone direct communications work that hold
we have to have X.509 certs and they have to be small enough to fit in
the very constrained spectrum that will be regulated to use for this.
Meanwhile in my RATS-styled Endorsements, I provide all the trust these
individuals claim to need in 136 bytes and can compress 16 bytes out of
that
(https://datatracker.ietf.org/doc/draft-moskowitz-drip-a2x-adhoc-session/).
These X.509 certs are, in DER format, 240 bytes.
So I go through the work and then at the 'end of the day' we see how we
address this problem. Would not surprise if next they throw CBOR certs
out at me. Just to have flexible content, when everything points that
flexibility can be better handled as signed attributes in the
drone-to-drone messaging.
So sorry for any breaking of best practices. I would rather not spend
ANY time on this, but I have to show due diligence.
Sigh.
On 5/31/23 21:55, Viktor Dukhovni wrote:
On Wed, May 31, 2023 at 09:21:07PM -0400, Robert Moskowitz wrote:
openssl rand -hex 1 > $dir/serial
Don't do that. You'll quickly create collisions.
Initialise the serial number to 1 more than the
serial number of the issuing CA, and let it be
auto-maintained thereafter.
This assumes a sound digest algorithm is used, otherwise predictable
serial numbers make it easier to mount collision attacks on the CA.
Are you sure you actually need to squeeze out every last byte?
Premature optimisation ...
