-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rodney Thayer wrote:
I think that products should be built with "test points" in them,
to allow such things as interoperability testing. This is how
we've had to do things in the IPsec and TLS worlds, and in other
places. I think we should be able to "dump the keys", and I
realize that means one
has to (gasp) have code that reveals the keys.
IPsec and TLS are hundreds of times more complicated to interop test
than OpenPGP should be. IPsec and TLS are extremely complex, OpenPGP
is fairly straight forward. Dumping keys is an obscure debug
scenario used to figure out why two implementations do not interop.
Frankly, I expect the OpenPGP testing will have very few cases of
interop failure, and that such cases will be reasonably explainable
with things like "we didn't implement that optional algorithm."
On the other hand, if we run in "trust me, it's ok" mode, we're
degenerating into security by obscurity. If I were auditing an
implementation, I'd want to see the keys to validate it myself.
A main part of the point I'm making is that we are NOT auditing
implementations. This is not a security review for each of our
products. This is an interop test. If some other product uses a
session key of 0, it's not the job of the interop tests to discover
that. If I can read the other guy's messages/keys and he can read
mine, we're set to go.
Remember, there's nothing stopping someone from revealing the keys
anyway -- you can't inhibit someone from saving copies of their
key material, or even publishing it. So this is a previously
existing non-problem.
As I said, the tests must be able to be run by any user sitting at
each of our products without debug tools or special code. Going
beyond that gets into a security review which is not what we're doing
here.
Hal Finney wrote:
I am inclined to think that traditional interoperability testing is
a better way to approach this problem. At least with openpgp we
don't all have to get together, it can all be done online.
We would define a specific set of message/key types to create, and
everyone who wanted to participate would create messages/keys of
those types (or whatever subset they support), then everyone else
would try to read them.
Thanks for the correction Hal. That sounds like an efficient
approach.
- -- Will
Will Price, Director of Engineering
PGP Security, Inc.
a division of Network Associates, Inc.
-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0 (Build 145 Alpha)
iQA/AwUBOOGac6y7FkvPc+xMEQI9wgCg3OzL+yq5b4sK+OeZiQohxpwvtIAAnjob
TdXKhEBO0bYmI73uRKwfjWvV
=S5P6
-----END PGP SIGNATURE-----