Subject: Re: [openpgp] The combinatorial complexity of OpenPGPv4

From: Peter Gutmann <[email-masked]>
Date: Tue, 17 Mar 2015 01:50:19 +0000

Derek Atkins <[email-masked]> writes:

>Having implemented it myself, I disagree completely.  It is absolutely
>possible to create a modular implementation.  See my Usenix Security Talk on
>the PGP Message Processing Pipeline from.... 1996??

PGP message processing isn't hard (apart from the *&*^#&*# partial-lengths
kludge), I've done the same, I have retargetable code that does either S/MIME
or PGP depending on which encoding/decoding functions you point to.

The killer with PGP is keyrings, which are impossible to process in any kind
of nontrivial API (in other words a library) because there's no concept of
"single blob containing a key + name" as there is for X.509 certs.  Instead,
you have a mass of packets concatenated together, deeply bound in a spaghetti
of implicit cross-references (some of the following packets apply to a
previous packet, and some are signatures that tie other bits together, and
then there's trust packets that change the semantics or earlier packets, and
so on).

It's pretty much impossible to create any clean API to handle this, you need
an interactive app that keeps going back to the user and asking "I've just
found some X here, what shall I do now?".  Similarly, storing these things in
something like a key/value store for fast lookup is nearly impossible because
you end up having a more or less open-ended number of index fields and cross-
references that need to be maintained.

If anyone wants to challenge that, please provide in your reply an outline of:

- An "add a key API" that takes a newly-received PGP key and adds it to a
  keyring, along with a clear description of its semantics.

- A schema for storing PGP keys in a key/value store.

(This is to pre-empt a flamefest.  If you think it's possible, prove it :-).

Peter.

---

From: Werner Koch <[email-masked]>
Date: Tue, 17 Mar 2015 12:35:59 +0100

> "single blob containing a key + name" as there is for X.509 certs.  Instead,

Better don't compare it to X.509.  Think only of stripped down root
certificates and the attribute certificates.  How to decide which
attribute to prioritize over another is also often not easy.  But I
don't have to tell you what's wrong with X.509.

> references that need to be maintained.

There are just N user ids and M fingerprints for each keyblock and one
of these fingerprints identifies the entire keyblock.  Why do you want
any more indices (unless you keep on supporting v3 keys)?

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 23 Mar 2015 15:23:28 -0500

So as with Smime, the message packaging bit is easy to implement, it is the key management bit that is hard.

Sent from my iPad

> On Mar 16, 2015, at 8:50 PM, Peter Gutmann <[email-masked]> wrote:
> 
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp