HP Open Source Security for OpenVMS Volume 1: Common Data Security Architecture > Chapter 3 Secure DeliveryCreating Manifests
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 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. 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 Signer Information Section example:
The PKCS#7 Signature block for this example is almost 4800 bytes of mostly binary data. 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:
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:
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. |