Issues in using OpenSAML 4.x in FIPS compliant applications
Brent Putman
putmanb at georgetown.edu
Fri Aug 18 00:57:25 UTC 2023
On 8/15/23 9:54 PM, Cantor, Scott via dev wrote:
>
> Whether that leads to a simple fix is a different issue, but that's up to Brent. I will say it seems pretty disadvantageous to me for the package names to be different between them. Unless those classes are programmatically loaded, not sure how that's going to fly. I assume they aren't now, or this wouldn't be a compile time dependency problem.
They aren't currently loaded reflectively, if that's what you mean.
I currently personally know nothing of FIPS compliance, so the concrete
requirements here are just a mystery to me at this point. But in general:
If it ever gets to the point of us trying to support FIPS properly,
we'd really need to nail down what the actual ask is here, what is
"good enough for FIPS users", etc. Right now the kludges people are
doing are just avoiding runtime errors for things they apparently
aren't currently using anyway.
But to do it properly, we might actually have to make all of that stuff
work with the BC FIPS dependency. As in, they might actually want to
use ConcatKDF with ECDH. Or even EC keys period, which is what most of
the ECNamedCurve* and EC5Util dependence is about (consuming and
emitting KeyInfo structures).
So, we might have to have separate modules in java-opensaml and
elsewhere, for FIPS vs non-FIPS. We might have to have then different
distributions of the IdP. Etc. Could get complicated.
And then there's the fact (that we apparently just had to deal with,
again) that the BC folks make completely breaking changes in any
release, i.e. no concept of minor or patch releases ala semantic
versioning, etc. So there's no guarantee at all over time that the
class named X in the non-FIPS artifact really has the same API as class
X in the FIPS artifact. Or which classes exist in one and not the
other. Etc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/dev/attachments/20230817/26335d9c/attachment.htm>
More information about the dev
mailing list