<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Hi Brent,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">It will work. The naming convention is
also to allow mixing and matching, you just need to add:<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">org.bouncycastle.jcajce.spec.UserKeyingMaterialSpec</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">as a parameter to the KeyAgreement.
It's unfortunate that the JCE doesn't define this parameter, so I
am not surprised you are not aware of it, but it's impossible to
use key agreement properly without it, and it exists in both BC
and BCFIPS specifically for situations like this.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">You use the UserKeyingMaterialSpec to
pass in otherInfo, which I can see is being constructed in
accordance with SP 800-56A which is the FIPS standard. There is
some BC support for otherInfo but we are using the ASN.1
construction, SP 800-56A allows for several others, and I'm not
sure what the XML standard settled on. You are probably better off
sticking to what you are doing now.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">For our part I think we'd just need to
add some additional KDF support for the non-NIST digests. In the
case of the SAML code it would just be a matter of replacing
SecretKey derive() I think and allowing for the
UserKeyingMaterialSpec construction.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Concerning your comments about BC and
BCFIPS. Yes the low level libraries are different, they have to
be, but we've been able to keep the JCE layer in sync since 1.58.
The upside of this is it means if people swap in BCFIPS rather
than BC they can be confident the code is then FIPS compliant. If
you interested in finding out why the difference exists, there is
actually a document</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><a class="moz-txt-link-freetext" href="https://www.bouncycastle.org/fips/BCFipsDescription.pdf">https://www.bouncycastle.org/fips/BCFipsDescription.pdf</a><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">which provides a summary. I would
recommend that over reading the FIPS IG and the 30 or so
associated documents that go with it unless you have a specific
interest. The same applies for Common Criteria. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I don't think there will be any
end-user problems as the end result will be a massive broadening
of what the OpenSAML project can be used for.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Any further questions or issues, please
let me know.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks,</div>
<div class="moz-cite-prefix"><br>
David<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 15/7/21 8:59 am, Brent Putman wrote:<br>
</div>
<blockquote type="cite"
cite="mid:6c8d1d8d-6f3c-561c-3422-81107b4410be@georgetown.edu">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi David,</p>
<p>I took a look and unfortunately what you propose won't work,
for at least 2 reasons.</p>
<p>First (the main and show-stopping technical issue), those
provider-based algorithms you mention are apparently for the
KeyAgreement service of the Java security framework. It seems
those combine the key agreement op with the KDF op all in one
go?</p>
<p>That won't work for our design because we're modeling the
requirements of XML Encryption 1.1 where the KA and KDF ops are
conceptually completely separate. They are defined separately,
have distinct XML representations, etc, so one can mix-and-match
KA algo and KDF algo.</p>
<p>So in OpenSAML we have distinct KA and KDF interfaces and then
various impls for each. For example we have interface
org.opensaml.xmlsec.derivation.KeyDerivation. The ConcatKDF
impl of that in question that threw a NoClassDefFoundError with
FIPS was our org.opensaml.xmlsec.derivation.impl.ConcatKDF,
which imports these KDF-related classes (along with some needed
BC digest classes):</p>
<p><font face="monospace">import
org.bouncycastle.crypto.agreement.kdf.ConcatenationKDFGenerator;<br>
import org.bouncycastle.crypto.params.KDFParameters;</font><br>
</p>
<p>It was specifically throwing on not finding
org.bouncycastle.crypto.DerivationParameters, which is the
interface implemented by the above BC KDFParameters. For
reference that source is here:</p>
<p><a class="moz-txt-link-freetext"
href="http://git.shibboleth.net/view/?p=java-opensaml.git;a=blob;f=opensaml-xmlsec-impl/src/main/java/org/opensaml/xmlsec/derivation/impl/ConcatKDF.java;hb=refs/heads/main"
moz-do-not-send="true">http://git.shibboleth.net/view/?p=java-opensaml.git;a=blob;f=opensaml-xmlsec-impl/src/main/java/org/opensaml/xmlsec/derivation/impl/ConcatKDF.java;hb=refs/heads/main</a><br>
</p>
<p>By contrast, for PBKDF2 we are using the SecretKeyFactory
service with the JDK-provided algorithm support for
"PBKDF2With*" (completed with the appropriate PRF algo ID). So
if the BC provider had a SecretKeyFactory impl for ConcatKDF by
itself, that would be closer to our needs. But....</p>
<p>Second, it's unlikely we could introduce a deployment
requirement for people to add the BC provider declaratively in
java.security and also questionable for us to add the BC
provider programmatically by default. As a library OpenSAML
probably shouldn't muck with people's environments like that.</p>
<p>And in XML Encryption 1.1, ConcatKDF is the
mandatory-to-implement KDF (PBKDF2 is optional). For that
reason it is our default KDF for ECDH, and it needs to work
out-of-the-box. So hopefully you can see that adding a
requirement on configuring a third-party provider would be an
issue for us. Our team can discuss further the idea of
automagically/programmatically adding in BC. I personally am
not a fan of the idea. But unless/until BC has a provider-based
impl of the ConcatKDF by itself, it's essentially a moot
question.</p>
<p>I guess what I would ask about the FIPS version is: If the
provider there fundamentally supports ConcatKDF via the
KeyAgreement algorithms you mention, then why aren't the KDF
interfaces/impls there as well? Probably they are there but
just with different package and/or class names, etc? If they
are, then you know, that means the FIPS version really isn't a
drop-in replacement for the regular library, so it's going to be
challenging for us as a downstream consumer to overcome that.<br>
</p>
<p>Thanks,<br>
Brent</p>
<p><br>
</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/13/21 10:30 PM, David Hook
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:029f362c-698c-41ce-1a0d-8c75fd5b1624@cryptoworkshop.com">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<div class="moz-cite-prefix">Hi Brent,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I'd like to suggest that it gets
changed to use the BC provider rather than the BC low-level
API.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">For some reason I can't connect to
any of the nabble references, so I can't easily find the
source file concerned, but from what I understand V4.1 added
support for the ConcatKDF key derivation function with ECDH.
When I checked the code this looked like something the BCFIPS
provider supports already (and the BC provider) for the JCE.
The agreement algorithms ending in CKDF use the concat KDF
function.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">The following ones are currently
available in both providers:</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">ECCDHWITHSHA1CKDF<br>
ECCDHWITHSHA256CKDF</div>
<div class="moz-cite-prefix">ECCDHWITHSHA384CKDF<br>
</div>
<div class="moz-cite-prefix">ECCDHWITHSHA512CKDF</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">I have subscribed to the dev list
if you would prefer to continue the discussion there. If you
would include the link to the source file either way we should
be able to work something out that will work for both
providers (as I have commit access to both, you'd hope so!).</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Let me know,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thanks,</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 14/7/21 7:17 am, Brent Putman
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:82b98164-38f8-07b9-7e98-c16a15b84c08@georgetown.edu">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<p>Hello,</p>
<p>Sorry David (Hook) that I didn't get back to you when I
returned from vacation a couple of weeks ago, I
unfortunately overlooked that email todo.</p>
<p>I'm interested to hear what you had in mind. If possible
it would be great to have this discussion over on the
Shibboleth/OpenSAML developers list, so that other members
of the team and community can be aware and participate:</p>
<p><a class="moz-txt-link-freetext"
href="https://shibboleth.net/mailman/listinfo/dev"
moz-do-not-send="true">https://shibboleth.net/mailman/listinfo/dev</a><br>
</p>
<p>Thanks,<br>
Brent</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/9/21 11:54 AM, David Castro
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAN0SfypGqdg1U6tr1m0EBRVDotj-f64CcKRVQtyaeDMq-R-8dA@mail.gmail.com">
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div dir="ltr">Brent,
<div><br>
</div>
<div>Just wanted to follow up Re: the following thread on
the FIPS issue we were having.</div>
<div>
<div><a
href="https://shibboleth.1660669.n2.nabble.com/Bouncy-Castle-FIPS-Issue-td7649455.html#a7649653"
moz-do-not-send="true"><br
class="gmail-Apple-interchange-newline">
https://shibboleth.1660669.n2.nabble.com/Bouncy-Castle-FIPS-Issue-td7649455.html#a7649653</a></div>
<div>
<div><br>
</div>
</div>
</div>
<div>We spoke with David Hook from Bouncy Castle (included
in this thread) and he had some ideas on resolving the
issue. Scott Cantor recommended you as the point of
contact, but let us know if there is someone else we
should reach out to.</div>
<div><br>
</div>
<div>
<div>We are also available to assist as needed.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>David</div>
<div><br>
</div>
-- <br>
<div dir="ltr" class="gmail_signature"
data-smartmail="gmail_signature">
<div dir="ltr"><span
style="color:rgb(0,112,192);font-family:Verdana,sans-serif;font-size:13.3333px">CONFIDENTIALITY
NOTICE: </span><span
style="color:rgb(0,112,192);font-family:Verdana,sans-serif;font-size:13.3333px;background-image:initial;background-position:initial;background-repeat:initial">This
transmission, and any attachments, may contain
CONFIDENTIAL, PRIVILEGED or PROPRIETARY
information of HRworx, LLC (dba Intelliworx) that
is protected from disclosure under applicable
laws. If you are not the intended recipient, any
disclosure, copying, distribution, or use of any
of the information contained in or attached to
this transmission is STRICTLY PROHIBITED. </span><span
style="color:rgb(0,112,192);font-family:Verdana,sans-serif;font-size:13.3333px">If
you have received this communication in error,
please notify the sender, by reply e-mail, and
delete the original message with any attachments.
Thank you for your cooperation.</span><br>
</div>
</div>
</div>
</div>
</blockquote>
</blockquote>
<p><br>
</p>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
</blockquote>
<p><br>
</p>
</body>
</html>