Sharing Keyrings in Top Secret
search cancel

Sharing Keyrings in Top Secret

book

Article ID: 270469

calendar_today

Updated On:

Products

Top Secret

Issue/Introduction

Hoping that there is a better way to create a Keyring and share certs.  Right now, we have a 'copy' defined for each person that needs the keyring and certs on it, but this leads to potential problems and cumbersome changes - especially now that certs need to be renewed annually.

Is there an option for adding to a profile, or some other mechanism so that they can be defined in one place and used by many.


 

Environment

Release : 16.0

Resolution

There are two options that can be explored that are a bit different than the common way of handling keyrings.
1)  You can use a Virtual Keyring.  In order for a virtual keyring to be used the application must support a keyring name of *.   
      The most common is to use CERTAUTH.  Certauth would have to own all the certificates on the keyring. 
      The Parms for the application would have *AUTH*/*.

      *AUTH* is the owner of the keyring and * is the name of the keyring.
      Anyone using the virtual keyring needs the usual IBMFAC permits:
        TSS PERMIT(acid) IBMFAC(IRR.DIGTCERT.LIST) ACCESS(UPDATE)
        TSS PERMIT(acid) IBMFAC(IRR.DIGTCERT.LISTRING) ACCESS(UPDATE
   And a permit for:
        TSS PERMIT(acid) RDATALIB(CERTAUTH.IRR_VIRTUAL_KEYRING.LST) ACCESS(UPDATE)
  When using a Virtual Keyring all certificates owned by Certauth are read.

2) You can permit acids to use another acid's keyring.
    The users would all have to have the following permits:

    TSS PERMIT(acid) IBMFAC(IRR.DIGTCERT.LIST) ACCESS(UPDATE)
    TSS PERMIT(acid) IBMFAC(IRR.DIGTCERT.LISTRING) ACCESS(UPDATE)
    TSS PERMIT(acid) RDATALIB(ringowner,ringname.LST) ACCESS(UPDATE)