Can create a cert with no serial number?

Thu Jun 1 18:59:13 UTC 2023

> On Thu, 2023-06-01 at 08:01 -0700, Job Cacka wrote:
> > “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

Of course, trying to change the signed contents (i.e., manipulating the
hashed part) is not what I meant.
But:
 * make sure that those low-entropy fields have "easily compressable"
   content
   by taking advantage of inessential or repeated portions of those
   strings
 * then let the CA sign the cert as usual
 * wherever size matters during storage and transfer, perform an
   efficient (likely custom) lossless compression on the cert
 * before using the cert (for any validation stuff where the cert is
   involved), uncompress it to its original form

Yet is mentioned, this hint is likely just theoretical/hypothetic,
because the receiving party would need to be able to handle (i.e.,
uncompress) such certs

David

>  
> 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>:
> > > >     
> > > >          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/dc3debfb/attachment-0001.htm>