Supported algorithms
Signing (RSA)
Config value for security.sign / mdn.signed_micalg:
| Name | Notes |
|---|---|
sha-256 | recommended default |
sha-384, sha-512 | |
sha-224 | |
sha-1 | legacy partners only |
md5 | legacy partners only |
rsassa-pss-sha-256 (also -sha-384, -sha-512, …) | RSASSA-PSS variants |
On the wire, digest names are emitted in RFC 5751 spelling (sha-256)
by default, RFC 3851 spelling (sha256) per partner via
interop.rfc3851_micalgs; inbound, all common spellings and aliases are
accepted and normalized.
Encryption (RSA key transport)
Config value for security.encrypt (also the wire names used in license
features.algorithms):
| Name | Notes |
|---|---|
aes128-cbc, aes192-cbc, aes256-cbc | recommended; universally interoperable |
3des | ubiquitous legacy default; fine for compatibility |
aes128-gcm, aes192-gcm, aes256-gcm | see GCM note below |
rc2 | legacy partners only (OpenSSL legacy provider, loaded automatically) |
cast5, idea | present but excluded from product support — see below |
The AES-GCM note
RFC 5084 specifies AuthEnvelopedData for GCM; the Java/BouncyCastle AS2
family instead ships GCM in plain EnvelopedData with the tag appended.
as2d receives both forms (tag always enforced). Sending defaults to
the conformant form; set interop.bc_style_gcm = true for Java-family
partners. Some non-Java counterparts support no GCM at all — AES-CBC is
the safe universal choice.
Why CAST5 and IDEA are unsupported
BouncyCastle and OpenSSL encode these ciphers’ CMS parameters incompatibly; exchanges fail in both directions with the entire Java AS2 family (measured, not theoretical). The ciphers remain in the binary for the rare non-Java counterpart, but they are outside the support and license scope, and as2d warns at startup when a partnership configures them.
Compression
ZLIB (RFC 3274 / RFC 5402), before-signing (the common form) or
after-signing. Inbound double compression is rejected
(decompression-failed), and decompression is capped by
limits.decompress_limit_mb.