Subject: Re: [openpgp] "OpenPGP Simple"

From: Peter Gutmann <[email-masked]>
Date: Tue, 17 Mar 2015 02:04:32 +0000

Jon Callas <[email-masked]> 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).

Peter.

---

From: Jon Callas <[email-masked]>
Date: Mon, 16 Mar 2015 23:48:46 -0700

> On Mar 16, 2015, at 7:04 PM, Peter Gutmann <[email-masked]> wrote:
> 

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."

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.

	Jon

---

From: Tim Bray <[email-masked]>
Date: Tue, 17 Mar 2015 20:03:09 +1300

I have repeatedly found it useful, even in recent times, to cut/paste
ASCII-armored messages on my mobile. Am I a Neanderthal?
On Mar 17, 2015 3:05 PM, "Peter Gutmann" <[email-masked]> wrote:

> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
>

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 17 Mar 2015 12:53:39 +0000

> ASCII-armored messages on my mobile. Am I a Neanderthal?

No!  This was exactly my first thought also. ASCII Armor format is
extremely useful for passing the messages from app-to-app via the system
clipboard using copy-and-paste.  As a mobile PGP developer, there are
situations where this is the most convenient way to move the PGP
message/key from a non-PGP enabled app (like most standard mobile mail
clients) and into an app that can decode/decrypt it correctly.

If ASCII Armor is to be deprecated, I would hope that we at least replace
it with something else that can be easily copied-and-pasted.

---

From: Nicholas Cole <[email-masked]>
Date: Tue, 17 Mar 2015 13:41:45 +0000

On Tue, Mar 17, 2015 at 12:53 PM, Wyllys Ingersoll <[email-masked]> wrote:
> No!  This was exactly my first thought also. ASCII Armor format is extremely
> useful for passing the messages from app-to-app via the system clipboard
> using copy-and-paste.  As a mobile PGP developer, there are situations where
> this is the most convenient way to move the PGP message/key from a non-PGP
> enabled app (like most standard mobile mail clients) and into an app that
> can decode/decrypt it correctly.
>
> If ASCII Armor is to be deprecated, I would hope that we at least replace it
> with something else that can be easily copied-and-pasted.

I do hope (more generally) that this new spec does not seek change for
change's sake.

Things that are (or are likely to be) a security flaw should be
corrected, and some things that make the spec hard to implement should
be streamlined.  Features that are no longer used should be removed.
That's all.

---

From: Stephen Paul Weber <[email-masked]>
Date: Tue, 17 Mar 2015 10:13:55 -0500

>discarded years, no decades, ago.

Maybe.  I mostly just think it could be relegated to a seperate RFC that's 
just refereced from the main one as optional.

-- 
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph

---

From: Stephen Paul Weber <[email-masked]>
Date: Tue, 17 Mar 2015 10:15:10 -0500

>it with something else that can be easily copied-and-pasted.

I don't think it needs to be deprecated, but certainly not all 
implementations / uses of OpenPGP in various applications need to support 
it, or even know about it.

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 17 Mar 2015 15:24:10 +0000

Agree.  Perhaps there could multiple optional-to-implement formats - ASCII
Armor, JSON, pure base64, XML (*ugh*), etc - each specified separately.

4880 section 6 has a very detailed description of the ASCII format - should
that be pulled out into a separate document and just referenced in the core
spec?

---

From: Derek Atkins <[email-masked]>
Date: Tue, 17 Mar 2015 11:35:02 -0400

> that be pulled out into a separate document and just referenced in the core

It could, but that actually *adds* complexity instead of reducing it.

IMHO it's much nicer, from an implementation point of view, to have
everything in one document instead of having to go off and reference a
dozen or more documents.

If you don't want to implement section 6 in your implementation then
just skip section 6.

-derek
-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [email-masked]                        PGP key available

---

From: Wyllys Ingersoll <[email-masked]>
Date: Tue, 17 Mar 2015 15:41:02 +0000

Im fine with leaving it in since it is the most commonly used format.  As
you say, it isnt mandatory anyway.

---

From: Stephen Paul Weber <[email-masked]>
Date: Tue, 17 Mar 2015 10:48:32 -0500

>everything in one document instead of having to go off and reference a

This is true if you're building a complete implentation like GnuPG, but less 
true if you just want a way to verify signatures sent to you.

I mean, not that I find the spec that complex, but the webby people I deal 
with seem to.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 Mar 2015 12:30:03 -0400

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

> 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.
>

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.

---

From: Christoph Anton Mitterer <[email-masked]>
Date: Wed, 18 Mar 2015 23:43:14 +0100

On Mon, 2015-03-16 at 23:48 -0700, Jon Callas wrote:
> ASCII armor ends up being a nice way to encode something so you don’t
> have to play "guess the binary format."
But isn't that basically the same case as with the character encoding
thread?! In the sense of:

