Re: 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]>
> *Sent:* Wednesday, June 20, 2018 3:49:52 PM
> *To:* [email protected]; [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]
> 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]]
> Sent: Wednesday, June 20, 2018 20:58
> To: David Hook; Matti Aarnio; [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]>; Matti Aarnio
> <[email protected]>; [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]>;
> [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]               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.
>
>
>