ietf-openpgp
[Top] [All Lists]

Re: [openpgp] Hybrid proposal for algorithm identifiers

2015-03-24 18:51:41
On Tue, 2015-03-24 at 23:17 +0000, ianG wrote: 
On the left, 
there are the pluralists
So pluralists are left-wing?! ;-P

Seriously, being one of the "pluralists", let me perhaps clarify this a
bit:

I don't think that the standard should necessarily standardise 20 alogs
for each type and make 10 of them mandatory.

- It should rather come with a few defined, perhaps at most 3 (per type)
  mandatory.
- It should be easy to extend it and the community should be open enough
  to at least not put unnecessary obstacles in the way of such
  extensions.
  (E.g. I remember that quite often some people would have liked to see
  Serpent supported - the first thing was always like "do we really want
  that and would we even support that").
  In the end, the implementations should decide which further algos are
  actually implemented, but even here, being a "pluralist" :D (I kinda
  like that ^^) I'd rather wish for a culture of accepting things, if
  a proper implementation is provided and there are not security
  concerns.
  E.g. if the Japanese really want their CAMELLIA or the Russians their
  GOST and if the provide a clean implementation and the algorithms
  aren't known to be severely flawed, I'd hope that Werner accept these
  in gnupg.
  However, whether he enables them per default for outgoing stuff,
  respectively whether he adds a warning about their use or perhaps
  requires a special parameter to enable/trust them... that would IMHO
  be totally up to him.
- It should be rather simple to change the mandatory algos in the
  standard.
  I mean we still list 3DES, while in reality it's probably AES.


Cheers,
Chris.

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp