-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
* sen_ml(_at_)eccosys(_dot_)com (sen_ml(_at_)eccosys(_dot_)com) [000823 05:17]:
Why don't we make the "wild card" or "speculative" key id support a
SHOULD? I at least want to see all the client's being able to properly
decrypt messages that use this feature.
I don't have a problem with the speculative keyID support
same here, though i think when this issue was brought up once before
there were some valid concerns brought up.
imo, one context in which i think speculative key ids support "SHOULD"
exist, is one which is user-driven -- if a user receives a message
that contains public key encrypted session key packets that contain
speculative key ids, the user should be able to have an openpgp
implementation attempt to decrypt the pk esk packets w/ the user's
secret key(s). the user shouldn't have to perform surgery on the pk
esk's (inserting key ids) and attempting to decrypt repeatedly.
The user *will* have to decrypt multiple secret keys if such exist. Perhaps a
recommendation that non-encrypted keys be tried first is an idea?
Actually, this might be of some concern. You could effectively send a email
using speculative KeyID, which would make the user decrypt all his key in
turn, thus providing a attacker with access to keyboard with passphrases to
*all* his KeyID's, including keys the user might have made to be extra secure,
and not for normal use (root keys etc).
Recommending some way of managing this, by specifying the order in which keys
are tried, or even marking keys as not to be used with spec keyid's is a
possible fix to this problem.
in other contexts (e.g. processing by a script on a mail gateway), i
was given to understand that there were valid reasons (e.g. computing
resource limitations) not to want to support the feature.
I'm one who has raised such concerns, although not in the discussion you
refer to. I don't see how the fact that use of spec keyid's isn't appropriate
in every situation should put breaks on making it a should. Sure, it'll force
admins of major mailing lists to have to think first, act later, but isn't
that always the case when you have to admin a mailing list which is using
encrypted emails to such a number of user that that's a concern?
but it does not address the underlying problem: Implementors not
understanding basic concepts of e-mail encryption.
i agree w/ this as well.
The question is, how would you like to solve the problem?
I don't see any quick fix for this. You can't force people to not write crypto
applications until they've been certifies in their field. You can't force
people to want to educate themselves.
I think the only thing one can do is offer help whenever possible, and view
everything with a critical eye, as well as publishing information about
potential problems, to help lesser skilled users from getting bitten.
Just my $0.02
Terje
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.2 (FreeBSD)
Comment: For info see http://www.gnupg.org
iD8DBQE5o4yF8HLgLrwmRg0RAv1PAJ9Uw3k80gHFDaktuqEbHvlGQ1elTgCfWvNP
7ouIyW4piHQZLjrBoVp05yo=
=bYcM
-----END PGP SIGNATURE-----