Some background...
Checking government-issued ID as is done at a Debian keysigning event gives the key signer a reason to believe that the person P whom he has met has a government-recognized name N and is claiming to control the public key K with uid: name N + e-mail address A.
A "casual" signature signifies only that one fact. Observing the signature to exist gives you, a third party, a (weaker, see below) reason to believe the same thing, namely, that that person P has government-recognized name N and claims to control K with uid N <A>.
That's very useful if you want to know which key to use in encrypting documents for P to read. In that case P's interest in receiving the document implies an interest in providing the necessary means for conveying the document in encrypted form. It is also useful if you want to check a signature made with K. If a document is signed with K and P has claimed to control K then the valid signature gives some assurance that the document really came from P. (It gives somewhat less assurance if there exists some incentive for P to misrepresent the document as his own; then P has an incentive falsely to claim control of K.)
All this subject to the uncertainty that the person named N to whom *you* want to send encrypted documents, or the documents from whom you want to verify the signatures on, may or may not be the same person as P. For most names N there are many people in the world with that name. (Which makes me wonder why Debian doesn't require that uid strings contain birth date and place information as well.)
For other purposes a casual signature is even less useful. In particular it isn't useful if you have an e-mail address A and want to know who controls it. Anyone can create a key, put address A in the uid field and get the key signed.
If, however, the key signer e-mails the signature to e-mail address A, rather than uploading it to a keyserver directly, then the signature gains the additional significance that P controls A, for only if P controlled A would the signature have gotten published.
Encrypting the signature with K, rather than sending it unencrypted, gives the signature the further significance that P controls K, for only if P controlled K could the signature have been published.
These additional assurance raise the "cert level" of the signature, in GnuPG parlance.
The caff program, which I only discovered last week, nicely automates the signing and e-mailing of separate signatures (actually, the key with the separate signatures in question) to the associated e-mail addresses. If caff is used after a Debian keysigning event, am I right in thinking that it is justified in assigning cert level 3 to the signatures sent out?
--
Thomas Hood