Your design looks a lot like RIPEM. I think that most of the functions
you want are already present there: there is a key server, support for
finger key distribution, etc. Its use in the internet is even growing.
But it is not PEM.
^^^^^^^^^^^^^^^^^
Exactly, which is the basic problem with PEM at the moment. The leading
implementation of something PEM-like which has the biggest growth
potential on the Internet due to its "bottom up" hierarchy, is not PEM
compliant by a strict interpretation of the standard. It is PEM that
needs to change to address what RIPEM has discovered during deployment.
Just because it may not be "pure" does not make it "wrong". When are we
going to see an RFC on RIPEM's extensions or an RFC extending PEM to
cater for what RIPEM can do, maybe with different "pure" mechanisms?
Cheers,
Rhys.
Then there is no problem. Make RIPEM an RFC and use it. Just because there
is something PEM-like that is more popular than PEM doesn't mean that PEM is
broken. It isn't a matter of purity either. RIPEM is RIPEM and makes no bones
about it. PEM is PEM and offers a set of services which RIPEM doesn't (and
which
the RIPEM documentation admits). If popularity were the standard then we would
all be using VMS or DOS or something. :-) Your argument is similar to one
which
states that because Xmodem gets the job done and is so popular that obviously
there is no need for TCP/IP.
John