Supported CMS Content Types

• EnvelopedData content type [RFC5652] using key management techniques key transport (ktri), key agreement (kari), previously distributed symmetric key-encryption keys (kekri), and password-based key management (pwri).
  • Supported key transport algorithms are the RSA encryption schemes RSAES-PKCS-v1_5 and RSAES-OAEP.
  • The supported key agreement algorithm is the 'standard' ECDH Elliptic Curve Diffie-Hellman scheme using ANSI-X9.63-KDF or HKDF.
    • dhSinglePass-stdDH-sha*kdf-scheme aka ecdhX963KDF-SHA* (where * is 1, 256, 384, or 512)
    • dhSinglePass-stdDH-hkdf-sha*-scheme aka ecdhHKDF-SHA* (where * is 256, 384, or 512)
  • For the RecipientIdentifier field in ktri and kari types both choices issuerAndSerialNumber and subjectKeyIdentifier are supported.
  • For kekri and pwri types only one recipientInfo is supported.
  • For pwri types, only the key derivation algorithm PBKDF2 from [RFC8018] and the key encryption algorithm pwriKEK from [RFC3211] are supported.
  • For kekri types, the key encryption algorithms cms3DESwrap and aes*-wrap are supported (where * is 128, 192, or 256).
  • The optional EnvelopedData fields OriginatorInfo and UnprotectedAttrs are not supported.
• In addition, for EnvelopedData, RSA-KEM is supported using the KemRecipientInfo structure (informally "kemri") inside a CMS OtherRecipientInfo (ori), see RSA-KEM.
• AuthEnvelopedData content type [RFC5083] using the same key management types and schemes as for EnvelopedData above using content-encryption algorithms AES_*_GCM and CHACHA20_POLY1305 (where * is 128, 192, or 256).
• SignedData content type [RFC5652].
  • Optional signed attributes are supported.
  • "Detached signature" is supported.
  • Degenerate SignedData "certs-only" messages, a.k.a. PKCS#7 certificate chains are supported.
  • The optional SignedData field UnsignedAttributes is not supported.
• CompressedData content type as per [RFC3274].

Only CMS objects with an id-data inner content type are supported.

X.509 Certificates

• You can create your own X.509 certificates as either Version 1 or Version 3 (default).
• You can create a self-signed CA certificate and use this to create your own internal chain of signed certificates.
• A Certificate Signing Request (CSR) file can be created to be submitted to the CA of your choice.
• The most commonly used options for X.509 distinguished names are provided: see Specifying Distinguished Names.
• Optional key usage extensions and X.509 Extensions can be added.
• X.509 certificate revocation lists (CRLs) can be read and version 1 CRLs can be created.
• Unicode character sets like UniversalString and BMPString are not supported, but UTF8 is.