I think it's an excellent idea to include a list of recommendations in the
RFC. I made similar lists of requirements for various technical features
and products in my book "Internet Cryptography." Those lists aren't
appropriate in their current form since they were meant to guide software
buyers rather than developers, but they might provide a useful point of
comparison. If someone has a draft list of recommendations for the RFC, I'd
be happy to review it and make suggestions based on the lists I published.
Regarding Adam Back's comment:
So long as the importance of adherence to security recommendations is
clear; ignoring them entirely could lead to some bizarrely insecure
implementations which could legitimately claim to be OpenPGP
compliant.
I doubt we can produce any lists that will prevent someone from
implementing "bizarrely insecure" implementations. There is always a "low
end" in the marketplace, even for security products. Someone will use
rand() to generate secret keys and seed it with the clock. Take it as a
given. People will probably even pay money for it. Even if we could prevent
such foolishness, it would require a very large crystal ball to forsee all
the different ways people will use a product, especially something this
new. If crypto becomes a tool of common folk, then people will develop
various habits and traditions that will affect the operating security more
than even the choice of bit length. Nobody, not even the NSA, can predict
how such systems will hold up under use by a giant population of untrained,
casual users.
I can't wait to see what happens.
Rick.
smith(_at_)securecomputing(_dot_)com Secure Computing Corporation
"Internet Cryptography" in bookstores or http://www.visi.com/crypto/