The project is not in a position to make any official statements or assurances regarding compliance (or lack thereof) with the US Federal Information Processing Standards. However, there are some clarifying points that may help others to reach useful conclusions about this.

Java

The Java products we produce, including the Identity Provider and OpenSAML libraries, rely on the Java Cryptograpy Extensions service APIs for virtually all encryption, decryption, signing, and verification operations involving the core protocols we support. There are two exceptions worthy of note that apply to the V3+ Identity Provider and OpenSAML stack:

• A version of the Bouncy Castle library provides:

  • ASN.1 parser and some certificate and key parsing functionality to one of our dependencies

  • (V4.1+) KeyInfo support for Elliptic Curve keys with Named Curves

  • (V4.1+) Our implementation of ConcatKDF key derivation for encryption using Elliptic Curve Diffie-Hellman (ECDH) key agreement

• One implementation of the OpenSAML StorageService API in V3 is implemented on top of the Bouncy Castle AES-GCM implementation due to compatibility issues with Java 7. While it is used by default within the Identity Provider software, it is not a requirement, and was replaced by the Java implementation in V4.

C++

The C++ products we produce, including the Service Provider and OpenSAML libraries, rely solely on OpenSSL for all underlying cryptographic operations. We do not have any specific knowledge as to the compatibility of such a version with our code but would be happy to consider any patches necessary to allow for this.