Hello, While surveying PKCS#1 v1.5 implementations [0] for the behavioral Bleichenbacher oracle [1] I found that GnuTLS exposes the oracle through its callable decrypt API. `gnutls_privkey_decrypt_data` / `gnutls_privkey_decrypt_data2` returns `GNUTLS_E_DECRYPTION_FAILED` on a non-conforming block and succeeds otherwise — a distinguishable bit. `_data2` is documented constant-time but that is constant-time *explicit* rejection, not implicit rejection; the behavioral bit remains. The oracle is closed inside the TLS key-exchange path (result discarded) but not for general callers (JOSE / CMS / PKCS#11 / direct decrypt). Runtime-confirmed, source-reviewed in `lib/privkey.c` and `lib/pk.c`. The CFRG implementation guidance draft [2] covers remediation: OAEP as the fix, implicit rejection (§7.2) as the stopgap if v1.5 must stay. Mark Esler [0] https://hexproof.dev/datagrams/bleichenbacher-oracle-survey/ [1] https://hexproof.dev/datagrams/ok-err-is-a-padding-oracle/ [2] https://datatracker.ietf.org/doc/draft-irtf-cfrg-rsa-guidance/