Werner's own blurbs

The STEED Self-Signing Nonthority

14 June 2012 6:26 PM (gnupg | steed | en)

Recently GnuPG got its feet in to the CA business. With 2.1beta3 the default installed certificates include this one:

      S/N: 01
   Issuer: /CN=The STEED Self-Signing Nonthority
  Subject: /CN=The STEED Self-Signing Nonthority
 validity: 2011-11-11 00:00:00 through 2106-02-06 00:00:00
 key type: 1024 bit RSA
key usage: certSign crlSign

Huh, what is that? Only 1024 bit — isn’t that insecure? Expires in 2106 — why this? Well, it even comes worse: We also distribute the corresponding private key in the source tarball at: tests/68A638998DFABAC510EA645CE34F9686B2EDF7EA.key.

Uh, that’s crazy. Not really: It is just another arbitrary certificate and GnuPG does not trust it unless the user confirms that it is a trustworthy root certificate. In fact any S/MIME mail may contain a self-signed certificates - they are actually quite common. So, what is special with that certificate?

A closer look shows that it features an uncommon signed attribute: 1.3.6.1.4.1.11591.2.2.2 which is also known as wellKnownPrivateKey (this OID is below the GNU arc). GPGSM (GnuPG’s S/MIME tool) recognizes this attribute, skips the check for trusted root certificates, and return an non-trusted error when operating in the standard validation models (shell and chain). Only in the steed validation model it does not return an error, this is because that model does not care about the certificate chain, but solely bases its validation result on the fingerprint of the certificate. In the steed model the whole certificate rummage is only used to convince existing software that it sees a real certificate. This allows to use existing software to store and transport such certificates. In GnuPG, this special root certificate makes it easier to handle certificates for the STEED system; without it GnuPG would need to make sure that all certificates used by the STEED system carry a special attribute, identifying them as STEED certificates. The solution with a special root is a bit cleaner. It also makes some fun of the existing public PKIs.

In case you wonder whether there is something special with the private key of this nonthority, check yourself: Build libgcrypt and run tests/prime --42.

No responses

Leave a Reply