Erron Criddle writes:
From discussions with people who have been involved with the standards
process, they believe that the OpenPGP RFC has a long way to go before it
would be accepted as a standard because the processing requirements of
OpenPGP have been superficially regarded with respect to packet formats
such as the calculation of the length of a packet and the combined security
of the actual packet (ie as OpenPGP is a security standard, so NO data
should be spooled to disk unless it is encrypted somehow).
What about S/MIME? It doesn't say anything about what you do when
spooling data to disk in order to calculate a signature on it, does it?
Do these people you know say that S/MIME shouldn't become a standard
either?
For example, in order to calculate the length of a stream of literal data
(before it is prepended with a one pass sig and appended with a standard
sig, and subsequently compressed then encrypted), you have to spool the
data to the disk if it is a very large file. In order to maintain security,
the data SHOULD be encypted to disk, however when we want to build the
above packet, we would then have to decrypt the data so it could be
prepended with the 1P sig, appended with the normal sig and then compressed
then encrypted ONCE AGAIN...etc etc
Actually, as I think you mentioned in a later mail, OpenPGP goes to some
lengths to define data formats which will avoid this problem. This is
why we added one-pass signatures, and why we added partial packet length
specifiers. So your people are apparently not even that familiar with
the standard.
This is one example I have been quoted and I cannot say there are
equivalent examples that "may" slow down the process of OpenPGP becoming a
standard.
It sounds to me like your people are looking for excuses.
The real problem I see with OpenPGP is simply that so few people implement
it. Making it an internet standard will not suddenly make people rush to
produce implementations, any more than making it a proposed standard did.
Hal Finney