<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Hi Brent,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">It would improve things.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">One other thing that might be worth
looking at is adopting an interface approach for calling out to
cryptographic services. We've done this for the PKIX APIs for BC
for both Java and C#, it's meant the functional component of the
CMS API is not only provider independent but also JCE independent.
The XML definitions do seem very similar to CMS so it might be
worth it. Further down the track this might also offer a way to
break the current dependency.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Regards,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">David<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 17/7/21 2:03 am, Brent Putman wrote:<br>
</div>
<blockquote type="cite"
cite="mid:a71897a9-2899-c3b6-a884-5f575f11e592@georgetown.edu">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi David,<br>
</p>
<p>Since sending the below, I also had a couple of small
epiphanies.</p>
<p>First, regarding HSM and private keys: XML Encryption only
defines and supports ECDH in ephemeral-static mode. So at least
on our IdP side, as the (typically) originator/encrypting party
there is no long-term private key since that's the ephemeral key
pair side. (Discounting the extremely uncommon case of
EncryptedIDs in inbound messages to the IdP.) Since it's just
one time use, the issues around leakage of ephemeral private key
info via the ephemeral agreement secret are close to
non-existent there, I think.</p>
<p>To the extent that there is any issue, it would be isolated to
the recipient/decrypting party side, which in SAML is typically
the SP side of the exchange. We don't currently have such a Java
product, although we are currently working on a Java-based
re-implementation of our SAML SP, so it would come up there.<br>
</p>
<p>Second, back to the practical issue here as originally
reported: I think there is a very simple solution to the issue
of the missing classes in the FIPS jar. I believe we can simply
suppress via an optional system prop etc the instantiation of
the OpenSAML class in the config bootstrap which references
those missing BC classes, thereby avoiding the issue. It would
mean such a deployment could not do ECDH with ConcatKDF (could
use PBKDF2 though), but would at least allow the IdP to
otherwise work correctly with the BC FIPS jar. (And lack of ECDH
is practically not an issue - we aren't aware of any current
SAML SP implementations which even support ECDH.)<br>
</p>
<p>The coding for that would be very simple. We expect to put out
an OpenSAML and IdP patch release soon, so unless there's a
problem with that approach we can likely include in that
release.</p>
<p>Thanks,<br>
Brent</p>
<p> <br>
</p>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 7/15/21 7:46 PM, Brent Putman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c3b64fba-bd17-1b52-f904-087af21a7b84@georgetown.edu">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Regarding HSMs and leaking info: From a practical standpoint
I think there's very little real world concern about the
ephemeral agreement secret being handled in memory on the
host. It's not stored persistently, but it is there as a local
method var, so will exist on the heap prior to GC. But even
more practically, we simply don't target the kind of high
security use case for HSMs. We're not sure it's even possible
to actually use an HSM with say the Shib IdP, and probably
zero users actually trying to do this via PKCS#11. (If someone
is please let us know!).</p>
<p>So realistically private keys are loaded from disk, they are
in-memory, and that's where the real world risk is. And so
any concern about the ephemeral agreement secret is trivial
and moot by comparison. That might not be "great" in some
absolute sense, but it's simply the reality of modern online
services, and we're just part of that world.</p>
<p>Thanks,<br>
Brent</p>
<br>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<p><br>
</p>
</body>
</html>