Bouncy Castle FIPS Issue

[Cantor, Scott]

> I don't know that the XML Encryption authors were deliberately trying to
> preclude FIPS, but I also don't think they were suggesting a required monolithic
> approach either.

I was there for the 1.1 work. The people involved, myself included, were largely people who operate on the higher levels of this stack, not cryptographers or people with significant implementation experience with the primitives. Decisions were made largely out of a significant amount of ignorance and lots of stuff got done that probably were bad ideas or without considering all of the implications. Nor, I would add, was Java the only target audience, of course.

FIPS was never even mentioned, that I recall, nor were the implications of any decisions on HSM use.

And KeyAgreement and KeyDerivation in general got very little review because virtually nobody was implementing them, us included. There are no SAML products I know of with ECDH but us. Hell, I don't think anybody else even supports AES-GCM save for a very few exceptions.

With respect to HSMs and this code in general, the only use of OpenSAML we care about is Shibboleth's, and the IdP code base largely does not consider the use of an HSM to be practical because most deployments now are virtualized in some way and network HSMs are either too expensive or too slow to be viable to our audience.

That kind of sucks, but we live in the world that exists, not the one we'd like, and considering that virtually only Shibboleth among SAML software even tries to solve the key management problem at all, we're not even on the radar if somebody wanted to go about fixing the myriad problems in this space re: keys and security.

-- Scott