The PKCS #7 standard defines the structure of encrypted content comprising a digital envelope which is intended for multiple recipients. RACF® will first sign, and then envelope (encrypt) the password or password phrase payload (defined below). The recipient will decrypt the envelope to obtain the payload. The recipient should also verify the signature of the envelope, although this is not necessary in order to obtain the payload.

Note that the RACF certificate is required to verify the signature of the envelope. See the description of the RACF password and password phrase enveloping function in z/OS Security Server RACF Security Administrator's Guide on how the recipient can obtain the RACF certificate.

For the structure of the envelope, refer to the PKCS #7 standard, Version 1.5, which can be obtained at .

PKCS #7 defines several data types using ASN.1 notation to describe them. Each type is contained in a ContentInfo type. ContentInfo simply identifies the contained data type with an object identifier (OID), followed by the actual data. See section 7 of the PKCS #7 standard.

On the outside of the structure is a ContentInfo containing the EnvelopedData content type. The EnvelopedData type is described in section 10 of the PKCS #7 standard. The EnvelopedData type is further broken down into subtypes such as RecipientInfos and EncryptedContentInfo. EncryptedContentInfo is broken down further into ContentType, ContentEncryptionAlgorithmIdentifier, and EncryptedContent. ContentType will be SignedData, and EncryptedContent, defined in the standard as OCTET STRING (which just means an arbitray string of data), will be the ContentInfo containing data of type SignedData which is the output of the System SSL signing function. See section 9.1 of the PKCS #7 standard describing the SignedData type.

SignedData contains a field called contentInfo, which is the data being signed. This data can be of any of the types defined by the standard. The type we use is Data, so the contentInfo field within SignedData contains the ContentInfo for the Data type. The Data type is defined as OCTET STRING. This OCTET STRING is the payload that RACF is constructing as input to the whole envelope-creation process. The payload contains password related information in BER-encoded ASCII format.

The following is the ASN.1 notation describing the password payload as constructed by RACF:

PasswordPayload::=SEQUENCE{
                   Version                         INTEGER
                   Expired                         BOOLEAN
                   Password                        UTF8String
                   Changetime                      IA5String
                   Language                        IA5String OPTIONAL   DEFAULT "ENU"
}

The following is the ASN.1 notation describing the password phrase payload as constructed by RACF:

PasswordphrasePayload::=SEQUENCE{ 
                         Version                 INTEGER 
                         Expired                 BOOLEAN 
                         Passwordphrase          UTF8String 
                         Changetime              IA5String 
                         Language                IA5String OPTIONAL DEFAULT "ENU" 
}

Version is the version number of the payload. For the password payload, it is set to 1 if the password has been changed to lowercase, or 2 if the password appears as entered. For the password phrase payload, it is set to 1.

Expired will be true if the new password or password phrase is marked as expired at the time of the change (for example, an ALTUSER command is used to change the password or password phrase without specifying the NOEXPIRED operand). If Expired is true, the password or password phrase must be changed the next time the user logs on.

Password is the value of the new password. If the mixed case password support is not active, the password is in lowercase. If it is active, the password case is as entered.

Passwordphrase is the value of the new password phrase, with case preserved.

Language is the 3 character language code which RACF has used in order to determine the UTF-8 code points for the variant characters. This is for diagnostic purposes. Currently, RACF assumes the language is U.S. English ('ENU'). This may result in RACF propagating a different password or password phrase than may be expected by a given user using a given keyboard and code page. If so, users should avoid using variant characters in passwords and password phrases when RACF is participating in a password synchronization network. For example, a person in the United Kingdom may enter the pound sterling symbol as a character in a new password. This is represented as X'5B' which RACF will accept. When RACF envelopes this password assuming U.S. English, the UTF-8 code point for '$' will be used. If this password is propagated to another system, and the person tries to log on to that system using the same keystrokes he used to change his password in RACF, the password will be rejected.