It's not OpenPGPs task to fix other applications/protocols!

If these need to use OpenPGP messages and they don't support binary
formats (which by itself is fine), then their own native means for
converting blobs into a suitable form should be used (e.g. XML's or
whichever) and if no such form exist, we should at best give a
recommendation about what to use (in the sense of referring to something
else).

Especially I don't like the idea that applications out there may use the
ascii armor's enclosing (i.e. the ---- PGP ... ----) to detect "this is
a PGP message".
There should be other things around in the protocol that uses OpenPGP
which specifies that (e.g. Content-Type: headers).

I think it would be theoretically[0] fine if a future OpenPGP standard
specifies multiple native formats, e.g. a binary one as we have right
now, a XML representation and whatever other ugly things (JSON?! ;-) )
people might want... but the ASCII armor isn't a real native format but
just an encoding, and that shouldn't be OpenPGPs duty.

Cheers,
Chris.

[0] In practise, though, there should be really strong reasons if more
than one such native format would be defined.

---

From: Derek Atkins <[email-masked]>
Date: Fri, 20 Mar 2015 12:23:24 -0400

Stephen Paul Weber <[email-masked]> writes:

> This is true if you're building a complete implentation like GnuPG,
> but less true if you just want a way to verify signatures sent to you.
>
> I mean, not that I find the spec that complex, but the webby people I
> deal with seem to.

Have you tried to have them read the CMS/PKIX set of specs??  And they
still think that 4880 is too complex??

-derek
-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

---

From: Derek Atkins <[email-masked]>
Date: Fri, 20 Mar 2015 12:26:20 -0400

Phillip Hallam-Baker <[email-masked]> writes:

> 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.

Okay, I'll bite..  Why don't you use JWS?  That would seem to be the
appropriate way to sign JSON, no?

-derek

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 Mar 2015 12:56:57 -0400

> appropriate way to sign JSON, no?

The idea is to use JWS for the signature. The only part that is not in
the JWS spec would be the 'JWS Serialization' signature packaging.
There are two versions of this in the current spec. All we are
proposing is to add a third.

JWS Compact Serialization is essentially

      BASE64URL(UTF8(JWS Protected Header)) || '.' ||
      BASE64URL(JWS Payload) || '.' ||
      BASE64URL(JWS Signature)

This is designed for use in OpenID. For our purposes, it is much easier to use:

JWS Signature
.
JWS Payload

The advantages of this change are:

1) It is more efficient in space (no need to base 64 encode)
2) It is easy to interpret examples and debug implementations if you
can see the plaintext without a tool
3) In our application, there isn't actually a need for the protected
header. But we could add that in as well just to keep things straight.

I can't see much point in going to JSON so that we have the benefits
of plaintext and then base64 encoding everything just to be compliant
with a spec written for a different purpose.

If adopted, I am sure that the JWS group will pick the scheme up and
add it to their spec at their next iteration. They have two
serialization formats today, adding a third is hardly an imposition.

---

From: ianG <[email-masked]>
Date: Mon, 23 Mar 2015 20:03:24 +0000

On 17/03/2015 12:53 pm, Wyllys Ingersoll wrote:
>
>
> On Tue, Mar 17, 2015 at 3:03 AM Tim Bray <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     I have repeatedly found it useful, even in recent times, to
>     cut/paste ASCII-armored messages on my mobile. Am I a Neanderthal?
>
>
> If ASCII Armor is to be deprecated, I would hope that we at least
> replace it with something else that can be easily copied-and-pasted.

Ascii armour is also very useful for plaintext keys, which make an 
appearance in contracts that distribute their own PKI.  Which also get 
signed inline with an ascii-armoured signature.  Also very useful.

Now, these things don't get cut&pasted much, if at all, although to be 
fair that was an expectation when I designed them.

But they do get printed out;  the contracts have been in court (twice to 
my knowledge) and their ability to be printed out and looked at by 
judges has been critical to their acceptance as contracts.

In short my 'requirement' would be printable keys and sigs.  I don't so 
much care if it is 'ascii-armoured' in the current form or not, but ... 
something would be nice.

iang

(For those unsure what I'm talking about, there is a form of legal 
contract called the Ricardian Contract which I wrote about here a long 
long time ago:  http://iang.org/papers/ricardian_contract.html This is 
now having a bit of a renaissance in Bitcoin / crypto-currency scenes as 
various businesses are discovering they want to couple legal prose into 
transactions and blockchains and whathaveyou.  End of obligatory plug.)

---

From: Stephen Paul Weber <[email-masked]>
Date: Tue, 24 Mar 2015 14:15:33 -0500

>still think that 4880 is too complex??

They wouldn't even touch those.  They just invent their own crypto system 
and go "poof, see, easier!"

I'm not supporting their decisions at all, just relaying them.  Again, see 
Salmon/MagicSig for one such example.