Re: [openpgp] "OpenPGP Simple"

[Phillip Hallam-Baker <[e-mail]>]

On Tue, Mar 17, 2015 at 2:48 AM, Jon Callas <[e-mail]> wrote:

>
> > On Mar 16, 2015, at 7:04 PM, Peter Gutmann <[e-mail]>
> wrote:
> >
> > Jon Callas <[e-mail]> writes:
> >
> >> Certainly the ASCII Armor checksum is something that could go, since we
> don't
> >> need to worry so much about modem line noise. :-) But you have to know
> enough
> >> to ignore it.
> >
> > It's not just the checksum, the entire ASCII armoring should have been
> > discarded years, no decades, ago.  The whole thing was originally
> implemented
> > because facilities like FidoNet and Usenet didn't handle binary
> messages, and
> > the checksum was because things like 2400bps modems (pre-MNP) on the DOS
> PCs
> > that PGP 1 was written for wouldn't cancel out line noise, so it was
> useful to
> > check for inadvertent message corruption before you warned about invalid
> > signatures.
> >
> > The MIME standard (going back to RFC 1341) is over 20 years old and
> pretty
> > much everything supports it, but PGP persists with something from even
> earlier
> > (PEM, from 1987, that's nearly 30 years ago).  It's not just "a museum of
> > 1990s crypto" (thanks to Matthew Green for the great quote), it's also a
> > museum of 1980s and 1990s everything-else.  The entire discussion of
> "ASCII
> > armour" should have been replaced with "use a mechanism like MIME" years
> ago.
> >
> > (Oh, and by "MIME" I mean proper use of MIME, not "wrap PGP-PEM in MIME
> > headers and pretend it's MIME", RFC 2015/3156).
> >
>
> Maybe not decades.
>
> ASCII armor as it exists now uses the same encoding as MIME for base64,
> purely by chance. It is one of the things that makes me least crazy because
> it’s mostly standard and actually kinda useful. There are a lot of semantic
> places where it’s nice to know that something is an OpenPGP object in
> human-readable form.
>
> Something that seems to be forgotten all over the place is that email is
> actually one of the least interesting places to use OpenPGP. ASCII armor
> ends up being a nice way to encode something so you don’t have to play
> "guess the binary format."
>

We have been having a similar discussion in ACME which is for issue of
certificates for use in TLS, email, etc.

The body of the message is going to be JSON. But the message needs to be
signed. After a number of proposals we seem to have settled on a scheme in
which the start of the message is a JSON header carrying the signature
which is followed by a JSON message carrying the transaction request or
response.



> Relatively recently, I was opining to someone that it would be useful to
> come up with a JSON encoding for OpenPGP that would give an easy-to-parse
> thing that’s not just ASCII armor. But some years ago, I said the same
> thing but it was XML, not JSON. And a few years before that, it was
> S-Expressions, most recently in SPKI format, and more Common LISP-ish
> before that even. JSON is what the cool kids are using this decade, don’t
> you know.
>
> And *that* is the reason to just stick with ASCII armor.
>

Well you go to MIT, you get S-Expressions... I am kind of surprised the
code made it out of 545 tech square without them.

When I was backing XML it was essentially just S-expressions with angle
brackets and the initial tag duplicated on the end. JSON gets us back to
what we were sold when XML was first offered before the namespace prefix
idiocy was introduced and the schema was botched.

I think I will actually disagree with you Jon, even though I started
thinking I was in agreement. I think that the IT world has in fact picked
winners and stuck with them. But for different purposes.

There is least convergence at the lower levels of the stack. I can't
imagine any new protocol using ASN.1 unless it is directly coupled to PKIX.
The IETF has converged on using the TLS notation and approach. It works.
Above that XML is the only viable choice for a document format, JSON is
emerging as the natural choice for Web Services. There is no consensus on a
binary version of JSON but there are many applications making use of them.


Given where we are today, there are two approaches that make sense. One is
to stay with the current approach, the other is to pick an existing
approach, adding essential features if absolutely required.

To be avoided at all costs is to abandon the current approach and instead
invent a new encoding. Yes, JSON does have limitations that make it
unsuited for some applications and it is therefore inevitable that there
will be some other encoding at some point in the future. But that does not
mean that there will be a new format that looks completely different to
JSON and we can be virtually certain that a new format proposed for PGP
that looks completely different to JSON and the TLS encoding is not going
to be picked up anywhere else.