Subject: [openpgp] Hybrid proposal for algorithm identifiers

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 24 Mar 2015 11:46:55 -0500

* Maintaining algorithm registries takes time and effort
* Modern best practice for algorithms rejects the idea that more algorithms is 'better'. 
  * The security of the system is determined by the weakest algorithm an attacker can persuade you to use,
  * One Mandatory to implement plus a reserve is generally emerging as best

* Support for vanity crypto is an unfortunate necessity.
* ASN.1 OIDs are kind of obnoxious
* Suites don't work
* Most OpenPGP folk would like to use short identifiers

For many years I have wanted a way to move discussion of vanity crypto out of the IETF, etc. If we touch a spec, the vendor can pretend that we endorse it.

So what I propose is a two level scheme:

Mandatory and Recommended algorithms are registered in a short identifier registry. 

For everything else there is a reserved 'escape code' that states the algorithm is specified by OID. 

OIDs do get a little large sometimes. But they do have the advantage that nobody can claim that they have IETF endorsement. That is not true of any scheme we could devise ourselves. 

This approach means that there is a real difference between being one of the supported algorithms and the recommended algorithm.

---

From: ianG <[email-masked]>
Date: Tue, 24 Mar 2015 23:17:42 +0000

>    * One Mandatory to implement plus a reserve is generally emerging as best

I would say One+One is emerging as a centrist compromise.  On the left, 
there are the pluralists, and on the right, there are OneTrueBelievers.

Personally, I think the numbers are balanced between the right and the 
center, with the left (many) now a clear minority party.  Or at least, 
that's what a straw poll showed about 6 months back.

> * Support for vanity crypto is an unfortunate necessity.

That ... is an argument I'd love to see fleshed out.

> This approach means that there is a real difference between being one of the supported algorithms and the recommended algorithm.

Assuming your premises, this is a good proposal.

iang

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 25 Mar 2015 00:51:21 +0100

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.

---

From: ianG <[email-masked]>
Date: Wed, 25 Mar 2015 11:37:56 +0000

> So pluralists are left-wing?! ;-P

Actually that's a point - you should be right wing.  That's the confused 
state of politics these days, or maybe it was the beer talking :)

iang

---

From: Phill <[email-masked]>
Date: Fri, 27 Mar 2015 12:03:18 -0500

> On Mar 24, 2015, at 6:51 PM, Christoph Anton Mitterer <[email-masked]> wrote:
> 

...
>  I mean we still list 3DES, while in reality it's probably AES.

We should separate out the question of backwards compatibility support…

* One mandatory to implement
* One strongly recommended backup
* Additional algorithms that have been found to be necessary in practice for legacy interop, preferably with ‘best before’ dates.

Decryption support is likely to be required for much longer than encryption.