Re: FIPS Java API provider and non-FIPS provider

Hi,

Yes, the FIPS package cannot be changed as it would require
revalidation, although that's really a financial, not a technical restraint.

There is a bit more to it though - the jars can't be used in the same
application as it would make it almost impossible to be sure that an
application was actually FIPS compliant. You would only need a 3rd party
library to be calling the BC lightweight API to use a non-certified
function and it would be all over. So they cannot co-exist, it just
won't work like that.

I'm happy to discuss this further off list, I'd just need a bit more
background on what you're trying to do.

Regards,

David

On 22/06/18 23:48, Rhuberg,Anthony wrote:
>
> Hi,
>
>  
>
> I appreciate your help trying to resolve this conflict.
>
>  
>
> Also, forgive my persistence.
>
>  
>
> We require a FIPS compliant/validated crypto module. I do not think
> “spongycastle-like” is an alternative.We are including both jars
> because some of our third parties already require use of the non-FIPS
> compliant jar (not something we can readily change). If I understand
> this correctly, the conflict seems to be an issue with common classes
> in either the bcfips and bcprov jars that contain the same classes
> with different implementations (that are causing the name clashes). If
> these jars are never intended to be integrated with the same
> application, I suppose I understand that limitation, but that probably
> makes it impossible to use the bcfips jar when other third parties
> (out of our/your control) use the non-fips version.
>
>  
>
> Can the FIPS package not be changed because that would require it to
> be revalidated (by CMVP) ? What would be the effort necessary for both
> the bcfips and bcprov to coexist? Maybe we could discuss this offline.
>
>  
>
> Respectfully,
>
> Tony
>
>  
>
>  
>
> *From:*David Hook [mailto:dgh-rTAZ0PM/[email protected]]
> *Sent:* Thursday, June 21, 2018 4:22 AM
> *To:* Rhuberg,Anthony <[email protected]>;
> [email protected]; [email protected]
> *Subject:* Re: [dev-crypto] FIPS Java API provider and non-FIPS provider
>
>  
>
>
> The FIPS package can't be changed. You could do a "spongycastle" on
> the original Bouncy Castle ones.
>
> The FIPS library doesn't have an implementation of the low-level BC
> library. From a FIPS point of view the low-level API breaks most of
> the existing rules, and probably a couple they did not consider.
>
> Providers can certainly co-exist, but package name clashes (at least
> in the system class loader) are right out.
>
> Regards,
>
> David
>
> On 21/06/18 06:33, Rhuberg,Anthony wrote:
>
>     Is it possible or an option to change the package names of bouncy
>     castle fips implementation? Changing the name would create a
>     independent provider that would not conflict with any other providers.
>
>      
>
>     ------------------------------------------------------------------------
>
>     *From:* Rhuberg,Anthony <[email protected]>
>     <mailto:[email protected]>
>     *Sent:* Wednesday, June 20, 2018 3:49:52 PM
>     *To:* [email protected] <mailto:[email protected]>;
>     [email protected] <mailto:[email protected]>
>     *Subject:* RE: [dev-crypto] FIPS Java API provider and non-FIPS
>     provider
>
>      
>
>     Thanks for the clarification. I found at least one class in the
>     same package with a different implementation in bc-fips than
>     bcprov. I am not sure that affects our workflow, but it explains
>     the conflict.
>
>
>     -----Original Message-----
>     From: Eckenfels. Bernd [mailto:[email protected]]
>     Sent: Wednesday, June 20, 2018 3:19 PM
>     To: [email protected] <mailto:[email protected]>
>     Subject: RE: [dev-crypto] FIPS Java API provider and non-FIPS provider
>
>     The problem is that BC and BcFiPS have conflicting implementation
>     classes. There is some logic to that (be a plugin replacement),
>     but overall it seems to hurt more than it helps. Maybe it would be
>     a option to offer a FIPS jar with distinct namespace for those cases.
>
>     --
>     https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.seeburger.com&data=02%7C01%7CAnthony.Rhuberg%40Cerner.com%7C0480b4cbfcff443e0de708d5d6e2ba56%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636651191659833148&sdata=fCAqTqOTcglZ49cyLIA6HCPBiNEp3g4i9Ijydu9sXbo%3D&reserved=0
>     ________________________________________
>     From: Rhuberg,Anthony [[email protected]
>     <mailto:[email protected]>]
>     Sent: Wednesday, June 20, 2018 20:58
>     To: David Hook; Matti Aarnio; [email protected]
>     <mailto:[email protected]>
>     Subject: RE: [dev-crypto] FIPS Java API provider and non-FIPS provider
>
>     Hi again,
>
>     I am trying to understand the conflict further and am not really
>     familiar with JCA/JCE.
>
>     If both JCE providers 'bcprov´and 'bcfips' are loaded into the
>     same class loader, I do not understand the conflict if they both
>     have different provider names and implementation classes. If I
>     request a Signature.getinstance("SHA256withRSA", "BCFIPS"), would
>     I not get the bcfips implementation and NOT the bcprov instance?
>
>     Can multiple JCE providers be deployed within an application and
>     the application decide which implementation to use without
>     conflict? I guess I am expecting providers to coexist.
>
>     Is this conflict a BC conflict only? I am asking because if we
>     selected another JCE provider (to get around this issue) and still
>     have bcprov in the same class loader, would we still have a
>     similar conflict between another provider and bcprov?
>
>     Thanks again,
>     Tony
>
>     From: David Hook [mailto:dgh-rTAZ0PM/[email protected]]
>     Sent: Tuesday, June 19, 2018 6:18 PM
>     To: Rhuberg,Anthony <[email protected]>
>     <mailto:[email protected]>; Matti Aarnio
>     <[email protected]> <mailto:[email protected]>;
>     [email protected] <mailto:[email protected]>
>     Subject: Re: [dev-crypto] FIPS Java API provider and non-FIPS provider
>
>
>     The high risk element is the JCE - it depends how it gets loaded
>     and if both things make use of the respective providers. Often
>     this means things end up in the system class loader and in that
>     case there can be only one.
>
>     If bcprov isn't loaded in the system class loader and/or bc-fips
>     is able to satisfy the dependency anyway, you will probably be okay.
>
>     General the problems you see if it is an issue don't make sense.
>     You'll get issues with undefined methods, class not found, missing
>     fields. In some cases you will get class cast exceptions where it
>     seems impossible as well.
>
>     If you want to ask the OpenSAML guys to talk to us we would be
>     happy to help them update.
>
>     Regards,
>
>     David
>
>     On 20/06/18 05:04, Rhuberg,Anthony wrote:
>     Just a follow up from my previous question.
>
>     We have a configuration with a Tomcat Valve which uses opensaml
>     (with a dependency on xmlsec -> bcprov-jdk15on). These classes are
>     part of the root class loader (call it CLroot).
>     We just started using bc-fips-1.0.1.jar for digital signatures in
>     a web application. That jar is part of the war (call it CL1).
>
>     Based on this configuration, we expected to observe some conflict
>     when executing the pathways for the Tomcat Valve and web application.
>
>     The applications are "working", but worry that there is some
>     unseen or potential problem that we have just not encountered.
>
>     Any thoughts? Do you have an examples of how a collision (between
>     the 2 jars bcprov-jdk15on - bc-fips-1.0.1.jar ) would be manifest?
>     Do you have examples of typical errors when there is a conflict?
>
>     Thanks,
>     Tony
>
>
>     From: Matti Aarnio [mailto:[email protected]]
>     Sent: Tuesday, June 05, 2018 2:33 PM
>     To: Rhuberg,Anthony <[email protected]>
>     <mailto:[email protected]><mailto:[email protected]>
>     <mailto:[email protected]>; [email protected]
>     <mailto:[email protected]><mailto:[email protected]>
>     <mailto:[email protected]>
>     Subject: Re: [dev-crypto] FIPS Java API provider and non-FIPS provider
>
>     Hi Tony,
>
>     The detail that affects more than "in same JVM" is "are they in
>     same class loader?"
>
>     WARs are loaded into separate class loader chains.
>     WAR1 gets loader chain:  CL1, CLroot.
>     WAR2 gets loader chain:  CL2, CLroot.
>
>     If neither BCFIPS nor BCPROV are in CLroot, and instead in
>     separate WARs, then the libraries will not see each other, and no
>     collision happens.
>
>     The "CLroot" is server/lib/ in current Tomcats.
>     The "CLn" is webapps/warname/WEB-INF/lib/
>
>     Best Regards, Matti
>
>     On 05.06.2018 21:01, Rhuberg,Anthony wrote:
>
>     We have an application deployed within Tomcat and that application
>     is uses Apache CXF which has a dependency on bcprov-jdk15on-1.51.
>
>     Referring to:
>     https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bouncycastle.org%2Ffips-java%2FBCFipsIn100.pdf&data=02%7C01%7CAnthony.Rhuberg%40Cerner.com%7C0480b4cbfcff443e0de708d5d6e2ba56%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636651191659833148&sdata=Uu0MQygo4cUAhLyJarXP1W30tz1sEcvY2u9N993brcY%3D&reserved=0<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bouncycastle.org%2Ffips-java%2FBCFipsIn100.pdf&data=02%7C01%7CAnthony.Rhuberg%40Cerner.com%7Ce60fa34500a84aeb1a7a08d5cb12c856%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636638203905695412&sdata=wmqUcMfgAVX7I2s%2F6rXx2ZCBUnzZZRRMKMBWZXLPR3o%3D&reserved=0>:
>     <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bouncycastle.org%2Ffips-java%2FBCFipsIn100.pdf&data=02%7C01%7CAnthony.Rhuberg%40Cerner.com%7C0480b4cbfcff443e0de708d5d6e2ba56%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636651191659833148&sdata=Uu0MQygo4cUAhLyJarXP1W30tz1sEcvY2u9N993brcY%3D&reserved=0%3Chttps://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.bouncycastle.org%2Ffips-java%2FBCFipsIn100.pdf&data=02%7C01%7CAnthony.Rhuberg%40Cerner.com%7Ce60fa34500a84aeb1a7a08d5cb12c856%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636638203905695412&sdata=wmqUcMfgAVX7I2s%2F6rXx2ZCBUnzZZRRMKMBWZXLPR3o%3D&reserved=0%3E:>
>     "The provider jar itself has no external dependencies, but it
>     cannot be used in the same JVM as the regular Bouncy Castle
>     provider. The classes in the two jar files do not get along".
>
>     We are integrating FIPS Java API provider into another application
>     WAR. We have not encountered an issues yet, but wanted to know
>     what kinds of errors are expected if two applications use
>     different Bouncy Castle Java implementations within the same JVM.
>
>     Thanks,Tony
>
>
>
>     CONFIDENTIALITY NOTICE This message and any included attachments
>     are from Cerner Corporation and are intended only for the
>     addressee. The information contained in this message is
>     confidential and may constitute inside or non-public information
>     under international, federal, or state securities laws.
>     Unauthorized forwarding, printing, copying, distribution, or use
>     of such information is strictly prohibited and may be unlawful. If
>     you are not the addressee, please promptly delete this message and
>     notify the sender of the delivery error by e-mail or you may call
>     Cerner's corporate offices in Kansas City, Missouri, U.S.A at (+1)
>     (816)221-1024.
>
>
>
>
>
>
>
>
>
>
>
>     SEEBURGER AG            Vorstand/SEEBURGER Executive Board:
>     Sitz der Gesellschaft/Registered Office:                Axel Haas,
>     Michael Kleeberg, Friedemann Heinz, Dr. Martin Kuntz, Matthias
>     Feßenbecker
>     Edisonstr. 1
>     D-75015 Bretten         Vorsitzende des Aufsichtsrats/Chairperson
>     of the SEEBURGER Supervisory Board:
>     Tel.: 07252 / 96 - 0            Prof. Dr. Simone Zeuchner
>     Fax: 07252 / 96 - 2222
>     Internet:
>     https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.seeburger.de&data=02%7C01%7CAnthony.Rhuberg%40Cerner.com%7C0480b4cbfcff443e0de708d5d6e2ba56%7Cfbc493a80d244454a815f4ca58e8c09d%7C0%7C1%7C636651191659833148&sdata=XDo7F4rA%2BTro3va1SqqA9eaq8zlVomq%2BY5RLMdVGYSI%3D&reserved=0              
>     Registergericht/Commercial Register:
>     e-mail: [email protected] <mailto:[email protected]>              
>     HRB 240708 Mannheim
>
>
>     Dieses E-Mail ist nur für den Empfänger bestimmt, an den es
>     gerichtet ist und kann vertrauliches bzw. unter das
>     Berufsgeheimnis fallendes Material enthalten. Jegliche darin
>     enthaltene Ansicht oder Meinungsäußerung ist die des Autors und
>     stellt nicht notwendigerweise die Ansicht oder Meinung der
>     SEEBURGER AG dar. Sind Sie nicht der Empfänger, so haben Sie diese
>     E-Mail irrtümlich erhalten und jegliche Verwendung,
>     Veröffentlichung, Weiterleitung, Abschrift oder jeglicher Druck
>     dieser E-Mail ist strengstens untersagt. Weder die SEEBURGER AG
>     noch der Absender (Eckenfels. Bernd) übernehmen die Haftung für
>     Viren; es obliegt Ihrer Verantwortung, die E-Mail und deren
>     Anhänge auf Viren zu prüfen.
>
>
>     This email is intended only for the recipient(s) to whom it is
>     addressed. This email may contain confidential material that may
>     be protected by professional secrecy. Any fact or opinion
>     contained, or expression of the material herein, does not
>     necessarily reflect that of SEEBURGER AG. If you are not the
>     addressee or if you have received this email in error, any use,
>     publication or distribution including forwarding, copying or
>     printing is strictly prohibited. Neither SEEBURGER AG, nor the
>     sender (Eckenfels. Bernd) accept liability for viruses; it is your
>     responsibility to check this email and its attachments for viruses.
>
>
>  
>