Derek Atkins <warlord(_at_)MIT(_dot_)EDU> 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
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 :-).
openpgp mailing list