HP OpenVMS Systems Documentation

Content starts here
HP Open Source Security for OpenVMS Volume 1: Common Data Security Architecture > Chapter 3 Secure Delivery

Creating Manifests

  Table of Contents



Secure Delivery provides a number of features to help with the creation of manifests. To create a manifest, a vendor must first create a self-signed certificate using CDSA. This certificate provides essential information about the party that can be integrated into all of the manifests that are created. After the self-signed certificates are created, they must be signed by the Certificate Authority (CA). OpenVMS is currently the CA for CDSA/Secure Delivery on OpenVMS. The signed certificates returned from the CA can then be used to create manifests. For information about how to use CDSA$GEN_CERTS.COM to generate self-signed certificates and get them signed by the CA, see Chapter 5.After the certificates are signed by the CA, they should be placed in the CDSA_SYSDIR:[SIGN] directory on a special system designated as the local signing system. At this point the CA also has a copy of this certificate in case it ever needs to be revoked. This certificate is now ready to be used to create manifests, as described in the following sections.

The Signing Process

The CDSA application CDSA$SIGN.EXE can be used to sign any file, including but not limited to executable files. The signing process combines three types of information into the manifest. Figure 3-1 illustrates these information types.

Figure 3-1 Information Combined Into Manifest

Information Combined Into Manifest

The format used to describe both the manifest and the signer's information is a series of Name:Value pairs (RFC 822).

Manifest Section example:

Manifest-Version: 2.0
Name: executable: cdsa$incssm300_shr.exe
SectionName: cdsa$incssm300_shr
Digest-Algorithms: SHA-1
SHA-1-Digest: sqHfj0uHdeNYZ5A062/78fZ6f3Q=
CDSA _GUID: {d6b5e820-f376-11d3-9bea-0008c74fe165}

Signer Information Section example:

Signature-Version: 2.0
Name: executable: cdsa$incssm300_shr .exe
SectionName: cdsa$incssm300_shr
Digest-Algorithms: SHA-1
SHA-1-Digest: kcwgKvohlRCnRXhghNUAcqT7lvY=

The PKCS#7 Signature block for this example is almost 4800 bytes of mostly binary data.

The CDSA$SD_SIGN.COM Procedure

The command file CDSA$SD_SIGN.COM uses CDSA$SIGN.EXE. CDSA$SD_SIGN.COM prompts for the file to sign, the signed certificate from the CA, and a password. This password must match the password that was used in the run files when creating the self-signed certificates.

The following is an example of calling CDSA$SD_SIGN.COM:

Please enter the full name of the module to sign including directory:
Please enter the name of your signed certificate, located in cdsa_sysdir:[sign]: intapps.cer
Please enter the password, it must match the password used to create self-signed certificates: ********
Invoking cdsa$sign.exe. Please wait.
Signed Manifest

Copy the manifest file to the same location as the file being signed. At this point, both files should be considered an inseparable pair. For example, if the original file is mastered onto a CD for distribution, the manifest should also be placed in the same directory on the CD. This allows the subsequent verification to take place, since the verification process looks in the directory where the original file being verified is located to find the manifest file.


In some instances, you might need to revoke one of your certificates. If a certificate is compromised or is rendered invalid for any reason, you can use CDSA$REVOKE.EXE to revoke the certificate.

Input to this application is the name of a file containing a list of certificates (by name) to be revoked. The application simply writes the certificates to the data file along with other bookkeeping information so that the CA can interpret the file.

The resulting revocation file is saved in the CDSA_SYSDIR:[CRL]CDSA$REVOCATION_REQ.CRR file.

The following is an example of using CDSA$REVOKE.EXE:

2 Certificates written to cdsa$revocation_req.crr.

The CDSA$REVOCATION_REC.CRR file can then be sent to the CA, where the data file is available to the CRL generation program. The CRL generation program updates the directory tree, and the certificate is considered revoked.