David Bird wrote:
>
> In my opinion, cryptography should be seen as an evolutionary
> process. Protocols are continuously evaluated for their "fitness" in the
> context of current number theory, advances in computers/CPUs, and many
> individual/company/implementation specific requirements. It may be
> impossible to get the ideal solution, but we optimize to what we consider
> vital for survival.
>
I've read with interest the thread, and I'd thought that we all came
to this conclusion some years back. That's why we had the SPKI
response to PKIX, OpenPGP, etc.
We could use the excuse of AES implementation to foster a move to a
new common denominator. That implies a willingness among ourselves
to move, abandoning the older solutions (with perhaps some migration
and translation programs to process archived information).
I once (circa 1996-1997) tried to foster this with PSPKI (Pretty Simple Public Key
Infrastructure), combining what I saw as
the strengths of
OpenPGP, SPKI, SPEKE, etc. Maybe it's time to try again?
My requirements were (off the top of my head, there were more):
1) simple, easy to process and debug data formats. Like SPKI and
KeyNote, not PKIX or even OpenPGP.
2) possibility of translation of public keys between systems (but
not the OpenPGP "sub-packets") for easier migration.
3) explicit inclusion of roles and capabilities. There are many
flavors of this -- I simply indicated a "group" of things to be
signed, but KeyNote attributes might serve better.
4) an agreed algorithm for generating private keys directly from
the passphrase, rather than keeping a private key database.
Moving folks from laptop to desktop has been pretty hard, and
public terminals are useless. AFS/Kerberos did this with a
"well-known" string-to-key algorithm, and it's hard to convince
folks to use a new system that's actually harder to use. We need
to design for ease of use!
What support is there among us for evolving together?
Are there other requirements?
Is it time?
