Personal
PKI Toolkit
Alpha
(proof of concept)
http://home.earthlink.net/~johnridgecook/Personal_PKI_Toolkit.html
On this site are folders
with self-contained files for creating X.509 digital certificates of various
types.
A bit of history
Long, long ago (2001) David Howe, Sam Schinke, and myself began to experiment
with this form of cryptographic keys in the Old Country. The idea began
to arise that it may be possible to create public keys whose use could extend
across several trust models (SSL,S/MIME, PGP/GPG, IPSec VPNs, perhaps SSH,
Windows EFS, the coming Palladium OS
releases and IPv6). To this end, David configured the Unix open source
program, OpenSSL, for Windows and wrote a series of batch files. They worked
but were clunky.
This reasoning also lead to the idea of building a SecureComp Certificate
Authority, combining features of PGP’s Web of Trust and a hierarchical PKI
structure. The Cambridge Model is an example and features from that were
borrowed. The SC CA would authenticate, using various standards,
submitted certificates, building up trust in those keys and their owners.
As SC progressed, those very same certificates might be used in advanced
networking, secure communications, and just fun; as well as more general
use on the Web.
Time passed and fitful progress was made on the CA front, but the certificate
creation was always a barrier. It was too difficult to do for the average
user and rather frustrating for a more advanced user. The realization
began to dawn that an Open Source front end GUI was necessary for
OpenSSL. People were contacted and interest expressed, but a more
organized file collection was needed to show exactly what happening and what
the goal was.
Recent revelations of a SSL hole prompted David to revisit OpenSSL, offer the
latest patched version for Windows (March, 2003) and rework the batch
files. At that time, for whatever reason, I felt more comfortable with
the files and worked to reorganize them. The result is –
Personal PKI ToolKit – Alpha (Proof of Concept)
These files contain ALL that is needed to create-
A) A Root-User hierarchy, suitable for use by a small office or family
who need the ability to securely communicate. The resulting certificates can be
imported to work/school mainline email clients for S/MIME or personal machines
and various VPN programs. In a small business environment, they would
provide the necessary elements for having a secure website, email, file
transfers, or VPN…if the Root Certificate can be distributed and accepted with
confidence.(here)
B) A Root-Intermediary-User hierarchy for a full fledged Certificate
Authority. Here one could have a Root, signing multiple authenticating
Intermediaries (Europe, Asia, North America-or-Accounting, Sales, Management…)
who then signs Users under those particular Intermediaries. (here)
C) An end User certificate request for submission to an existing
Certificate Authority. This request can be of whatever key size and
contain whatever data you wish. When the signed certificate is returned, it can
be combined with its private key and converted to .p12/,pfx format for import
into Internet Explorer, Mozilla/Netscape, PGP, and any other program that uses
X.509 certs. (here)
Included is the program, Putty Key generator, for an easy non-PGP source of
random data.
The batch files have been rewritten and coordinated so that anyone with a
moderate level of Windows experience can easily use them. Truthfully,
this is the best I can do and I don’t see how much more they can be improved
without a GUI.
For GPG users, I have found that GPG will accept the certs (4096 bit max) once
they have gone through PGP and exported as v3 RSA .asc keypair ; as long as
they have been self signed. The problem comes up with the Root cert,
since OpenSSL self signs it. PGP recognizes that signature and will not
do it twice. GPG does not and will not import the keypair. Import
into a 2.6.3 Multi version of PGP, then signing may solve that glitch
Note-Guy reports a work around that solves this problem-
“I export the key (including secret) with the
X.509 certificate.
On the keyring I delete the X.509 certificate and self sign the key
with a exportable signature. Then re-import the previously exported key.”
Uses of X.509 certificates are controlled by “extensions”. Internal code
which say what this cert is allowed to do. The default for theses files
is “everything”. Once in IE that program lists one of these User certs can be
used for-
Server
Authentication, Client Authentication, code signing, secure email, time
stamping, MS trust list signing, MS time stamping, IP Security end user, IP
Security User, Encrypting File System,. Windows Hardware Driver verification,
Windows system component verification, OEM Windows system component
verification, Embedded Windows system component verification, key pack
licenses, License server verification, smart card logon, Digital Rights, file
recovery.
More can be added with the right “oid” number.
(note-the current 2nd level files
are being protested by some applications, though they work. Refinement in the extensions options is
being checked-RC)
The goal for the GUI is to make this process even clearer and easy. Filling in
blanks instead of altering config or batch files. Streamlining file management
and making extension control a matter of checking boxes. Some attempts have
been made for Linux in Python or Perl , TinyCA (http://tinyca.sm-zone.net/), OpenCA (http://openca.sourceforge.net/), and
the Microsoft CertServer on Windows 2000 Server are good places to look for how
they do it.
Future goals may be extending the GUI to encompass the S/MIME features of
OpenSSL so that email encryption can be done outside of email clients who may
not have that capability (or whose competence one may distrust). Simple key and
file management would have to be included.
To be done-
Fine tune the Intermediary Certificates, sometimes IE will place them in the
proper store, sometimes not. Mozilla treats all certs signed by an accepted
Root as being on the same level, displaying them as such. This has no
effect in following a trust chain and making judgments as to validity.
Confirm the GPG importation of keys and make it consistent. Once again,
it seems to work most of the time as described, but sometimes not, for unknown
reasons.
Decide on a different key hash or have multiple ones so
that cert/key fingerprints are consistent across several applications.
Explore the S/MIME uses of OpenSSL.
Work and work these files until they are totally understood under different
production environments.
Comments or questions can be directed to-
news://news.securecomp.org/WebOfTrust
Enjoy.
Thanks to David Howe.
Yours-
Ridge Cook
---PGP Key 0x43537711---
3/15/03