One thing to remember about IETF specs, especially format specifications,
is that they describe input and output, not implementation.
An implementation is free to store any of these data structures in any way
they see fit. You're free to convert them in memory, or put them in a
database in whatever is convenient to you. What 2440, and other IETF specs
really say are:
* If you write out the structures in this format, and another
implementation doesn't accept them, it's the reader's problem.
* If you read in a structure that is not in this format, and you don't feel
like compensating, it's writer's problem.
You are always free to correctly read things that don't meet the spec!
Remember the IETF meta-rule, "be conservative in what you emit, and
generous in what you accept." Following this guideline, accepting an MPI
with extra leading zeroes is a fine thing to do, but you really ought to
write it out with no extra leading zeroes.
Here's a different example. Suppose you were making an OpenPGP
implementation for a cell phone. You need it to be small. It's therefore
perfectly acceptable to always write out packets with 5-byte lengths, thus
saving on code size, but you still need to *read* the other packet lengths.
On a slightly related issue, OpenPGP encourages, but does not require
compatibility with PGP 2.6. Nothing in the spec forbids you from reading in
a V3 key, and immediately converting it to a V4 key internally and using
it. It might be polite to be able to re-export it in V3 format -- and you
might get catcalls from the user community if you didn't -- but you don't
*have* to to be OpenPGP compliant. One can even argue that we're getting
close to when we should start deprecating V3 structures. The known flaws
keep piling up.
Jon
--