Object signing and signature verification prerequisites

 

This topic provides information about configuration prerequisites, as well as other planning considerations for signing objects and verifying signatures on your system running the i5/OS^® operating system.

i5/OS object signing and signature verification capabilities provide you with an additional powerful means of controlling objects on your system. To take advantage of these capabilities, meet the prerequisites for using them.

 

Object signing prerequisites

There are a number of methods that you can use to sign objects: depending on your business and security needs:

• You can use the Digital Certificate Manager (DCM).

• You can write a program that uses the Sign Object API.

• You can use the Management Central function of iSeries™ Navigator to sign objects as you package them for distribution to endpoint systems.

Which method you choose for signing objects depends on your business and security needs. Regardless of the method you plan to use to sign objects, ensure that certain prerequisite conditions are met:

• You must meet the prerequisites for installing and using Digital Certificate Manager (DCM).

  • You must use DCM to create the *OBJECTSIGNING certificate store. You create this certificate store either as part of the process of creating a Local Certificate Authority (CA) or as part of the process of managing object signing certificates from a public Internet CA.

  • The *OBJECTSIGNING certificate store must contain at least one certificate, either one that you created by using a Local CA or one that you obtained from a public Internet CA.

  • You must use DCM to create at least one object signing application definition to use for signing objects.

  • You must use DCM to assign a specific certificate to the object signing application definition.

• The user profile that signs objects must have *ALLOBJ special authority. The user profile that creates the *SIGNATUREVERIFICATION certificate store must have *SECADM and *ALLOBJ special authorities.

 

Signature verification prerequisites

There are a number of methods that you can use to verify signatures on objects:

• You can use the Digital Certificate Manager (DCM).

• You can write a program that uses the Verify Object (QYDOVFYO) API.

• You can use one of a number of commands, such as the Check Object Integrity (CHKOBJITG) command.

Which method you choose for verifying signatures depends on your business and security needs. Regardless of the method you plan to use, ensure that certain prerequisite conditions are met:

• You must meet the prerequisites for installing and using Digital Certificate Manager (DCM).

• You must create the *SIGNATUREVERIFICATION certificate store. You can create this certificate store in one of two ways, depending on your needs. You can create it by using Digital Certificate Manager (DCM) to manage your signature verification certificates. Or, if you are using a public certificate to sign objects, you can create this certificate store by writing a program that uses the Add Verifier (QYDOADDV) API.

  The Add Verifier API creates the certificate store with a default password. You need to use DCM to reset this default password to one of your choosing to prevent unauthorized access to the certificate store.

• The *SIGNATUREVERIFICATION certificate store must contain a copy of the certificate that signed the objects. You can add this certificate to the certificate store in one of two ways. You can use DCM on the signing system to export the certificate to a file and then use DCM on the target verification system to import the certificate into the *SIGNATUREVERIFICATION certificate store. Or, if you are using a public certificate to sign objects, you can add the certificate to the target verification system's certificate store by writing a program that uses the Add Verifier API .

• The *SIGNATUREVERIFICATION certificate store must contain a copy of the CA certificate that issued the certificate that signed the objects. If you are using a public certificate to sign objects, the certificate store on the target verification system may already have a copy of the required CA certificate. If you are using a certificate issued by a Local CA to sign objects, however, use DCM to add a copy of the Local CA certificate to the certificate store on the target verification system.

  For security reasons, the Add Verifier API does not allow you to insert a Certificate Authority (CA) certificate into the *SIGNATUREVERIFICATION certificate store. When you add a CA certificate to the certificate store, the system considers the CA to be a trusted source of certificates. Consequently, the system treats a certificate that the CA issued as having originated from a trusted source. Therefore, you cannot use the API to create an install exit program to insert a CA certificate into the certificate store. You must use Digital Certificate Manager to add a CA certificate to the certificate store to ensure that someone must specifically and manually control which CAs the system trusts. Doing so prevents the possibility that the system might import certificates from sources that an administrator did not knowingly specify as trusted.

  If you are using a certificate issued by a Local CA to sign objects, use DCM on the Local CA host system to export a copy of the Local CA certificate to a file. You can then use DCM on the target verifying system to import the Local CA certificate into the *SIGNATUREVERIFICATION certificate store. To prevent a possible error, import the Local CA certificate into this certificate store before using the Add Verifier API to add the signature verification certificate. Consequently, if you are using a certificate issued by a Local CA, you may find it easier to use DCM to import both the CA certificate and the verification certificate into the certificate store.

  If you want to prevent anyone from using this API to add a verification certificate to your *SIGNATUREVERIFICATION certificate store without your knowledge, you need to consider disabling this API on your system. You can do this by using the system service tools (SST) to disallow changes to security-related system values.

• The system user profile that verifies signatures must have *AUDIT special authority. The system user profile that creates the *SIGNATUREVERIFICATION certificate store or changes the password for it must have *SECADM and *ALLOBJ special authorities.

 

Parent topic:

Object signing and signature verification