On 11/08/2015 11:10 am, 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.
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.
Hmmm... I understand that. What I'm not convinced of is that at the
current time we can sensibly allocate the numbers.
As far as I can see, to sensibly allocate the numbers, we'd want:
* to choose which SHA3 we're going for. This not only means
addressing the additionals (like the 4 lengths) but also resolving the
uncertainty (perhaps in my mind only) about SHAKES.
* to build a more comprehensive alg-failure recovery strategy. By
this I mean, more than handwaving at SHA3 as a potential drop in;
making it the actual drop in with a process by which we trigger that
move and a series of events listed that we anticipate happening; text
in the draft that lays that out; etc.
Otherwise, we're fortune gazing.
(It may sound like I'm engaging in waffly rhetoric again - but there is
a known discipline for this. It's called *disaster recovery* and it's a
required component of many compliance programmes, taught and certified
in various places. There are many people who know how to do this stuff,
it's just that it is a relatively new and/or infrequent delivery in the
open source crypto world.)
iang
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp