On Sun, Mar 22, 2015 at 9:54 AM, Peter Gutmann
<pgut001(_at_)cs(_dot_)auckland(_dot_)ac(_dot_)nz> wrote:
Derek Atkins <derek(_at_)ihtfp(_dot_)com> writes:
Have you tried to have them read the CMS/PKIX set of specs?? And they still
think that 4880 is too complex??
Having implemented both 3369 and 4880 (I'm not going to touch 5280 et al, no-
one has that much asbestos), 3369 is much easier to work with. The reason for
this is that there's a single overall type (ContentInfo) for everything and
then consistent subtypes (SignedData, EnvelopedData) within that, all
collected together inside type-specific containers. PGP OTOH is a series of
packets with somewhat arbitrary fields (look at the literal-data packet for
example), all concatenated together in a rather ad hoc order, which means you
have to hand-craft parsing code for almost everything. When a new type
(AuthEnvelopedData) was added to CMS I just added an OID and a function
pointer to the decoding table and a bit of glue code and I was done. The PGP
equivalent OTOH, MDC'd data... ugh.
I have also done a CMS a few times, it isn't a biggie. PKIX path math
certainly is, particularly if the insanity of policy constraints is
attempted. But CMS isn't that hard.
Even ASN.1 BER encoding isn't that difficult. The really horrible part
is having to do DER.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp