Can create a cert with no serial number?

Thu Jun 1 15:01:23 UTC 2023

“If certificates could be transmitted/stored in efficiently compressed (zipped) from,
theoretically one could save a couple of bytes by choosing as values

of low-entropy fields such as notBefore, notAfter, subject, and issuer

not only strings as short as possible, but also with a high portion of repeated chars,

such as

  Issuer: CN = 20010000000000efS
  Not Before: Nov 11 11:11:11 2023 GMT
  Not After : Nov 11 11:11:11 2025 GMT

”

Intentionally repeating characters in a hash is a great way to provide the hash to be broken. As I recall there is something about repeating a character more than 3 times consecutively that decreases the effectiveness of the hash. So the use of the series of zero’s and the repeated pattern “11:” are probably bad for hash security. I am unsure if that matters in this context however. 

Thanks,

Job

From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of David von Oheimb
Sent: Thursday, June 1, 2023 12:00 AM
To: Robert Moskowitz <rgm at htt-consult.com>
Cc: openssl-users at openssl.org
Subject: Re: Can create a cert with no serial number?

Probably could cut more if I put the DET (a specific IPv6 address) 

somehow into subject rather than SAN flagged critical.  

Generally, removing X.509v3 extensions helps save space, 

yet replacing a SAN with an IPv6 address by a subject DN entry

simulating the value, e.g., in the CN would be counterproductive
because the binary representation in the SAN is more efficient.
Here is an example (ab-)using OpenSSL test credential material:

openssl x509 -new -CA test/certs/server-ed25519-cert.pem \
 -set_serial 2 -CAkey test/certs/server-ed25519-key.pem \
 -force_pubkey test/certs/root-ed25519.pubkey.pem -subj / \
 -extfile <(printf "subjectAltName = IP:2001:3F:FE3F:F805:A93E:53B7:2709:E0BA\n 
                    subjectKeyIdentifier = none\n authorityKeyIdentifier = none") \
 -days 365 -outform der | wc | awk '{ print $3 }'
226

openssl x509 -new -CA test/certs/server-ed25519-cert.pem \
 -set_serial 2 -CAkey test/certs/server-ed25519-key.pem \
 -force_pubkey test/certs/root-ed25519.pubkey.pem \
 -subj "/CN=20013FFE3FF805A93E53B72709E0BA" \
 -extfile <(printf "subjectKeyIdentifier = none\n authorityKeyIdentifier = none") \
 -days 365 -outform der | wc | awk '{ print $3 }'
238

Unfortunately you cannot drop the rather inessential notBefore field,

and the coding restrictions in RFC 5280

disallow using a shortened (possibly even empty) string there.

If certificates could be transmitted/stored in efficiently compressed (zipped) from,
theoretically one could save a couple of bytes by choosing as values

of low-entropy fields such as notBefore, notAfter, subject, and issuer

not only strings as short as possible, but also with a high portion of repeated chars,

such as

  Issuer: CN = 20010000000000efS
  Not Before: Nov 11 11:11:11 2023 GMT
  Not After : Nov 11 11:11:11 2025 GMT

                David

On Wed, 2023-05-31 at 14:19 -0400, Robert Moskowitz wrote:

Well, I got the DER down to 240 bytes by dropping all the constraints.  

Probably could cut more if I put the DET (a specific IPv6 address) 

somehow into subject rather than SAN flagged critical.  For your review, 

this is what I have come up with.  This will replace what I currently 

have in draft-moskowitz-drip-dki

Use of this cert will rely on the DNS structure we will be creating for 

DRIP.  For example to find the issuing cert, the CN below maps to a 

specific FQDN that any DRIP compliant implementation will know to find.  

And if this cert is not found in the matching ip6.arpa. fqdn it has been 

revoked.  This cert is 2x the size of the DRIP specific RATS-styled 

Endorsement.  Implementers will be able to choose their poison.

Certificate:

     Data:

         Version: 3 (0x2)

         Serial Number: 160 (0xa0)

         Signature Algorithm: ED25519

         Issuer: CN = 2001003ffe3ff805S

         Validity

             Not Before: May 21 00:00:00 2023 GMT

             Not After : May 24 00:00:00 2023 GMT

         Subject:

         Subject Public Key Info:

             Public Key Algorithm: ED25519

                 ED25519 Public-Key:

                 pub:

                     bf:04:53:a0:11:20:ed:8e:65:1a:e9:f6:95:1a:82:

                     78:3d:a8:20:29:6a:33:8e:ff:d5:4a:0b:a8:46:a9:

                     98:75

         X509v3 extensions:

             X509v3 Subject Alternative Name: critical

                 IP Address:2001:3F:FE3F:F805:A93E:53B7:2709:E0BA

     Signature Algorithm: ED25519

     Signature Value:

         d1:cd:bb:64:03:9e:95:1a:8c:fa:eb:59:a6:65:ff:bc:0f:39:

         e4:4f:ac:81:cf:c5:13:1e:62:e3:f1:bd:84:46:9c:5f:7c:52:

         ff:bd:3e:f8:e7:d4:9d:8d:38:fe:70:62:f9:9c:10:f1:aa:b0:

         46:c8:92:f9:9b:1a:09:d0:d6:0f

On 5/31/23 13:36, Richard Levitte wrote:

The serial number is a defined field in the certificate structure.

It's not optional, so you can't get away from it.

In ASN.1 terms, it's an INTEGER.  In DER terms, the smallest possible

INTEGER occupies 3 bytes (one for the tag, which is 02, one for the

length 01, and one value byte in the decimal range -128..127 (80..7F)).

Without the serial number (just like without any other non-optional

field), whatever you happen to produce will not be a recognisable

X.509 certificate.

That's it.

Cheers,

Richard

     Am 31. Mai 2023 15:41:02 MESZ schrieb Robert Moskowitz <rgm at htt-consult.com <mailto:rgm at htt-consult.com> >:

         I tried putting in my conf:

         serial = none

         and that made an error.

         Best I have done is a serial of length 1 byte.  But in my work, the subject or SAN provide uniqueness and CRLs will not be used.  So want to see if I can create a cert with NO serial number.

         Thanks

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mta.openssl.org/pipermail/openssl-users/attachments/20230601/3072d03c/attachment-0001.htm>