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

From: [email-masked]
Date: Tue, 22 Aug 2000 22:40:21 -0700

Erron writes, quoting me:

> >   If you are decrypting, isn't looking up by keyid the only possibility?
>
> If you're not using speculative Key ID's and you're talking about sigs, yes.
>
> >   There is no userid to tell you which key to decrypt with.
>
> Yes; if the headers have been stripped from the email message - no; if 
> they're not :)

I see, so you use the email message headers to figure out which key
to decrypt with.  That could work, for the specific case of decrypting
email.  Even if you did pick the wrong key, you would of course not be
troubled by false decryptions, you'd know that something had gone wrong.
However adding the ability to lookup by keyid is something you might
consider, for increased flexibility and reliability of lookup.

> >No, subkeys can have keyids too.  A PKESK packet should use the keyid of
> >the specific subkey which can decrypt it.
>
> OK, here is where I am confused. For example, a tag 14 (Public Subkey 
> Packet) hasn't the facility to store the Key ID and from reading the tag 2 
> (signature packet), you cannot store the key ID's there either - either 
> within the sig. packet or a subpacket of the signature. Where exactly do 
> you store the Key ID of an encryption subkey...I am totally bamboozled!

Here is the source of your confusion.  Keyids are not stored on keys.
Rather, they are calculated from the key data, like key fingerprints.
When we read in a key, we calculate its keyid and store it alongside
the key.  We can then use this stored keyid to find the key.

In PGP 2.6, we did not store the keys in memory, but rather we calculated
the keyid as we read and parsed each key on disk (it was simple for those
old V3 RSA keys).  This was then used to match against the desired keyid.

> Sorry, I didn't clarify enough - when I refer to using User ID's, I am 
> referring to decryption, not verification. The signature Key ID's can be 
> looked up via the self sig.

I don't quite understand how this would work; how would you know that
a sig is a "self sig" except by seeing that the keyid in the sig packet
matches the calculated keyid of the parent key?  Or do you just assume
the first sig on an object is a self sig?

Hal