On Tue, 11 Aug 2015, Werner Koch wrote:
We have a lot of experience in how to deploy new algorithms and we are
very conservative here. My request for adding SHA3 algo ids does not
mean in any way that I endorse its use or would even suggest that
4880bis should contain a SHOULD or MAY for implementing such an
algorithm. When we come to the point on deciding on algorithms I would
suggest something like this:
- Implementations MUST implement SHA-1. Implementations MAY implement
- other algorithms. MD5 is deprecated.
+ Implementations MUST implement SHA-1 and SHA2-FIXME. Implementations
+ MUST NOT implement MD5. Implementations SHOULD NOT implement
+ SHA3-xxxx. Implementations MAY implement other algorithms.
openpgp is unique in that there is a _very_ long validity time required
for some algorithms, so one could verify a 20 year old message, even if
that security 20 years later is questionable (eg breakable)
I would like to see (and maybe the documents already do that but the
above bullet points don't indicicate this) a difference in support for
verifying signatures (eg we should implement MD5 and MUST implement
SHA1) and creating new signatures (MUST NOT use MD5 or SHA1)
The algo ids are a different case and I would be fine with the RFC-7120
method. Iff the unexpected case happens that a severe weakness in SHA2
is found, the pre-allocated SHA3 ids will allow us to quickly switch to
SHA3. Isn't that the whole point of SHA3 being plugin-in replacements
for SHA2?
Yes, but I don't see why we need to have 6 versions of SHA3 on standbye.
openpgp validity / security is measured in years, and as such,
performance don't really come to play when considering algorithms.
Paul
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp