William Geiger <whgiii(_at_)invweb(_dot_)net> writes:
[MUST = DSA/EG/3DES
SHOULD = RSA/IDEA/MD5]
A very basic reason: SHOULD is only for things that are strongly desired
by all implementations. If we have a strong algorithm for a MUST and
another strong algorithm for a SHOULD, I see no point to tossing another
SHOULD in. Many developers try to implement all SHOULD-level specs, and
this would cause needless software bloat with little definable benefit.
And, again, I would strongly lobby against any MAY list. A list of IDs
for all known algorithms identifiers is enough.
Well FWIW I don't have a problem with only having one MUST and one SHOULD
but if we are going that route there should be some documentation on what
algorithms PGP 2.6.x & PGP 5.x are using and what the default operations
are so implementors can insure that they have compatability with the
current software available.
It may not be necessary to have CAST5 to be interoperable with pgp5.x
-- the symmetric cipher capability flags which are attached to public
keys would allow people not implementing "MAY/or just OID listed"
CAST5 to warn pgp5.x that they can't handle CAST5.
Or stated the other way around, if CAST5 is not to be listed as a
SHOULD, there better be a way to tell pgp5.x not to send email
encrypted with CAST5 which reliably ensures you don't get CAST5 in
your mailbox. By reliably I mean even with Cc combinations of people
with different combinations where multiple recipient encryption is
used.
Perhaps someone from PGP Inc with a better understanding of how this
works (as the draft is not out yet) could explain how this would work
out.
There may even be that there is a case for CAST5 to be a SHOULD for
compatibility with pgp5.x. PGP Inc clarifications please!
My understanding is that CAST5 is the default algorithm in 5.x, if
it is not a MUST or SHOULD there still should be some mention that
it is the default in PGP and those wishing to be able to communicate
with 5.x users will need to implement it. Simmilar documentation
should be provide in regards to 2.6.x and the RSA/IDEA/MD5
algortihms.
I agree with the need to document cipher mode as well as OID -- for
instance the IDEA mode is particularly odd: a non-standard CFB and it
has particular checksum requirements. (8 byte random junk is
encrypted to act as IV, and then 2 bytes of checksum repeating the
last 2 bytes of the random junk. In addition something weird is done
to the feedback at semantic boundaries in the message. Personally I
find this quirky mode annoying, but we've got it now for backwards
compatibility. Is this quirky semantic context variable length
feedback CFB used with CAST5 and 3DES?)
Adam
--
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/
print pack"C*",split/\D+/,`echo "16iII*o\U(_at_){$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`