On Mon, 10 Aug 2015 22:50, phill(_at_)hallambaker(_dot_)com said:
Given that email recipients tend to end up having to implement all the code
points in a cipher suite because they can't really control what is sent, I
That is not the case with OpenPGP. If you encrypt and sign the key
gives you a list of hash algorithms supported by the recipient. Only
those may be used. In a signature only case there is no point in an using
extravagant hash algorithm because most recipients won't be able to
verify such a signature.
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.
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?
I suggest to use a different thread for discussing algorithm selection
because that is a different topic than assigning algorithm ids.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp