Webservice error - 2 counts of InaccessibleWSDLException - due to JDK update from 112 to 121

[Patrick Goovaerts]

Hi,

After updating JKD 1.8.0 from u112 to u121, i get errors executing webservices 
which uses a certificate.

The error I get is: 
com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of 
InaccessibleWSDLException
In the example I ran the code with u152 but same prob occurs as from u121

Anyone who could help me with this?


PC - COMMAND PROMPT - JAVA 1_8_00152

C:\Data\Kantoor\WebServices\PLDA>"C:\Program Files\Java\jdk8\bin\java" -version
java version "1.8.0_152"
Java(TM) SE Runtime Environment (build 1.8.0_152-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.152-b16, mixed mode)

C:\Data\Kantoor\WebServices\PLDA>"C:\Program Files\JAVA\jdk8\bin\java" -cp 
WS-Clients.jar;Conti7.jar;Conti7Utilities.jar com.clipper.ws.clients.Plda
2018-01-23 21:39:06.559 com.clipper.ws.clients.Plda 
Plda(keyStore=C:/Data/kantoor/WebServices/PLDA/PGO_Conti71619.pfx, 
keyStoreType=pkcs12, keyStorePwd=Conti7Sp0rtlife): Creating WebService Plda 
object...
2018-01-23 21:39:06.576 com.clipper.ws.clients.Plda Create 
PldaWebwervice_Service(): Creating Service
Exception in thread "main" 
com.sun.xml.internal.ws.wsdl.parser.InaccessibleWSDLException: 2 counts of 
InaccessibleWSDLException.

java.net.SocketException: java.security.NoSuchAlgorithmException: Error 
constructing implementation (algorithm: Default, provider: SunJSSE, class: 
sun.security.ssl.SSLContextImpl$DefaultSSLContext)
java.net.SocketException: java.security.NoSuchAlgorithmException: Error 
constructing implementation (algorithm: Default, provider: SunJSSE, class: 
sun.security.ssl.SSLContextImpl$DefaultSSLContext)

at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.tryWithMex(RuntimeWSDLParser.java:260)
at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:231)
at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:194)
at 
com.sun.xml.internal.ws.wsdl.parser.RuntimeWSDLParser.parse(RuntimeWSDLParser.java:163)
at 
com.sun.xml.internal.ws.client.WSServiceDelegate.parseWSDL(WSServiceDelegate.java:348)
at 
com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:306)
at 
com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:215)
at 
com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:196)
at 
com.sun.xml.internal.ws.client.WSServiceDelegate.(WSServiceDelegate.java:192)
at 
com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:104)
at javax.xml.ws.Service.(Service.java:77)
at 
com.clipper.ws.plda.PldaWebservice_Service.(PldaWebservice_Service.java:51)
at com.clipper.ws.clients.Plda.(Plda.java:30)
at com.clipper.ws.clients.Plda.main(Plda.java:80)


Patrick Goovaerts

Re: Da Capo: JSON "clear text" signatures

[Hannes Wallnöfer]

Hi Anders,

I think I lack the context required to understand what you’re asking for. Can 
you explain how transmitting numbers/doubles in JSON should work and how the 
static method you’re asking for would enable this?

Also, is there a document somewhere describing the IETF standardization work 
you’re talking about?

Thanks,
Hannes

> Am 28.01.2018 um 10:48 schrieb Anders Rundgren 
> :
> 
> The JSON "clear text" signature initiative seems to (finally) be headed for 
> IETF standardization.  The plan is having a BOF session at the next IETF in 
> London.
> 
> This scheme builds on EcmaScript JSON processing rules for data normalization 
> which only rely on JSON.parse() and JSON.stringify().
> 
> A thorny issue for implementers is though serializing the JSON "Number" type.
> 
> An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely 
> compatible...) solution is currently available in "Nashorn":
> http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java
> 
> It would be great if such support could for example be included as a static 
> method in java.lang.Double, making Java and EcmaScript/JavaScript 100% 
> interoperable with respect to this feature, the rest is actually close to 
> trivial.
> 
> thanx,
> Anders
> https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705

Re: Da Capo: JSON "clear text" signatures

[Anders Rundgren]

On 2018-01-29 15:49, Sundararajan Athijegannathan wrote:

Just to be clear. so.. do you want a toString (static method?) variant
in java.lang.Double class as per this specification?


I don't think this is a major issue because all fundamental JSON types anyway 
needs be dealt with separately or through a super interface.
The existing Nashorn method (after upgrade to match ES better) moved to the 
Java layer would probably be just fine.

Anders



-Sundar

On 29/01/18, 7:45 PM, Anders Rundgren wrote:

On 2018-01-29 14:52, Hannes Wallnöfer wrote:

Hi Anders,

I think I lack the context required to understand what you’re asking
for. Can you explain how transmitting numbers/doubles in JSON should
work and how the static method you’re asking for would enable this?


Sure.  Signatures depend on that data appears identical on both sides
(sender + receiver).
If one side outputs the integer 10 as 10.0 (which is OK JSON-wise),
the signature will break in an EcmaScript environment where it must be
10 and nothing else.
JSON tools would call the proposed static method rather than building
their own number serializer.

Initially I thought number serialization was a simple problem but that
was entirely wrong :-)
Fortunately the ECMA folks have the expertize needed and their
solution is already supported in billions of devices.
Nashorn almost cuts it but only for JavaScript, not Java.


Also, is there a document somewhere describing the IETF
standardization work you’re talking about?


You will have to wait to next week (when it becomes public), but in
the meantime you can take a look at the core "input specifications":
https://cyberphone.github.io/doc/security/jose-jcs.html
https://cyberphone.github.io/doc/security/jose-jef.html

Thanx,
Anders



Thanks,
Hannes


Am 28.01.2018 um 10:48 schrieb Anders Rundgren
:

The JSON "clear text" signature initiative seems to (finally) be
headed for IETF standardization.  The plan is having a BOF session
at the next IETF in London.

This scheme builds on EcmaScript JSON processing rules for data
normalization which only rely on JSON.parse() and JSON.stringify().

A thorny issue for implementers is though serializing the JSON
"Number" type.

An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely
compatible...) solution is currently available in "Nashorn":
http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java


It would be great if such support could for example be included as a
static method in java.lang.Double, making Java and
EcmaScript/JavaScript 100% interoperable with respect to this
feature, the rest is actually close to trivial.

thanx,
Anders
https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705

Re: Update mechanism for the upcoming trust store

[Fotis Loukos]

On 26/01/2018 11:31 μμ, Sean Mullan wrote:
> On 1/24/18 5:39 AM, Fotis Loukos wrote:
>>> You may not be aware, but the JDK does currently support a mechanism for
>>> blacklisting certificates. The lib/security/blacklisted.certs file
>>> contains a list of the fingerprints of certificates that are explicitly
>>> distrusted. If a root was compromised and added to this file it would no
>>> longer be trusted.
>> My biggest concern is what you describe below, the dynamic update.
>>
>>> However, currently there is no mechanism in OpenJDK to dynamically
>>> update that file. While I think there is merit in implementing something
>>> like that, many challenges would need to be addressed as part of that,
>>> for example, where and how does this file get updated, how is it
>>> verified, etc.
>> The verification step can be implemented as described above. I think
>> that the update step requires some design, but I don't think it is that
>> difficult. For example, a naive algorithm such as every Monday plus a
>> random number of days/hours/minutes in order to avoid heavy traffic
>> during the update period would be good for starters. As a first step to
>> try a new format, you could even fetch it once during installation and
>> provide a means for the user to update it manually.
> 
> One thing we could potentially do initially is to provide a stable https
> URL where an updated blacklist could be downloaded, something like what
> Mozilla does for OneCRL [1]. This would be an initial step, not the
> whole solution of course, but it at least would allow someone to quickly
> update their JDK should a certificate need to be distrusted ASAP.
> 
> Let me look into that a bit.
> 
> I think implementing a dynamic solution is more challenging and would
> require more design/review, etc but feel free to provide more details on
> any additional thoughts or design sketches you might have.

I find it pretty important to ensure that the file is also signed and
not just served over https. I was wondering if the community runs a
private CA, or has access to an HSM that can be used to generate and
store a private key that will sign these files.

Regards,
Fotis

> 
> --Sean
> 
> [1]
> https://firefox.settings.services.mozilla.com/v1/buckets/blocklists/collections/certificates/records
> 
> 
> 


-- 
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fot...@ssl.com
w: https://www.ssl.com

Re: Da Capo: JSON "clear text" signatures

[Anders Rundgren]

On 2018-01-29 14:52, Hannes Wallnöfer wrote:

Hi Anders,

I think I lack the context required to understand what you’re asking for. Can 
you explain how transmitting numbers/doubles in JSON should work and how the 
static method you’re asking for would enable this?


Sure.  Signatures depend on that data appears identical on both sides (sender + 
receiver).
If one side outputs the integer 10 as 10.0 (which is OK JSON-wise), the 
signature will break in an EcmaScript environment where it must be 10 and 
nothing else.
JSON tools would call the proposed static method rather than building their own 
number serializer.

Initially I thought number serialization was a simple problem but that was 
entirely wrong :-)
Fortunately the ECMA folks have the expertize needed and their solution is 
already supported in billions of devices.
Nashorn almost cuts it but only for JavaScript, not Java.


Also, is there a document somewhere describing the IETF standardization work 
you’re talking about?


You will have to wait to next week (when it becomes public), but in the meantime you can 
take a look at the core "input specifications":
https://cyberphone.github.io/doc/security/jose-jcs.html
https://cyberphone.github.io/doc/security/jose-jef.html

Thanx,
Anders



Thanks,
Hannes


Am 28.01.2018 um 10:48 schrieb Anders Rundgren :

The JSON "clear text" signature initiative seems to (finally) be headed for 
IETF standardization.  The plan is having a BOF session at the next IETF in London.

This scheme builds on EcmaScript JSON processing rules for data normalization 
which only rely on JSON.parse() and JSON.stringify().

A thorny issue for implementers is though serializing the JSON "Number" type.

An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely compatible...) 
solution is currently available in "Nashorn":
http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java

It would be great if such support could for example be included as a static 
method in java.lang.Double, making Java and EcmaScript/JavaScript 100% 
interoperable with respect to this feature, the rest is actually close to 
trivial.

thanx,
Anders
https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705