At 01:33 PM 22/08/2000 +0900, sen_ml(_at_)eccosys(_dot_)com wrote:
<snip>
since this means that each recipient receives a message containing a
public key encrypted session key packet for each recipient, each recipient
is able to tell who all of the recipients were (assuming no use of
speculative key ids) -- or at least all key ids.
even if speculative key ids were to be used, a recipient would likely
be able to tell that there were other recipients than those implied
in the headers of a message. also, afaik, nai pgp doesn't support
speculative key ids, so in terms of interroperability it's not a great
option at this point.
As far as I'm concerned the Key ID is a complete waste of time unless a
lookup is being made on a server that is automatically decrypting each
message. This is OK here because you can configure the database to store
the Key ID and that makes lookups easier (if there are no duplicate Key
ID's). From my understanding of the Public and Private Keyring structures,
you can only have a Key ID for the highest level key (self sig.) and cannot
store the Key ID's for the subkeys.
For our client software, we are not doing lookups via the Key ID (as it
isn't stored in the public/private keyrings), however the server version
will support lookups via Key ID's.
We have found it better just to do lookups via the User ID - at least you
can store that within the private /public keyring structures.
If anyone can tell me otherwise regarding the storage of Signing and
Encryption Key ID's within the private/public keyrings, it would be great.
Cheers.
Regards
Erron Criddle
Comasp Ltd.
Level 2, 45 Stirling Hwy
NEDLANDS WA 6009
Australia
Fax: 08 9386 9473
Tel: 08 9386 9534
http://www.comasp.com
ejc(_at_)comasp(_dot_)com