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.
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_MODULE: CSSM
CDSA _GUID: {d6b5e820-f376-11d3-9bea-0008c74fe165}
Signer Information Section example:
Signature-Version: 2.0
CDSA_PVC_API: OFF
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:
$ @CDSA_SYSDIR:[SIGN]CDSA$SD_SIGN.COM
Please enter the full name of the module to sign including directory:
SYS$KITS:[KERBEROS]HP-AXPVMS-KERBEROS-V0200-6-1.PCSI
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.
The CDSA$REVOKE.EXE
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:
$ REVOKE :== $SYS$SYSTEM:CDSA$REVOKE.EXE ! see SYS$MANAGER:CDSA$SYMBOLS.COM
$ REVOKE CDSA_SYSDIR:[CRL]REVOKE_EX.DAT;1
2 Certificates written to cdsa$revocation_req.crr.
CDSA_SYSDIR:[CRL]CDSA$REVOCATION_REQ.CRR successfully created.
$ |
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.
