LockIt signature creation is according to Qualified Electronic Signature profile for interoperability

Lock It Signature Creation is according to NSA Qualified Electronic Signature profile for interoperability No.: 917/2011/IBEP/OEP-001

For the signature creation and validation there are used the following CAdES attributes where the following conditions must be met:
The RFC 5652 Cryptographic Message Syntax (CMS) defines:
SignedData ::= SEQUENCE {
   version CMSVersion,
   digestAlgorithms DigestAlgorithmIdentifiers,
   encapContentInfo EncapsulatedContentInfo,
   certificates [0] IMPLICIT CertificateSet OPTIONAL,
   crls [1] IMPLICIT RevocationInfoChoices OPTIONAL,
  signerInfos SignerInfos }

In RFC 5652 it is intended that the SignedData-certificates are sufficient to contain certification paths from a recognized "root" or "top-level certification authority" to all of the signers in the SignedData-signerInfos field. There may be more certificates than necessary, and there may be certificates sufficient to contain certification paths from two or more independent top-level certification authorities.
According to this profile the signer's certificate MUST be included and also must be included the whole certification path selected by the signer during the signature creation process (CWA 14170), what means, the signer must perform the initial certificate verification before the signature creation (CWA 14170).
In RFC 5652 it is intended that the SignedData-crls type gives a set of revocation status information alternatives. It is intended that the set contains information sufficient to determine whether the certificates and attribute certificates with which the set is associated are revoked. However, there MAY be more revocation status information than necessary or there MAY be less revocation status information than necessary. X.509 Certificate revocation lists (CRLs) [X.509-97] are the primary source of revocation status information, but any other revocation information format can be supported. The OtherRevocationInfoFormat alternative is provided to support any other revocation information format without further modifications to the CMS. For example, Online Certificate Status Protocol (OCSP) Responses [RFC 2560 - OCSP] can be supported using the OtherRevocationInfoFormat.
According to this profile the SignedData-crls SHOULD contain CRL or OCSP responses for validation of each certificate used in SignedData-signerInfos before signature archiving by the archiving timestamp or archiving by the secure audit trail. The field SignedData-crls MAY also contain CRL or OCSP responses which are not used in validation of signatures included in SignedData-signerInfos.
RevocationInfoChoices ::= SET OF RevocationInfoChoice

RevocationInfoChoice ::= CHOICE {
   crl CertificateList,
   other [1] IMPLICIT OtherRevocationInfoFormat }

OtherRevocationInfoFormat ::= SEQUENCE {
   otherRevInfoFormat OBJECT IDENTIFIER,
   otherRevInfo ANY DEFINED BY otherRevInfoFormat }

According to this profile when OCSP response is used the SignedData-crls-[1]otherRevInfoFormat MUST contain OID id-pkix-ocsp-basic (1.3.6.1.5.5.7.48.1.1) and SignedData-crls-[1]otherRevInfo MUST contain BasicOCSPResponse.