A Lotus Notes Application Signing Primer

Design element signatures are something of a mystery for many Lotus Notes developers and administrators. So here’s a brief rundown of what design signatures in Notes are all about:

Design Signatures in Lotus Notes are digital fingerprint stamps created through a cryptographic hash function.

According to IBM’s documentation, signatures are used to “vouch” for a database or template’s integrity. Signatures are a key component of the Lotus Notes security scheme.

Imagine a disgruntled former employee injected some malicious code into an important Notes application—the Execution Control List (ECL) would spot his-or-her unauthorized signature and display a warning to the end-user. (Hopefully the end-user would heed the ECL warning and prevent anything harmful from running on the client side). At the same time the server’s security would stop rogue agents from running.

Signatures also help administrators keep tabs on what agents do. Any time an agent running on a server creates or modifies a document, you’ll find the signer’s name in the document’s ‘Modified by’ property (unless the administrator explicitly sets the agent’s ‘Run on behalf of…’ setting to another ID).

Each time a design note is saved, it gets signed with the Notes ID of whoever saved it. But often a more appropriate signature ID is required before the database is released or placed on a production server, so an administrator will need to re-sign the designs.

When a design note is signed, Notes takes the content of all the items (fields) of the design note and flags them to be included in the signature. A ‘signature digest’ is then created; this digest lists all the flagged items plus the current date and user ID. The signature digest is stored in the $Signature item.

Whenever a field is part of the signature digest you’ll see a ‘Sign’ flag in the Domino Designer Property Box (or in scanEZ).

Signatures are stored in the $Signature field of a design element. You can see this in the Domino Designer Property Box dialog.

Signing policy—the good, the bad and the ugly

One of tricky things about design signature policy in Notes is that it impacts both development and administration. Sensible signing policy lets good applications and well-written agents run smoothly and appropriately on wisely administered Domino servers. But good signing policy can also help contain the damage caused by incompetent coding or lax administration. So here’s a quick run-down of good, bad and ugly approaches to signing policy:

The Good: dedicated application signing ID(s)

The most secure, most professional and most flexible approach to design element signing is to use secure dedicated application signing IDs. This is unquestionably the “best practice.”

You can see this policy in action at IBM/Lotus where templates, for example, are signed:

CN=Lotus Notes Template Development/O=Lotus Notes.

The Bad: signing with the server ID

Notes/Domino R5 introduced a feature that let administrators sign applications with the active server ID. On the surface it seemed like a killer feature—the server ID is probably fairly secure plus you wouldn’t need to interrupt your work with a switch ID (as you would if you were using a dedicated application signing ID).

But once the euphoria died down, savvy administrators realized that signing with the server ID is a risky proposition. For starters, it would give signed agents the full rights of the server. And since the server ID’s access requirements are completely different from what would be appropriate access for an application (and especially any agents inside an application), administrators will often need to create very complicated ACL groups just to get things to work properly.

The Ugly: the free-for-all signing policy

And what about organizations that have no signing policy at all? A whole slew of problems can emerge if developers just sign applications with their own names. First off, end-users will see a potentially frightening pop-up asking them if they would start trusting some developer (whose name they’ve perhaps never even heard of!).

Secondly, this non-policy greatly complicates administration. For instance, a junior developer’s ID might need far more access than would otherwise be appropriate for the agents in his-or-her database to run effectively.

And there’s even a more basic argument against this practice: Having developers (or administrators) sign production databases with their own IDs links a process to a person’s name. If a developer leaves the company, his-or-her signatures will remain. (Update: BastianW’s comment below explains some of the real-world implications of this).

This article was originally published in the Notes Code newsletter.

PS: Ytria makes the ultimate Lotus Notes signature tool: signEZ. The free Lite version of signEZ lets you audit the signature status of all the designs in any Notes application. Download it here.