Re: [openpgp] "OpenPGP Simple"

[Christoph Anton Mitterer <[e-mail]>]

On Sun, 2015-03-15 at 12:57 -0500, Stephen Paul Weber wrote: 
> One of the big obstacles to OpenPGP deployments that I've faced over time is 
> the perception that it's "too complicated", mostly based on the sheer size 
> of the current RFC.
Uhm? Compared to other standards it seems to be rather simple.

Apart from that, not everyone needs to (neither should one) re-invent
the wheel.
I don't say that there should be no more than one implementation of
OpenPGP, but having too many is just bad for security.
That being said - we already have a number of implementations which
cover the standard quite well - what's wrong with [contributing to|
using] them?


> 1) Sections of the RFC define what you might call "extras", such as the 
> ASCII Armor (including a checksum unused elsewhere in the spec)
As some others already said, using e.g. MIME would be better - but ASCII
armors aren't just used when sending mail (people use it e.g. to post
their raw key on a website or things like that).
So if ASCII Armors are dropped, the standard should refer to something
else that is used instead - just to prevent that people are using all
different froms of base64 encoding, uuencode, etc.


> 2) There are a lot of backwards-compatibility things (old-style lengths, 
> lots of different algorithms)
Agree with that.


> Is there any prior art on IETF specs having a "full" and "simple" form where 
> full implementations can read any output of simple ones, but not always 
> vice-versa?
I'd say that this is rather a bad idea.
For many standards where this was done it caused more troubles than
good.
It's also security-wise a problem:
Who decides what's not critical enough for the base standard? Is it
guaranteed that implementations that don't implement the "full" standard
are still secure?

And often it just means that simply no one ever implements the
extensions to the base standard (think of the dozens of JPEG2000
profiles). If something is so special that it wouldn't be needed in the
base standard, one should perhaps question whether it's needed at all.


Cheers,
Chris.