In <p04310103b506a93ebb88(_at_)[172(_dot_)20(_dot_)1(_dot_)38]>, on 03/28/00
at 12:51 PM, Jon Callas <jon(_at_)callas(_dot_)org> said:
I think this is an excellent idea. 2440 is a data format standard, and
consequently, the test suite mostly should consist of data. The only real
comment I have on your list is that PGP/MIME isn't part of 2440, it's a
separate RFC. (And in my opinion, this is a feature, not a bug. It's
called layering.)
Yes but there is no reason why not to include PGP/MIME test data. One can
document that this part of the data is for a seperate yet related RFC.
Most 2440 applications will also want to be PGP/MIME compliant.
There's a related issue that I want to bring up, though.
Well I see the testing of the application as 2 part. The 1st part would be
the "inbound" processing of RFC 2440 packets. I don't see any risks
involved with using a fixed data set for this part of the testing.
The second part would be the "outbound" generation of RFC 2440 packets. We
should be able to have a set of "skeleton" packets that the tester could
use for compairison while ignoring the raw data (ie MPI's) that may be
different. As an example the application being tested needs to generate a
v3 RSA public key. The tests could use the "skeleton" test packet to
compair that all of the parts are generated and formated properly while
ignoring that data contained in MPI(1) and MPI(2) is different.
--
---------------------------------------------------------------
William H. Geiger III http://www.openpgp.net
Geiger Consulting
Data Security & Cryptology Consulting
Programming, Networking, Analysis
PGP for OS/2: http://www.openpgp.net/pgp.html
---------------------------------------------------------------