The (compelling!) reason for “digitally signed cookies” is a so-called session riding attack, which involves (in its various forms) the use of replayed, forged or tampered cookies. Many ill-designed systems assume that, if you present them with a “session ID” cookie that appears to be of the correct format (it could just be an MD5 string...) this ID must represent an existing or we-should-make-one-now session. Or perhaps, that user's identity. A captured token might be replayed, e.g. by a rogue script running on that user's machine, and thus gain rights it should not (still) have.

There are many cookie-validation schemes out there on CPAN now, so you don't have to create this from scratch, but the basic idea might be (for example...) this:

1. To the basic cookie value, append:
   • A random integer, called salt, which is included in the cookie in its unaltered, unencrypted form.
   • A guard value computed (say) by a secure SHA1 (not MD5...) hash of the cookie, the salt, and a very-long random string known only to you and provided by a sub so that its value never exists in any potentially dumpable variable-namespace.
2. When the cookie is received, a rigorous regular-expression verifies that its format is exactly as it is supposed to be, then separates it into its three component parts.
3. The same hash-algorithm is applied and the result is compared to the guard-value. It must match exactly.

The now-validated ID can be used as needed. Because of the “salt,” which is random, millions of entirely-different guard-strings can be produced for the same information. Because a non-extendable algorithm like SHA1 was used and since the once-computer-generated random secret-string might be thousands of bytes long, it is impossible for an intruder to forge the value unless he has captured a copy of the source-code.

This scheme can be used to append other information to the cookie, such as an expiration-time. “Guard digits accompanied by a long, random, secret string” can also be used to produce masks, so that (say) the true value of a session-ID can be concealed.

Remember:   in CPAN this sort of thing already exists. Cookie-validation (and POST-data validation!) should be provided at a very high level within your application framework so that these services become reliably available to every part of your application without further concern from you. (If it were something that you had to be conscious of, you'd miss something and an exploitable “hole” would be awaiting discovery. Because rogues use automatic scripts to test such things, it would be discovered.)

Don't “trust” ... verify.