Mark Windsor (mark(_at_)windsor(_dot_)a92104(_dot_)sai(_dot_)com) asks:
A few weeks ago, Mark Riordan asked here if anyone was working on
a public-domain implementation of PEM using RSAREF.
I have a less ambitious project in mind: a simple but usable PK
RSAREF-based encryption program. Everyone who gets RSAREF notices
immediately that such a thing is missing, and it doesn't seem like
it would be that hard to write one, given RSAREF.
Unlike PEM, which derives much of its complexity from its notion
of key certificates, with the associated Issuing Agencies, Certificate
Revocation Lists, Distinguished Names, etc., I'd propose to just
bypass the issue of how you gained trust in the public keys you're
using. (Maybe you simply called the other guy on the phone and verified
the PK directly.)
The program would allow you, then, to create and store keys, and to
encrypt, decrypt, sign and check messages. There would be some
simple facilities for mailing public keys to one another and
saving them associated with the name of the owner.
I believe this is basically the same functionality provided in Mark
Riordan's earlier program, rpem, which was based on Rabin encryption.
So, I will echo Mark's earlier question, and ask whether anyone is
working on a program like this. In particular, is Mark R. himself
doing something like this, or is he more interested in a full PEM
implementation?
Actually, this is exactly what I meant to be asking in my previous
posting. I intended "PEM" in the generic sense.
I am just starting on this and haven't written any code yet
(beyond what I already wrote in rpem).
I'd like to see some discussion of standardization of message formats
and possibly key formats for programs like this. I've looked at PEM
and at RSA's PKCS, but both are largely certificate-based. They'd
have to be at least modified for a simple non-certificate program
like this.
Right--this is the sort of thing I've been mulling over.
I'm not up-to-date on all the PEM standards and would hate to
go off and write something that's completely incompatible. On
the other hand, I'm not going to get into the certificate business,
and I don't want my little project to get out-of-hand.
My idea would be to use RFC 1113-1115 style headers as much
as possible, as was done in rpem. Whether this facade of standards
compliance would actually be of use to anyone is an unanswered question.
As for the storage of keys, I would invent my own format in the
absence of input from others. If there were standards on which I
could base the key formats of my implementation, I'd much rather
use them.
[Incidentally, I would want to encrypt the private components
of public keys with a cipher like DES. I consider it ironic that
RSAREF bundles a perfectly good DES implementation, but I am not
allowed to call their DES routines directly. This means I'd have
to link in a second, separate DES implementation--a bit of a waste. The
sample applies to RFC 1113 encoding. I hope RSA relaxes their
restrictions on this.]
I have various ideas on offering an informal, non-certified
server for a repository of public keys, possibly eventually to
evolve into some sort of distributed server (as domain name
servers are). But I doubt I'd ever be in a position to offer this
as an official Internet resource (if there is such a thing),
so I'm not sure how useful the idea would be. On the other hand,
a lot of useful services like Usenet News seem to have gotten
along OK without an official central organizing body.
Any program I would write would at least have the ability to
read from a flat file of public keys, a la rpem. Maybe the addition of
a key server would wait for a subsequent release.
I would be delighted to hear that someone else is already doing
this; I would be glad to work with that individual, or drop my work
on this altogether (there are plenty of other projects to work on).
Mark Riordan mrr(_at_)scss3(_dot_)cl(_dot_)msu(_dot_)edu