Re: mail client implementations problem? bcc and encrypting to multiple recipients

[Erron Criddle <ejc@xxxxxxxxxx>]

At 01:03 PM 22/08/2000 -0500, "William H. Geiger III" <whgiii@xxxxxxxxxxx> 
wrote:

<snip>

> >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.
>
>
>     IMHO using the userID is *not* the way to go. While userID lookups 
> can be used the first time you are encrypting a message to a new e-mail 
> address precautions need to be made. A dialog between the user should be 
> established to verify that this is the actual key that should be used 
> (anyone can create a key with any userID, multiple keys with the same 
> userID may be present, ...ect).

Agreed that User ID's provide the encryptor (user) options as to which key 
to use for encryption.

>  Key lookups need to be based on the 64bit keyID, it's the only way to 
> insure that you are getting the correct key (for signature verifications 
> it is the only way to find the key).

A 8 octet lookup of the Key ID for sigs. is definitely the only way to go 
(you can obtain the Key ID from the self sig. of the signature key). A 
lookup via a Key ID with a PKESK is only good if you are not using 
speculative Key ID's.

>  Once a user has selected a key to use for a new e-mail address the 
> application should store the 64bit keyID & the e-mail address in a table.

Agreed.

>  For subsequent encryptions to that address the application should lookup 
> the e-mail address in the table and then extract the PGP public key from 
> the keyring using the corresponding keyID.

That's where my dilemma starts - how do you store the Key ID of encryption 
subkeys on a keyring? I think this should be made possible somehow.

> Now granted the keyID is not stored in the key itself, this is not really 
> that big of an issue. I can currently process a 1Gb keyring, calculating 
> all the keyID's, in a couple of mins. For an average size keyring the 
> processing time is less that a second. If you find your application needs 
> to work with large keyrings maintaining a simple external index on the 
> keyring by keyID will greatly improve performance.

Yes, that's what we are doing - creating an index that links key ID's to 
email addresses - it certainly speeds things up.




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@xxxxxxxxxx