On Sun, 15 Mar 2015 18:57, singpolyma(_at_)singpolyma(_dot_)net said:
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. There are two things going on
FWIW, having implemented both OpenPGP and CMS/X.509 (aka S/MIME) I can
only tell how easy it was to implement and maintain OpenPGP in contrast
to the S/MIME. Up until ECC support, only one RFC and not several every
few years changing huge RFCs with so much room for interpretation that
you can't implement them without looking at older standards and actual
implementations.
2) There are a lot of backwards-compatibility things (old-style
lengths, lots of different algorithms)
Actually there are not many algorithms. If you know two (with 64 bit
and 128 block length) you know all of them ;-). CMS hides a lot of
details by refering to BER or DER encoding and that is really hard to
test.
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? Given the (necessary) size of OpenPGP as a whole,
it seems like this might be worth considering.
You mean notes in the margin to easier see MAY parts? I doubt that the
RFC format can provide this. Having two separate official documents
raises the danger that they are not consistent. Your annotated/edited
version of OpenPGP is likely the best thing to do. It is similar to
reading a set of RFCs compared to reading Stevens - it is much easier to
grok his books than to start from scratch with the RFCs.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp