From christoph.langer at sap.com  Fri Feb  1 12:10:32 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Fri, 1 Feb 2019 12:10:32 +0000
Subject: RFR [11u backport]: 8217579: TLS_EMPTY_RENEGOTIATION_INFO_SCSV is
 disabled after 8211883
In-Reply-To: <126f9dda-e20b-6971-4bcd-f12c26f1e8a6@oracle.com>
References: <3aacce99786c4295ae877bc3adebffe1@sap.com>
 <126f9dda-e20b-6971-4bcd-f12c26f1e8a6@oracle.com>
Message-ID: <98aa66447ded43679e3ffa60f9cfa4c6@sap.com>

Thanks Sean. Pushed with the replacement as you suggested.

> -----Original Message-----
> From: Sean Mullan <sean.mullan at oracle.com>
> Sent: Donnerstag, 31. Januar 2019 21:03
> To: Langer, Christoph <christoph.langer at sap.com>; security-
> dev at openjdk.java.net
> Subject: Re: RFR [11u backport]: 8217579:
> TLS_EMPTY_RENEGOTIATION_INFO_SCSV is disabled after 8211883
> 
> CheckCipherSuites.java
> 
> 116     // List of enabled cipher suites when the "crypto.policy" security
> 
> typo: s/enabled/supported/
> 
> (I realized that typo after I had already pushed the fix to JDK 13, but
> better to just fix it here now).
> 
> Otherwise looks good.
> 
> --Sean
> 
> On 1/31/19 8:36 AM, Langer, Christoph wrote:
> > Hi,
> >
> > please review the backport of the fix for 8217579 to jdk11u.
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8217579
> >
> > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8217579.11u/
> >
> > Original review thread:
> > https://mail.openjdk.java.net/pipermail/security-dev/2019-
> January/019256.html
> >
> > The patch did apply cleanly but I had to remove the ChaCha ciphers to
> > make the test work with JDK 11.
> >
> > Thanks and Best regards
> >
> > Christoph
> >

From weijun.wang at oracle.com  Sun Feb  3 14:44:33 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sun, 3 Feb 2019 22:44:33 +0800
Subject: RFR 8180569: Refactor sun/security/krb5/ shell tests to plain java
 tests
Message-ID: <004DCA97-218A-47A3-B1C2-BE0CAF2C5BEF@oracle.com>

Please take a review at

   https://cr.openjdk.java.net/~weijun/8180569/webrev.00

I've combined ktarg.sh, ktmissing.sh, and ktzero.sh into KtabZero.java.

rcache_usemd5.sh is renamed to ReplayCacheTestProcWithMD5.java. The test has no content and is only used to launch another test. I don't want to combine them because I want different working directory.

runNameEquals.sh is left as a shell test. It calls quite some *nix commands and is better to stay unchanged.

Thanks,
Max


From dpenick at gmail.com  Mon Feb  4 10:08:05 2019
From: dpenick at gmail.com (David Penick)
Date: Mon, 4 Feb 2019 04:08:05 -0600
Subject: Signed JCE and providers jars
Message-ID: <CAMZ5TuYYOD+aKKczJ_9bONffr-PVpZEzNzbt0qkYfci1V=FrBw@mail.gmail.com>

I?ve downloaded OpenJDK builds from AdoptOpenJDK and Azul Zulu, and I?ve
noticed that the jce.jar, sunjce_provider.jar and sunpkcs11.jar jar files
do not appear to be signed. I?m surprised they work without being signed,
but I also haven?t been able to find anyone asking how to get signed
versions of the Sun JCE.



How can I get signed versions of the Sun JCE jars, or should I not worry
about it, and if so, why not?



Thanks,

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190204/a60b5064/attachment.html>

From ecki at zusammenkunft.net  Mon Feb  4 10:37:46 2019
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Mon, 4 Feb 2019 10:37:46 +0000
Subject: Signed JCE and providers jars
In-Reply-To: <CAMZ5TuYYOD+aKKczJ_9bONffr-PVpZEzNzbt0qkYfci1V=FrBw@mail.gmail.com>
References: <CAMZ5TuYYOD+aKKczJ_9bONffr-PVpZEzNzbt0qkYfci1V=FrBw@mail.gmail.com>
Message-ID: <DB7PR08MB3307D25A412EA2CFA9EF9D67FF6D0@DB7PR08MB3307.eurprd08.prod.outlook.com>

The OpenJDK JCA does not do provider signature checking. So you can install your own providers and don?t need to sign them.

Gruss
Bernd
--
http://bernd.eckenfels.net

________________________________
Von: security-dev <security-dev-bounces at openjdk.java.net> im Auftrag von David Penick <dpenick at gmail.com>
Gesendet: Montag, Februar 4, 2019 11:18 AM
An: security-dev at openjdk.java.net
Betreff: Signed JCE and providers jars

I?ve downloaded OpenJDK builds from AdoptOpenJDK and Azul Zulu, and I?ve noticed that the jce.jar, sunjce_provider.jar and sunpkcs11.jar jar files do not appear to be signed. I?m surprised they work without being signed, but I also haven?t been able to find anyone asking how to get signed versions of the Sun JCE.

How can I get signed versions of the Sun JCE jars, or should I not worry about it, and if so, why not?

Thanks,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190204/e8d0efa3/attachment.html>

From bradford.wetmore at oracle.com  Mon Feb  4 22:08:56 2019
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 4 Feb 2019 14:08:56 -0800
Subject: Signed JCE and providers jars
In-Reply-To: <CAMZ5TuYYOD+aKKczJ_9bONffr-PVpZEzNzbt0qkYfci1V=FrBw@mail.gmail.com>
References: <CAMZ5TuYYOD+aKKczJ_9bONffr-PVpZEzNzbt0qkYfci1V=FrBw@mail.gmail.com>
Message-ID: <c30003d7-ac62-1403-abfc-b0827f1ba22f@oracle.com>

Hi David,

On 2/4/2019 2:08 AM, David Penick wrote:
> I?ve downloaded OpenJDK builds from AdoptOpenJDK and Azul Zulu, and I?ve 
> noticed that the jce.jar, sunjce_provider.jar and sunpkcs11.jar jar 
> files do not appear to be signed. I?m surprised they work without being 
> signed, but I also haven?t been able to find anyone asking how to get 
> signed versions of the Sun JCE.
> 
> How can I get signed versions of the Sun JCE jars, or should I not worry 
> about it, and if so, why not?

In Oracle's JDK 8 and earlier releases, the same rules still apply in 
that the Oracle Framework and Providers (previously called the "Sun 
Framework and Providers" in 
jce.jar/sunjce_provider.jar/sunpkcs11.jar/sunmscapi.jar/etc.) must be 
signed and properly verify.  This signing requirement also applies to 
3rd Party Provider jar files.

In Oracle's JDK 9+ releases, the Oracle Framework/Providers are now 
implemented as modules (java.base/jdk.crypto.cryptoki/etc.) rather than 
jar files, and are not signed.

3rd Party Providers must still be signed in order to be used in the 
commercial Oracle JDK product.

3rd Party providers do not need to be signed for use with the Oracle 
OpenJDK builds, which is not a commercial product.

It is up to other OpenJDK-based implementations 
(AdoptOpenJDK/Azul/IBM/etc.) to determine whether 3rd Party providers 
must be signed, and make the appropriate modifications to the code.

Brad




From sean.mullan at oracle.com  Tue Feb  5 15:21:20 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 5 Feb 2019 10:21:20 -0500
Subject: CSR Review Request, JDK-8217835, Remove the experimental SunJSSE
 FIPS compliant mode.
In-Reply-To: <69e31dc5-647f-a19f-f9de-ae51f8110a60@oracle.com>
References: <69e31dc5-647f-a19f-f9de-ae51f8110a60@oracle.com>
Message-ID: <07801ca5-9768-8630-f091-e3ba6f30feab@oracle.com>

Looks good -- I added my name as Reviewer.

--Sean

On 1/28/19 1:46 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the CSR reviewed:
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8217907
> 
> and here is the proposed release note:
>  ?? https://bugs.openjdk.java.net/browse/JDK-8217911
> 
> If you are using this experimental feature, please let me know the 
> compatibility impact by the end of Jan 31, 2019.
> 
> Thanks,
> Xuelei

From david at penick.net  Tue Feb  5 17:41:27 2019
From: david at penick.net (David Penick)
Date: Tue, 5 Feb 2019 11:41:27 -0600
Subject: Signed JCE and providers jars
In-Reply-To: <c30003d7-ac62-1403-abfc-b0827f1ba22f@oracle.com>
References: <CAMZ5TuYYOD+aKKczJ_9bONffr-PVpZEzNzbt0qkYfci1V=FrBw@mail.gmail.com>
 <c30003d7-ac62-1403-abfc-b0827f1ba22f@oracle.com>
Message-ID: <6AB70F40-25DE-4DDB-80A8-3CE3F95E51C8@penick.net>

Thanks Brad and Bernd!

David 

> On Feb 4, 2019, at 4:08 PM, Bradford Wetmore <bradford.wetmore at oracle.com> wrote:
> 
> Hi David,
> 
>> On 2/4/2019 2:08 AM, David Penick wrote:
>> I?ve downloaded OpenJDK builds from AdoptOpenJDK and Azul Zulu, and I?ve noticed that the jce.jar, sunjce_provider.jar and sunpkcs11.jar jar files do not appear to be signed. I?m surprised they work without being signed, but I also haven?t been able to find anyone asking how to get signed versions of the Sun JCE.
>> How can I get signed versions of the Sun JCE jars, or should I not worry about it, and if so, why not?
> 
> In Oracle's JDK 8 and earlier releases, the same rules still apply in that the Oracle Framework and Providers (previously called the "Sun Framework and Providers" in jce.jar/sunjce_provider.jar/sunpkcs11.jar/sunmscapi.jar/etc.) must be signed and properly verify.  This signing requirement also applies to 3rd Party Provider jar files.
> 
> In Oracle's JDK 9+ releases, the Oracle Framework/Providers are now implemented as modules (java.base/jdk.crypto.cryptoki/etc.) rather than jar files, and are not signed.
> 
> 3rd Party Providers must still be signed in order to be used in the commercial Oracle JDK product.
> 
> 3rd Party providers do not need to be signed for use with the Oracle OpenJDK builds, which is not a commercial product.
> 
> It is up to other OpenJDK-based implementations (AdoptOpenJDK/Azul/IBM/etc.) to determine whether 3rd Party providers must be signed, and make the appropriate modifications to the code.
> 
> Brad
> 
> 
> 

From xuelei.fan at oracle.com  Tue Feb  5 18:44:02 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 5 Feb 2019 10:44:02 -0800
Subject: Code Review Request, JDK-8217835, Remove the experimental SunJSSE
 FIPS compliant mode
Message-ID: <2b0668ee-cf1f-707a-e5ae-42afffaa755a@oracle.com>

Hi,

Could I have the update reviewed?
    http://cr.openjdk.java.net/~xuelei/8217835/webrev.00/

With this update, the experimental FIPS 140 compliant mode is removed 
from the SunJSSE provider. As the SunJSSE provider uses the JDK default 
cryptography providers, alternatively applications can configure the 
Java Security Property to use FIPS 140 compliant cryptography providers.

More details,  please refer to CSR:
    https://bugs.openjdk.java.net/browse/JDK-8217907

Thanks & Regards,
Xuelei

From anthony.scarpino at oracle.com  Tue Feb  5 23:52:02 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 5 Feb 2019 15:52:02 -0800
Subject: RFR[s]: 8201633 Problems with AES-GCM native acceleration
Message-ID: <4e76b39c-8a6f-bf2b-7d14-177e68fe4aee@oracle.com>


I need a review of this change which is to help the AES/GCM intrinsic 
activate on large data sizes.  It's not the ideal resolution, which 
splits up the crypto operation in chucks, but I significantly improves 
performance for larger data sizes.  Additionally there is an 
optimization to not allocated and use an unnecessary buffer in the 
init()-doFinal() case  that helped performance with large data sizes. 
The final result was a 1MB file is encrypted at 2GB/sec vs 250MB/sec.

This change is not meant to fix all possible performance bottlenecks.

http://cr.openjdk.java.net/~ascarpino/8201633/webrev/

Tony

From sean.coffey at oracle.com  Wed Feb  6 15:32:59 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Wed, 6 Feb 2019 15:32:59 +0000
Subject: RFR: 8218553: Enhance keystore load debug output
Message-ID: <1c3883ef-07eb-3922-a3e4-d8cf2bba43b4@oracle.com>

Looking to improve debug output in the keystore area.

It's useful to know how many keys/certs are found in such stores
to ensure correct set up.

https://bugs.openjdk.java.net/browse/JDK-8218553
http://cr.openjdk.java.net/~coffeys/webrev.8218553/webrev/

-- 
Regards,
Sean.


From weijun.wang at oracle.com  Wed Feb  6 16:24:15 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 7 Feb 2019 00:24:15 +0800
Subject: RFR: 8218553: Enhance keystore load debug output
In-Reply-To: <1c3883ef-07eb-3922-a3e4-d8cf2bba43b4@oracle.com>
References: <1c3883ef-07eb-3922-a3e4-d8cf2bba43b4@oracle.com>
Message-ID: <410ACC87-76B1-477C-B98F-D2F3153D21E2@oracle.com>

Hi S?an,

Change looks fine.

I usually think there is no need to provide data in the debug output that were already available from public APIs (i.e. they are not something that can only be revealed from "internally"), but these numbers could help a supporter engineer to quickly find out if there is some really simple error in a customer's environment. So, good to have them.

And I definitely believe you know better that I what a support engineer needs.

Thanks,
Max

> On Feb 6, 2019, at 11:32 PM, Se?n Coffey <sean.coffey at oracle.com> wrote:
> 
> Looking to improve debug output in the keystore area.
> 
> It's useful to know how many keys/certs are found in such stores
> to ensure correct set up.
> 
> https://bugs.openjdk.java.net/browse/JDK-8218553
> http://cr.openjdk.java.net/~coffeys/webrev.8218553/webrev/
> 
> -- 
> Regards,
> Sean.
> 


From adam.petcher at oracle.com  Wed Feb  6 20:23:12 2019
From: adam.petcher at oracle.com (Adam Petcher)
Date: Wed, 6 Feb 2019 15:23:12 -0500
Subject: RFR[s]: 8201633 Problems with AES-GCM native acceleration
In-Reply-To: <4e76b39c-8a6f-bf2b-7d14-177e68fe4aee@oracle.com>
References: <4e76b39c-8a6f-bf2b-7d14-177e68fe4aee@oracle.com>
Message-ID: <87eb4cee-e568-83b9-7b73-5a91c5a1d6d3@oracle.com>

I'm still not sold on this---it seems like a specific solution to a 
single instance of a more general problem.

Have you investigated any tweaks to the JVM or compiler settings? Andrew 
prototyped something[1], but it looks like this is also specific to GCM. 
A more general solution would be some way to tell the JVM that some 
method should always be compiled. I think this is the exact problem that 
motivated per-method compile thresholds[2], though it's not clear if the 
current implementation of that feature helps us here.

[1] http://cr.openjdk.java.net/~aph/gctr/
[2] https://bugs.openjdk.java.net/browse/JDK-8059606

On 2/5/2019 6:52 PM, Anthony Scarpino wrote:
>
> I need a review of this change which is to help the AES/GCM intrinsic 
> activate on large data sizes.? It's not the ideal resolution, which 
> splits up the crypto operation in chucks, but I significantly improves 
> performance for larger data sizes. Additionally there is an 
> optimization to not allocated and use an unnecessary buffer in the 
> init()-doFinal() case? that helped performance with large data sizes. 
> The final result was a 1MB file is encrypted at 2GB/sec vs 250MB/sec.
>
> This change is not meant to fix all possible performance bottlenecks.
>
> http://cr.openjdk.java.net/~ascarpino/8201633/webrev/
>
> Tony

From anthony.scarpino at oracle.com  Wed Feb  6 21:18:34 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 6 Feb 2019 13:18:34 -0800
Subject: RFR[s]: 8201633 Problems with AES-GCM native acceleration
In-Reply-To: <87eb4cee-e568-83b9-7b73-5a91c5a1d6d3@oracle.com>
References: <4e76b39c-8a6f-bf2b-7d14-177e68fe4aee@oracle.com>
 <87eb4cee-e568-83b9-7b73-5a91c5a1d6d3@oracle.com>
Message-ID: <00aa73c6-36f3-898e-1b50-b3d39fcb0330@oracle.com>

Andrew's fix looked much more complicated than running a simple loop in 
the byte code.  The way I read CompileCommand, I don't think it applies 
to intrinsics, or at least I don't see how it relates to make this easier.

The slow start seems to be getting enough attention that addressing it 
is probably easier than arguing why it's not a problem.

Tony


On 2/6/19 12:23 PM, Adam Petcher wrote:
> I'm still not sold on this---it seems like a specific solution to a 
> single instance of a more general problem.
> 
> Have you investigated any tweaks to the JVM or compiler settings? Andrew 
> prototyped something[1], but it looks like this is also specific to GCM. 
> A more general solution would be some way to tell the JVM that some 
> method should always be compiled. I think this is the exact problem that 
> motivated per-method compile thresholds[2], though it's not clear if the 
> current implementation of that feature helps us here.
> 
> [1] http://cr.openjdk.java.net/~aph/gctr/
> [2] https://bugs.openjdk.java.net/browse/JDK-8059606
> 
> On 2/5/2019 6:52 PM, Anthony Scarpino wrote:
>>
>> I need a review of this change which is to help the AES/GCM intrinsic 
>> activate on large data sizes.? It's not the ideal resolution, which 
>> splits up the crypto operation in chucks, but I significantly improves 
>> performance for larger data sizes. Additionally there is an 
>> optimization to not allocated and use an unnecessary buffer in the 
>> init()-doFinal() case? that helped performance with large data sizes. 
>> The final result was a 1MB file is encrypted at 2GB/sec vs 250MB/sec.
>>
>> This change is not meant to fix all possible performance bottlenecks.
>>
>> http://cr.openjdk.java.net/~ascarpino/8201633/webrev/
>>
>> Tony


From valerie.peng at oracle.com  Wed Feb  6 22:19:52 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 6 Feb 2019 14:19:52 -0800
Subject: RFR[s]: 8201633 Problems with AES-GCM native acceleration
In-Reply-To: <4e76b39c-8a6f-bf2b-7d14-177e68fe4aee@oracle.com>
References: <4e76b39c-8a6f-bf2b-7d14-177e68fe4aee@oracle.com>
Message-ID: <25683c00-382a-ef5d-87ca-d7f857aeda20@oracle.com>

Hi Tony,

Changes look fine, just some nits.

- line 402, 96 bit should be 96-byte?

- line 408, can we not use "l"?? It looks too similar to "1"

- As for the comments on line 586, 587, It seems to be for the "else" 
part of this if-condition. So I find it a bit confusing. Maybe simplify 
it to something like "copy input data into ibuffer when there are 
buffered bytes or when input buffer is same as output buffer". Or, use 
what you have and add ", otherwise, copy input data into ibuffer".

You'll probably need to add noreg-perf label.

Thanks,

Valerie

On 2/5/2019 3:52 PM, Anthony Scarpino wrote:
>
> I need a review of this change which is to help the AES/GCM intrinsic 
> activate on large data sizes.? It's not the ideal resolution, which 
> splits up the crypto operation in chucks, but I significantly improves 
> performance for larger data sizes. Additionally there is an 
> optimization to not allocated and use an unnecessary buffer in the 
> init()-doFinal() case? that helped performance with large data sizes. 
> The final result was a 1MB file is encrypted at 2GB/sec vs 250MB/sec.
>
> This change is not meant to fix all possible performance bottlenecks.
>
> http://cr.openjdk.java.net/~ascarpino/8201633/webrev/
>
> Tony

From anthony.scarpino at oracle.com  Wed Feb  6 23:22:10 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 6 Feb 2019 15:22:10 -0800
Subject: RFR[s]: 8201633 Problems with AES-GCM native acceleration
In-Reply-To: <25683c00-382a-ef5d-87ca-d7f857aeda20@oracle.com>
References: <4e76b39c-8a6f-bf2b-7d14-177e68fe4aee@oracle.com>
 <25683c00-382a-ef5d-87ca-d7f857aeda20@oracle.com>
Message-ID: <dc106b64-fa6c-3953-2081-e9309f9ed4a7@oracle.com>

Agreed..  webrev updated.. I inadvertently updated in-place.

Tony

On 2/6/19 2:19 PM, Valerie Peng wrote:
> Hi Tony,
> 
> Changes look fine, just some nits.
> 
> - line 402, 96 bit should be 96-byte?
> 
> - line 408, can we not use "l"?? It looks too similar to "1"
> 
> - As for the comments on line 586, 587, It seems to be for the "else" 
> part of this if-condition. So I find it a bit confusing. Maybe simplify 
> it to something like "copy input data into ibuffer when there are 
> buffered bytes or when input buffer is same as output buffer". Or, use 
> what you have and add ", otherwise, copy input data into ibuffer".
> 
> You'll probably need to add noreg-perf label.
> 
> Thanks,
> 
> Valerie
> 
> On 2/5/2019 3:52 PM, Anthony Scarpino wrote:
>>
>> I need a review of this change which is to help the AES/GCM intrinsic 
>> activate on large data sizes.? It's not the ideal resolution, which 
>> splits up the crypto operation in chucks, but I significantly improves 
>> performance for larger data sizes. Additionally there is an 
>> optimization to not allocated and use an unnecessary buffer in the 
>> init()-doFinal() case? that helped performance with large data sizes. 
>> The final result was a 1MB file is encrypted at 2GB/sec vs 250MB/sec.
>>
>> This change is not meant to fix all possible performance bottlenecks.
>>
>> http://cr.openjdk.java.net/~ascarpino/8201633/webrev/
>>
>> Tony


From sean.coffey at oracle.com  Thu Feb  7 12:05:42 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 7 Feb 2019 12:05:42 +0000
Subject: RFR: 8218553: Enhance keystore load debug output
In-Reply-To: <410ACC87-76B1-477C-B98F-D2F3153D21E2@oracle.com>
References: <1c3883ef-07eb-3922-a3e4-d8cf2bba43b4@oracle.com>
 <410ACC87-76B1-477C-B98F-D2F3153D21E2@oracle.com>
Message-ID: <7c65eae1-dd95-03f2-680c-3da3a32bd4b7@oracle.com>


On 06/02/2019 16:24, Weijun Wang wrote:
> Hi S?an,
>
> Change looks fine.
>
> I usually think there is no need to provide data in the debug output that were already available from public APIs (i.e. they are not something that can only be revealed from "internally"), but these numbers could help a supporter engineer to quickly find out if there is some really simple error in a customer's environment. So, good to have them.
>
> And I definitely believe you know better that I what a support engineer needs.

Thanks for review. Yes - use of APIs to retrieve such data is not an 
option when someone is trying to debug a live production issue. I think 
this will help admins to confirm if keystore configuration looks correct 
in such environments.

regards,
Sean.

>
> Thanks,
> Max
>
>> On Feb 6, 2019, at 11:32 PM, Se?n Coffey <sean.coffey at oracle.com> wrote:
>>
>> Looking to improve debug output in the keystore area.
>>
>> It's useful to know how many keys/certs are found in such stores
>> to ensure correct set up.
>>
>> https://bugs.openjdk.java.net/browse/JDK-8218553
>> http://cr.openjdk.java.net/~coffeys/webrev.8218553/webrev/
>>
>> -- 
>> Regards,
>> Sean.
>>

From sean.mullan at oracle.com  Thu Feb  7 15:49:25 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 7 Feb 2019 10:49:25 -0500
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
Message-ID: <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>

On 2/6/19 4:51 PM, Open eSignForms wrote:
> I have a test version of the code that can run standalone and shows the 
> bug.? I'm not sure how best to transfer this information to the forum 
> for those to play with, but it is included below.

Thanks, I can reproduce the issue now. I will need to debug further to 
see what might be causing this.

--Sean

From yozons at gmail.com  Wed Feb  6 21:51:04 2019
From: yozons at gmail.com (Open eSignForms)
Date: Wed, 6 Feb 2019 13:51:04 -0800
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
Message-ID: <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>

I have a test version of the code that can run standalone and shows the 
bug.? I'm not sure how best to transfer this information to the forum 
for those to play with, but it is included below.

Note that we use the BouncyCastle BC used in our code, but if you don't 
have or want to use the BC provider JAR, it will fallback to the 
SunRsaSign provider that appears to be bundled with JDKs.

I get the same results with BC and SunRsaSign providers.? It's just the 
Java version that causes the issue.

In testing with or without the BC provider, the Java 8, 9 and 10 
versions run and produces the signed XML, while the Java 11 fails.

java version "10.0.2" 2018-07-17
Java(TM) SE Runtime Environment 18.3 (build 10.0.2+13)
Java HotSpot(TM) 64-Bit Server VM 18.3 (build 10.0.2+13, mixed mode)

openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

The Java 11 exception:

XmlDigitalSignature.main() exception: NAMESPACE_ERR: An attempt is made 
to create or change an object in a way which is incorrect with regard to 
namespaces.
org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create or 
change an object in a way which is incorrect with regard to namespaces.
 ??? at 
java.xml/com.sun.org.apache.xerces.internal.dom.ElementNSImpl.setName(ElementNSImpl.java:109)
 ??? at 
java.xml/com.sun.org.apache.xerces.internal.dom.ElementNSImpl.<init>(ElementNSImpl.java:84)
 ??? at 
java.xml/com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.createElementNS(CoreDocumentImpl.java:2089)
 ??? at 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.XmlWriterToTree.writeStartElement(XmlWriterToTree.java:99)
 ??? at 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller.marshalGenericNode(Marshaller.java:303)
 ??? at 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller.marshalGenericNode(Marshaller.java:286)
 ??? at 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller$14.marshalObject(Marshaller.java:251)
 ??? at 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller$14.marshalObject(Marshaller.java:247)
 ??? at 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.XmlWriterToTree.marshalStructure(XmlWriterToTree.java:200)
 ??? at 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLObject.marshal(DOMXMLObject.java:180)
 ??? at 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.marshal(DOMXMLSignature.java:233)
 ??? at 
java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:325)
 ??? at 
com.esignforms.open.xmldsigbug.XmlDigitalSignature.sign(XmlDigitalSignature.java:212)
 ??? at 
com.esignforms.open.xmldsigbug.XmlDigitalSignature.main(XmlDigitalSignature.java:732)

Under Java 10, the signed XML:

<snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
timestamp="2019-02-06T13:29:02-08:00" type="document"><![CDATA[<html 
xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
document</p></body></html>]]><Signature 
xmlns="http://www.w3.org/2000/09/xmldsig#" 
Id="OpenESignForms_Seal"><SignedInfo><CanonicalizationMethod 
Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><SignatureMethod 
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><Reference 
Id="Payload_Reference_ID" URI=""><Transforms><Transform 
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></Transforms><DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><DigestValue>xbX6EvkJBIDySHYJizqf4rNkEi5eQRyWfpD5TX1xaSI7pez0isMTFwho7/F+fJioI2eHEBPpujhn
wvIlHvvCOg==</DigestValue></Reference><Reference 
URI="#KeyInfo_ID"><DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><DigestValue>D6WsZi/HzkmfZCT3tg7rvoo8S3mkNx5WkEp71OiOJ+JVYG+UAF6aVadY55Jt/tR3BF/wDntWOraK
gmAXZ2ifHQ==</DigestValue></Reference><Reference 
URI="#QualifyingProperties_ID"><DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><DigestValue>1tOD+n70iPIcUM0gylw5Wu4LpFQUyEi0L+aq0Z5RgdvO4xsoypumooQRPWWxn/esiisbbRSEbCxs
11jaahDUGQ==</DigestValue></Reference><Reference 
URI="#OpenESignForms_Seal_ID"><DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><DigestValue>A9REglXLHIr8M5xFHIR8o93pNKMiCoOQTW/58WOXLnQ/8Gaw4txOTwIsnclKxG+5bkQ76/KR/It+
/ljnjdlmFw==</DigestValue></Reference></SignedInfo><SignatureValue>FxFXp98EIK2+NoHlwE6ewE9En+X02tz0Fb4IBlHKLh/aRYbGQn8ceexq27nbfA3wKXYgLM5aG9Mv
n+nvkLQfP+U0jXtW6En0hGnbmCa2sBevEB0l31HItXW6+KocAJBio8FT1Sps0mAn7eAAfKbuVyTu
Xy+SOcJZWrTzSkI7V323+TwRv4i6NbIpVJsH/Cj7AfuqWocWenPAmBNDfzmgjohnL8vN1OFNPdXz
RN6rkVbPl+yvjhUtX2XgGkHiMvYmrd64XGGfGv80Iu052+CUoe5ZHEIe1M26hK995ffotVzPbHov
2O2cCIXJI1xWIHpS926KTvtpMVHEiWtDqGbh2mKmG7zD2AHEJY2d/u34pOauLkeU5Yk87BK0Dt9Q
jiDxJy28wMbO0eyoiMfWwf5VWeiyzbPkDGzCqUvQEbXmGuvkhxRuztE7cELF2dWdvx/8rRjc7Imh
OJ4pwgaxHS4Ek5C8mP6MCPfdiztCO4z08iKbnXOBaG1oe1+SyvecksLy2vF8UxQwPfV6LVU7cxhy
C51R3nXZcsgNNTvxLyO8npKKlLtJj4O1D3cfhgKUWNZCKg9HCh1J6VKyEg3KFXWN//vD8QPSDhmx
BPKLq+QZQw8SW4bMTrI5xIgY5FYiwMex5lyezGcjFzWAp64m8lehpW889wi2A18j6ccQ2K8+PN4=</SignatureValue><KeyInfo 
Id="KeyInfo_ID"><KeyName>5c585e1f-634a-4ddb-bbe0-9b110e38d3a6</KeyName><KeyValue><RSAKeyValue><Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9
Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW
I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU
MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX
oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ
Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB
snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z
Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n
C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue></KeyValue><X509Data><X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu
X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z
VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2
NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh
YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz
Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh
bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw
ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ
RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi
MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A
5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6
drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/
pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn
bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy
JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW
Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR
onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz
GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj
K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC
JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc
2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI
8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl
kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o
97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY
LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N
SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E
aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg
Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV
Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC
AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q
3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX
SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D
pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+
aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx
GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P
TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf
hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z
IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0
FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN
BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk
zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw
LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz
syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO
KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK
GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u
FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/
aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX
3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy
VMfem/JPPYT/veThnefIgQk=</X509Certificate></X509Data></KeyInfo><Object><QualifyingProperties 
Id="QualifyingProperties_ID"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-06T13:29:03-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></Object><Object><SignatureProperties><SignatureProperty 
Id="OpenESignForms_Seal_ID" 
Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
DeploymentHostAddress="192.1.1.1" 
DeploymentHostName="open.esignforms.com" DeploymentId="1.1.1.1" 
SignerAddress="192.1.1.1" SignerAgent="No-Browser-Test" 
Timestamp="2019-02-06T13:29:03-08:00" 
Version="19.1.19"/></SignatureProperty></SignatureProperties></Object></Signature></snapshot>

XML Digital Signature code used:

// Copyright (C) 2011-2019 Yozons, Inc.

// Open eSignForms - Web-based electronic contracting software

//

// This program is free software: you can redistribute it and/or modify 
it under the terms of the GNU Affero General Public License

// as published by the Free Software Foundation, either version 3 of the 
License, or (at your option) any later version.

//

// This program is distributed in the hope that it will be useful, but 
WITHOUT ANY WARRANTY;

// without even the implied warranty of MERCHANTABILITY or FITNESS FOR A 
PARTICULAR PURPOSE.

// See the GNU Affero General Public License for more details.

//

// You should have received a copy of the GNU Affero General Public 
License along with this program.

// If not, see <http://open.esignforms.com/agpl.txt> or 
<http://www.gnu.org/licenses/>.

// Contact information is via the public forums 
athttp://open.esignforms.com <http://open.esignforms.com/>or via private 
email toopen-esign at yozons.com <mailto:open-esign at yozons.com>.

//

*package*com.esignforms.open.xmldsigbug;

*import*java.io.BufferedInputStream;

*import*java.io.ByteArrayInputStream;

*import*java.io.StringWriter;

*import*java.io.Writer;

*import*java.nio.charset.StandardCharsets;

*import*java.security.Key;

*import*java.security.KeyException;

*import*java.security.KeyFactory;

*import*java.security.KeyPair;

*import*java.security.NoSuchProviderException;

*import*java.security.PrivateKey;

*import*java.security.PublicKey;

*import*java.security.cert.Certificate;

*import*java.security.cert.CertificateFactory;

*import*java.security.cert.X509Certificate;

*import*java.security.spec.PKCS8EncodedKeySpec;

*import*java.security.spec.X509EncodedKeySpec;

*import*java.time.ZonedDateTime;

*import*java.time.format.DateTimeFormatter;

*import*java.util.Collections;

*import*java.util.Iterator;

*import*java.util.LinkedList;

*import*java.util.List;

*import*java.util.UUID;

*import*javax.xml.crypto.AlgorithmMethod;

*import*javax.xml.crypto.KeySelector;

*import*javax.xml.crypto.KeySelectorException;

*import*javax.xml.crypto.KeySelectorResult;

*import*javax.xml.crypto.XMLCryptoContext;

*import*javax.xml.crypto.XMLStructure;

*import*javax.xml.crypto.dom.DOMStructure;

*import*javax.xml.crypto.dsig.DigestMethod;

*import*javax.xml.crypto.dsig.Reference;

*import*javax.xml.crypto.dsig.SignatureMethod;

*import*javax.xml.crypto.dsig.SignatureProperties;

*import*javax.xml.crypto.dsig.SignatureProperty;

*import*javax.xml.crypto.dsig.SignedInfo;

*import*javax.xml.crypto.dsig.Transform;

*import*javax.xml.crypto.dsig.XMLObject;

*import*javax.xml.crypto.dsig.XMLSignature;

*import*javax.xml.crypto.dsig.XMLSignatureFactory;

*import*javax.xml.crypto.dsig.dom.DOMSignContext;

*import*javax.xml.crypto.dsig.dom.DOMValidateContext;

*import*javax.xml.crypto.dsig.keyinfo.KeyInfo;

*import*javax.xml.crypto.dsig.keyinfo.KeyInfoFactory;

*import*javax.xml.crypto.dsig.keyinfo.KeyName;

*import*javax.xml.crypto.dsig.keyinfo.KeyValue;

*import*javax.xml.crypto.dsig.keyinfo.X509Data;

*import*javax.xml.crypto.dsig.spec.C14NMethodParameterSpec;

*import*javax.xml.crypto.dsig.spec.TransformParameterSpec;

*import*javax.xml.parsers.DocumentBuilderFactory;

*import*javax.xml.transform.OutputKeys;

*import*javax.xml.transform.Transformer;

*import*javax.xml.transform.TransformerFactory;

*import*javax.xml.transform.dom.DOMSource;

*import*javax.xml.transform.stream.StreamResult;

*import*org.w3c.dom.Document;

*import*org.w3c.dom.Element;

*import*org.w3c.dom.NodeList;

/**

* This code is adapted from the Open eSignForms source file 
com.esignforms.open.crypto.XmlDigitalSignature, with all platform hooks 
removed.

*

* XmlDigitalSignature provides our interface to XML Digital Signatures.

*

* Much of the code understanding came from Oracle's technotes:

*http://download.oracle.com/javase/6/docs/technotes/guides/security/xmldsig/XMLDigitalSignature.html

*

**@author*Yozons, Inc.

*/

*public**final**class*XmlDigitalSignature {

// These literals are supported as of Java 7, but are not defined in the 
API yet...

*private**static**final*String*/SignatureMethod_RSA_SHA512/*="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512";

*private**static**final*String*/CanonicalizationMethod_INCLUSIVE_C14N11_WITH_COMMENTS/*="http://www.w3.org/2006/12/xml-c14n11#WithComments";

*private*XMLSignatureFactoryxmlSignatureFactory;

*public*XmlDigitalSignature() {

xmlSignatureFactory= XMLSignatureFactory./getInstance/("DOM");

 ? }

*public*String sign(StringxmlToSign, Stringdescription, 
StringcontentType, SignatureKeysignatureKey)*throws*Exception {

*return*sign(xmlToSign,description,contentType,signatureKey,*null*,*null*);

 ? }

*public*String sign(StringxmlToSign, Stringdescription, 
StringcontentType, SignatureKeysignatureKey, StringsignerIpHost, 
StringsignerUserAgent)*throws*Exception {

*if*(/isBlank/(xmlToSign))

*throw**new*Exception("Missing XML string to be signed.");

*if*(signatureKey==*null*)

*throw**new*Exception("Missing the signature key needed to sign.");

*try*{

// Our KeyInfo section will have a KeyName that is our signature key's 
id, as well as the public key itself,

// and our self-sign X.509 certificate.

KeyInfoFactorykeyInfoFactory=xmlSignatureFactory.getKeyInfoFactory();

List<XMLStructure>keyInfoList=*new*LinkedList<XMLStructure>();

 ? KeyNamekeyName=keyInfoFactory.newKeyName(signatureKey.id.toString());

keyInfoList.add(keyName);

 ? 
KeyValuekeyValue=keyInfoFactory.newKeyValue(signatureKey.keyPair.getPublic());

keyInfoList.add(keyValue);

 ? 
X509DatakeyX409Data=keyInfoFactory.newX509Data(Collections./singletonList/(signatureKey.cert));

keyInfoList.add(keyX409Data);

 ? KeyInfokeyInfo=keyInfoFactory.newKeyInfo(keyInfoList,"KeyInfo_ID");

// Instantiate the document to be signed

DocumentBuilderFactorydbf= DocumentBuilderFactory./newInstance/();

dbf.setNamespaceAware(*true*);

 ? 
Documentdocument=dbf.newDocumentBuilder().parse(*new*BufferedInputStream(*new*ByteArrayInputStream(/stringToBytes/(xmlToSign))));

// Create a DOMSignContext and specify the RSA PrivateKey and

// location of the resulting XMLSignature's parent element.

DOMSignContextdomSignContext=*new*DOMSignContext(signatureKey.keyPair.getPrivate(),document.getDocumentElement());

// Add in the EU Directive 
extras:http://uri.etsi.org/01903/v1.4.1/ts_101903v010401p.pdf

 ? StringsigningTime=/toXmlWithTz/(ZonedDateTime./now/());

 ? 
ElementqualifyingPropertiesElement=document.createElement("QualifyingProperties");

qualifyingPropertiesElement.setAttribute("Id","QualifyingProperties_ID");

qualifyingPropertiesElement.setIdAttribute("Id",*true*);// mark our id 
as the "Id" attribute

 ? 
ElementsignedPropertiesElement=document.createElement("SignedProperties");

 ? 
ElementsignedSignaturePropertiesElement=document.createElement("SignedSignatureProperties");

 ? ElementsigningTimeElement=document.createElement("SigningTime");

signingTimeElement.setTextContent(signingTime);

 ? 
ElementsignedDataObjectPropertiesElement=document.createElement("SignedDataObjectProperties");

 ? 
ElementdataObjectFormatElement=document.createElement("DataObjectFormat");

dataObjectFormatElement.setAttribute("ObjectReference","#Payload_Reference_ID");

 ? 
ElementdataObjectDescriptionElement=document.createElement("Description");

dataObjectDescriptionElement.setTextContent(/toEscapedXml/(description));

dataObjectFormatElement.appendChild(dataObjectDescriptionElement);

 ? ElementdataObjectMimeTypeElement=document.createElement("MimeType");

dataObjectMimeTypeElement.setTextContent(/toEscapedXml/(contentType));

dataObjectFormatElement.appendChild(dataObjectMimeTypeElement);

qualifyingPropertiesElement.appendChild(signedPropertiesElement);

signedPropertiesElement.appendChild(signedSignaturePropertiesElement);

signedPropertiesElement.appendChild(signedDataObjectPropertiesElement);

signedSignaturePropertiesElement.appendChild(signingTimeElement);

signedDataObjectPropertiesElement.appendChild(dataObjectFormatElement);

 ? 
DOMStructurequalifyingPropertiesObject=*new*DOMStructure(qualifyingPropertiesElement);

XMLObjectqualifyingPropertiesXMLObject=xmlSignatureFactory.newXMLObject(Collections./singletonList/(qualifyingPropertiesObject),*null*,*null*,*null*);

// Our signature includes the deployment id, and the current timestamp

 ? 
ElementesignformsElement=document.createElement("OpenESignForms_XmlDigitalSignatureSeal");

esignformsElement.setAttribute("Version",/toEscapedXml/("19.1.19"));

esignformsElement.setAttribute("Timestamp",signingTime);

esignformsElement.setAttribute("DeploymentId","1.1.1.1");

esignformsElement.setAttribute("DeploymentHostName","open.esignforms.com");

esignformsElement.setAttribute("DeploymentHostAddress","192.1.1.1");

*if*(!/isBlank/(signerIpHost))

esignformsElement.setAttribute("SignerAddress",/toEscapedXml/(signerIpHost));

*if*(!/isBlank/(signerUserAgent))

esignformsElement.setAttribute("SignerAgent",/toEscapedXml/(signerUserAgent));

DOMStructuresignatureObject=*new*DOMStructure(esignformsElement);

SignaturePropertysignatureProperty=xmlSignatureFactory.newSignatureProperty(Collections./singletonList/(signatureObject),"#OpenESignForms_Seal",

"OpenESignForms_Seal_ID");

SignaturePropertiessignatureProperties=xmlSignatureFactory.newSignatureProperties(Collections./singletonList/(signatureProperty),*null*);

XMLObjectsignaturePropertiesXMLObject=xmlSignatureFactory.newXMLObject(Collections./singletonList/(signatureProperties),*null*,*null*,*null*);

// Sign the main payload

ReferencereferencePayload=xmlSignatureFactory.newReference("",xmlSignatureFactory.newDigestMethod(DigestMethod.*/SHA512/*,*null*),

Collections./singletonList/(xmlSignatureFactory.newTransform(Transform.*/ENVELOPED/*, 
(TransformParameterSpec)*null*)),*null*,"Payload_Reference_ID");

// Sign the KeyInfo per the EU spec

ReferencereferenceKeyInfo=xmlSignatureFactory.newReference("#KeyInfo_ID",xmlSignatureFactory.newDigestMethod(DigestMethod.*/SHA512/*,*null*));

// Sign the EU qualifying properties

ReferencereferenceQualifyingProperties=xmlSignatureFactory.newReference("#QualifyingProperties_ID",

xmlSignatureFactory.newDigestMethod(DigestMethod.*/SHA512/*,*null*));

// Sign our seal

ReferencereferenceSignatureProperties=xmlSignatureFactory.newReference("#OpenESignForms_Seal_ID",

xmlSignatureFactory.newDigestMethod(DigestMethod.*/SHA512/*,*null*));

List<Reference>referenceList=*new*LinkedList<Reference>();

referenceList.add(referencePayload);

referenceList.add(referenceKeyInfo);

referenceList.add(referenceQualifyingProperties);

referenceList.add(referenceSignatureProperties);

 ? SignedInfosignedInfo=xmlSignatureFactory

.newSignedInfo(

xmlSignatureFactory.newCanonicalizationMethod(

*/CanonicalizationMethod_INCLUSIVE_C14N11_WITH_COMMENTS/*/* 
CanonicalizationMethod.INCLUSIVE_WITH_COMMENTS */, 
(C14NMethodParameterSpec)*null*),

xmlSignatureFactory.newSignatureMethod(*/SignatureMethod_RSA_SHA512/*,*null*),referenceList);

// Create the XMLSignature, but don't sign it yet.

List<XMLObject>signingXMLObjects=*new*LinkedList<XMLObject>();

signingXMLObjects.add(qualifyingPropertiesXMLObject);

signingXMLObjects.add(signaturePropertiesXMLObject);

XMLSignaturexmlSignature=xmlSignatureFactory.newXMLSignature(signedInfo,keyInfo,signingXMLObjects,"OpenESignForms_Seal",*null*);

// Marshal, generate, and sign the enveloped signature.

xmlSignature.sign(domSignContext);

 ? Writerwriter=*new*StringWriter(xmlToSign.length() + 8000);// add in 
overhead for Signature element

TransformerFactorytf= TransformerFactory./newInstance/();

Transformertransformer=tf.newTransformer();

// we don't want <?xml version="1.0" encoding="UTF-8" standalone="no"?> 
at the top since we embed our signed XML in other XML structures

// (it's not a standalone document at all)

transformer.setOutputProperty(OutputKeys.*/OMIT_XML_DECLARATION/*,"yes");

transformer.transform(*new*DOMSource(document),*new*StreamResult(writer));

*return*writer.toString();

 ? }*catch*(Exceptione) {

 ? System.*/err/*.println("XmlDigitalSignature.sign() SERIOUS-ERROR 
exception: "+e.getMessage());

e.printStackTrace();

*throw*e;

 ? }

 ? }

*public**void*verify(StringsignedXml, 
SignatureKeysignatureKey)*throws*Exception {

*if*(/isBlank/(signedXml) ||signatureKey==*null*)

*throw**new*Exception("Missing required parameter signedXml and/or 
signatureKey");

*try*{

DocumentBuilderFactorydbf= DocumentBuilderFactory./newInstance/();

dbf.setNamespaceAware(*true*);

 ? 
Documentdocument=dbf.newDocumentBuilder().parse(*new*BufferedInputStream(*new*ByteArrayInputStream(/stringToBytes/(signedXml))));

 ? 
NodeListqualifyingPropertiesNodeList=document.getElementsByTagName("QualifyingProperties");

*if*(qualifyingPropertiesNodeList!=*null*) {

*for*(*int*i= 0;i<qualifyingPropertiesNodeList.getLength(); ++i) {

 ? ElementqualifyingPropertiesElement= 
(Element)qualifyingPropertiesNodeList.item(i);

*if*(qualifyingPropertiesElement!=*null*)

qualifyingPropertiesElement.setIdAttribute("Id",*true*);// mark our id 
as the "Id" attribute

 ? }

 ? }

 ? 
NodeListnl=document.getElementsByTagNameNS(XMLSignature.*/XMLNS/*,"Signature");

*if*(nl.getLength() == 0) {

 ? System.*/err/*.println("XmlDigitalSignature.verify(SignatureKey) 
SERIOUS-ERROR no Signature element");

*throw**new*Exception("The signedXML has no Signature element");

 ? }

// The embedded key must match our signatureKey's values or the 
validation will fail.

DOMValidateContextvalContext=*new*DOMValidateContext(*new*VerifyingKeySelector(signatureKey),nl.item(0));

XMLSignaturesignature=xmlSignatureFactory.unmarshalXMLSignature(valContext);

*if*(!signature.validate(valContext)) {

*boolean*isSignatureValueValid=signature.getSignatureValue().validate(valContext);

 ? System.*/err/*.println("XmlDigitalSignature.verify(SignatureKey) 
SERIOUS-ERROR Failed core validation; SignatureValue validated: 
"+isSignatureValueValid);

StringBuilderexceptionText=*new*StringBuilder();

exceptionText.append("Invalid signature. SignatureValue 
").append(isSignatureValueValid?"validated":"INVALID");

Iterator<?>i=signature.getSignedInfo().getReferences().iterator();

*for*(*int*j= 0;i.hasNext();j++) {

*boolean*refValid= ((Reference)i.next()).validate(valContext);

 ? System.*/err/*.println(" -> Reference["+j+"] validated: "+refValid);

exceptionText.append("; 
").append(/getReferenceName/(j)).append(refValid?" validated":" INVALID");

 ? }

*throw**new*Exception(exceptionText.toString());

 ? }

 ? }*catch*(Exceptione) {

 ? System.*/err/*.println("XmlDigitalSignature.verify(SignatureKey) 
SERIOUS-ERROR exception: "+e.getMessage());

e.printStackTrace();

*throw*e;

 ? }

 ? }

*private**static*String getReferenceName(*int*i) {

*if*(i== 0)

*return*"XML data payload";

*if*(i== 1)

*return*"OpenESignForms Seal";

*return*"Unexpected Reference["+i+"]";

 ? }

*public**void*verify(StringsignedXml, PublicKeypublicKey)*throws*Exception {

*if*(/isBlank/(signedXml) ||publicKey==*null*)

*throw**new*Exception("Missing required parameter signedXml and/or 
publicKey");

*try*{

DocumentBuilderFactorydbf= DocumentBuilderFactory./newInstance/();

dbf.setNamespaceAware(*true*);

 ? 
Documentdocument=dbf.newDocumentBuilder().parse(*new*BufferedInputStream(*new*ByteArrayInputStream(/stringToBytes/(signedXml))));

 ? 
NodeListqualifyingPropertiesNodeList=document.getElementsByTagName("QualifyingProperties");

*if*(qualifyingPropertiesNodeList!=*null*) {

*for*(*int*i= 0;i<qualifyingPropertiesNodeList.getLength(); ++i) {

 ? ElementqualifyingPropertiesElement= 
(Element)qualifyingPropertiesNodeList.item(i);

*if*(qualifyingPropertiesElement!=*null*)

qualifyingPropertiesElement.setIdAttribute("Id",*true*);// mark our id 
as the "Id" attribute

 ? }

 ? }

 ? 
NodeListnl=document.getElementsByTagNameNS(XMLSignature.*/XMLNS/*,"Signature");

*if*(nl.getLength() == 0) {

 ? System.*/err/*.println("XmlDigitalSignature.verify(PublicKey) 
SERIOUS-ERROR no Signature element");

*throw**new*Exception("The signedXML has no Signature element");

 ? }

DOMValidateContextvalContext=*new*DOMValidateContext(publicKey,nl.item(0));

// DOMValidateContext valContext = new 
DOMValidateContext(KeySelector.singletonKeySelector(publicKey), nl.item(0));

XMLSignaturesignature=xmlSignatureFactory.unmarshalXMLSignature(valContext);

*if*(!signature.validate(valContext)) {

*boolean*isSignatureValueValid=signature.getSignatureValue().validate(valContext);

 ? System.*/err/*.println("XmlDigitalSignature.verify(PublicKey) 
SERIOUS-ERROR Failed core validation; SignatureValue validated; 
"+isSignatureValueValid);

StringBuilderexceptionText=*new*StringBuilder();

exceptionText.append("Invalid signature. SignatureValue 
").append(isSignatureValueValid?"validated":"INVALID");

Iterator<?>i=signature.getSignedInfo().getReferences().iterator();

*for*(*int*j= 0;i.hasNext();j++) {

*boolean*refValid= ((Reference)i.next()).validate(valContext);

 ? System.*/err/*.println(" -> Reference["+j+"] validated: "+refValid);

exceptionText.append("; 
").append(/getReferenceName/(j)).append(refValid?" validated":" INVALID");

 ? }

*throw**new*Exception(exceptionText.toString());

 ? }

 ? }*catch*(Exceptione) {

 ? System.*/err/*.println("XmlDigitalSignature.verify(PublicKey) 
SERIOUS-ERROR exception: "+e.getMessage());

e.printStackTrace();

*throw*e;

 ? }

 ? }

*public**void*verifyAcceptEmbeddedKeysIfKeyIdNotFound(StringsignedXml)*throws*Exception 
{

*if*(/isBlank/(signedXml))

*throw**new*Exception("Missing required parameter signedXml");

*try*{

DocumentBuilderFactorydbf= DocumentBuilderFactory./newInstance/();

dbf.setNamespaceAware(*true*);

 ? 
Documentdocument=dbf.newDocumentBuilder().parse((*new*BufferedInputStream(*new*ByteArrayInputStream(/stringToBytes/(signedXml)))));

 ? 
NodeListqualifyingPropertiesNodeList=document.getElementsByTagName("QualifyingProperties");

*if*(qualifyingPropertiesNodeList!=*null*) {

*for*(*int*i= 0;i<qualifyingPropertiesNodeList.getLength(); ++i) {

 ? ElementqualifyingPropertiesElement= 
(Element)qualifyingPropertiesNodeList.item(i);

*if*(qualifyingPropertiesElement!=*null*)

qualifyingPropertiesElement.setIdAttribute("Id",*true*);// mark our id 
as the "Id" attribute

 ? }

 ? }

 ? 
NodeListnl=document.getElementsByTagNameNS(XMLSignature.*/XMLNS/*,"Signature");

*if*(nl.getLength() == 0) {

 ? 
System.*/err/*.println("XmlDigitalSignature.verifyAcceptEmbeddedKeysIfKeyIdNotFound() 
SERIOUS-ERROR no Signature element");

*throw**new*Exception("The signedXML has no Signature element");

 ? }

// The embedded key must match our signatureKey's values or the 
validation will fail.

DOMValidateContextvalContext=*new*DOMValidateContext(*new*AcceptEmbeddedKeySelector(),nl.item(0));

XMLSignaturesignature=xmlSignatureFactory.unmarshalXMLSignature(valContext);

*if*(!signature.validate(valContext)) {

*boolean*isSignatureValueValid=signature.getSignatureValue().validate(valContext);

 ? 
System.*/err/*.println("XmlDigitalSignature.verifyAcceptEmbeddedKeysIfKeyIdNotFound() 
SERIOUS-ERROR Failed core validation; SignatureValue validated; "

 ? +isSignatureValueValid);

StringBuilderexceptionText=*new*StringBuilder();

exceptionText.append("Invalid signature. SignatureValue 
").append(isSignatureValueValid?"validated":"INVALID");

Iterator<?>i=signature.getSignedInfo().getReferences().iterator();

*for*(*int*j= 0;i.hasNext();j++) {

*boolean*refValid= ((Reference)i.next()).validate(valContext);

 ? System.*/err/*.println(" -> Reference["+j+"] validated: "+refValid);

exceptionText.append("; 
").append(/getReferenceName/(j)).append(refValid?" validated":" INVALID");

 ? }

*throw**new*Exception(exceptionText.toString());

 ? }

 ? }*catch*(Exceptione) {

 ? 
System.*/err/*.println("XmlDigitalSignature.verifyAcceptEmbeddedKeysIfKeyIdNotFound() 
SERIOUS-ERROR exception: "+e.getMessage());

e.printStackTrace();

*throw*e;

 ? }

 ? }

*protected**static**class*VerifyingKeySelector*extends*KeySelector {

SignatureKeysignatureKey;

*public*VerifyingKeySelector(SignatureKeysignatureKey) {

*this*.signatureKey=signatureKey;

 ? }

*public*VerifyingKeySelector() {

*this*.signatureKey=*null*;

 ? }

@Override

*public*KeySelectorResult select(KeyInfokeyInfo, Purposepurpose, 
AlgorithmMethodmethod, 
XMLCryptoContextcontext)*throws*KeySelectorException {

*if*(keyInfo==*null*)

*throw**new*KeySelectorException("NULL KeyInfo");

SignatureMethodsm= (SignatureMethod)method;

List<?>list=keyInfo.getContent();

 ? UUIDkeyId=*null*;

PublicKeypublicKey=*null*;

*for*(*int*i= 0;i<list.size();i++) {

XMLStructurexmlStructure= (XMLStructure)list.get(i);

*if*(xmlStructure*instanceof*KeyName) {

 ? Stringname= ((KeyName)xmlStructure).getName();

keyId= UUID./fromString/(name);

 ? }*else**if*(xmlStructure*instanceof*KeyValue) {

*try*{

publicKey= ((KeyValue)xmlStructure).getPublicKey();

 ? }*catch*(KeyExceptionke) {

*throw**new*KeySelectorException(ke);

 ? }

 ? }

 ? }

*if*(keyId==*null*||publicKey==*null*)

*throw**new*KeySelectorException("XML Signature element needs KeyName 
and KeyValue to verify");

// If we don't have a signatureKey set, let's see if we can find it by 
the id

*if*(signatureKey==*null*)

signatureKey=*new*SignatureKey(keyId);

*if*(signatureKey==*null*)

*throw**new*KeySelectorException("KeyName and KeyValue cannot be 
verified without a SignatureKey");

*if*(keyId.equals(signatureKey.id) 
&&publicKey.equals(signatureKey.keyPair.getPublic()) 
&&/algEquals/(sm.getAlgorithm(),publicKey.getAlgorithm()))

*return**new*SimpleKeySelectorResult(publicKey);

*throw**new*KeySelectorException("KeyName and KeyValue are not correct 
and do not match the expected SignatureKey");

 ? }

 ? }

*protected**static**class*AcceptEmbeddedKeySelector*extends*KeySelector {

*public*AcceptEmbeddedKeySelector() {

 ? }

@Override

*public*KeySelectorResult select(KeyInfokeyInfo, Purposepurpose, 
AlgorithmMethodmethod, 
XMLCryptoContextcontext)*throws*KeySelectorException {

*if*(keyInfo==*null*)

*throw**new*KeySelectorException("NULL KeyInfo");

SignatureMethodsm= (SignatureMethod)method;

List<?>list=keyInfo.getContent();

 ? UUIDkeyId=*null*;

PublicKeypublicKey=*null*;

*for*(*int*i= 0;i<list.size();i++) {

XMLStructurexmlStructure= (XMLStructure)list.get(i);

*if*(xmlStructure*instanceof*KeyName) {

 ? Stringname= ((KeyName)xmlStructure).getName();

keyId= UUID./fromString/(name);

 ? }*else**if*(xmlStructure*instanceof*KeyValue) {

*try*{

publicKey= ((KeyValue)xmlStructure).getPublicKey();

 ? }*catch*(KeyExceptionke) {

*throw**new*KeySelectorException(ke);

 ? }

 ? }

 ? }

*if*(keyId==*null*||publicKey==*null*)

*throw**new*KeySelectorException("XML Signature element needs KeyName 
and KeyValue as these are always present when valid, even if not trusted");

// If we can find the key that uses the keyid specified, we'll ensure 
the public key is valid, but if not found,

// we'll implicitly trust it for this method's purpose.

SignatureKeysignatureKey=*new*SignatureKey(keyId);

*if*(signatureKey==*null*){

*if*(/algEquals/(sm.getAlgorithm(),publicKey.getAlgorithm()))

*return**new*SimpleKeySelectorResult(publicKey);

}*else*{

*if*(publicKey.equals(signatureKey.keyPair.getPublic()) 
&&/algEquals/(sm.getAlgorithm(),publicKey.getAlgorithm()))

*return**new*SimpleKeySelectorResult(publicKey);

 ? }

*throw**new*KeySelectorException("KeyName and KeyValue are not correct");

 ? }

 ? }

*public**static**class*SimpleKeySelectorResult*implements*KeySelectorResult 
{

PublicKeypublicKey;

SimpleKeySelectorResult(PublicKeypublicKey) {

*this*.publicKey=publicKey;

 ? }

*public*Key getKey() {

*return*publicKey;

 ? }

 ? }

*static**boolean*algEquals(StringalgURI, StringalgName) {

*return*(algName.equalsIgnoreCase("DSA") 
&&algURI.equalsIgnoreCase(SignatureMethod.*/DSA_SHA1/*))

 ? || (algName.equalsIgnoreCase("RSA") && 
(algURI.equalsIgnoreCase(*/SignatureMethod_RSA_SHA512/*) 
||algURI.equalsIgnoreCase(SignatureMethod.*/RSA_SHA1/*)));

 ? }

// End of original code

// Various utility routines added to replace OpenESF logic

*static**boolean*isBlank(Stringv) {

*if*(v==*null*)

*return**true*;

*for*(*int*i= 0;i<v.length(); ++i) {

*if*(!Character./isWhitespace/(v.charAt(i)))

*return**false*;

 ? }

*return**true*;

 ? }

*static**final**byte*[] stringToBytes(Stringv) {

*if*(v==*null*)

*return**null*;

*return*v.getBytes(StandardCharsets.*/UTF_8/*);

 ? }

*static**final*String bytesToString(*byte*[]v) {

*if*(v==*null*)

*return**null*;

*return**new*String(v, StandardCharsets.*/UTF_8/*);

 ? }

*static*String toXmlWithTz(ZonedDateTimedate) {

*if*(date==*null*)

*return*"";

// XML TZ is like -08:00, but Java Z format wants -0800

DateTimeFormatterfmt= 
DateTimeFormatter./ofPattern/("yyyy-MM-dd'T'HH:mm:ssZ");

// If we have a 4 digit TZ, make it HH:MM format rather than HHMM format 
Java gives us

 ? Stringxml=fmt.format(date);

xml=xml.substring(0, 22) +":"+xml.substring(22);

*return*xml;

 ? }

*static**boolean*isUnexpectedISOControlCharacter(*char*c) {

*if*(c=='\n'||c=='\r'||c=='\t')

*return**false*;

*return*Character./isISOControl/(c);

 ? }

*static*String toEscapedXml(Strings) {

*if*(s==*null*)

*return*"";

// The gamble here is that most strings will not contain the special 
characters,

// so we optimize things in that case by appending the original string 
without

// creating any new objects.

*int*length=s.length();

*int*currentPos;

*for*(currentPos= 0;currentPos<length; ++currentPos) {

*char*c=s.charAt(currentPos);

*if*(c=='"'||c=='<'||c=='>'||c=='&'||c=='\''||/isUnexpectedISOControlCharacter/(c))

*break*;// we'll need to escape this one

 ? }

// No quoting necessary, so just append the original string into the buffer.

*if*(currentPos>=length) {

*return*s;

 ? }

StringBuilderbuf=*new*StringBuilder(s.length());

buf.append(s.substring(0,currentPos));

*for*(;currentPos<length; ++currentPos) {

*char*c=s.charAt(currentPos);

*switch*(c) {

*case*'"':

buf.append("&quot;");

*break*;

*case*'\'':

buf.append("&apos;");// aka: &#039; but we don't do any of these codes here

*break*;

*case*'<':

buf.append("&lt;");

*break*;

*case*'>':

buf.append("&gt;");

*break*;

*case*'&': {

buf.append("&amp;");

*break*;

 ? }

*default*:

*if*(!/isUnexpectedISOControlCharacter/(c))// we won't allow these in 
our XML data

buf.append(c);

*break*;

 ? }

 ? }

*return*buf.toString();

 ? }

*static*X509Certificate 
toX509CertificateFromBase64Encoded(Stringbase64EncodeCert) {

*try*{

*byte*[]encodedCert= 
java.util.Base64./getDecoder/().decode(base64EncodeCert);

*if*(encodedCert==*null*) {

 ? System.*/err/*.println("toX509CertificateFromBase64Encoded() - Failed 
to Base64 decode.");

*return**null*;

 ? }

CertificateFactoryfactory= CertificateFactory./getInstance/("X.509");

*if*(factory==*null*) {

 ? System.*/err/*.println("toX509CertificateFromBase64Encoded() - Failed 
to get an X.509 certificate factory.");

*return**null*;

 ? }

ByteArrayInputStreambais=*new*ByteArrayInputStream(encodedCert);

Certificatecert= (X509Certificate)factory.generateCertificate(bais);

*if*(cert*instanceof*X509Certificate)

*return*(X509Certificate)cert;

 ? System.*/err/*.println("toX509CertificateFromBase64Encoded() 
certficate is not X.509 as expected. Type is: "+cert.getType());

*return**null*;

 ? }*catch*(java.security.cert.CertificateExceptione) {

 ? System.*/err/*.println("toX509CertificateFromBase64Encoded() 
exception: "+e.getMessage());

e.printStackTrace();

*return**null*;

 ? }

 ? }

*static*PublicKey 
getPublicFromX509Encoded(KeyFactorykeyFactory,*byte*[]x509EncodedPublicKey) 
{

*try*{

X509EncodedKeySpecpubKeySpec=*new*X509EncodedKeySpec(x509EncodedPublicKey);

*return*keyFactory.generatePublic(pubKeySpec);

 ? }*catch*(Exceptione) {

 ? System.*/err/*.println("getPublicFromX509Encoded() Failed to decode: 
"+e.getMessage());

*return**null*;

 ? }

 ? }

*static*PrivateKey 
getPrivateFromPkcs8Encoded(KeyFactorykeyFactory,*byte*[]pkcs8EncodedPrivateKey) 
{

*try*{

PKCS8EncodedKeySpecprivKeySpec=*new*java.security.spec.PKCS8EncodedKeySpec(pkcs8EncodedPrivateKey);

*return*keyFactory.generatePrivate(privKeySpec);

 ? }*catch*(Exceptione) {

 ? System.*/err/*.println("getPrivateFromPkcs8Encoded() Failed to 
decode: "+e.getMessage());

*return**null*;

 ? }

 ? }

*static**final*String*/CERT/*="MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVuX2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1zVmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlhYzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAzMjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2NhbGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEwZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJRC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIICJjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOlkR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEYLuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89NSrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+EaVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMgXd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQVFezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCCAiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDANBgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4TovkzDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQwLX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiazsyix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQOKEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtKGrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/uFRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48XbckvyVMfem/JPPYT/veThnefIgQk=";

*static**final*String*/PUBKEY/*="MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEAkPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWWI42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujUMCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQXoU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJQjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aBsnJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6zVv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/nC+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gMCAwEAAQ==";

*static**final*String*/PRIVKEY/*="MIIJQQIBADANBgkqhkiG9w0BAQEFAASCCSswggknAgEAAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABAoICAG8F/CT2Fg+8nLpQ4UueQ84CQI4gV4d69JohqIVVpoNk96U4CbMlpvfFSI9ssbh/B7V4gRmK38TKn2lvvY1eOA4NbYRU+W+ct2YJP5K1MN3hQmpaNDKyKv9vCuAkWl2dzOcg7g0uceQBGUTyhkPBTUH8OkKnjiC54T2Zhfsq078kPkw9vU51iLgnZh42QryDodobWS6jbFd4J2wY4x1mXClGOMaIYR+OPimzzX3FbhX7U7o010sxV1hJR09M6CVlXTxCuaaAtx+I6M6TOPP5QpmJtjYGBP1ppu74YMdvXK0oZluMOPGVNCie5EYeVvHLIeXxMebtstDaaRAx/w9WyKJ7kFFx/KwwA3uC34IaOG68zFHblnEhbPSP89Px1rptXEkuO8QR/h6kkyuGPCWLGn3NP//ZrWFB04ojFCWc1Dznbs4r+Xv9A7MBbrjKB6l1YbuaOrUTG6kWnVVYBg8eyGxrJ0r/oVHYBc3ppD9yZiENhts1sMKISxn7fMgDxRydvFNyfa02kzX40n2MlQN/ApRh0RDmJeGUC0pSNAYavoaJzQCTax5J2j7MJduwkxnZR/8IiP0TZTUo7hUPzR/Jad1LizDz3e6zHMFHmInzq/9pc+P//OnFdESVkEXLWeVmj4RBgPUFXGn2BkmYknZeZdA93+BnP/Szp4FOW5mtWr0ZAoIBAQDR/6gi83QyYfuWUFx1Aep7bpmXB6lRQxHRzA07ytj4/RVwHldhKbpO1+crQ6hBe+d2xp2X6VDR23HZ5lYgOqcXJPlfV/V08m9qcyqZID5XV/MHwhRxfMQ+LxtAviJst3TYg+MaDCjyCLh9FjRB2WIwtaFHVz8w66oGGgfnmNg09zXNBsoeW5QJ7h7+re81xgZkgEUmYDIteKl0kp2vqvXN0e/zeDlnxYGUSMGB58XsN4dU9dN1Lm2jUBnY4pqZibgA+Ph+QW0/9dsPz3rl8DMIieBztprj1bx9apZK0Re/Ezl22myzscOdBRLRdoHsOhYYMOU5cP+XdTbbz6BWraIlAoIBAQCwsKaJtPqRwCyvoZzURx7xGItebTVmYyCQ8kW5V6B42532VDdUFgDgFXOLKapDs/tpRa4GmVlTMBBacUqvmUEOocny/6RYmY7vDYQWm4qgXFc2aIF1Z8H+q4JXmui19T/eEGnk6N6tC6lwaGtdIgesQcIylAQJwpsTQODaxsEIcC0J8nbpRz/dkfkPgZaCmxVa15S8Go5/nGXH8Uzv9gH+fpAotoKX1AHKkyym+vKabXS8Za5Ch+d43Vb0cechgYVAmV0EUrIHVCUI8cUdfdfKvisz6S1KCPVclOzLKKU9GEXe+UJt5Mmb/InoBxtSAZjDggwIV4gZF06UsjIQVLcHAoIBAGqoVLdbu1qTlXqk2jC7hmKmq++ffom9bOGHp/kEb+sWb7sAThUVYoEE+25n8J9B1S/odMZhRCEyOcMYUAoSgCcrKlUYkZySPbBtSed4DvHBw7ffBQ8W9X0347mgWE+rZfdKFSB3qJw1fa5ahrQjOtHOjllzoK6yIyryMa2ZXcaZAIRfvGxqyue4P5nOsb44E6sb0wNIvHOH41lH1jsQs8OTqzGXkGB6WfP8d/wIwefV1DB8oqfTqu/VkSss/KSa5A/qZBuME3b24gpHsP30X5cooA1lY4nwVsnERw084bi0hO0uxyMFWHr5xrMIY7idT/d9bg8cq1Q7vl8qNx+PFNkCggEAPxLgcHollJAYo526oWC+H+zWG6A6ltE+F+AUmcQ5KcukSQHpOmAcceHWfFAkUsTWM89G/14QsAyRWefldGft/G4u7Err/SDcEGQvye4+f15XV7nYtPOUIfhRsDpBZmslIH2Vf7zNeNKX6uOrp/R07r4OuAV0p5NLzoSzgAXBdOSuf0WJw17G4q6wTSPCed8osWQR2VBVnCJVhxmRkHuuXI4Loiz803xAI3OEVhtxLUVzjalympdvPwssdliO3LwiuFvHA7sNiGY2TkoYRp3cwag/Pem4XBx0klcrbJ6W1gdrMdyjJR2uBrwQ8r5Ot2iQgwJSj0vH7sUOLTCrhH7pUwKCAQAjXNqClU9mjWBNEZNIWCzDOdiRsH9FmtHeEnp6uv+mdbE433bW4RS25oL+qh2MytAxGYE1mIjCuTLca3NCOCPVyFzRS3IkVxn3YRIRgNS9IGMaIA7xt+dSy75BIJ3AgjMJ4H5pGCKPUQN+2EBjyXekajvppkDZF+MYj/rM0a4auQuK1AewntJppVgZ9DbiHtZnuSMyLncJW18xvoIWi08dGUPYArcPiFGaf4GmP/Ucr2X/DJeU+0jfhCalgamEuMyCOQAudgXYEzD4Z3nJvCXs7kMZTO+TOg1NYkhMAxv42CIc+ajPYMzMGIGADf27Cn8ROW8yUrEyIz3StTQVt6Ih";

*public**static**class*SignatureKey {

*public*UUIDid;

*public*KeyPairkeyPair;

*public*X509Certificatecert;

*public*SignatureKey(UUIDid) {

*this*.id=id;

 ? Stringbase64Cert=*/CERT/*;

 ? Stringbase64PublicKey=*/PUBKEY/*;

 ? Stringbase64PrivateKey=*/PRIVKEY/*;

*try*{

KeyFactorykeyFactory=*null*;

*try*{

keyFactory= KeyFactory./getInstance/("RSA","BC");

 ? System.*/err/*.println("SignatureKey: Using BC provider on RSA 
KeyFactory");

 ? }*catch*(NoSuchProviderExceptione) {

*try*{

keyFactory= KeyFactory./getInstance/("RSA","SunRsaSign");

 ? System.*/err/*.println("SignatureKey: Using SunRsaSign provider on 
RSA KeyFactory");

 ? }*catch*(NoSuchProviderExceptione2) {

 ? System.*/err/*.println("SignatureKey -- no KeyFactory provider found 
exception: "+e.getMessage());

e.printStackTrace();

 ? System./exit/(2);

 ? }

 ? }

cert=/toX509CertificateFromBase64Encoded/(base64Cert);

*byte*[]encodedPublicKey= 
java.util.Base64./getDecoder/().decode(base64PublicKey);

PublicKeypublicKey=/getPublicFromX509Encoded/(keyFactory,encodedPublicKey);

*byte*[]encodedPrivateKey= 
java.util.Base64./getDecoder/().decode(base64PrivateKey);

PrivateKeyprivateKey=/getPrivateFromPkcs8Encoded/(keyFactory,encodedPrivateKey);

keyPair=*new*KeyPair(publicKey,privateKey);

 ? }*catch*( Exceptione) {

 ? System.*/err/*.println("SignatureKey - exception: "+e.getMessage());

e.printStackTrace();

 ? }

 ? }

 ? }

*static**final*String*/html/*="<html 
xmlns=\"http://www.w3.org/1999/xhtml\"><head></head><body><p>Dummy HTML 
document</p></body></html>";

*static**final*String*/XML_NAMESPACE_2011/*="http://open.esignforms.com/XMLSchema/2011";

// Added main so can run the test under different JDKs.

*public**static**void*main(String[]args) {

*try*{

 ? java.security.Security./setProperty/("crypto.policy","unlimited");// 
Should work in Java 9 to allow unlimited crypto strength.

*try*{

 ? Class<?>jceProvider= 
Class./forName/("org.bouncycastle.jce.provider.BouncyCastleProvider");

java.security.Providerp= (java.security.Provider)jceProvider.newInstance();

java.security.Security./addProvider/(p);

p= java.security.Security./getProvider/("BC");

*if*(p==*null*)

 ? System.*/err/*.println("Could not find the BC JCE provider; hoping 
that the SunRsaSign is in there!");

*else*

 ? System.*/err/*.println("Found BC Provider: "+p.getInfo());

 ? }*catch*(ClassNotFoundExceptione) {

 ? System.*/err/*.println("ClassNotFoundException: Could not find the BC 
JCE provider");

 ? }*catch*(InstantiationExceptione) {

 ? System.*/err/*.println("InstantiationException: Could not find the BC 
JCE provider");

 ? }*catch*(IllegalAccessExceptione) {

 ? System.*/err/*.println("IllegalAccessException: Could not find the BC 
JCE provider");

 ? }

 ? 
StringnamespaceTimestampAttributes="xmlns=\""+*/XML_NAMESPACE_2011/*+"\" 
timestamp=\""+/toXmlWithTz/(ZonedDateTime./now/()) +"\"";

 ? Stringxml="<snapshot type=\"document\" 
"+namespaceTimestampAttributes+"><![CDATA["+*/html/*+"]]></snapshot>";

SignatureKeysignatureKey=*new*SignatureKey(UUID./randomUUID/());

XmlDigitalSignaturexmldsig=*new*XmlDigitalSignature();

 ? 
StringsignedXml=xmldsig.sign(xml,"description","text/html",signatureKey,"192.1.1.1","No-Browser-Test");

 ? System.*/out/*.println("Signed XML:");

 ? System.*/out/*.println(signedXml);

 ? }*catch*(Exceptione) {

 ? System.*/err/*.println("XmlDigitalSignature.main() exception: 
"+e.getMessage());

e.printStackTrace();

 ? System./exit/(1);

 ? }

 ? System./exit/(0);

 ? }

}

On 1/30/19 1:54 PM, Sean Mullan wrote:
> Hi,
>
> Thanks for reporting the issue. Can you please file a bug at 
> https://bugreport.java.com/bugreport/ so that it can be tracked and 
> further evaluated?
>
> --Sean
>
> On 1/30/19 3:59 PM, Open eSignForms wrote:
>>
>> My XML Digital Signature code runs fine under Java 8 (1.8.0_161), but 
>> on upgrading to OpenJDK 11 (11.0.2, ), it now traps with an 
>> NAMESPACE_ERR exception:
>>
>> org.w3c.dom.DOMException: NAMESPACE_ERR: An attempt is made to create 
>> or change an object in a way which is incorrect with regard to 
>> namespaces.
>>
>> at 
>> java.xml/com.sun.org.apache.xerces.internal.dom.ElementNSImpl.setName(ElementNSImpl.java:109)
>>
>> at 
>> java.xml/com.sun.org.apache.xerces.internal.dom.ElementNSImpl.<init>(ElementNSImpl.java:84)
>>
>> at 
>> java.xml/com.sun.org.apache.xerces.internal.dom.CoreDocumentImpl.createElementNS(CoreDocumentImpl.java:2089)
>>
>> at 
>> java.xml.crypto/org.jcp.xml.dsig.internal.dom.XmlWriterToTree.writeStartElement(XmlWriterToTree.java:99)
>>
>> at 
>> java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller.marshalGenericNode(Marshaller.java:303)
>>
>> at 
>> java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller.marshalGenericNode(Marshaller.java:286)
>>
>> at 
>> java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller$14.marshalObject(Marshaller.java:251)
>>
>> at 
>> java.xml.crypto/org.jcp.xml.dsig.internal.dom.Marshaller$14.marshalObject(Marshaller.java:247)
>>
>> at 
>> java.xml.crypto/org.jcp.xml.dsig.internal.dom.XmlWriterToTree.marshalStructure(XmlWriterToTree.java:200)
>>
>> at 
>> java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLObject.marshal(DOMXMLObject.java:180)
>>
>> at 
>> java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.marshal(DOMXMLSignature.java:233)
>>
>> at 
>> java.xml.crypto/org.jcp.xml.dsig.internal.dom.DOMXMLSignature.sign(DOMXMLSignature.java:325)
>>
>> at 
>> com.esignforms.open.crypto.XmlDigitalSignature.sign(XmlDigitalSignature.java:208)
>>
>> If I revert back to Java 8, it works again.
>>
>> I noted that our XML digital signature code makes no direct 
>> references to namespaces.? Basic code does set the 
>> DocumentBuildFactory to be namespace aware:
>>
>> ? DocumentBuilderFactorydbf= DocumentBuilderFactory./newInstance/();
>>
>> dbf.setNamespaceAware(*true*);
>>
>> When we sign under Java 8, this is the resulting digitally signed 
>> output for our XML <snapshot> element, which does have a namespace of 
>> our own:
>>
>> <snapshotxmlns="http://open.esignforms.com/XMLSchema/2011"timestamp="2019-01-30T12:40:46-08:00"type="document"><![CDATA[<!DOCTYPE 
>> html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" 
>> "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
>>
>> <html xmlns="http://www.w3.org/1999/xhtml">
>>
>> <head>
>>
>> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
>>
>> <title>Date Doc 1</title>
>>
>> <meta name="robots" content="noindex, nofollow" />
>>
>> <meta name="Description" content="Confidential document" />
>>
>> <meta name="viewport" content="width=device-width, initial-scale=1" />
>>
>> <meta name="Generator" content="Yozons Open eSignForms document 
>> generator version 19.1.19_p0129_1657" />
>>
>> <meta name="DeploymentId" 
>> content="bbfe9bed-918d-446b-9518-8ec303bafb83" />
>>
>> <meta name="TransactionId" 
>> content="5163276c-d8aa-436f-8a96-5bc0c9eca931" />
>>
>> <meta name="TransactionTemplateId" 
>> content="d15a91a3-87b8-457e-84bc-0b56ac7ebb10" />
>>
>> <meta name="TransactionMode" content="Test" />
>>
>> <meta name="PackageId" content="60301b59-ca07-429e-bb76-7083bfd6e642" />
>>
>> <meta name="PackageVersionId" 
>> content="61afd6f3-b79e-4d14-844d-3a38541020ea" />
>>
>> <meta name="PackageVersionPartyName" content="FirstParty" />
>>
>> <meta name="DocumentId" content="e105af31-4b37-4092-9795-48b7c762ae97" />
>>
>> <meta name="DocumentName" content="Date Doc 1" />
>>
>> <meta name="DocumentVersionId" 
>> content="52248c28-187e-43f0-8de8-98357fa63654" />
>>
>> <meta name="DocumentVersionPageId" 
>> content="62edfd59-be00-435a-9bd5-583cc84d220a" />
>>
>> <meta name="DocumentVersionPartyName" content="FirstParty" />
>>
>> <meta name="DocumentPageMode" content="REVIEW" />
>>
>> <meta name="HtmlRenderTimestamp" content="2019-01-30 12:40:43.041 PST" />
>>
>> <meta name="RequestIpAddr" 
>> content="50-46-115-249.evrt.wa.frontiernet.net 
>> <http://50-46-115-249.evrt.wa.frontiernet.net> (50.46.115.249)" />
>>
>> <meta name="RequestUserAgent" content="Mozilla/5.0 (Macintosh; Intel 
>> Mac OS X 10_14_3) AppleWebKit/605.1.15 (KHTML, like Gecko) 
>> Version/12.0.3 Safari/605.1.15" />
>>
>> <base href="https://open.esignforms.com/demo/" />
>>
>> <style type="text/css">
>>
>> /* platform esf.css */
>>
>> @import url(//fonts.googleapis.com/css?family=Pacifico 
>> <http://fonts.googleapis.com/css?family=Pacifico>);
>>
>> body.esf { font-family: Calibri, Arial, Helvetica, sans-serif; 
>> font-size: 1em; }
>>
>> .esf a img { border: none; }
>>
>> .esf table.center, .esf div.center { margin-left: auto; margin-right: 
>> auto; }
>>
>> .esf p.left, .esf span.left, .esf div.left, .esf th.left, .esf 
>> td.left { text-align: left; }
>>
>> .esf p.right, .esf span.right, .esf div.right, .esf th.right, .esf 
>> td.right { text-align: right; }
>>
>> .esf p.center, .esf span.center, .esf th.center, .esf td.center { 
>> text-align: center; }
>>
>> .esf p.justify, .esf span.justify, .esf div.justify { text-align: 
>> justify; }
>>
>> .esf .bottom { vertical-align: bottom; }
>>
>> .esf .top { vertical-align: top; }
>>
>> .esf .middle { vertical-align: middle; }
>>
>> .esf .w5 { width: 5%; }
>>
>> .esf .w10 { width: 10%; }
>>
>> .esf .w15 { width: 15%; }
>>
>> .esf .w20 { width: 20%; }
>>
>> .esf .w25 { width: 25%; }
>>
>> .esf .w30 { width: 30%; }
>>
>> .esf .w33 { width: 33%; }
>>
>> .esf .w34 { width: 34%; }
>>
>> .esf .w35 { width: 35%; }
>>
>> .esf .w40 { width: 40%; }
>>
>> .esf .w45 { width: 45%; }
>>
>> .esf .w48 { width: 48%; }
>>
>> .esf .w50 { width: 50%; }
>>
>> .esf .w60 { width: 60%; }
>>
>> .esf .w70 { width: 70%; }
>>
>> .esf .w75 { width: 75%; }
>>
>> .esf .w80 { width: 80%; }
>>
>> .esf .w85 { width: 85%; }
>>
>> .esf .w90 { width: 90%; }
>>
>> .esf .w95 { width: 95%; }
>>
>> .esf .w98 { width: 98%; }
>>
>> .esf .w100 { width: 100%; }
>>
>> .esf .boT { border-top: 1px solid black; }
>>
>> .esf .boB { border-bottom: 1px solid black; }
>>
>> .esf .boTB { border-top: 1px solid black; border-bottom: 1px solid 
>> black; }
>>
>> .esf .boL { border-left: 1px solid black; }
>>
>> .esf .boR { border-right: 1px solid black; }
>>
>> .esf .boLR { border-left: 1px solid black; border-right: 1px solid 
>> black; }
>>
>> .esf .boBdash { border-bottom: 1px dashed black; }
>>
>> .esf .boBdot { border-bottom: 1px dotted black; }
>>
>> .esf .boBthick { border-bottom: 4px solid black; }
>>
>> .esf .box { border: 1px solid black; }
>>
>> .esf .boxthicker { border: 2px solid black; }
>>
>> .esf .boxthick { border: 4px solid black; }
>>
>> .esf .underline { text-decoration: underline; }
>>
>> .esf .bold { font-weight: bold; }
>>
>> .esf .italic { font-style: italic; }
>>
>> .esf ::-webkit-input-placeholder { font-style: italic; }
>>
>> .esf :-moz-placeholder { font-style: italic; }
>>
>> .esf ::-moz-placeholder { font-style: italic; }
>>
>> .esf :-ms-input-placeholder { font-style: italic; }
>>
>> .esf .caps { text-transform: uppercase; }
>>
>> .esf .smallcaps { font-variant: small-caps; }
>>
>> .esf .lowercase { text-transform: lowercase; }
>>
>> .esf .f6 { font-size: 6pt; }
>>
>> .esf .f7 { font-size: 7pt; }
>>
>> .esf .f8 { font-size: 8pt; }
>>
>> .esf .f9 { font-size: 9pt; }
>>
>> .esf .f10 { font-size: 10pt; }
>>
>> .esf .f11 { font-size: 11pt; }
>>
>> .esf .f12 { font-size: 12pt; }
>>
>> .esf .f14 { font-size: 14pt; }
>>
>> .esf .f16 { font-size: 16pt; }
>>
>> .esf .f18 { font-size: 18pt; }
>>
>> .esf .f20 { font-size: 20pt; }
>>
>> .esf .f22 { font-size: 22pt; }
>>
>> .esf .f24 { font-size: 24pt; }
>>
>> .esf .f28 { font-size: 28pt; }
>>
>> .esf .f32 { font-size: 32pt; }
>>
>> .esf .f36 { font-size: 36pt; }
>>
>> .esf .f40 { font-size: 40pt; }
>>
>> .esf .f48 { font-size: 48pt; }
>>
>> .esf .f60 { font-size: 60pt; }
>>
>> .esf .f72 { font-size: 72pt; }
>>
>> .esf .f96 { font-size: 96pt; }
>>
>> .esf .red {color: red;}
>>
>> .esf .green {color: green;}
>>
>> .esf .blue {color: blue;}
>>
>> .esf .white {color: white;}
>>
>> .esf .black {color: black;}
>>
>> .esf .gray? {color: gray;}
>>
>> .esf .nomargin { margin: 0; }
>>
>> .esf .nomarginT { margin-top: 0; }
>>
>> .esf .nomarginB { margin-bottom: 0; }
>>
>> .esf .nomarginTB { margin-top: 0; margin-bottom: 0; }
>>
>> .esf .nomarginL { margin-left: 0; }
>>
>> .esf .nomarginR { margin-right: 0; }
>>
>> .esf .nomarginLR { margin-left: 0; margin-right: 0; }
>>
>> .esf .nowrap { white-space: nowrap; }
>>
>> /* HTML5 versions for table cellpadding="0" through cellpadding="5" */
>>
>> .esf table.cellpadding0 th, .esf table.cellpadding0 td { padding: 0; }
>>
>> .esf table.cellpadding1 th, .esf table.cellpadding1 td { padding: 1px; }
>>
>> .esf table.cellpadding2 th, .esf table.cellpadding2 td { padding: 2px; }
>>
>> .esf table.cellpadding3 th, .esf table.cellpadding3 td { padding: 3px; }
>>
>> .esf table.cellpadding4 th, .esf table.cellpadding4 td { padding: 4px; }
>>
>> .esf table.cellpadding5 th, .esf table.cellpadding5 td { padding: 5px; }
>>
>> /* HTML5 versions for table cellspacing="0" through cellspacing="5" */
>>
>> .esf table.cellspacing0 { border-spacing: 0; }
>>
>> .esf table.cellspacing1 { border-spacing: 1px; }
>>
>> .esf table.cellspacing2 { border-spacing: 2px; }
>>
>> .esf table.cellspacing3 { border-spacing: 3px; }
>>
>> .esf table.cellspacing4 { border-spacing: 4px; }
>>
>> .esf table.cellspacing5 { border-spacing: 5px; }
>>
>> /* HTML5 version of border="1" through border="2" */
>>
>> table.gridBorder { border-top: 1px solid black; border-left: 1px 
>> solid black; }
>>
>> table.gridBorder th, table.gridBorder td { border-bottom: 1px solid 
>> black; border-right: 1px solid black; }
>>
>> table.gridBorder2 { border-top: 2px solid black; border-left: 2px 
>> solid black; }
>>
>> table.gridBorder2 th, table.gridBorder2 td { border-bottom: 2px solid 
>> black; border-right: 2px solid black; }
>>
>> .esf div.newPage { border-top: 1px dotted gray; }
>>
>> .esf .doNotPrint { } /* do nothing normally, but we override in 
>> @print so suppress the element */
>>
>> .esf div.pagediv { } /* do nothing, but allows you to style as each 
>> page is wrapped in a div */
>>
>> .esf div.inline { display: inline-block; }
>>
>> .esf span.inlineblock { display: inline-block; }
>>
>> /* The following are generally not useful for a document, but are 
>> used in the auto-rendering of fields, labels, errors, etc. Many of 
>> these can be set via DocumentStyles in Open ESF. */
>>
>> /* For the Field Label rendering */
>>
>> .esf label.normal { }
>>
>> .esf label.normal-error { color: red; font-weight: bold; 
>> background-color: yellow; }
>>
>> .esf label.small { font-size: 8pt; }
>>
>> .esf label.small-error { font-size: 8pt; color: red; font-weight: 
>> bold; background-color: yellow; }
>>
>> .esf span.viewFieldData { width: inherit; } /* when viewing field 
>> data -- not in input mode */
>>
>> .esf span.viewFieldData-error { font-weight: bold; font-style: 
>> italic; background-color: pink; border: 2px dashed red; } /* when 
>> viewing data that was not known -- not in input mode */
>>
>> .esf span.labelFieldArea { display: inline-block; } /* sets the width 
>> for the label and field area */
>>
>> .esf span.labelFieldArea span.labelAreaStacked { display: block; 
>> white-space: nowrap; }
>>
>> .esf span.labelFieldArea span.labelAreaRightStacked { display: block; 
>> text-align: right; white-space: nowrap; }
>>
>> .esf span.labelFieldArea span.labelAreaCenterStacked { display: 
>> block; text-align: center; white-space: nowrap; }
>>
>> .esf span.labelFieldArea span.labelArea { display: inline-block; 
>> white-space: nowrap; }
>>
>> .esf span.labelFieldArea span.labelAreaRight { display: inline-block; 
>> text-align: right; white-space: nowrap; }
>>
>> .esf span.labelFieldArea span.labelAreaCenter { display: 
>> inline-block; text-align: center; white-space: nowrap; }
>>
>> .esf span.labelFieldArea span.fieldAreaStacked { display: block; 
>> width: 100%; }
>>
>> .esf span.labelFieldArea span.fieldAreaLeftStacked { display: block; 
>> width: 100%; text-align: left; }
>>
>> .esf span.labelFieldArea span.fieldAreaRightStacked { display: block; 
>> width: 100%; text-align: right; }
>>
>> .esf span.labelFieldArea span.fieldAreaCenterStacked { display: 
>> block; width: 100%; text-align: center; }
>>
>> .esf span.labelFieldArea span.fieldArea { display: inline-block; 
>> width: 100%; }
>>
>> .esf span.labelFieldArea span.fieldAreaLeft { display: inline-block; 
>> width: 100%; text-align: left; }
>>
>> .esf span.labelFieldArea span.fieldAreaRight { display: inline-block; 
>> width: 100%; text-align: right; }
>>
>> .esf span.labelFieldArea span.fieldAreaCenter { display: 
>> inline-block; width: 100%; text-align: center; }
>>
>> .esf span.labelFieldArea span.fieldAreaStackedAuto { display: block; 
>> width: auto; }
>>
>> .esf span.labelFieldArea span.fieldAreaLeftStackedAuto { display: 
>> block; width: auto; text-align: left; }
>>
>> .esf span.labelFieldArea span.fieldAreaRightStackedAuto { display: 
>> block; width: auto; text-align: right; }
>>
>> .esf span.labelFieldArea span.fieldAreaCenterStackedAuto { display: 
>> block; width: auto; text-align: center; }
>>
>> .esf span.labelFieldArea span.fieldAreaAuto { display: inline-block; 
>> width: auto; }
>>
>> .esf span.labelFieldArea span.fieldAreaLeftAuto { display: 
>> inline-block; width: auto; text-align: left; }
>>
>> .esf span.labelFieldArea span.fieldAreaRightAuto { display: 
>> inline-block; width: auto; text-align: right; }
>>
>> .esf span.labelFieldArea span.fieldAreaCenterAuto { display: 
>> inline-block; width: auto; text-align: center; }
>>
>> .esf span.fieldArea { display: inline-block; }
>>
>> .esf span.fieldAreaLeft { display: inline-block; text-align: left; }
>>
>> .esf span.fieldAreaRight { display: inline-block; text-align: right; }
>>
>> .esf span.fieldAreaCenter { display: inline-block; text-align: center; }
>>
>> .esf span.fieldAreaAuto { display: inline; }
>>
>> /* Auto widths do not make sense really with alignment as the field 
>> should be no bigger than the contents; we'll keep it inline-blocked */
>>
>> .esf span.fieldAreaLeftAuto { display: inline-block; text-align: left; }
>>
>> .esf span.fieldAreaRightAuto { display: inline-block; text-align: 
>> right; }
>>
>> .esf span.fieldAreaCenterAuto { display: inline-block; text-align: 
>> center; }
>>
>> /* For signature/initials display */
>>
>> .esf .signature, .esf .signature input { font-family: 'Pacifico', 
>> 'Bradley Hand ITC', 'Lucida Handwriting', 'Comic Sans MS', cursive; 
>> font-size: 14pt; color: blue; white-space: nowrap; }
>>
>> .esf div.signatureBlock { border: 3px solid #9899c4; border-radius: 
>> 10px; background-color: #efffff; padding: 0px 3px 3px 12px; width: 
>> 720px; page-break-inside: avoid; }
>>
>> .esf div.signatureBlock p.signatureHeader { font-size: 11pt; 
>> font-weight: bold; text-decoration: underline; margin-bottom: 0px; }
>>
>> .esf .signatureMetadata { font-size: 8pt; font-family: 'Courier New', 
>> Courier, monospace; white-space: nowrap; }
>>
>> /* For optional/required/error input fields; uses span.viewFieldData 
>> for showing the data when in non-edit mode */
>>
>> .esf input.required { background-color: #FFFFE7; font-weight: bold; 
>> border: 1px solid #7F9DB9; width: inherit; }
>>
>> .esf input.optional { background-color: white; font-weight: bold; 
>> border: 1px solid #7F9DB9; width: inherit; }
>>
>> .esf input.error { background-color: #FFC0CB; font-weight: bold; 
>> border: 1px solid red; width: inherit; }
>>
>> .esf select.required { background-color: #FFFFE7; font-weight: bold; 
>> border: 1px solid #7F9DB9; width: inherit; }
>>
>> .esf select.optional { background-color: white; font-weight: bold; 
>> border: 1px solid #7F9DB9; width: inherit; }
>>
>> .esf select.error { background-color: #FFC0CB; font-weight: bold; 
>> border: 1px solid red; width: inherit; }
>>
>> .esf textarea.required { background-color: #FFFFE7; font-weight: 
>> bold; border: 1px solid #7F9DB9; width: inherit; }
>>
>> .esf textarea.optional { background-color: white; font-weight: bold; 
>> border: 1px solid #7F9DB9; width: inherit; }
>>
>> .esf textarea.error { background-color: #FFC0CB; font-weight: bold; 
>> border: 1px solid red; width: inherit; }
>>
>> /* Special override for optional checkboxes to not have a border 
>> around them */
>>
>> .esf input[type="checkbox"].required { border: 0 none !important; 
>> outline-color: #FFFFE7; outline-style: solid; outline-width: medium; }
>>
>> .esf input[type="checkbox"].optional { border: 0 none !important; }
>>
>> .esf input[type="checkbox"].error { outline: 1px solid red; }
>>
>> /* Special override for optional radio to not have a border around 
>> them */
>>
>> .esf input[type="radio"].required { border: 0 none !important; 
>> outline-color: #FFFFE7; outline-style: solid; outline-width: medium; }
>>
>> .esf input[type="radio"].optional { border: 0 none !important; }
>>
>> .esf input[type="radio"].error { outline: 1px solid red; }
>>
>> .esf input[type="radio"] { margin-bottom: 3px; } /* push it up a bit 
>> so fits with label better */
>>
>> /* For buttons */
>>
>> .esf p.buttons { margin-top: 2em; margin-left: 2em; }
>>
>> .esf p.buttons input { margin-right: 2em; font-size: 1.1em; padding: 
>> 5px 10px; margin-top: 5px; }
>>
>> .esf p.buttons input.caution { color: #FF8000; }
>>
>> .esf p.buttons input.preferredFlow { font-weight: bold; color: green; 
>> font-size: 1.3em; padding: 8px 15px; }
>>
>> .esf p.extraButtons { text-align: right; margin-top: -3em; }
>>
>> .esf p.extraButtons input { color: blue; font-size: 0.6em; padding: 
>> 2px 3px; margin-right: 1em; }
>>
>> .esf div.documentAndPageNumbersInfo { font-family: 'Courier New', 
>> Courier, monospace; font-size: 8pt; text-align: right; color: 
>> lightgray; }
>>
>> /* For image overlays */
>>
>> .esf div.imageOverlay { position: relative; display: inline-block; }
>>
>> .esf div.imageOverlay img { margin: 0; padding: 0; }
>>
>> .esf div.imageOverlay span.imageOverlayFieldArea { position: 
>> absolute; margin: 0; padding: 0; }
>>
>> .esf div.imageOverlay span.imageOverlayFieldArea input[type="radio"] 
>> { margin: 0; padding: 0; }
>>
>> .esf div.imageOverlay span.imageOverlayFieldArea 
>> input[type="checkbox"] { margin: 0; padding: 0; }
>>
>> .esf input.small { font-size: 8pt; }
>>
>> .esf input.upload { color: green; }
>>
>> /* For file uploads of images displayed inline */
>>
>> .esf img.fileUploadInlineImage200 { max-width: 200px; border: 2px 
>> solid black; page-break-inside: avoid; }
>>
>> .esf img.fileUploadInlineImage400 { max-width: 400px; border: 2px 
>> solid black; page-break-inside: avoid; }
>>
>> .esf img.fileUploadInlineImage600 { max-width: 800px; border: 2px 
>> solid black; page-break-inside: avoid; }
>>
>> .esf img.fileUploadInlineImage800 { max-width: 800px; border: 2px 
>> solid black; page-break-inside: avoid; }
>>
>> /* For standard display of ErrorEntry[] arrays from Errors */
>>
>> .esf table.errorEntryArea { margin-left: 1em; border: 1px solid 
>> #FBD777; border-radius: 5px; background-color: #FDE8A5; width: 95%; 
>> padding-top: 2px; padding-bottom: 2px; }
>>
>> .esf ul.errorEntryArea { padding-left: 20px; }
>>
>> .esf li.error-ErrorEntry { list-style-type: circle; font-size: 1em; 
>> font-weight: bold; color: red; margin-left: 0px; margin-right: 1em; }
>>
>> .esf li.warning-ErrorEntry { list-style-type: circle; font-size: 1em; 
>> font-weight: bold; color: blue; margin-left: 0px; margin-right: 1em; }
>>
>> .esf li.success-ErrorEntry { list-style-type: circle; font-size: 1em; 
>> font-weight: bold; color: green; margin-left: 0px; margin-right: 1em; }
>>
>> .esf li.info-ErrorEntry { list-style-type: circle; font-size: 1em; 
>> font-weight: bold; color: black; margin-left: 0px; margin-right: 1em; }
>>
>> /* Used for multi-line reports to separate them like "greenbar paper" 
>> of old */
>>
>> .esf .bgGreenbarLight { background-color: transparent; }
>>
>> .esf .bgGreenbarDark { background-color: #E8E6E6; }
>>
>> .esf span.jspfooter { font-size: 8pt; color: gray; }
>>
>> .esf div.jspErrorPageMessage { margin-left: 1em; width: 700px; 
>> font-weight: bold; background-color: pink; border: 1px solid black; 
>> border-radius: 10px; padding: 0px 1em 0px 1em; }
>>
>> @media print {
>>
>> ? body.esf { margin: 0; padding: 0; font-size: 80% !important; }
>>
>> ? .esf div.newPage { border-top: none; page-break-after: always; }
>>
>> ? .esf a.showURL:link:after, a.showURL:visited:after { content: " (" 
>> attr(href) ")"; font-size: 80%; }
>>
>> ? .esf .doNotPrint { display: none; }
>>
>> }
>>
>> /* Begin document style id: 9a000404-5f56-4a1c-ad4a-be6382c67d97, 
>> version id: 86f339d5-81e2-4117-95c2-8f747f5a6fe3 */
>>
>> body.esf { font-family: Calibri, Arial, Helvetica, sans-serif; 
>> font-size: 11pt;??? }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 span.signature { 
>> font-family: Pacifico, cursive; font-size: 14pt; color: blue; 
>> font-style: normal; font-weight: normal; font-variant: normal; 
>> text-transform: inherit;? }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 span.signature input { 
>> font-family: Pacifico, cursive; font-size: 14pt; color: blue; 
>> font-style: normal; font-weight: normal; font-variant: normal; 
>> text-transform: inherit;? }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 span.viewFieldData {????? }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 
>> input[type='checkbox'].required { border: 0 none !important; 
>> outline-color: #FFFFE7; outline-style: solid; outline-width: medium; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 
>> input[type='radio'].required { border: 0 none !important; 
>> outline-color: #FFFFE7; outline-style: solid; outline-width: medium; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 input.required {??? 
>> font-style: normal; font-weight: bold; font-variant: normal; 
>> text-transform: inherit; background-color: #FFFFE7; border: 1px solid 
>> #7F9DB9; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 select.required {??? 
>> font-style: normal; font-weight: bold; font-variant: normal; 
>> text-transform: inherit; background-color: #FFFFE7; border: 1px solid 
>> #7F9DB9; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 textarea.required {??? 
>> font-style: normal; font-weight: bold; font-variant: normal; 
>> text-transform: inherit; background-color: #FFFFE7; border: 1px solid 
>> #7F9DB9; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 input.optional {??? 
>> font-style: normal; font-weight: bold; font-variant: normal; 
>> text-transform: inherit; background-color: white; border: 1px solid 
>> #7F9DB9; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 select.optional {??? 
>> font-style: normal; font-weight: bold; font-variant: normal; 
>> text-transform: inherit; background-color: white; border: 1px solid 
>> #7F9DB9; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 textarea.optional {??? 
>> font-style: normal; font-weight: bold; font-variant: normal; 
>> text-transform: inherit; background-color: white; border: 1px solid 
>> #7F9DB9; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 
>> input[type='checkbox'].error { border: 0 none !important; outline: 
>> 1px solid red; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 input[type='radio'].error 
>> { border: 0 none !important; outline: 1px solid red; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 input.error {??? 
>> font-style: normal; font-weight: bold; font-variant: normal; 
>> text-transform: inherit; background-color: #FFC0CB; border: 1px solid 
>> red; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 select.error {??? 
>> font-style: normal; font-weight: bold; font-variant: normal; 
>> text-transform: inherit; background-color: #FFC0CB; border: 1px solid 
>> red; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 textarea.error {??? 
>> font-style: normal; font-weight: bold; font-variant: normal; 
>> text-transform: inherit; background-color: #FFC0CB; border: 1px solid 
>> red; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 label.normal {????? }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 label.normal-error {?? 
>> color: red; font-style: normal; font-weight: bold; font-variant: 
>> normal; text-transform: inherit; background-color: yellow; }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 label.small {? font-size: 
>> 8pt;??? }
>>
>> .esf .X86f339d5_81e2_4117_95c2_8f747f5a6fe3 label.small-error {? 
>> font-size: 8pt; color: red; font-style: normal; font-weight: bold; 
>> font-variant: normal; text-transform: inherit; background-color: 
>> yellow; }
>>
>> /* End document style */
>>
>> </style>
>>
>> <script type="text/javascript">
>>
>> (function() {
>>
>> ? // If not defined yet, ensure our top "JavaScript namespace" 
>> variable 'esf' is created.
>>
>> ? if ( typeof esf == "undefined" ) {
>>
>> ? esf = {
>>
>> ? version: {
>>
>> ? major: 19, minor: 1, update: '19',
>>
>> ? toString: function(){
>>
>> ? with(esf.version){
>>
>> ? return major + "." + minor + "." + update;
>>
>> ? }
>>
>> ? }
>>
>> ? },
>>
>> ? appname: 'Open eSignForms',
>>
>> ? htmlCopyright: '&copy; 2019 Yozons, Inc.',
>>
>> ? textCopyright: 'Copyright (c) 2009-2019 Yozons, Inc.'
>>
>> ? };
>>
>> ? esf.getRelease = function() {
>>
>> ? return this.appname + " " + this.version.toString();
>>
>> ? };
>>
>> ? if ( typeof console != "undefined") console.log(esf.getRelease() + 
>> ' - ' + esf.textCopyright);
>>
>> ? esf.saveScrollPosition = function(elem) {
>>
>> ? var currLeft = window.pageXOffset || 
>> document.documentElement.scrollLeft;
>>
>> ? var currTop? = window.pageYOffset || 
>> document.documentElement.scrollTop;
>>
>> ? elem.form.ESF_PAGE_SCROLLLEFT.value = currLeft;? // form field name 
>> must match DocumentPageBean.HIDDEN_PAGE_SCROLLLEFT
>>
>> ? elem.form.ESF_PAGE_SCROLLTOP.value? = currTop;?? // form field name 
>> must match DocumentPageBean.HIDDEN_PAGE_SCROLLTOP
>>
>> ? }
>>
>> ? esf.autoPost = function(inputField) {
>>
>> ? esf.confirmOnPageUnloadMessage = null; // do not block leaving page 
>> for autopost
>>
>> ? esf.hideAllSubmitInputFields();
>>
>> ? inputField.form.ESF_AUTO_POST_FIELD_ID.value = inputField.id; // 
>> form field name must match DocumentPageBean.HIDDEN_AUTO_POST_FIELD_ID
>>
>> ? esf.saveScrollPosition(inputField);
>>
>> ? inputField.form.submit();
>>
>> ? };
>>
>> ? esf.blockEnterKeyViaInputFields = function(e) {
>>
>> ? var evt = e || window.event;
>>
>> ? var node = (evt.target) ? evt.target : ((evt.srcElement) ? 
>> evt.srcElement : null);
>>
>> ? if ((evt.keyCode == 13) && (node.type=="text")) {
>>
>> ? return false;
>>
>> ? }
>>
>> ? };
>>
>> ? esf.checkConfirmOnPageUnload = function(confirm,durationMsec) {
>>
>> ? if (! confirm) {
>>
>> ? window.onbeforeunload = null;
>>
>> ? }
>>
>> ? if ( durationMsec && durationMsec > 0 )
>>
>> esf.hideAllSubmitInputFieldsTemporarily(durationMsec);
>>
>> ? else
>>
>> ? esf.hideAllSubmitInputFields();
>>
>> ? };
>>
>> ? // For links, we don't hide buttons and we don't clear the unload 
>> unless requested AND the target is _top or _self (or no target set)
>>
>> ? esf.checkLinkConfirmOnPageUnload = function(confirm,atag) {
>>
>> ? if (! confirm && (atag.target == "_top" || atag.target == "_self" 
>> || atag.target == "") ) {
>>
>> ? window.onbeforeunload = null;
>>
>> ? }
>>
>> ? };
>>
>> ? // Default is no message to display on page unload
>>
>> ? esf.confirmOnPageUnloadMessage = null;
>>
>> ? esf.confirmOnPageUnload = function(e) {
>>
>> ? e = e || window.event;
>>
>> ????????? if ( esf.confirmOnPageUnloadMessage ) {
>>
>> ????????? if (e) {
>>
>> ????????? e.returnValue = esf.confirmOnPageUnloadMessage;
>>
>> ????????? }
>>
>> ????????????? return esf.confirmOnPageUnloadMessage;
>>
>> ????????? }
>>
>> ? };
>>
>> ? esf.hideAllSubmitInputFields = function() {
>>
>> ??? if ( document.getElementsByTagName ) {
>>
>> ??? var inputFields = document.getElementsByTagName("input");
>>
>> ??? for( var i=0; i < inputFields.length; ++i ) {
>>
>> ????? if ( inputFields[i].type == "submit" )
>>
>> ????????? esf.makeInvisible(inputFields[i]);
>>
>> ??? }
>>
>> ??? var buttonFields = document.getElementsByTagName("button");
>>
>> ??? for( var i=0; i < buttonFields.length; ++i ) {
>>
>> ??? esf.makeInvisible(buttonFields[i]);
>>
>> ??? }
>>
>> ??? return true;
>>
>> ??? }
>>
>> ? };
>>
>> ? esf.showAllSubmitInputFields = function() {
>>
>> ??? if ( document.getElementsByTagName ) {
>>
>> ????? var inputFields = document.getElementsByTagName("input");
>>
>> ??? for( var i=0; i < inputFields.length; ++i ) {
>>
>> ????? if ( inputFields[i].type == "submit" )
>>
>> ????????? esf.makeVisible(inputFields[i]);
>>
>> ??? }
>>
>> ??? var buttonFields = document.getElementsByTagName("button");
>>
>> ??? for( var i=0; i < buttonFields.length; ++i ) {
>>
>> ??? esf.makeVisible(buttonFields[i]);
>>
>> ??? }
>>
>> ??? return true;
>>
>> ??? }
>>
>> ? };
>>
>> ? esf.hideAllSubmitInputFieldsTemporarily = function(durationMsec) {
>>
>> ? esf.hideAllSubmitInputFields();
>>
>> ? setTimeout( esf.showAllSubmitInputFields, durationMsec );
>>
>> ? };
>>
>> ? esf.displayById = function(id) {
>>
>> ? if ( document.getElementById && document.getElementById(id) )
>>
>> ? esf.display(document.getElementById(id));
>>
>> ? };
>>
>> ? esf.display = function(elem) {
>>
>> ? if ( elem && elem.style )
>>
>> ? elem.style.display = "block";
>>
>> ? };
>>
>> ? esf.hideById = function(id) {
>>
>> ? if ( document.getElementById && document.getElementById(id) )
>>
>> ? esf.hide(document.getElementById(id));
>>
>> ? };
>>
>> ? esf.hide = function(elem) {
>>
>> ? if ( elem && elem.style )
>>
>> ? elem.style.display = "none";
>>
>> ? };
>>
>> ? esf.makeVisibleById = function(id) {
>>
>> ? if ( document.getElementById && document.getElementById(id) )
>>
>> ? esf.makeVisible(document.getElementById(id));
>>
>> ? };
>>
>> ? esf.makeVisible = function(elem) {
>>
>> ??? if ( elem && elem.style )
>>
>> ??? elem.style.visibility = 'visible';
>>
>> ? };
>>
>> ? esf.makeInvisibleById = function(id) {
>>
>> ? if ( document.getElementById && document.getElementById(id) )
>>
>> ? esf.makeInvisible(document.getElementById(id));
>>
>> ? };
>>
>> ? esf.makeInvisible = function(elem) {
>>
>> ??? if ( elem && elem.style )
>>
>> ??? elem.style.visibility = 'hidden';
>>
>> ? };
>>
>> ? esf.makeTemporarilyInvisible = function(elem, durationMsec) {
>>
>> ? esf.makeInvisible(elem);
>>
>> ????? setTimeout( function(){esf.makeVisible(elem);}, durationMsec );
>>
>> ? };
>>
>> ? esf.ensureTopWindow = function() {
>>
>> ??? if (window != window.top)
>>
>> ? top.location.href = location.href;
>>
>> ? };
>>
>> ? esf.getElementsByFieldName = function(fieldName) {
>>
>> ??? if ( document.getElementsByName ) {
>>
>> ??? return document.getElementsByName(fieldName.toLowerCase()); // 
>> Field names are all lowercase in the HTML DOM
>>
>> ??? }
>>
>> ??? return []; // not really an empty node list, but an empty array 
>> so it has a 'length' property to query before accessing
>>
>> ? };
>>
>> ? esf.getElementByFieldName = function(fieldName) {
>>
>> ??? var elemNL = esf.getElementsByFieldName(fieldName);
>>
>> ??? return elemNL.length > 0 ? elemNL[0] : null;
>>
>> ? };
>>
>> ? esf.setAllCheckboxesByName = function(name,b) {
>>
>> ??? var checkboxes = esf.getElementsByFieldName(name);
>>
>> ??? for( var i=0; i < checkboxes.length; ++i ) {
>>
>> ????? if ( checkboxes[i].type == "checkbox" )
>>
>> ????????? checkboxes[i].checked = b;
>>
>> ??? }
>>
>> ? };
>>
>> ? esf.checkAllCheckboxesByName = function(name) {
>>
>> ????? esf.setAllCheckboxesByName(name,true);
>>
>> ? };
>>
>> ? esf.uncheckAllCheckboxesByName = function(name) {
>>
>> ????? esf.setAllCheckboxesByName(name,false);
>>
>> ? };
>>
>> ? /* Expects two radiobuttons to be laid out as [] Yes [] No order -- 
>> can also be stacked as long as Yes is first */
>>
>> ? esf.setupDisplayIfYesNoRadioButtonGroupIsYes = 
>> function(yesNoRadioButtonGroupName,elemIdToShowIfYes,currentRadioButtonGroupFieldValue) 
>> {
>>
>> ??? var rbYesNoElems = 
>> document.getElementsByName(yesNoRadioButtonGroupName.toLowerCase());
>>
>> ??? if ( rbYesNoElems && rbYesNoElems.length == 2 ) { /* radio 
>> buttons will only exist in EDIT mode */
>>
>> ??? rbYesNoElems[0].onclick = function() { 
>> esf.displayById(elemIdToShowIfYes); }; /* yes rb */
>>
>> ??? rbYesNoElems[1].onclick = function() { 
>> esf.hideById(elemIdToShowIfYes); }; /* no rb */
>>
>> ??? }
>>
>> ??? var lowerValue = currentRadioButtonGroupFieldValue.toLowerCase();
>>
>> ??? if ( lowerValue.startsWith('y') || lowerValue.startsWith('t') || 
>> lowerValue == '1' )
>>
>> ??????? esf.displayById(elemIdToShowIfYes);
>>
>> ??? else
>>
>> ??????? esf.hideById(elemIdToShowIfYes);
>>
>> ? };
>>
>> ? /* Expects two radiobuttons to be laid out as [] Yes [] No order -- 
>> can also be stacked as long as Yes is first */
>>
>> ? esf.setupDisplayIfYesNoRadioButtonGroupIsNo = 
>> function(yesNoRadioButtonGroupName,elemIdToShowIfNo,currentRadioButtonGroupFieldValue) 
>> {
>>
>> ??????? var rbYesNoElems = 
>> document.getElementsByName(yesNoRadioButtonGroupName.toLowerCase());
>>
>> ??? if ( rbYesNoElems && rbYesNoElems.length == 2 ) { /* radio 
>> buttons will only exist in EDIT mode */
>>
>> ??? rbYesNoElems[0].onclick = function() { 
>> esf.hideById(elemIdToShowIfNo); }; /* yes rb */
>>
>> ??? rbYesNoElems[1].onclick = function() { 
>> esf.displayById(elemIdToShowIfNo); }; /* no rb */
>>
>> ??? }
>>
>> ??? var lowerValue = currentRadioButtonGroupFieldValue.toLowerCase();
>>
>> ??? if ( lowerValue.startsWith('n') || lowerValue.startsWith('f') || 
>> lowerValue == '0' )
>>
>> ??? esf.displayById(elemIdToShowIfNo);
>>
>> ??? else
>>
>> ??? esf.hideById(elemIdToShowIfNo);
>>
>> ????? };
>>
>> ? esf.setupDisplayIfChecked = 
>> function(checkboxName,elemIdToShowIfChecked,currentCheckboxFieldValue,checkboxValueWhenChecked) 
>> {
>>
>> ??? var cbElems = document.getElementsByName(checkboxName.toLowerCase());
>>
>> ??? if ( cbElems && cbElems.length == 1 ) { /* checkboxes will only 
>> exist in EDIT mode */
>>
>> ??? cbElems[0].onchange = function() {
>>
>> ??? if ( this.checked )
>>
>> ??? esf.displayById(elemIdToShowIfChecked);
>>
>> ??? else
>>
>> ??? esf.hideById(elemIdToShowIfChecked);
>>
>> ??? };
>>
>> ??? }
>>
>> ??? if ( currentCheckboxFieldValue == checkboxValueWhenChecked )
>>
>> ??????? esf.displayById(elemIdToShowIfChecked);
>>
>> ??? else
>>
>> ??????? esf.hideById(elemIdToShowIfChecked);
>>
>> ? };
>>
>> ? esf.containsSpace = function(s) {
>>
>> ? if ( s == null )
>>
>> ? return false;
>>
>> ? i = 0;
>>
>> ? while( i < s.length ) {
>>
>> ? if ( s.charAt(i) == ' ' )
>>
>> ? return true;
>>
>> ? ++i;
>>
>> ? }
>>
>> ? return false;
>>
>> ? };
>>
>> ? esf.isOnlyNumbers = function(s) {
>>
>> ? if ( s == null )
>>
>> ? return false;
>>
>> ? var i = 0;
>>
>> ? while( i < s.length ) {
>>
>> ? if ( "0123456789".indexOf(s.charAt(i)) < 0 )
>>
>> ? return false;
>>
>> ? i++;
>>
>> ? }
>>
>> ? return true;
>>
>> ? };
>>
>> ? // Trims whitespace from the front and end of a string
>>
>> ? esf.trimSpace = function(s) {
>>
>> ? if ( s == null || s.length == 0 )
>>
>> ? return s;
>>
>> ? var beginIndex = 0;
>>
>> ? var endIndex?? = s.length - 1;
>>
>> ? while( beginIndex < s.length && s.charAt(beginIndex) == ' ' )
>>
>> ? ++beginIndex;
>>
>> ? while( endIndex >= 0 && s.charAt(endIndex) == ' ' )
>>
>> ? --endIndex;
>>
>> ? ++endIndex;
>>
>> ? if ( beginIndex >= endIndex )
>>
>> ? return '';
>>
>> ? return s.substring(beginIndex,endIndex);
>>
>> ? };
>>
>> ? // Opens a window -- for a given name, width and height
>>
>> ? esf.showWindow = function(url,name,width,height) {
>>
>> ? var win = 
>> window.open(url,name,'width='+width+',height='+height+',scrollbars=yes,resizable=yes');
>>
>> ? win.focus();
>>
>> ? return false;
>>
>> ? };
>>
>> ? }
>>
>> })();
>>
>> /* Workaround for IE, the only browser in the world that doesn't 
>> support standard JavaScript String.startsWith() */
>>
>> if ( ! String.prototype.startsWith ) {
>>
>> ? String.prototype.startsWith = function(searchString, position) {
>>
>> ? position = position || 0;
>>
>> ? return this.indexOf(searchString, position) === position;
>>
>> ? };
>>
>> }
>>
>> </script>
>>
>> </head>
>>
>> <body class="esf">
>>
>> <div id="X52248c28_187e_43f0_8de8_98357fa63654" 
>> class="X86f339d5_81e2_4117_95c2_8f747f5a6fe3 pagediv">
>>
>> <div id="ESF_TEST_TRANSACTION_HEADER" style="background-color: pink; 
>> text-align: center; width: 100%;">* * * ? T E S T ? T R A N S A C T I 
>> O N ? * * *</div>
>>
>> <div id="X62edfd59_be00_435a_9bd5_583cc84d220a" class="Page1">
>>
>> <p><span class="labelFieldArea bottom" style="width: 10em;"><span 
>> class="labelAreaStacked"><label class="small">Current 
>> Date:?</label></span><span class="bottom fieldArea viewFieldData " 
>> >January 30, 2019</span></span></p>
>>
>> </div>
>>
>> </div>
>>
>> </body>
>>
>> </html>
>>
>> ]]><Signaturexmlns="http://www.w3.org/2000/09/xmldsig#"Id="OpenESignForms_Seal"><SignedInfo><CanonicalizationMethodAlgorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><SignatureMethodAlgorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><ReferenceId="Payload_Reference_ID"URI=""><Transforms><TransformAlgorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></Transforms><DigestMethodAlgorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><DigestValue>82PhK9E99GBG/pq5PSLRIGqpz0QbwwN8wlYQJsR3e4r5g1M8yhD3J0XhxNcMHmJIyyyb7yzo947O
>>
>> y2T9M/EHQw==</DigestValue></Reference><ReferenceURI="#KeyInfo_ID"><DigestMethodAlgorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><DigestValue>zqVVsv0tdx1Fp/c1rrj5b7aKdVtwtq2u0R0RsUnwCja3aMXGjsfqA68lZawt5wCtZqLWsKllPUom
>>
>> Z5quVeBVBg==</DigestValue></Reference><ReferenceURI="#QualifyingProperties_ID"><DigestMethodAlgorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><DigestValue>AKs1UqheswdoyC7xfofmnZoCOF8dmFISw0Cnqfp9n294EgvP5dnZAWWXH+yspvhnNr3qOJmcaP3N
>>
>> ZYoN6rG5XA==</DigestValue></Reference><ReferenceURI="#OpenESignForms_Seal_ID"><DigestMethodAlgorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><DigestValue>PzDq2Q3GpkgsnMmD//3bp5q+IksCxpR106yL1hx+WdxNvZWeAdT3SFAoHgLZtx4KL814iqLbiL5U
>>
>> kwwmI2q8DA==</DigestValue></Reference></SignedInfo><SignatureValue>ID9zJVDWmIjJzv2TWdq3RjZ4MdF3+gX2LX2du7uRw0A2BJ7u8DAg33Wzlg0EnGNyOFC/P8obaegE
>>
>> xCaomRhZXqrLdCoyobe5zWxAFZ+cEHvUY4IwZKdf06i8UEgWiREdHTLfmqqbrhWrnXSnyFoSzAR3
>>
>> pn4WssvP4LlJqoMPVQfHtO2aPJQpBBbnQe9wa8K0DgEpAy3ge6OwTtOZ48F27AweZPnFQOBhcmw4
>>
>> Rfsri9CmZKUWI46RmLuSBv5uyxSwaZIX88uGPd4bG2zXcHd2VBxDyKblpGgIU+xcG+nxuSYNN8Y6
>>
>> rs5o9/XoMM6T8x8LTdNWIgMRf11VhJ1bCh6uF8nEi/QYnV5GcRys/14a8J1oq7l/RNwEk1rMU1m/
>>
>> VWDWhQT591S8hD4ZCVx7tokHdqtPg7hGHBbNdpcDYDKAhwRm3PJJBJ9XBHTgByrxnCqVk1W7D50f
>>
>> bSiITGvsOIp3ooX3wsq44zv/GVl6BamUPMLhgDq30YZmMNDobJsZxY+CoxQPINfv325R4solQ6s0
>>
>> WXqg5RzHHjRTfTK6uNNX931iCb9o3HzKZhtyfZcLygUY69og0etvVpUXjMc2m590eUFUs14ekKwU
>>
>> hvB8rN0Qz+FVFH/jwR7AsNgDwE2KGaHEgypEOG5m3vLfLlJXP9ocGuCTp8IpOetx3GAndDFmizU=</SignatureValue><KeyInfoId="KeyInfo_ID"><KeyName>021eddcd-ebd0-4603-8b26-24b3f7fee682</KeyName><KeyValue><RSAKeyValue><Modulus>iSEKAXeyDOq1RKCwypjN5iuU2uR//YM4ssMBGBCtfpq7eF6pXm0rU5Zz4LnmoptUyu4IcnrStgRr
>>
>> JP3NPOeHgibR8i/Ef9frzd4rCwX2JpY3tztCGYByzk93ln7tzRYnMug9q0IVk6Far7JxBIuMy/eg
>>
>> LOyptCZGnRU8wV6D+gydsdoFsaR+zghMtBmoZ8sArGd81rzq28B3NDdqrd4camU7viI+5mMTRGJn
>>
>> UtBzU/4p7kxv2gePzUc2vJ76+8I1eUGbqc7Co12q8vS+wGpQ4a0lUiWJwj7BRXR21oPz+Qo5fiqb
>>
>> a/mSo0gv11s3T2oHTTzWSyvTPb2wbwyBSFAVVaoqJ0g01UEjU2Lv2RkTi/YZpyyPPUDh4OA1KMfX
>>
>> f3M7wxzS0+tJFfE4O4ELsaYlcRElVIor1y98LPKmqWgTg0olfU8H00igjbJdU37SzyqygqNadZlC
>>
>> ocTtaMvveNIkDURAPPZS/Llp1KUm4YY29m+Of0JK0ZoEBLIj5R0uEIpOBe0MWhH4d8l5mxn8IKpR
>>
>> chGgxgJ4P7bNpPQmPUH2rpFukV0NIPe946X7oJE/NubjePyQxpQwwE6zzavz0rf9s4OQpW7tdG/+
>>
>> fyubGHXq4H/DH4ZZt0KBuIhLfqjEd3mgyzp4waihnkn4bhcRFm8s5UJEuszp6BkD0EHcPfN76Uk=</Modulus><Exponent>AQAB</Exponent></RSAKeyValue></KeyValue><X509Data><X509Certificate>MIIKkDCCCHigAwIBAgIIXjPAnc0XFeIwDQYJKoZIhvcNAQENBQAwgcIxOTA3BgNVBAMMME9wZW5f
>>
>> ZVNpZ25Gb3Jtc19odHRwczovL29wZW4uZXNpZ25mb3Jtcy5jb20vZGVtbzE6MDgGA1UECgwxRGVw
>>
>> bG95bWVudElEL2JiZmU5YmVkLTkxOGQtNDQ2Yi05NTE4LThlYzMwM2JhZmI4MzE8MDoGA1UECwwz
>>
>> U2lnbmF0dXJlS2V5SUQvMDIxZWRkY2QtZWJkMC00NjAzLThiMjYtMjRiM2Y3ZmVlNjgyMQswCQYD
>>
>> VQQGEwJVUzAeFw0xMTA0MTYwMzIxMzhaFw0yMTA0MTYwMzIxMzhaMIHCMTkwNwYDVQQDDDBPcGVu
>>
>> X2VTaWduRm9ybXNfaHR0cHM6Ly9vcGVuLmVzaWduZm9ybXMuY29tL2RlbW8xOjA4BgNVBAoMMURl
>>
>> cGxveW1lbnRJRC9iYmZlOWJlZC05MThkLTQ0NmItOTUxOC04ZWMzMDNiYWZiODMxPDA6BgNVBAsM
>>
>> M1NpZ25hdHVyZUtleUlELzAyMWVkZGNkLWViZDAtNDYwMy04YjI2LTI0YjNmN2ZlZTY4MjELMAkG
>>
>> A1UEBhMCVVMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCJIQoBd7IM6rVEoLDKmM3m
>>
>> K5Ta5H/9gziywwEYEK1+mrt4XqlebStTlnPgueaim1TK7ghyetK2BGsk/c0854eCJtHyL8R/1+vN
>>
>> 3isLBfYmlje3O0IZgHLOT3eWfu3NFicy6D2rQhWToVqvsnEEi4zL96As7Km0JkadFTzBXoP6DJ2x
>>
>> 2gWxpH7OCEy0GahnywCsZ3zWvOrbwHc0N2qt3hxqZTu+Ij7mYxNEYmdS0HNT/inuTG/aB4/NRza8
>>
>> nvr7wjV5QZupzsKjXary9L7AalDhrSVSJYnCPsFFdHbWg/P5Cjl+Kptr+ZKjSC/XWzdPagdNPNZL
>>
>> K9M9vbBvDIFIUBVVqionSDTVQSNTYu/ZGROL9hmnLI89QOHg4DUox9d/czvDHNLT60kV8Tg7gQux
>>
>> piVxESVUiivXL3ws8qapaBODSiV9TwfTSKCNsl1TftLPKrKCo1p1mUKhxO1oy+940iQNREA89lL8
>>
>> uWnUpSbhhjb2b45/QkrRmgQEsiPlHS4Qik4F7QxaEfh3yXmbGfwgqlFyEaDGAng/ts2k9CY9Qfau
>>
>> kW6RXQ0g973jpfugkT825uN4/JDGlDDATrPNq/PSt/2zg5Clbu10b/5/K5sYdergf8Mfhlm3QoG4
>>
>> iEt+qMR3eaDLOnjBqKGeSfhuFxEWbyzlQkS6zOnoGQPQQdw983vpSQIDAQABo4IEhjCCBIIwggIz
>>
>> BgNVHQ4EggIqBIICJjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAIkhCgF3sgzqtUSg
>>
>> sMqYzeYrlNrkf/2DOLLDARgQrX6au3heqV5tK1OWc+C55qKbVMruCHJ60rYEayT9zTznh4Im0fIv
>>
>> xH/X683eKwsF9iaWN7c7QhmAcs5Pd5Z+7c0WJzLoPatCFZOhWq+ycQSLjMv3oCzsqbQmRp0VPMFe
>>
>> g/oMnbHaBbGkfs4ITLQZqGfLAKxnfNa86tvAdzQ3aq3eHGplO74iPuZjE0RiZ1LQc1P+Ke5Mb9oH
>>
>> j81HNrye+vvCNXlBm6nOwqNdqvL0vsBqUOGtJVIlicI+wUV0dtaD8/kKOX4qm2v5kqNIL9dbN09q
>>
>> B0081ksr0z29sG8MgUhQFVWqKidINNVBI1Ni79kZE4v2Gacsjz1A4eDgNSjH139zO8Mc0tPrSRXx
>>
>> ODuBC7GmJXERJVSKK9cvfCzypqloE4NKJX1PB9NIoI2yXVN+0s8qsoKjWnWZQqHE7WjL73jSJA1E
>>
>> QDz2Uvy5adSlJuGGNvZvjn9CStGaBASyI+UdLhCKTgXtDFoR+HfJeZsZ/CCqUXIRoMYCeD+2zaT0
>>
>> Jj1B9q6RbpFdDSD3veOl+6CRPzbm43j8kMaUMMBOs82r89K3/bODkKVu7XRv/n8rmxh16uB/wx+G
>>
>> WbdCgbiIS36oxHd5oMs6eMGooZ5J+G4XERZvLOVCRLrM6egZA9BB3D3ze+lJAgMBAAEwggI3BgNV
>>
>> HSMEggIuMIICKoCCAiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCJIQoBd7IM6rVE
>>
>> oLDKmM3mK5Ta5H/9gziywwEYEK1+mrt4XqlebStTlnPgueaim1TK7ghyetK2BGsk/c0854eCJtHy
>>
>> L8R/1+vN3isLBfYmlje3O0IZgHLOT3eWfu3NFicy6D2rQhWToVqvsnEEi4zL96As7Km0JkadFTzB
>>
>> XoP6DJ2x2gWxpH7OCEy0GahnywCsZ3zWvOrbwHc0N2qt3hxqZTu+Ij7mYxNEYmdS0HNT/inuTG/a
>>
>> B4/NRza8nvr7wjV5QZupzsKjXary9L7AalDhrSVSJYnCPsFFdHbWg/P5Cjl+Kptr+ZKjSC/XWzdP
>>
>> agdNPNZLK9M9vbBvDIFIUBVVqionSDTVQSNTYu/ZGROL9hmnLI89QOHg4DUox9d/czvDHNLT60kV
>>
>> 8Tg7gQuxpiVxESVUiivXL3ws8qapaBODSiV9TwfTSKCNsl1TftLPKrKCo1p1mUKhxO1oy+940iQN
>>
>> REA89lL8uWnUpSbhhjb2b45/QkrRmgQEsiPlHS4Qik4F7QxaEfh3yXmbGfwgqlFyEaDGAng/ts2k
>>
>> 9CY9QfaukW6RXQ0g973jpfugkT825uN4/JDGlDDATrPNq/PSt/2zg5Clbu10b/5/K5sYdergf8Mf
>>
>> hlm3QoG4iEt+qMR3eaDLOnjBqKGeSfhuFxEWbyzlQkS6zOnoGQPQQdw983vpSQIDAQABMA4GA1Ud
>>
>> DwEB/wQEAwIGwDANBgkqhkiG9w0BAQ0FAAOCAgEAaGn/Q+1fjL7N675UYMGuC5EfloDQ3Y+zuYyx
>>
>> FtMrwO3GuvABTf+oKsQc5n7XDgpQVBWlgIHH+LldDhRPQ1a0MPvMzPDL3Ps1K+hJewNhcec6fqXS
>>
>> t+lszt+mnuK6gGKTioTbO6Li1E41WtJ1UhK4br1lsoNkM0E4rB5KUyj0ZmTCSlYlchAzMYLr1Ymc
>>
>> Q5wgAu0lFIpluhd12un9mUWWXouSC+8pI+ZKfPz2lm+PGBDTTp0TsLLWldvLcnEAgbLG4wZvb1za
>>
>> 3EccZWtCX0b5lGjMCajhADiz76GgYZt1fTus1fhoTe6GsJV9lM11NZTEeTPAUE9VvtNGYOaNUl2e
>>
>> S9pE1myNfiBgXNNJ3L4J6d6fGPlHV9rNPzjclfAOn4a1c+7ZBIsvW1znaeaAoeNyCcRPUr9rgKBS
>>
>> L+izvr6w3eYiqjQWozCi2Nw/oTKk1dC32uzD9KRrQ8pAlSDsspic7FJpFqPVuxrvs8z7tXpc6uyB
>>
>> cmaNZN91xowONrPljlbW2jm5AkebDyTMPfxIRcrTybOr/K3nOYEMkV8G/tRli4SRleGr3cUusHd5
>>
>> 47BlUSoncDYywh+4drtCycli2mfph3hjB34qkwbzI8j8iX6PSROH+AGcC0L1MEgRq2Um9+K3iTBA
>>
>> 9zGxY4cvR4vn4VtWcebg9AVMJCwhV85c7l0P0uU=</X509Certificate></X509Data></KeyInfo><Object><QualifyingPropertiesId="QualifyingProperties_ID"><SignedProperties><SignedSignatureProperties><SigningTime>2019-01-30T12:40:46-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormatObjectReference="#Payload_Reference_ID"><Description>document.html</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></Object><Object><SignatureProperties><SignaturePropertyId="OpenESignForms_Seal_ID"Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSealDeploymentHostAddress="104.239.136.116"DeploymentHostName="open.esignforms.com 
>> <http://open.esignforms.com>"DeploymentId="bbfe9bed-918d-446b-9518-8ec303bafb83"SignerAddress="50-46-115-249.evrt.wa.frontiernet.net 
>> <http://50-46-115-249.evrt.wa.frontiernet.net> 
>> (50.46.115.249)"SignerAgent="Mozilla/5.0 (Macintosh; Intel Mac OS X 
>> 10_14_3) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.3 
>> Safari/605.1.15"Timestamp="2019-01-30T12:40:46-08:00"Version="19.1.19_p0129_1657"/></SignatureProperty></SignatureProperties></Object></Signature></snapshot>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190206/b3f20180/attachment-0001.html>

From valerie.peng at oracle.com  Thu Feb  7 22:09:02 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 7 Feb 2019 14:09:02 -0800
Subject: [13] RFR JDK-8216597 "SIGBUS in
 Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047"
Message-ID: <02f7f228-66d1-0ed1-0b5b-760e3e84ddfa@oracle.com>

Hi,

Anyone can help review this fix? More detailed info on cause and fixes 
can be found in the bug report and fix has been verified through mach5 run.

Bug: https://bugs.openjdk.java.net/browse/JDK-8216597

Webrev: http://cr.openjdk.java.net/~valeriep/8216597/webrev.00/

Thanks!
Valerie

From xuelei.fan at oracle.com  Fri Feb  8 16:16:57 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 8 Feb 2019 08:16:57 -0800
Subject: Code Review Request, JDK-8218580, endpoint identification algorithm
 should be case-insensitive
Message-ID: <c1d43346-e18a-fe2b-8c62-847807ab6408@oracle.com>

Hi,

Please review this update:
    http://cr.openjdk.java.net/~xuelei/8218580/webrev.00/

Objects.equals is case-sensitive, and should not be used to recognize 
case-insensitive objects.

Trivial update, no new regression test.

Thanks,
Xuelei

From jamil.j.nimeh at oracle.com  Fri Feb  8 16:46:11 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Fri, 8 Feb 2019 08:46:11 -0800
Subject: Code Review Request, JDK-8218580, endpoint identification
 algorithm should be case-insensitive
In-Reply-To: <c1d43346-e18a-fe2b-8c62-847807ab6408@oracle.com>
References: <c1d43346-e18a-fe2b-8c62-847807ab6408@oracle.com>
Message-ID: <46042528-ceea-7f5b-c40e-cbf8fa073f52@oracle.com>

Looks fine to me.

--Jamil

On 2/8/2019 8:16 AM, Xuelei Fan wrote:
> Hi,
>
> Please review this update:
> ?? http://cr.openjdk.java.net/~xuelei/8218580/webrev.00/
>
> Objects.equals is case-sensitive, and should not be used to recognize 
> case-insensitive objects.
>
> Trivial update, no new regression test.
>
> Thanks,
> Xuelei

From sean.mullan at oracle.com  Fri Feb  8 19:06:03 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 8 Feb 2019 14:06:03 -0500
Subject: RFR 8180569: Refactor sun/security/krb5/ shell tests to plain
 java tests
In-Reply-To: <004DCA97-218A-47A3-B1C2-BE0CAF2C5BEF@oracle.com>
References: <004DCA97-218A-47A3-B1C2-BE0CAF2C5BEF@oracle.com>
Message-ID: <c6033d3c-c701-0e51-15f5-a89106720717@oracle.com>

Looks good to me.

--Sean

On 2/3/19 9:44 AM, Weijun Wang wrote:
> Please take a review at
> 
>     https://cr.openjdk.java.net/~weijun/8180569/webrev.00
> 
> I've combined ktarg.sh, ktmissing.sh, and ktzero.sh into KtabZero.java.
> 
> rcache_usemd5.sh is renamed to ReplayCacheTestProcWithMD5.java. The test has no content and is only used to launch another test. I don't want to combine them because I want different working directory.
> 
> runNameEquals.sh is left as a shell test. It calls quite some *nix commands and is better to stay unchanged.
> 
> Thanks,
> Max
> 

From xuelei.fan at oracle.com  Fri Feb  8 20:26:06 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 8 Feb 2019 12:26:06 -0800
Subject: RFR 8168069 : X509TrustManagerImpl causes ClassLoader leaks with
 unparseable extensions
Message-ID: <dce9b293-0d1f-b249-075e-b0f2776665c9@oracle.com>

Hi,

Could I get the following update reviewed?
    http://cr.openjdk.java.net/~xuelei/8168069/webrev.00/

In the lazy initialization holder in SSLContextImpl, an exception is 
reserved as static in order to check if the holder is initialized 
properly.  If the exception had a strong referent to some object, the 
object will be out of the cycle of garbage collection.

With this update, the original exception is debug logged, and a new 
exception with the same exception message as the original one.

Code cleanup, no new regression test.

Thanks & Regards,
Xuelei

From jay at elastic.co  Fri Feb  8 20:43:25 2019
From: jay at elastic.co (Jay Modi)
Date: Fri, 8 Feb 2019 13:43:25 -0700
Subject: TLSv1.3 HttpsServer endless loop based on client socket i/o shutdown
Message-ID: <CAAcXADf9cy+vwSP36hj5A=dMwhdS8ou_VxDW+_h4x1WrLpD6hw@mail.gmail.com>

Hi,

I've been doing some testing with Apache HttpClient against the
com.sun.net.httpserver.HttpsServer that is included with the JDK and came
across some interesting behavior that occurs when using TLSv1.3, but
TLSv1.2 works normally. If the client manually calls Socket#shutdownOutput
and Socket#shutdownInput before closing the socket, the HttpsServer goes
into an endless loop while trying send the close back to the client. Is
this expected? I've done my best to create a minimal reproducer without
Apache HttpClient[1].

To me this behavior does not seem right and as I mentioned, I did not have
these issues when using TLSv1.2. I'm running on macOS with the following
JDK:
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)

Jay

[1] https://gist.github.com/jaymode/3a6562beaa7ea789b287372bd10d4d1d
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190208/6c8cd43e/attachment.html>

From heiko.jakob at gediegos.de  Sun Feb 10 01:34:30 2019
From: heiko.jakob at gediegos.de (Heiko Jakob)
Date: Sun, 10 Feb 2019 02:34:30 +0100
Subject: ldaps:// ignores alternative DNS names / SNA (Subject Alternative
 Name) certs if hostname != CN name
Message-ID: <2d1a1cfe-bb0d-5f1b-cdb7-c54bfb2d4e44@gediegos.de>

Hi,

connecting to a secure ldap server with a SNA certificate fails with
"javax.naming.CommunicationException: simple bind failed: 
ldap.foo.bar:636 [Root exception is javax.net.ssl.SSLHandshakeException: 
No subject alternative DNS name matching ldap.foo.bar found.]"

The certificate is valid and i've tested it on https on the same machine 
which works flawlessly. The problem does not effect the Oracle JDK/JRE, 
only OpenJDK. I've testen OpenJDK 1.8.0_181, 11.0.1, 11.0.2 and all are 
affected.


With best regards

Heiko Jakob


How to reproduce:
Have a valid certificate for a host named CN "realhost.foo.bar" with 
x509 SNA extension for DNS.1 "realhost.foo.bar" DNS.2 "ldap.foo.bar". 
Use the same certificate for https & ldap on the same host.

Examine the certificate to have CN="realhost.foo.bar" and x509 SNA 
extension for ldap.foo.bar
$ openssl x509 -in my.crt -text -noout | less
Certificate:

...

 ?????? Validity
 ??????????? Not Before: Feb? 8 11:28:53 2019 GMT
 ??????????? Not After : Feb? 7 11:28:53 2024 GMT
 ??????? Subject: C = DE, ST = BW, L = Stuttgart, O = foo.bar, OU = IT 
Department, CN = realhost.foo.bar
...
 ??????????? X509v3 Subject Alternative Name:
 ??????????????? DNS:realhost.foo.bar, DNS:ldap.foo.bar


Run the following small test program to reproduce the problem.

package testSSL;

import java.net.URL;
import java.net.URLConnection;
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.directory.DirContext;
import javax.naming.directory.InitialDirContext;

public final class TestSSL {

 ??? public static void main(String[] args) {
 ??? ??? String url_l = "ldaps://ldap.foo.bar:636";
 ??? ??? String url_h = "https://ldap.foo.bar";

 ??? ??? System.out.println("TestSSL");
 ??? ??? URL url;
 ??? ??? try {
 ??? ??? ??? System.out.println("Test " + url_h);
 ??? ??? ??? url = new URL(url_h);
 ??? ??? ??? URLConnection conn = url.openConnection();
 ??? ??? ??? conn.connect();
 ??? ??? } catch (Exception e) {
 ??? ??? ??? e.printStackTrace();
 ??? ??? ??? System.out.println("Failed " + url_h);
 ??? ??? ??? System.exit(-1);
 ??? ??? }
 ??? ??? System.out.println("https:// OK");


 ??? ??? System.out.println("Test " + url_l);
 ??? ??? Hashtable env = new Hashtable();
 ??? ??? env.put(Context.INITIAL_CONTEXT_FACTORY,
 ??? ??? ??? "com.sun.jndi.ldap.LdapCtxFactory");
 ??? ??? env.put(Context.PROVIDER_URL, url_l);
 ??? ??? env.put(Context.SECURITY_PROTOCOL, "ssl");
 ??? ??? env.put(Context.SECURITY_AUTHENTICATION, "simple");
 ??? ??? env.put(Context.SECURITY_PRINCIPAL, "cn=admin,dc=foo,dc=bar");
 ??? ??? env.put(Context.SECURITY_CREDENTIALS, "mysecret");
 ??? ??? try {
 ??? ??? ??? DirContext ctx = new InitialDirContext(env);
 ??? ??? } catch (Exception e) {
 ??? ??? ??? e.printStackTrace();
 ??? ??? ??? System.out.println("Failed " + url_l);
 ??? ??? ??? System.exit(-1);
 ??? ??? }
 ??? ??? System.out.println("ldaps:// OK");
 ??? }
}

Test it against various JDKs

$ (for j in $(find /opt/java/ -type f -name 'java' 2> /dev/null); do 
echo $j; $j -version; $j -classpath ./ testSSL.TestSSL; echo""; echo 
"##############################################";echo ""; sleep 30; done 
) 2>&1 | tee -a testSSL.out

Reference output from oracle JDK

opt/java/jdk1.8.0_73/bin/java
java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)
TestSSL
https://ldap.foo.bar
https:// OK
ldaps://ldap.foo.bar:636
ldaps:// OK

##############################################
....
##############################################

/opt/java/jdk-11.0.2/bin/java
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
TestSSL
https://ldap.foo.bar
https:// OK
ldaps://ldap.foo.bar:636
javax.naming.CommunicationException: simple bind failed: 
ldap.foo.bar:636 [Root exception is javax.net.ssl.SSLHandshakeException: 
No subject alternative DNS name matching ldap.foo.bar found.]
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
 ??????? at java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2795)
 ??????? at java.naming/com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:320)
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
 ??????? at 
java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:730)
 ??????? at 
java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
 ??????? at 
java.naming/javax.naming.InitialContext.init(InitialContext.java:236)
 ??????? at 
java.naming/javax.naming.InitialContext.<init>(InitialContext.java:208)
 ??????? at 
java.naming/javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
 ??????? at testSSL.TestSSL.main(TestSSL.java:57)
Caused by: javax.net.ssl.SSLHandshakeException: No subject alternative 
DNS name matching ldap.foo.bar found.
 ??????? at 
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
 ??????? at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
 ??????? at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
 ??????? at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
 ??????? at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:642)
 ??????? at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:461)
 ??????? at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:361)
 ??????? at 
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
 ??????? at 
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
 ??????? at 
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
 ??????? at 
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
 ??????? at 
java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
 ??????? at 
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
 ??????? at 
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
 ??????? at 
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
 ??????? at 
java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:716)
 ??????? at 
java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:970)
 ??????? at 
java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
 ??????? at 
java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
 ??????? at 
java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:398)
 ??????? at 
java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:371)
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
 ??????? ... 12 more



From pallavi.sonal at oracle.com  Mon Feb 11 05:31:46 2019
From: pallavi.sonal at oracle.com (Pallavi Sonal)
Date: Sun, 10 Feb 2019 21:31:46 -0800 (PST)
Subject: ldaps:// ignores alternative DNS names / SNA (Subject Alternative
 Name) certs if hostname != CN name)
Message-ID: <5226cccc-8740-4018-97fc-6d001c35c77c@default>

Hi Heiko,
Please refer the release notes for JDK 8u181 at https://www.oracle.com/technetwork/java/javase/8u181-relnotes-4479407.html , there is a change to improve LDAP support and make it more secure. It is not possible now to establish an LDAPS connection to a server which presents a certificate whose CN or SAN  does not contain the requested host name. So, either the same host name should be used which is there in the certificate's CN or SAN or the certificate should be updated to have the matching hostname as in its CN or SAN. I have added the snippet from the release notes below for your reference  :
---------------------------------------------------------------
? Improve LDAP support
Endpoint identification has been enabled on LDAPS connections.

To improve the robustness of LDAPS (secure LDAP over TLS) connections, endpoint identification algorithms have been enabled by default.

Note that there may be situations where some applications that were previously able to successfully connect to an LDAPS server may no longer be able to do so. Such applications may, if they deem appropriate, disable endpoint identification using a new system property: com.sun.jndi.ldap.object.disableEndpointIdentification.

Define this system property (or set it to true) to disable endpoint identification algorithms.
---------------------------------------------------------------

Thanks,
Pallavi Sonal

Date: Sun, 10 Feb 2019 02:34:30 +0100
From: Heiko Jakob <heiko.jakob at gediegos.de>
To: security-dev at openjdk.java.net
Subject: ldaps:// ignores alternative DNS names / SNA (Subject
	Alternative Name) certs if hostname != CN name
Message-ID: <2d1a1cfe-bb0d-5f1b-cdb7-c54bfb2d4e44 at gediegos.de>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

connecting to a secure ldap server with a SNA certificate fails with
"javax.naming.CommunicationException: simple bind failed: 
ldap.foo.bar:636 [Root exception is javax.net.ssl.SSLHandshakeException: 
No subject alternative DNS name matching ldap.foo.bar found.]"

The certificate is valid and i've tested it on https on the same machine which works flawlessly. The problem does not effect the Oracle JDK/JRE, only OpenJDK. I've testen OpenJDK 1.8.0_181, 11.0.1, 11.0.2 and all are affected.


With best regards

Heiko Jakob


How to reproduce:
Have a valid certificate for a host named CN "realhost.foo.bar" with
x509 SNA extension for DNS.1 "realhost.foo.bar" DNS.2 "ldap.foo.bar". 
Use the same certificate for https & ldap on the same host.

Examine the certificate to have CN="realhost.foo.bar" and x509 SNA extension for ldap.foo.bar $ openssl x509 -in my.crt -text -noout | less
Certificate:

...

 ?????? Validity
 ??????????? Not Before: Feb? 8 11:28:53 2019 GMT  ??????????? Not After : Feb? 7 11:28:53 2024 GMT  ??????? Subject: C = DE, ST = BW, L = Stuttgart, O = foo.bar, OU = IT Department, CN = realhost.foo.bar ...
 ??????????? X509v3 Subject Alternative Name:
 ??????????????? DNS:realhost.foo.bar, DNS:ldap.foo.bar


Run the following small test program to reproduce the problem.

package testSSL;

import java.net.URL;
import java.net.URLConnection;
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.directory.DirContext;
import javax.naming.directory.InitialDirContext;

public final class TestSSL {

 ??? public static void main(String[] args) {
 ??? ??? String url_l = "ldaps://ldap.foo.bar:636";
 ??? ??? String url_h = "https://ldap.foo.bar";

 ??? ??? System.out.println("TestSSL");
 ??? ??? URL url;
 ??? ??? try {
 ??? ??? ??? System.out.println("Test " + url_h);
 ??? ??? ??? url = new URL(url_h);
 ??? ??? ??? URLConnection conn = url.openConnection();
 ??? ??? ??? conn.connect();
 ??? ??? } catch (Exception e) {
 ??? ??? ??? e.printStackTrace();
 ??? ??? ??? System.out.println("Failed " + url_h);
 ??? ??? ??? System.exit(-1);
 ??? ??? }
 ??? ??? System.out.println("https:// OK");


 ??? ??? System.out.println("Test " + url_l);
 ??? ??? Hashtable env = new Hashtable();
 ??? ??? env.put(Context.INITIAL_CONTEXT_FACTORY,
 ??? ??? ??? "com.sun.jndi.ldap.LdapCtxFactory");
 ??? ??? env.put(Context.PROVIDER_URL, url_l);
 ??? ??? env.put(Context.SECURITY_PROTOCOL, "ssl");
 ??? ??? env.put(Context.SECURITY_AUTHENTICATION, "simple");
 ??? ??? env.put(Context.SECURITY_PRINCIPAL, "cn=admin,dc=foo,dc=bar");
 ??? ??? env.put(Context.SECURITY_CREDENTIALS, "mysecret");
 ??? ??? try {
 ??? ??? ??? DirContext ctx = new InitialDirContext(env);
 ??? ??? } catch (Exception e) {
 ??? ??? ??? e.printStackTrace();
 ??? ??? ??? System.out.println("Failed " + url_l);
 ??? ??? ??? System.exit(-1);
 ??? ??? }
 ??? ??? System.out.println("ldaps:// OK");
 ??? }
}

Test it against various JDKs

$ (for j in $(find /opt/java/ -type f -name 'java' 2> /dev/null); do 
echo $j; $j -version; $j -classpath ./ testSSL.TestSSL; echo""; echo 
"##############################################";echo ""; sleep 30; done 
) 2>&1 | tee -a testSSL.out

Reference output from oracle JDK

opt/java/jdk1.8.0_73/bin/java
java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)
TestSSL
https://ldap.foo.bar
https:// OK
ldaps://ldap.foo.bar:636
ldaps:// OK

##############################################
....
##############################################

/opt/java/jdk-11.0.2/bin/java
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
TestSSL
https://ldap.foo.bar
https:// OK
ldaps://ldap.foo.bar:636
javax.naming.CommunicationException: simple bind failed: 
ldap.foo.bar:636 [Root exception is javax.net.ssl.SSLHandshakeException: 
No subject alternative DNS name matching ldap.foo.bar found.]
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
 ??????? at java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2795)
 ??????? at java.naming/com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:320)
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
 ??????? at 
java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:730)
 ??????? at 
java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
 ??????? at 
java.naming/javax.naming.InitialContext.init(InitialContext.java:236)
 ??????? at 
java.naming/javax.naming.InitialContext.<init>(InitialContext.java:208)
 ??????? at 
java.naming/javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
 ??????? at testSSL.TestSSL.main(TestSSL.java:57)
Caused by: javax.net.ssl.SSLHandshakeException: No subject alternative 
DNS name matching ldap.foo.bar found.
 ??????? at 
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
 ??????? at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
 ??????? at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
 ??????? at 
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
 ??????? at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:642)
 ??????? at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:461)
 ??????? at 
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:361)
 ??????? at 
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
 ??????? at 
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
 ??????? at 
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
 ??????? at 
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
 ??????? at 
java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
 ??????? at 
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
 ??????? at 
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
 ??????? at 
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
 ??????? at 
java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:716)
 ??????? at 
java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:970)
 ??????? at 
java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
 ??????? at 
java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
 ??????? at 
java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:398)
 ??????? at 
java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:371)
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
 ??????? at 
java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
 ??????? ... 12 more




End of security-dev Digest, Vol 140, Issue 11
*********************************************

From daniel.fuchs at oracle.com  Mon Feb 11 09:58:36 2019
From: daniel.fuchs at oracle.com (Daniel Fuchs)
Date: Mon, 11 Feb 2019 10:58:36 +0100
Subject: TLSv1.3 HttpsServer endless loop based on client socket i/o
 shutdown
In-Reply-To: <CAAcXADf9cy+vwSP36hj5A=dMwhdS8ou_VxDW+_h4x1WrLpD6hw@mail.gmail.com>
References: <CAAcXADf9cy+vwSP36hj5A=dMwhdS8ou_VxDW+_h4x1WrLpD6hw@mail.gmail.com>
Message-ID: <78b535ce-0b02-f5e5-b83e-c41377e25523@oracle.com>

Hi Jay,


It looks like this is JDK-8214418 - which has been fixed
in 12.0.1 b03 and 13-ea b04. The issue was with the
half closed semantics of the SSL engine in TLS 1.3.

best regards,

-- daniel

On 08/02/2019 21:43, Jay Modi wrote:
> Hi,
> 
> I've been doing some testing with Apache HttpClient against the 
> com.sun.net.httpserver.HttpsServer that is included with the JDK and 
> came across some interesting behavior that occurs when using TLSv1.3, 
> but TLSv1.2 works normally. If the client manually calls 
> Socket#shutdownOutput and Socket#shutdownInput before closing the 
> socket, the HttpsServer goes into an endless loop while trying send the 
> close back to the client. Is this expected? I've done my best to create 
> a minimal reproducer without Apache HttpClient[1].
> 
> To me this behavior does not seem right and as I mentioned, I did not 
> have these issues when using TLSv1.2. I'm running on macOS with the 
> following JDK:
> openjdk version "11.0.2" 2019-01-15
> OpenJDK Runtime Environment 18.9 (build 11.0.2+9)
> OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode)
> 
> Jay
> 
> [1] https://gist.github.com/jaymode/3a6562beaa7ea789b287372bd10d4d1d


From j.p.cranendonk at gmail.com  Mon Feb 11 10:43:00 2019
From: j.p.cranendonk at gmail.com (Jeroen Cranendonk)
Date: Mon, 11 Feb 2019 11:43:00 +0100
Subject: Status of JDK-8207031
Message-ID: <CAJ2eHMbX4L_f69EYk10E6ju0WfdBhJ2+U45P6p58nNcV7RVk4w@mail.gmail.com>

Hi!

I'm wondering what the status is on the issue:
https://bugs.openjdk.java.net/browse/JDK-8207031

I saw a request for review:
https://mail.openjdk.java.net/pipermail/security-dev/2018-July/017581.html
But I don't think that's been followed up on?

We are looking to switch to Java 11, and this is becoming one of the
biggest blockers to us :)

Cheers!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190211/88ab0933/attachment.html>

From sha.jiang at oracle.com  Mon Feb 11 10:47:42 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 11 Feb 2019 18:47:42 +0800
Subject: RFR[13] JDK-8146392: sun/security/tools/keytool/selfissued.sh failed
 with ar_SA locale
Message-ID: <0442ebc3-f6e7-d8cf-d2cf-152b4464beca@oracle.com>

Hi,
This fix just makes sure that the keytool in test 
sun/security/tools/keytool/selfissued.sh uses en_US locale,
or the test fails with ar_SA.

diff -r bc20d0376402 test/jdk/sun/security/tools/keytool/selfissued.sh
--- a/test/jdk/sun/security/tools/keytool/selfissued.sh??? Mon Jan 28 
23:00:31 2019 +0100
+++ b/test/jdk/sun/security/tools/keytool/selfissued.sh??? Mon Feb 11 
14:58:34 2019 +0800
@@ -1,5 +1,5 @@
 ?#
-# Copyright (c) 2009, 2014, Oracle and/or its affiliates. All rights 
reserved.
+# Copyright (c) 2009, 2019, Oracle and/or its affiliates. All rights 
reserved.
 ?# DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 ?#
 ?# This code is free software; you can redistribute it and/or modify it
@@ -45,7 +45,7 @@
 ?esac

 ?KS=selfsigned.ks
-KT="$TESTJAVA${FS}bin${FS}keytool ${TESTTOOLVMOPTS} -storepass changeit 
-keypass changeit -keystore $KS -keyalg rsa"
+KT="$TESTJAVA${FS}bin${FS}keytool ${TESTTOOLVMOPTS} 
-J-Duser.language=en -J-Duser.country=US -storepass changeit -keypass 
changeit -keystore $KS -keyalg rsa"

 ?rm $KS


Best regards,
John Jiang


From weijun.wang at oracle.com  Mon Feb 11 10:57:21 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Mon, 11 Feb 2019 18:57:21 +0800
Subject: RFR[13] JDK-8146392: sun/security/tools/keytool/selfissued.sh
 failed with ar_SA locale
In-Reply-To: <0442ebc3-f6e7-d8cf-d2cf-152b4464beca@oracle.com>
References: <0442ebc3-f6e7-d8cf-d2cf-152b4464beca@oracle.com>
Message-ID: <33C162EB-8600-46CF-8969-6B63F5D6A05C@oracle.com>

Please close it as will-not-fix because I'm about to modify it into a java test soon.

Thanks,
Max

> On Feb 11, 2019, at 6:47 PM, sha.jiang at oracle.com wrote:
> 
> Hi,
> This fix just makes sure that the keytool in test sun/security/tools/keytool/selfissued.sh uses en_US locale,
> or the test fails with ar_SA.
> 
> diff -r bc20d0376402 test/jdk/sun/security/tools/keytool/selfissued.sh
> --- a/test/jdk/sun/security/tools/keytool/selfissued.sh    Mon Jan 28 23:00:31 2019 +0100
> +++ b/test/jdk/sun/security/tools/keytool/selfissued.sh    Mon Feb 11 14:58:34 2019 +0800
> @@ -1,5 +1,5 @@
>  #
> -# Copyright (c) 2009, 2014, Oracle and/or its affiliates. All rights reserved.
> +# Copyright (c) 2009, 2019, Oracle and/or its affiliates. All rights reserved.
>  # DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  #
>  # This code is free software; you can redistribute it and/or modify it
> @@ -45,7 +45,7 @@
>  esac
> 
>  KS=selfsigned.ks
> -KT="$TESTJAVA${FS}bin${FS}keytool ${TESTTOOLVMOPTS} -storepass changeit -keypass changeit -keystore $KS -keyalg rsa"
> +KT="$TESTJAVA${FS}bin${FS}keytool ${TESTTOOLVMOPTS} -J-Duser.language=en -J-Duser.country=US -storepass changeit -keypass changeit -keystore $KS -keyalg rsa"
> 
>  rm $KS
> 
> 
> Best regards,
> John Jiang
> 


From pallavi.sonal at oracle.com  Mon Feb 11 12:49:47 2019
From: pallavi.sonal at oracle.com (Pallavi Sonal)
Date: Mon, 11 Feb 2019 04:49:47 -0800 (PST)
Subject: ldaps:// ignores alternative DNS names / SNA (Subject Alternative
 Name) certs if hostname != CN name)
In-Reply-To: <5226cccc-8740-4018-97fc-6d001c35c77c@default>
References: <5226cccc-8740-4018-97fc-6d001c35c77c@default>
Message-ID: <77112a81-ef16-450c-bb93-6ba1f26f9abc@default>

Just for reference and as conclusion to this thread -  had a chat with OP on another mail , this actually turned out to be an environment issue.

-----Original Message-----
From: Pallavi Sonal 
Sent: February-11-19 11:02 AM
To: Heiko Jakob <heiko.jakob at gediegos.de>
Cc: security-dev at openjdk.java.net
Subject: RE: ldaps:// ignores alternative DNS names / SNA (Subject Alternative Name) certs if hostname != CN name)

Hi Heiko,
Please refer the release notes for JDK 8u181 at https://www.oracle.com/technetwork/java/javase/8u181-relnotes-4479407.html , there is a change to improve LDAP support and make it more secure. It is not possible now to establish an LDAPS connection to a server which presents a certificate whose CN or SAN  does not contain the requested host name. So, either the same host name should be used which is there in the certificate's CN or SAN or the certificate should be updated to have the matching hostname as in its CN or SAN. I have added the snippet from the release notes below for your reference  :
---------------------------------------------------------------
? Improve LDAP support
Endpoint identification has been enabled on LDAPS connections.

To improve the robustness of LDAPS (secure LDAP over TLS) connections, endpoint identification algorithms have been enabled by default.

Note that there may be situations where some applications that were previously able to successfully connect to an LDAPS server may no longer be able to do so. Such applications may, if they deem appropriate, disable endpoint identification using a new system property: com.sun.jndi.ldap.object.disableEndpointIdentification.

Define this system property (or set it to true) to disable endpoint identification algorithms.
---------------------------------------------------------------

Thanks,
Pallavi Sonal

Date: Sun, 10 Feb 2019 02:34:30 +0100
From: Heiko Jakob <heiko.jakob at gediegos.de>
To: security-dev at openjdk.java.net
Subject: ldaps:// ignores alternative DNS names / SNA (Subject
	Alternative Name) certs if hostname != CN name
Message-ID: <2d1a1cfe-bb0d-5f1b-cdb7-c54bfb2d4e44 at gediegos.de>
Content-Type: text/plain; charset=utf-8; format=flowed

Hi,

connecting to a secure ldap server with a SNA certificate fails with
"javax.naming.CommunicationException: simple bind failed: 
ldap.foo.bar:636 [Root exception is javax.net.ssl.SSLHandshakeException: 
No subject alternative DNS name matching ldap.foo.bar found.]"

The certificate is valid and i've tested it on https on the same machine which works flawlessly. The problem does not effect the Oracle JDK/JRE, only OpenJDK. I've testen OpenJDK 1.8.0_181, 11.0.1, 11.0.2 and all are affected.


With best regards

Heiko Jakob


How to reproduce:
Have a valid certificate for a host named CN "realhost.foo.bar" with
x509 SNA extension for DNS.1 "realhost.foo.bar" DNS.2 "ldap.foo.bar". 
Use the same certificate for https & ldap on the same host.

Examine the certificate to have CN="realhost.foo.bar" and x509 SNA extension for ldap.foo.bar $ openssl x509 -in my.crt -text -noout | less
Certificate:

...

 ?????? Validity
 ??????????? Not Before: Feb? 8 11:28:53 2019 GMT  ??????????? Not After : Feb? 7 11:28:53 2024 GMT  ??????? Subject: C = DE, ST = BW, L = Stuttgart, O = foo.bar, OU = IT Department, CN = realhost.foo.bar ...
 ??????????? X509v3 Subject Alternative Name:
 ??????????????? DNS:realhost.foo.bar, DNS:ldap.foo.bar


Run the following small test program to reproduce the problem.

package testSSL;

import java.net.URL;
import java.net.URLConnection;
import java.util.Hashtable;
import javax.naming.Context;
import javax.naming.directory.DirContext;
import javax.naming.directory.InitialDirContext;

public final class TestSSL {

 ??? public static void main(String[] args) {  ??? ??? String url_l = "ldaps://ldap.foo.bar:636";  ??? ??? String url_h = "https://ldap.foo.bar";

 ??? ??? System.out.println("TestSSL");
 ??? ??? URL url;
 ??? ??? try {
 ??? ??? ??? System.out.println("Test " + url_h);  ??? ??? ??? url = new URL(url_h);  ??? ??? ??? URLConnection conn = url.openConnection();  ??? ??? ??? conn.connect();  ??? ??? } catch (Exception e) {  ??? ??? ??? e.printStackTrace();  ??? ??? ??? System.out.println("Failed " + url_h);  ??? ??? ??? System.exit(-1);  ??? ??? }  ??? ??? System.out.println("https:// OK");


 ??? ??? System.out.println("Test " + url_l);  ??? ??? Hashtable env = new Hashtable();  ??? ??? env.put(Context.INITIAL_CONTEXT_FACTORY,
 ??? ??? ??? "com.sun.jndi.ldap.LdapCtxFactory");
 ??? ??? env.put(Context.PROVIDER_URL, url_l);  ??? ??? env.put(Context.SECURITY_PROTOCOL, "ssl");  ??? ??? env.put(Context.SECURITY_AUTHENTICATION, "simple");  ??? ??? env.put(Context.SECURITY_PRINCIPAL, "cn=admin,dc=foo,dc=bar");  ??? ??? env.put(Context.SECURITY_CREDENTIALS, "mysecret");  ??? ??? try {  ??? ??? ??? DirContext ctx = new InitialDirContext(env);  ??? ??? } catch (Exception e) {  ??? ??? ??? e.printStackTrace();  ??? ??? ??? System.out.println("Failed " + url_l);  ??? ??? ??? System.exit(-1);  ??? ??? }  ??? ??? System.out.println("ldaps:// OK");  ??? } }

Test it against various JDKs

$ (for j in $(find /opt/java/ -type f -name 'java' 2> /dev/null); do echo $j; $j -version; $j -classpath ./ testSSL.TestSSL; echo""; echo "##############################################";echo ""; sleep 30; done
) 2>&1 | tee -a testSSL.out

Reference output from oracle JDK

opt/java/jdk1.8.0_73/bin/java
java version "1.8.0_73"
Java(TM) SE Runtime Environment (build 1.8.0_73-b02) Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode) TestSSL https://ldap.foo.bar https:// OK
ldaps://ldap.foo.bar:636
ldaps:// OK

##############################################
....
##############################################

/opt/java/jdk-11.0.2/bin/java
openjdk version "11.0.2" 2019-01-15
OpenJDK Runtime Environment 18.9 (build 11.0.2+9) OpenJDK 64-Bit Server VM 18.9 (build 11.0.2+9, mixed mode) TestSSL https://ldap.foo.bar https:// OK
ldaps://ldap.foo.bar:636
javax.naming.CommunicationException: simple bind failed: 
ldap.foo.bar:636 [Root exception is javax.net.ssl.SSLHandshakeException: 
No subject alternative DNS name matching ldap.foo.bar found.]  ??????? at
java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:219)
 ??????? at java.naming/com.sun.jndi.ldap.LdapCtx.connect(LdapCtx.java:2795)
 ??????? at java.naming/com.sun.jndi.ldap.LdapCtx.<init>(LdapCtx.java:320)
 ??????? at
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURL(LdapCtxFactory.java:192)
 ??????? at
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getUsingURLs(LdapCtxFactory.java:210)
 ??????? at
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getLdapCtxInstance(LdapCtxFactory.java:153)
 ??????? at
java.naming/com.sun.jndi.ldap.LdapCtxFactory.getInitialContext(LdapCtxFactory.java:83)
 ??????? at
java.naming/javax.naming.spi.NamingManager.getInitialContext(NamingManager.java:730)
 ??????? at
java.naming/javax.naming.InitialContext.getDefaultInitCtx(InitialContext.java:305)
 ??????? at
java.naming/javax.naming.InitialContext.init(InitialContext.java:236)
 ??????? at
java.naming/javax.naming.InitialContext.<init>(InitialContext.java:208)
 ??????? at
java.naming/javax.naming.directory.InitialDirContext.<init>(InitialDirContext.java:101)
 ??????? at testSSL.TestSSL.main(TestSSL.java:57)
Caused by: javax.net.ssl.SSLHandshakeException: No subject alternative DNS name matching ldap.foo.bar found.
 ??????? at
java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
 ??????? at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:321)
 ??????? at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:264)
 ??????? at
java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:259)
 ??????? at
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.checkServerCerts(CertificateMessage.java:642)
 ??????? at
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.onCertificate(CertificateMessage.java:461)
 ??????? at
java.base/sun.security.ssl.CertificateMessage$T12CertificateConsumer.consume(CertificateMessage.java:361)
 ??????? at
java.base/sun.security.ssl.SSLHandshake.consume(SSLHandshake.java:392)
 ??????? at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:444)
 ??????? at
java.base/sun.security.ssl.HandshakeContext.dispatch(HandshakeContext.java:421)
 ??????? at
java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:178)
 ??????? at
java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
 ??????? at
java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
 ??????? at
java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
 ??????? at
java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
 ??????? at
java.base/sun.security.ssl.SSLSocketImpl.ensureNegotiated(SSLSocketImpl.java:716)
 ??????? at
java.base/sun.security.ssl.SSLSocketImpl$AppOutputStream.write(SSLSocketImpl.java:970)
 ??????? at
java.base/java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:81)
 ??????? at
java.base/java.io.BufferedOutputStream.flush(BufferedOutputStream.java:142)
 ??????? at
java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:398)
 ??????? at
java.naming/com.sun.jndi.ldap.Connection.writeRequest(Connection.java:371)
 ??????? at
java.naming/com.sun.jndi.ldap.LdapClient.ldapBind(LdapClient.java:359)
 ??????? at
java.naming/com.sun.jndi.ldap.LdapClient.authenticate(LdapClient.java:214)
 ??????? ... 12 more




End of security-dev Digest, Vol 140, Issue 11
*********************************************

From Nico.Williams at twosigma.com  Mon Feb 11 19:05:16 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Mon, 11 Feb 2019 19:05:16 +0000
Subject: ldaps:// ignores alternative DNS names / SNA (Subject
 Alternative Name) certs if hostname != CN name)
In-Reply-To: <5226cccc-8740-4018-97fc-6d001c35c77c@default>
References: <5226cccc-8740-4018-97fc-6d001c35c77c@default>
Message-ID: <20190211190516.GA4046@twosigma.com>

On Sun, Feb 10, 2019 at 09:31:46PM -0800, Pallavi Sonal wrote:
> Please refer the release notes for JDK 8u181 at
> https://www.oracle.com/technetwork/java/javase/8u181-relnotes-4479407.html ,
> there is a change to improve LDAP support and make it more secure. It is not
> possible now to establish an LDAPS connection to a server which presents a
> certificate whose CN or SAN  does not contain the requested host name. So,
> either the same host name should be used which is there in the certificate's
> CN or SAN or the certificate should be updated to have the matching hostname
> as in its CN or SAN. I have added the snippet from the release notes below
> for your reference  :

Heiko's post shows that the certificate had the correct hostname as a dNSName
SAN.

Sounds like a bug to me, and a serious one at that.

Nico
-- 

From anthony.scarpino at oracle.com  Mon Feb 11 19:30:07 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 11 Feb 2019 11:30:07 -0800
Subject: [13] RFR JDK-8216597 "SIGBUS in
 Java_sun_security_pkcs11_wrapper_PKCS11_getNativeKeyInfo after JDK-6913047"
In-Reply-To: <02f7f228-66d1-0ed1-0b5b-760e3e84ddfa@oracle.com>
References: <02f7f228-66d1-0ed1-0b5b-760e3e84ddfa@oracle.com>
Message-ID: <81e73bd1-f327-3120-ebf1-68fd0dec3a8d@oracle.com>

On 2/7/19 2:09 PM, Valerie Peng wrote:
> Hi,
> 
> Anyone can help review this fix? More detailed info on cause and fixes 
> can be found in the bug report and fix has been verified through mach5 run.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8216597
> 
> Webrev: http://cr.openjdk.java.net/~valeriep/8216597/webrev.00/
> 
> Thanks!
> Valerie

The change looks fine.

Tony


From xuelei.fan at oracle.com  Mon Feb 11 19:32:29 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 11 Feb 2019 11:32:29 -0800
Subject: RFR [13] JDK-4919790 : Errors in alert ssl message does not reflect
 the actual certificate status
Message-ID: <3c720033-6206-0a49-86d7-5ee407f995a9@oracle.com>

Hi,

Could I get the update reviewed?
    http://cr.openjdk.java.net/~xuelei/4919790/webrev.00/

It had been a while that the SunJSSE provider use certificate_unknown or 
certificate_revoked (or bad_certificate_status_response for OCSP 
stapling) as the certificate issues alert.  Other certificate alert like 
certificate_expired are not used.

The bug was reported in JDK 6.  With the introducing of 
CertPathValidatorException.BasicReason in JDK 7. Now we can handle the 
alert more accuracy.

Note: please don't rely on the certificate alert type for application 
development.  The alert type may be changed and different per the 
provider preference.

No new regression test as the update is simple and straightforward.

Thanks,
Xuelei

From anthony.scarpino at oracle.com  Mon Feb 11 21:45:39 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 11 Feb 2019 13:45:39 -0800
Subject: RFR[13]: Delegated task created by SSLEngine throws
 java.nio.BufferUnderflowException
Message-ID: <91f58fe2-9400-7bdd-73fc-f206f427ea90@oracle.com>

Hi,

I need a review of this simple change that throws the wrong exception

http://cr.openjdk.java.net/~ascarpino/8215790/webrev/

Tony

From jamil.j.nimeh at oracle.com  Tue Feb 12 00:33:24 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 11 Feb 2019 16:33:24 -0800
Subject: RFR[13]: Delegated task created by SSLEngine throws
 java.nio.BufferUnderflowException
In-Reply-To: <91f58fe2-9400-7bdd-73fc-f206f427ea90@oracle.com>
References: <91f58fe2-9400-7bdd-73fc-f206f427ea90@oracle.com>
Message-ID: <6424c4e7-4148-f299-b64d-83b58b7fc81e@oracle.com>

Looks good to me.

--Jamil

On 2/11/2019 1:45 PM, Anthony Scarpino wrote:
> Hi,
>
> I need a review of this simple change that throws the wrong exception
>
> http://cr.openjdk.java.net/~ascarpino/8215790/webrev/
>
> Tony


From sean.mullan at oracle.com  Tue Feb 12 18:25:44 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 12 Feb 2019 13:25:44 -0500
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
Message-ID: <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>

Hi Andi,

TLS/JSSE topics are best discussed on the security-dev alias, so I am 
copying that list for more discussion and -bcc-ing core-libs-dev.

--Sean

On 2/11/19 3:29 PM, Andi Mullaraj wrote:
> Hi java-core community,
> 
> I have been directed to this channel to discuss matters related to Java
> performant ssl communications.  Maybe this is a topic that has been
> discussed in the past, in which case I would appreciate if someone pointed
> me to that particular topic.
> 
> Back in 2002 I personally applauded the java.nio.channels (jdk1.4) package,
> realizing that there was no way to port this to the secure communications,
> due to lack of a comparable implementation for SSL.  But I thought it was
> going to just be matter of time.  A couple of years ago I had to go back
> search for it, and was kind of surprised to find the following in
> http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG
> :
> 
> --- begin quote ---
> Newcomers to the API may wonder "Why not just have an SSLSocketChannel
> which extends java.nio.channels.SocketChannel?" There are two main reasons:
> 
> 1. There were a lot of very difficult questions about what a
> SSLSocketChannel should be, including its class hierarchy and how it should
> interoperate with Selectors and other types of SocketChannels. Each
> proposal brought up more questions than answers. It was noted that any new
> API abstraction extended to work with SSL/TLS would require the same
> significant analysis and could result in large and complex APIs.
> 2. Any JSSE implementation of a new API would be free to choose the "best"
> I/O & compute strategy, but hiding any of these details is inappropriate
> for those applications needing full control. Any specific implementation
> would be inappropriate for some application segment.
> --- end quote ---
> 
> It has been a while since this was stated, and I would really like to
> revisit it.  I personally believe that the question #1 has a quite natural
> answer, while #2 should not really be a concern if we adhere to the spi
> model where users can bring their own implementation if needed.  I know
> because I have also implemented it (but would like to discuss that in a
> later stage, if it comes to it).
> 
> The benefit of such implementation would be immense.  Imagine many Java
> services written with nio and which struggle to move to SSL due to the
> great complexity of using SSLEngine (zookeeper service to name one), while
> all they would need to do (if SSLSocketChannels were available) is to
> instantiate an instance of SSLSocketChannel/SSLSelector when the security
> is required and the rest would stay the same (as in case of plain
> communication using SocketChannel/Selector).  Another important use case is
> the advent of IOT, where millions of devices, with relatively low
> throughput would want to protect their communication via SSL.
> 
> The ways I have seen the community deal with this are mainly:
> 
> 1. Go through the pain of learning SSLEngine (and hope to get it right)
> 2. Build their services around tested libraries (like Jetty, which handle
> the SSL offload but don't resurface it in SocketChannel/Selector paradigm,
> that also come with their huge set of dependencies, bringing in unavoidable
> version collisions)
> 3. Use proxies (nginx, ha) to deal with the high number of SSL connections
> and divide the load by scaling horizontally in the back end (making for a
> harder deployment model)
> 
> We can make this a lot easier!
> 
> Any feedback is greatly appreciated,
> Best,
> 
> Andi Mullaraj
> 

From sean.mullan at oracle.com  Tue Feb 12 19:54:55 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 12 Feb 2019 14:54:55 -0500
Subject: Code Review Request, JDK-8217835, Remove the experimental SunJSSE
 FIPS compliant mode
In-Reply-To: <2b0668ee-cf1f-707a-e5ae-42afffaa755a@oracle.com>
References: <2b0668ee-cf1f-707a-e5ae-42afffaa755a@oracle.com>
Message-ID: <2f2135d9-6297-62ee-0857-162b7bcdfd21@oracle.com>

Looks good, pretty straightforward cleanup.

--Sean

On 2/5/19 1:44 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I have the update reviewed?
>  ?? http://cr.openjdk.java.net/~xuelei/8217835/webrev.00/
> 
> With this update, the experimental FIPS 140 compliant mode is removed 
> from the SunJSSE provider. As the SunJSSE provider uses the JDK default 
> cryptography providers, alternatively applications can configure the 
> Java Security Property to use FIPS 140 compliant cryptography providers.
> 
> More details,? please refer to CSR:
>  ?? https://bugs.openjdk.java.net/browse/JDK-8217907
> 
> Thanks & Regards,
> Xuelei

From christoph.langer at sap.com  Tue Feb 12 21:57:23 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Tue, 12 Feb 2019 21:57:23 +0000
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <af6b23e04a2548179460a006b34a3afc@sap.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <CA+3eh102cMGphPPbABv2ef_M5Py5+Mg-FRU94HcpKUH3gaV6+w@mail.gmail.com>
 <fd756aff51134b15a40fe55247d4a87e@sap.com>
 <CA+3eh13dP-tCdq4H4z3KWJZQzfMJYqDNkx9fMh3tNfL08RCtDg@mail.gmail.com>
 <7b513a34196141f595cd5d194fb9d8a2@sap.com>
 <fa4078d9-7aec-f122-e9ca-7b816e115c9b@oracle.com>
 <CA+3eh10kDtTEpcRsUWhQEkEyRyTdbvxxmZ8U-G97OeUG2kkU3A@mail.gmail.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
Message-ID: <3aeba9a64a434a968fc1d82a44077745@sap.com>

Hi Alan, all,

here comes the next proposal for POSIX support in jdk.zipfs - which hopefully represents the converged solution, at least in its overall design.

http://cr.openjdk.java.net/~clanger/webrevs/8213031.6/

With that patch, the behavior is the following:
a) A ZipFileSystem instance by default does NOT support the PosixFileAttributeView. However, it is possible to query for a known attribute named "zip:storedPermissions". Its value can be null to represent no  permission information or any set of PosixFileAttribute.
b) A ZipFileSystem instance can be created with the property "posix"=true. In that case, PosixFileAttributeView is supported with default values.
	-> owner: A UserPrincipal with the name of System.getProperty("user.name") if property access is allowed, "<zipfs_default>" otherwise
	-> group: A GroupPrincipal with the name "<zipfs_default>".
	-> permissions: Set.of(OWNER_READ, OWNER_WRITE, GROUP_READ)

	The default values can be modified by using the properties "defaultOwner", "defaultGroup" and "defaultPermissions".

Implementation wise the ZipFileAttributeView always extends PosixFileAttributeView but behaves different, depending on how it was obtained.

Within ZipFileSystem, the Entry inner class is not static any more but always has a reference to the Enclosing ZipFileSystem. That's needed because default owner/group/permission can be set on ZipFileSystem instance level now and the Entry, implementing the FileAttributes needs to know where it belongs to. This seems somewhat logical anyway.

The new test "TestPosix" is quite extensive. I had to add 2 permissions to test.policy to allow testing in a restricted environment.

Module-info and CSR have been adopted, too.

Thanks in advance for reviewing.

Best regards
Christoph

> -----Original Message-----
> From: Langer, Christoph
> Sent: Montag, 21. Januar 2019 10:17
> To: 'Alan Bateman' <Alan.Bateman at oracle.com>
> Cc: nio-dev <nio-dev at openjdk.java.net>; OpenJDK Dev list <security-
> dev at openjdk.java.net>; Java Core Libs <core-libs-dev at openjdk.java.net>;
> Volker Simonis <volker.simonis at gmail.com>
> Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions
> 
> Hi Alan,
> 
> first of all, thank you for your input on this.
> 
> > I think the approach to explore are:
> >
> > 1. zipfs supports PosixFileAttributeView without subsetting. If
> > readAttribute(file, BasicFileAttributes.class) succeeds then
> > readAttribute(file, PosixFileAttributes.class) should also succeed, even
> > if there aren't permissions encoded in the zip entry's external file
> > attributes. It would mean that owner and group return default values,
> > and permissions may return a default value. It does mean you can't
> > distinguish the default value from "no permissions" but there is
> > precedence for that, e.g. mount a FAT32 file system on Linux or Unix
> > systems and `stat` a file to have the stat structure populated with
> > default uid, gid and mode bits.
> 
> OK, I can see the point that in a PosixFileAttributeView as it is, there's no
> place for optionality/null values. However, with this approach the benefits
> would be that Files::get/setPosixPermissions would work and that's why I
> think we should pursue this. The challenge will be to find reasonable
> defaults.
> 
> > 2. zipfs defines a new FileAttributeView that defines read and write
> > access to permissions stored in a zip entry's external file attribute.
> > As it's a new view then it can define the behavior for the case that the
> > zip entry doesn't have permissions. Furthermore it does not need to
> > extend BasicFileAttributeView so doesn't need to be concerned with bulk
> > access, nor concerned with group/owner. As you know, the attributes API
> > allows for both type safe and dynamic access so you have a choice as to
> > whether to support both or just dynamic access. With the first then
> > jdk.zipfs would export a package with a public interface that defines
> > the view. If someone wants type safe access to the permissions attribute
> > then you need to import the class. The alternative is to not export any
> > packages but just define the view in the module-info. The view its name
> > and define the name/type of the permissions attribute, it will also
> > define how it behaves when the external attributes aren't populated. In
> > usage terms it means reading the permissions will be something like
> > Files.readAttribute(file, "zip:permissions") and casting the value to
> > Set<PosixFilePermission> - not pretty but it avoids depending on a
> > JDK-specific API.
> 
> For this approach, there are 2 things I dislike. The first is that I don't think we
> should export named packages from module jdk.zipfs that people would
> develop Java code against while not being in the Java API. And secondly, this
> way would not support using Files::set/getPosixPermissions since the
> specification/implementation of that utility method explicitly refers to
> PosixFileAttributeView.
> 
> I can imagine something like this:
> Zipfs by default implements an own view that offers dynamic, not type safe
> access to "zip:permissions" and we'll document this. If a user of zipfs wants
> to see full PosixFileAttributeView support with default values, then we
> should allow for a creation attribute for the zipfs that can control this. Maybe
> we can even allow specifying default values for user, group and permissions
> via zipfs attributes.
> 
> I'll work to develop the patch into this direction unless you tell me that this
> idea is bogus (if so, then I hope it be soon ??)
> 
> Thanks
> Christoph
> 
> 


From sean.mullan at oracle.com  Tue Feb 12 22:14:41 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 12 Feb 2019 17:14:41 -0500
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
Message-ID: <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>

The bug is now at https://bugs.openjdk.java.net/browse/JDK-8218629

I have started looking at this issue and have some progress I can report.

In JDK 9, we updated the version of the Apache XML Signature 
implementation in the JDK. Some of the marshalling code was rewritten 
such that it will throw Exceptions if legacy DOM level 1 methods were 
used to create XML content which is then passed into XMLObject and 
similar XMLSignature types that take DOMStructure objects. This is 
because the DOM level 1 methods do not support namespaces.

I am still evaluating what the best fix is. However, you can workaround 
the issue by always using DOM level 3 methods which are namespace aware. 
For example, use Document.createElementNS instead of 
Document.createElement and Element.createAttributeNS instead of 
Element.createAttribute.

Using legacy or non-namespace aware XML parsers or implementations is 
not recommended and the XML Signature Best Practices document gives some 
rationale: 
https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces
That said, this is a regression in behavior so it would be best if we 
could restore the previous behavior.

I have attached a modified version of the test case to the bug report 
which no longer throws an Exception. Let me know if this is an 
acceptable workaround. Double-check the namespaces that I used to make 
sure they are correct.

--Sean


On 2/7/19 11:23 AM, Open eSignForms wrote:

> On 2/7/19 7:49 AM, Sean Mullan wrote:
>> On 2/6/19 4:51 PM, Open eSignForms wrote:
>>> I have a test version of the code that can run standalone and shows 
>>> the bug.? I'm not sure how best to transfer this information to the 
>>> forum for those to play with, but it is included below.
>>
>> Thanks, I can reproduce the issue now. I will need to debug further to 
>> see what might be causing this.
>>
>> --Sean

From yozons at gmail.com  Tue Feb 12 23:28:03 2019
From: yozons at gmail.com (Open eSignForms)
Date: Tue, 12 Feb 2019 15:28:03 -0800
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
Message-ID: <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>

Thanks for the update, Sean.? I'm a bit perplexed because I found the 
original code works under Java 9 and Java 10, so it seems like the 
change occurred in Java 11.

I don't see the modified version of the test case.? If you attached it, 
it somehow didn't make it through to me.

If it's just a matter of making the code more correct, we'd love to make 
the changes.? My concern, of course, is that we've already done millions 
of XML digital signatures, so we need that to continue to verify 
correctly (and even under Java 11, it seems that the verify code works 
against previously digitally signed content) even if we now start 
digitally signing using more update-to-date code.

Please send over the modified test case and I'll take a look.

Thanks!
David

On 2/12/19 2:14 PM, Sean Mullan wrote:
> The bug is now at https://bugs.openjdk.java.net/browse/JDK-8218629
>
> I have started looking at this issue and have some progress I can report.
>
> In JDK 9, we updated the version of the Apache XML Signature 
> implementation in the JDK. Some of the marshalling code was rewritten 
> such that it will throw Exceptions if legacy DOM level 1 methods were 
> used to create XML content which is then passed into XMLObject and 
> similar XMLSignature types that take DOMStructure objects. This is 
> because the DOM level 1 methods do not support namespaces.
>
> I am still evaluating what the best fix is. However, you can 
> workaround the issue by always using DOM level 3 methods which are 
> namespace aware. For example, use Document.createElementNS instead of 
> Document.createElement and Element.createAttributeNS instead of 
> Element.createAttribute.
>
> Using legacy or non-namespace aware XML parsers or implementations is 
> not recommended and the XML Signature Best Practices document gives 
> some rationale: 
> https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces
> That said, this is a regression in behavior so it would be best if we 
> could restore the previous behavior.
>
> I have attached a modified version of the test case to the bug report 
> which no longer throws an Exception. Let me know if this is an 
> acceptable workaround. Double-check the namespaces that I used to make 
> sure they are correct.
>
> --Sean
>
>
> On 2/7/19 11:23 AM, Open eSignForms wrote:
>
>> On 2/7/19 7:49 AM, Sean Mullan wrote:
>>> On 2/6/19 4:51 PM, Open eSignForms wrote:
>>>> I have a test version of the code that can run standalone and shows 
>>>> the bug.? I'm not sure how best to transfer this information to the 
>>>> forum for those to play with, but it is included below.
>>>
>>> Thanks, I can reproduce the issue now. I will need to debug further 
>>> to see what might be causing this.
>>>
>>> --Sean

From weijun.wang at oracle.com  Wed Feb 13 03:01:54 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 13 Feb 2019 11:01:54 +0800
Subject: RFR 8180573: Refactor sun/security/tools shell tests to plain java
 tests
Message-ID: <2B9C2E12-4BCE-4FFE-84FF-F21CE5FAC56F@oracle.com>

Please review the fix at

   https://cr.openjdk.java.net/~weijun/8180573/webrev.00/

Notes:

- Most changes are just .sh -> .java

- StorePasswordsByShell.sh combined into StorePasswords.java

- In most cases, JarUtils is called to create a jar file. Sometimes the jar command is called because of delicate differences, for example, jar adds directory entries also.

- The i18n tests are completely manual described in i18n.html. Old i18n.java is useless, now is also empty.

- Copyright year updated to 2019, @bug unchanged.

Two files not converted yet:

- ./keytool/console.sh

This is a manual test calling old versions of JDK.

- ./keytool/ListKeychainStore.sh

I tried on this one but "security list-keychains -s ..." has no effect on mach5 machines when calling by ProcessTools. No idea why, I've created a separate bug (JDK-8218886) for it.

Thanks,
Max


From weijun.wang at oracle.com  Wed Feb 13 03:31:33 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 13 Feb 2019 11:31:33 +0800
Subject: RFR 8218888: keytool -genkeypair should not have the -destalias option
Message-ID: <A0919773-0596-4827-82CD-9583471EDC97@oracle.com>

The -genkeypair command mistakenly lists -destalias in its option table. Here is the simple patch:

diff --git a/src/java.base/share/classes/sun/security/tools/keytool/Main.java b/src/java.base/share/classes/sun/security/tools/keytool/Main.java
--- a/src/java.base/share/classes/sun/security/tools/keytool/Main.java
+++ b/src/java.base/share/classes/sun/security/tools/keytool/Main.java
@@ -211,7 +211,7 @@
             STORETYPE, PROVIDERNAME, ADDPROVIDER, PROVIDERCLASS,
             PROVIDERPATH, V, PROTECTED),
         GENKEYPAIR("Generates.a.key.pair",
-            ALIAS, KEYALG, KEYSIZE, CURVENAME, SIGALG, DESTALIAS, DNAME,
+            ALIAS, KEYALG, KEYSIZE, CURVENAME, SIGALG, DNAME,
             STARTDATE, EXT, VALIDITY, KEYPASS, KEYSTORE,
             STOREPASS, STORETYPE, PROVIDERNAME, ADDPROVIDER,
             PROVIDERCLASS, PROVIDERPATH, V, PROTECTED),

Thanks
Max
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190213/53372004/attachment.html>

From xuelei.fan at oracle.com  Wed Feb 13 04:00:59 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 12 Feb 2019 20:00:59 -0800
Subject: Not possible to disable new TLS extensions for TLS 1.2 connections
In-Reply-To: <CAJ3+Awc9F5phKuMZZ1ohYtkhBHKvydvVioHJGpCkRaThAD6t=g@mail.gmail.com>
References: <CAJ3+Awc9F5phKuMZZ1ohYtkhBHKvydvVioHJGpCkRaThAD6t=g@mail.gmail.com>
Message-ID: <3dfb3505-dd0e-3b91-17a0-c6165d7a1069@oracle.com>

Hi Amir,

It should be rare now the a TLS vendor cannot ignore unknown extensions.

 > "issuer": "CN=invalid2.invalid, OU="No SNI provided;
 > please fix your client."",
The error message encapsulated in the certificate does not sound right 
to me.  Is it caused by the absence of SNI extension?

Did you have a test case that I can reproduce the problem?

Thanks & Regards,
Xuelei


On 1/7/2019 9:27 PM, Amir Khassaia wrote:
> Xuelei,
> The certificate in the connection is a red herring and not important. 
> It's actually a very unusual behaviour by talk.google.com 
> <http://talk.google.com> endpoint to encapsulate an error message inside 
> a certificate.
> 
> As per the output I included:
> 
> /"certificate" : { />/? ? "version"? ? ? ? ? ? : "v3", />/? ? "serial number"? ? ? : "00 90 76 89 18 E9 33 93 A0", />/? ? "signature algorithm": "SHA256withRSA", />/? ? "issuer"? ? ? ? ? ? ?: "CN=invalid2.invalid, OU="No SNI provided; />/please fix your client."", />/? ? "not before"? ? ? ? ?: "2015-01-01 11:00:00.000 AEDT", />/? ? "not? after"? ? ? ? ?: "2030-01-01 11:00:00.000 AEDT", />/? ? "subject"? ? ? ? ? ? : "CN=invalid2.invalid, OU="No SNI provided; />/please fix your client."",/
> 
> /
> /
> 
> This certificate simply masks the TLS interoperability issue as an 
> untrusted certificate issue.
> 
> The fact is, some of the extensions sent by JSSE are changes to TLS 1.2 
> to support TLS 1.3, this however affects some clients adversely in 
> practice and usually JDK provides properties to turn new enhancements 
> off and work around such behaviour, for the extensions I mentioned this 
> is not provided and hence they are always sent for client sockets unless 
> TLSv1.2 is not in use.
> 
> The impact to us is that upgrading to JDK11 means for some endpoints or 
> devices that are not 100% compliant to the spec the security is reduced 
> as we have to now work around to drop connections to these to TLSv1.1 or 
> TLS1.0 or not to move to Java 11 at all.
> 
> My request is simply to have all of the new extensions configurable on 
> individual basis so that they can be turned off if needed for 
> compatibility just like most other security enhancements that were 
> delivered in the past.
> 
> It appears some of the issues can come from
> 
> - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can 
> disabled at least
> 
> -signature_algorithms_cert and supported_versions extensions which seem 
> to be hardcoded for TLS 1.2 (I was not able to conclusively identify 
> which of these caused my troubles)
> 
> https://tools.ietf.org/html/rfc8446#section-1.3 does say that TLS 1.2 
> clients are affected but in an optional manner.Just today I've 
> encountered another Java 11 interop issue with TLS but this time with a 
> physical device which can have a long shelf life yet running a simple 
> client socket handshake abruptly terminates the connection upon client 
> hello (no server_hello at all), and downgrading the JRE below 11 works 
> fine. I'm including a trace for that as well:
> 
> 
> javax.net.ssl|DEBUG|01|main|2019-01-0813:40:14.395  AEDT|SSLCipher.java:437|jdk.tls.keyLimits: ? entry = AES/GCM/NoPadding KeyUpdate2^37. AES/GCM/NOPADDING:KEYUPDATE =137438953472
> 
> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433 
> AEDT|ServerNameExtension.java:255|Unable to indicate server name
> 
> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 
> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: 
> server_name
> 
> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433 
> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: 
> status_request
> 
> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443 
> AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not 
> supported by the underlying providers
> 
> javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444 
> AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not 
> supported by the underlying providers
> 
> javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449 
> AEDT|AlpnExtension.java:161|No available application protocols
> 
> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449 
> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: 
> application_layer_protocol_negotiation
> 
> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450 
> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: 
> status_request_v2
> 
> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453 
> AEDT|ClientHello.java:651|Produced ClientHello handshake message (
> 
> "ClientHello": {
> 
> "client version"? ? ? : "TLSv1.2",
> 
> "random"? ? ? ? ? ? ? : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 7F 34 3D 
> 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68",
> 
> "session id"? ? ? ? ? : "",
> 
> "cipher suites"? ? ? ?: 
> "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), 
> TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), 
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), 
> TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]",
> 
> "compression methods" : "00",
> 
> "extensions"? ? ? ? ? : [
> 
> "supported_groups (10)": {
> 
> "versions": [secp256r1, secp384r1, secp521r1, secp160k1]
> 
>  ? ? },
> 
> "ec_point_formats (11)": {
> 
> "formats": [uncompressed]
> 
>  ? ? },
> 
> "signature_algorithms (13)": {
> 
> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, 
> ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, 
> rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, 
> rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, 
> rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, 
> ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
> 
>  ? ? },
> 
> "signature_algorithms_cert (50)": {
> 
> "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, 
> ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384, 
> rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384, 
> rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384, 
> rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224, 
> ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
> 
>  ? ? },
> 
> "extended_master_secret (23)": {
> 
>  ? ? ? <empty>
> 
>  ? ? },
> 
> "supported_versions (43)": {
> 
> "versions": [TLSv1.2, TLSv1.1]
> 
>  ? ? },
> 
> "renegotiation_info (65,281)": {
> 
> "renegotiated connection": [<no renegotiated connection>]
> 
>  ? ? }
> 
>  ? ]
> 
> }
> 
> )
> 
> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455 
> AEDT|Alert.java:232|Received alert message (
> 
> "Alert": {
> 
> "level"? ? ? : "fatal",
> 
> "description": "handshake_failure"
> 
> }
> 
> )
> 
> javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456 
> AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Received fatal 
> alert: handshake_failure (
> 
> "throwable" : {
> 
>  ? javax.net.ssl.SSLHandshakeException: Received fatal alert: 
> handshake_failure
> 
>  ? ? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
> 
>  ? ? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> 
>  ? ? at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
> 
>  ? ? at 
> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
> 
>  ? ? at 
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
> 
>  ? ? at 
> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
> 
>  ? ? at 
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
> 
>  ? ? at 
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
> 
>  ? ? at 
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
> 
>  ? ? at SslSocketClient.main(SslSocketClient.kt:47)}
> 
> 
> )
> 
> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 
> AEDT|SSLSocketImpl.java:1361|close the underlying socket
> 
> javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457 
> AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative)
> 
> Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received 
> fatal alert: handshake_failure
> 
>  ? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
> 
>  ? at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> 
>  ? at 
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
> 
>  ? at java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
> 
>  ? at 
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
> 
>  ? at java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
> 
>  ? at 
> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
> 
>  ? at 
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
> 
>  ? at 
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
> 
>  ? at SslSocketClient.main(SslSocketClient.kt:47)
> 
> 
> 
> 

From sean.mullan at oracle.com  Wed Feb 13 13:12:35 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 13 Feb 2019 08:12:35 -0500
Subject: RFR 8218888: keytool -genkeypair should not have the -destalias
 option
In-Reply-To: <A0919773-0596-4827-82CD-9583471EDC97@oracle.com>
References: <A0919773-0596-4827-82CD-9583471EDC97@oracle.com>
Message-ID: <99b1882d-542c-cd7c-c4b7-6bb2d35cf9a7@oracle.com>

Looks good.

--Sean

On 2/12/19 10:31 PM, Weijun Wang wrote:
> The -genkeypair command mistakenly lists -destalias in its option table. 
> Here is the simple patch:
> 
> *diff --git 
> a/src/java.base/share/classes/sun/security/tools/keytool/Main.java 
> b/src/java.base/share/classes/sun/security/tools/keytool/Main.java*
> *--- a/src/java.base/share/classes/sun/security/tools/keytool/Main.java*
> *+++ b/src/java.base/share/classes/sun/security/tools/keytool/Main.java*
> @@ -211,7 +211,7 @@
>  ?? ? ? ? ? ? STORETYPE, PROVIDERNAME, ADDPROVIDER, PROVIDERCLASS,
>  ?? ? ? ? ? ? PROVIDERPATH, V, PROTECTED),
>  ?? ? ? ? GENKEYPAIR("Generates.a.key.pair",
> -? ? ? ? ? ? ALIAS, KEYALG, KEYSIZE, CURVENAME, SIGALG, DESTALIAS, DNAME,
> +? ? ? ? ? ? ALIAS, KEYALG, KEYSIZE, CURVENAME, SIGALG, DNAME,
>  ?? ? ? ? ? ? STARTDATE, EXT, VALIDITY, KEYPASS, KEYSTORE,
>  ?? ? ? ? ? ? STOREPASS, STORETYPE, PROVIDERNAME, ADDPROVIDER,
>  ?? ? ? ? ? ? PROVIDERCLASS, PROVIDERPATH, V, PROTECTED),
> 
> Thanks
> Max

From sean.mullan at oracle.com  Wed Feb 13 14:03:33 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 13 Feb 2019 09:03:33 -0500
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
Message-ID: <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>

On 2/12/19 6:28 PM, Open eSignForms wrote:
> Thanks for the update, Sean.? I'm a bit perplexed because I found the 
> original code works under Java 9 and Java 10, so it seems like the 
> change occurred in Java 11.

Sorry, that was a typo, I meant to say JDK 11.

> I don't see the modified version of the test case.? If you attached it, 
> it somehow didn't make it through to me.
> 
> If it's just a matter of making the code more correct, we'd love to make 
> the changes.? My concern, of course, is that we've already done millions 
> of XML digital signatures, so we need that to continue to verify 
> correctly (and even under Java 11, it seems that the verify code works 
> against previously digitally signed content) even if we now start 
> digitally signing using more update-to-date code.

The verification of pre-existing signatures should continue to work 
regardless of how this bug is addressed.

> Please send over the modified test case and I'll take a look.

It is attached to the bug report in the Attachments section: 
https://bugs.openjdk.java.net/browse/JDK-8218629 (make sure you download 
the one I added yesterday).

--Sean

> 
> Thanks!
> David
> 
> On 2/12/19 2:14 PM, Sean Mullan wrote:
>> The bug is now at https://bugs.openjdk.java.net/browse/JDK-8218629
>>
>> I have started looking at this issue and have some progress I can report.
>>
>> In JDK 9, we updated the version of the Apache XML Signature 
>> implementation in the JDK. Some of the marshalling code was rewritten 
>> such that it will throw Exceptions if legacy DOM level 1 methods were 
>> used to create XML content which is then passed into XMLObject and 
>> similar XMLSignature types that take DOMStructure objects. This is 
>> because the DOM level 1 methods do not support namespaces.
>>
>> I am still evaluating what the best fix is. However, you can 
>> workaround the issue by always using DOM level 3 methods which are 
>> namespace aware. For example, use Document.createElementNS instead of 
>> Document.createElement and Element.createAttributeNS instead of 
>> Element.createAttribute.
>>
>> Using legacy or non-namespace aware XML parsers or implementations is 
>> not recommended and the XML Signature Best Practices document gives 
>> some rationale: 
>> https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces 
>>
>> That said, this is a regression in behavior so it would be best if we 
>> could restore the previous behavior.
>>
>> I have attached a modified version of the test case to the bug report 
>> which no longer throws an Exception. Let me know if this is an 
>> acceptable workaround. Double-check the namespaces that I used to make 
>> sure they are correct.
>>
>> --Sean
>>
>>
>> On 2/7/19 11:23 AM, Open eSignForms wrote:
>>
>>> On 2/7/19 7:49 AM, Sean Mullan wrote:
>>>> On 2/6/19 4:51 PM, Open eSignForms wrote:
>>>>> I have a test version of the code that can run standalone and shows 
>>>>> the bug.? I'm not sure how best to transfer this information to the 
>>>>> forum for those to play with, but it is included below.
>>>>
>>>> Thanks, I can reproduce the issue now. I will need to debug further 
>>>> to see what might be causing this.
>>>>
>>>> --Sean

From dhiller at twitter.com  Wed Feb 13 16:21:45 2019
From: dhiller at twitter.com (Dean Hiller)
Date: Wed, 13 Feb 2019 09:21:45 -0700
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
Message-ID: <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>

I would highly suggest implementing your own for a much better
understanding.

I did implement something like what you want and in so doing realized I
like their decision.  ie. See the heirarchy here
https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/webpieces/nio/api/channels

The TCPChannel could be SSL or not SSL as there are two implementations.

If you do want an implementation that does what you want though, this
library does exactly that
https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2

which is used in the webpieces webserver
https://github.com/deanhiller/webpieces

That nio library is standalone even though it is in the webpieces repo.  I
mean, every component in webpieces is another stand-alone piece.

The downside is the library owns a thread which typical java libraries
avoid.  ie. it has to have a thread to poll the selector and read from all
the sockets to be fed to the thread pools, etc.  I think that is the main
reason they decided not to have this type of library.  They prefer not to
be running threads(which I agree, the jdk shouldn't).

later,
Dean




On Tue, Feb 12, 2019 at 7:54 PM Sean Mullan <sean.mullan at oracle.com> wrote:

> Hi Andi,
>
> TLS/JSSE topics are best discussed on the security-dev alias, so I am
> copying that list for more discussion and -bcc-ing core-libs-dev.
>
> --Sean
>
> On 2/11/19 3:29 PM, Andi Mullaraj wrote:
> > Hi java-core community,
> >
> > I have been directed to this channel to discuss matters related to Java
> > performant ssl communications.  Maybe this is a topic that has been
> > discussed in the past, in which case I would appreciate if someone
> pointed
> > me to that particular topic.
> >
> > Back in 2002 I personally applauded the java.nio.channels (jdk1.4)
> package,
> > realizing that there was no way to port this to the secure
> communications,
> > due to lack of a comparable implementation for SSL.  But I thought it was
> > going to just be matter of time.  A couple of years ago I had to go back
> > search for it, and was kind of surprised to find the following in
> >
> http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG
> > :
> >
> > --- begin quote ---
> > Newcomers to the API may wonder "Why not just have an SSLSocketChannel
> > which extends java.nio.channels.SocketChannel?" There are two main
> reasons:
> >
> > 1. There were a lot of very difficult questions about what a
> > SSLSocketChannel should be, including its class hierarchy and how it
> should
> > interoperate with Selectors and other types of SocketChannels. Each
> > proposal brought up more questions than answers. It was noted that any
> new
> > API abstraction extended to work with SSL/TLS would require the same
> > significant analysis and could result in large and complex APIs.
> > 2. Any JSSE implementation of a new API would be free to choose the
> "best"
> > I/O & compute strategy, but hiding any of these details is inappropriate
> > for those applications needing full control. Any specific implementation
> > would be inappropriate for some application segment.
> > --- end quote ---
> >
> > It has been a while since this was stated, and I would really like to
> > revisit it.  I personally believe that the question #1 has a quite
> natural
> > answer, while #2 should not really be a concern if we adhere to the spi
> > model where users can bring their own implementation if needed.  I know
> > because I have also implemented it (but would like to discuss that in a
> > later stage, if it comes to it).
> >
> > The benefit of such implementation would be immense.  Imagine many Java
> > services written with nio and which struggle to move to SSL due to the
> > great complexity of using SSLEngine (zookeeper service to name one),
> while
> > all they would need to do (if SSLSocketChannels were available) is to
> > instantiate an instance of SSLSocketChannel/SSLSelector when the security
> > is required and the rest would stay the same (as in case of plain
> > communication using SocketChannel/Selector).  Another important use case
> is
> > the advent of IOT, where millions of devices, with relatively low
> > throughput would want to protect their communication via SSL.
> >
> > The ways I have seen the community deal with this are mainly:
> >
> > 1. Go through the pain of learning SSLEngine (and hope to get it right)
> > 2. Build their services around tested libraries (like Jetty, which handle
> > the SSL offload but don't resurface it in SocketChannel/Selector
> paradigm,
> > that also come with their huge set of dependencies, bringing in
> unavoidable
> > version collisions)
> > 3. Use proxies (nginx, ha) to deal with the high number of SSL
> connections
> > and divide the load by scaling horizontally in the back end (making for a
> > harder deployment model)
> >
> > We can make this a lot easier!
> >
> > Any feedback is greatly appreciated,
> > Best,
> >
> > Andi Mullaraj
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190213/e7aab0bd/attachment-0001.html>

From dhiller at twitter.com  Wed Feb 13 16:26:04 2019
From: dhiller at twitter.com (Dean Hiller)
Date: Wed, 13 Feb 2019 09:26:04 -0700
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
Message-ID: <CAN1v_zpjX1Jjz2y3awS4rX9TDhLHZX9q3fcqy5yvrGC00T2tyA@mail.gmail.com>

I forgot about and forgot to mention there is a special backpressure in the
webpieces implementation.

Say A connects through socket to B and B has this webpieces
channelmanager.  Let's say C is the client code of B.  If C does not
consume the data fast enough from A, channelmanager deregisters the socket
to A to PAUSE reading from A until C catches up.  Once C catches up, it
re-registers the socket un-pausing.  This yields a graceful performance
degredation AND it turns out an increase in performance due to less
'jittering' ...a term from the audio world.  It's a very complex topic and
hard to explain the reasons behind it.

Anyways, it was quite an interesting experience.



On Wed, Feb 13, 2019 at 9:21 AM Dean Hiller <dhiller at twitter.com> wrote:

> I would highly suggest implementing your own for a much better
> understanding.
>
> I did implement something like what you want and in so doing realized I
> like their decision.  ie. See the heirarchy here
>
> https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/webpieces/nio/api/channels
>
> The TCPChannel could be SSL or not SSL as there are two implementations.
>
> If you do want an implementation that does what you want though, this
> library does exactly that
>
> https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2
>
> which is used in the webpieces webserver
> https://github.com/deanhiller/webpieces
>
> That nio library is standalone even though it is in the webpieces repo.  I
> mean, every component in webpieces is another stand-alone piece.
>
> The downside is the library owns a thread which typical java libraries
> avoid.  ie. it has to have a thread to poll the selector and read from all
> the sockets to be fed to the thread pools, etc.  I think that is the main
> reason they decided not to have this type of library.  They prefer not to
> be running threads(which I agree, the jdk shouldn't).
>
> later,
> Dean
>
>
>
>
> On Tue, Feb 12, 2019 at 7:54 PM Sean Mullan <sean.mullan at oracle.com>
> wrote:
>
>> Hi Andi,
>>
>> TLS/JSSE topics are best discussed on the security-dev alias, so I am
>> copying that list for more discussion and -bcc-ing core-libs-dev.
>>
>> --Sean
>>
>> On 2/11/19 3:29 PM, Andi Mullaraj wrote:
>> > Hi java-core community,
>> >
>> > I have been directed to this channel to discuss matters related to Java
>> > performant ssl communications.  Maybe this is a topic that has been
>> > discussed in the past, in which case I would appreciate if someone
>> pointed
>> > me to that particular topic.
>> >
>> > Back in 2002 I personally applauded the java.nio.channels (jdk1.4)
>> package,
>> > realizing that there was no way to port this to the secure
>> communications,
>> > due to lack of a comparable implementation for SSL.  But I thought it
>> was
>> > going to just be matter of time.  A couple of years ago I had to go back
>> > search for it, and was kind of surprised to find the following in
>> >
>> http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG
>> > :
>> >
>> > --- begin quote ---
>> > Newcomers to the API may wonder "Why not just have an SSLSocketChannel
>> > which extends java.nio.channels.SocketChannel?" There are two main
>> reasons:
>> >
>> > 1. There were a lot of very difficult questions about what a
>> > SSLSocketChannel should be, including its class hierarchy and how it
>> should
>> > interoperate with Selectors and other types of SocketChannels. Each
>> > proposal brought up more questions than answers. It was noted that any
>> new
>> > API abstraction extended to work with SSL/TLS would require the same
>> > significant analysis and could result in large and complex APIs.
>> > 2. Any JSSE implementation of a new API would be free to choose the
>> "best"
>> > I/O & compute strategy, but hiding any of these details is inappropriate
>> > for those applications needing full control. Any specific implementation
>> > would be inappropriate for some application segment.
>> > --- end quote ---
>> >
>> > It has been a while since this was stated, and I would really like to
>> > revisit it.  I personally believe that the question #1 has a quite
>> natural
>> > answer, while #2 should not really be a concern if we adhere to the spi
>> > model where users can bring their own implementation if needed.  I know
>> > because I have also implemented it (but would like to discuss that in a
>> > later stage, if it comes to it).
>> >
>> > The benefit of such implementation would be immense.  Imagine many Java
>> > services written with nio and which struggle to move to SSL due to the
>> > great complexity of using SSLEngine (zookeeper service to name one),
>> while
>> > all they would need to do (if SSLSocketChannels were available) is to
>> > instantiate an instance of SSLSocketChannel/SSLSelector when the
>> security
>> > is required and the rest would stay the same (as in case of plain
>> > communication using SocketChannel/Selector).  Another important use
>> case is
>> > the advent of IOT, where millions of devices, with relatively low
>> > throughput would want to protect their communication via SSL.
>> >
>> > The ways I have seen the community deal with this are mainly:
>> >
>> > 1. Go through the pain of learning SSLEngine (and hope to get it right)
>> > 2. Build their services around tested libraries (like Jetty, which
>> handle
>> > the SSL offload but don't resurface it in SocketChannel/Selector
>> paradigm,
>> > that also come with their huge set of dependencies, bringing in
>> unavoidable
>> > version collisions)
>> > 3. Use proxies (nginx, ha) to deal with the high number of SSL
>> connections
>> > and divide the load by scaling horizontally in the back end (making for
>> a
>> > harder deployment model)
>> >
>> > We can make this a lot easier!
>> >
>> > Any feedback is greatly appreciated,
>> > Best,
>> >
>> > Andi Mullaraj
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190213/f3dd9848/attachment-0001.html>

From yozons at gmail.com  Wed Feb 13 19:20:04 2019
From: yozons at gmail.com (Open eSignForms)
Date: Wed, 13 Feb 2019 11:20:04 -0800
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
 <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
Message-ID: <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>

Thanks, Sean.? I was able to find the updated test case source code.

A preliminary review seems to show worthwhile changes to our code.? That 
is, the namespaces and such seem to make sense as you have them.

In particular, the use of:

domSignContext.putNamespacePrefix(XMLSignature.XMLNS, "dsig");

and adding this namespace to additional elements we added:

 ??? ??? ??? String xmlns = "http://uri.etsi.org/01903/v1.1.1#";

seem reasonable and an acceptable workaround for us.? I'm not sure if 
those were oversights from before, but likely were the result of it 
being based on Oracle/Java example code from Java 6 days...

We'll incorporate your namespace changes in our code and test, but this 
seems like it will work as I was able to confirm that your fixed version 
seems to run on Java 10 and Java 11.

It is interesting that the fixed code, though, generates different 
output on Java 10 and Java 11.? I'm not positive, but it seems that Java 
11 adds '&#13;' to the end of many lines that aren't present in Java 
10's output.

Under Java 10, a test run products this result:

<snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
timestamp="2019-02-13T11:02:30-08:00" type="document"><![CDATA[<html 
xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
document</p></body></html>]]><dsig:Signature 
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod 
Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Zqmii2rv6C+bFM+CSO3s8sAGOrl67HEnv4t8XUgQd5iguf9m7vcVJn3pJz5inCZfx5V9lTtDaj0u
xbZSyWE5kQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
URI="#KeyInfo_ID"><dsig:DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>kZM1pJpRXoeDuolU+kyK41BotQoW7ir5lfg/nNSMoC69bUC2OHzWbQ5Kug0gtrLVIuq5HRdzk6zc
2N2jA0WKMQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
URI="#QualifyingProperties_ID"><dsig:DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>AFx1CJi739IWZwJL1Y5KU2B+ZioT3ONMBLwLTdT/NTysV/+KYF7lZMgEHaGtLxvc6haIKKKzZisr
r2YDQVgs5w==</dsig:DigestValue></dsig:Reference><dsig:Reference 
URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>jhVDd7nvr4s2bu7LRNHb7yj2gQRzAE7fXcsgonq2Qsn4EWNfpqNEVUViIy9jh86tTs5ZiakaGAEs
l9YV1hNnEg==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>izJCFA5lBOjc7zhlc/1Wrsu+/jd0o0aPtemm4hM7aMKJvzkKddhjaHRY9iX4qtMZJtl7L1qj4YGN
hxHc2Wjuj6F1ZFD9asPf/kumVliAqTwNvhfyVfmpbaZtzQVtOQWhNIC1PivbPfbwTKr1yztLbo0K
B8TJWWiqHBjgEjlhw8X84buXVsCIUaAkOJG73Q0x9hMDVPf5y5R56xknLwjwzQPdveMI3zKvKvq5
vj1UPKVqlCjrjPa1HR0g4wEOjL51HCK/EWVbB4LLRAL59KB6ERW01CaRX1crGzQw6wz5eFVWK/0o
NcIdn4wc7rWPdYfT362iqqJMzIyUQGHmk7FVD/1Nky2wlEvYaRk7PrpbXo8ISSPB+RQM+EWQbYCP
RVT5oq6d4dnu0cUuj/wG8Ng7FIfSY3C8Ds9cw7CTKi/Dbmw3oE8yaJHNqfjEMAW2tmqQmuC4ZRXG
7DfqeNdgiHwoQLdLzD/vj/00SWmcM67NWQNwblbPJ5MhVeFmh/fIbd7bkIyANbw1FAYIj1b+Hf8b
cZzC+lNecKxzkcY9/VZ3ny4kBBQmxwBLlojBa2ll8B9m+sYN0enRGwy9GG2eBY2Gb53KqAALQAUU
kjXjJYxrQh64Y2RTAgp01Nbfj7QbvuKW93YDR6cpjNTM7EfJfQM/cz+VHHngFCRr/N0/WmM4j0A=</dsig:SignatureValue><dsig:KeyInfo 
Id="KeyInfo_ID"><dsig:KeyName>c42c747f-0f03-46a3-8ae8-81fc95464c8f</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9
Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW
I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU
MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX
oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ
Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB
snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z
Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n
C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu
X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z
VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2
NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh
YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz
Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh
bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw
ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ
RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi
MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A
5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6
drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/
pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn
bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy
JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW
Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR
onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz
GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj
K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC
JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc
2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI
8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl
kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o
97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY
LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N
SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E
aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg
Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV
Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC
AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q
3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX
SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D
pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+
aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx
GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P
TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf
hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z
IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0
FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN
BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk
zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw
LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz
syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO
KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK
GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u
FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/
aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX
3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy
VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
ns0:Id="QualifyingProperties_ID" 
xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:02:30-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
Id="OpenESignForms_Seal_ID" 
Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
ns0:DeploymentHostAddress="192.1.1.1" 
xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
ns1:DeploymentHostName="open.esignforms.com" 
xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
ns2:DeploymentId="1.1.1.1" 
xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
ns3:SignerAddress="192.1.1.1" 
xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
ns4:SignerAgent="No-Browser-Test" 
xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
ns5:Timestamp="2019-02-13T11:02:30-08:00" 
xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot>

while when run under Java 11 it shows what seems to be the same 
(clearly, the digest/hashes aren't the same as the 'timestamp' differs 
because they are actual times) except for lots of '&#13;' added to the 
digests and signatures:

<snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
timestamp="2019-02-13T11:01:22-08:00" type="document"><![CDATA[<html 
xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
document</p></body></html>]]><dsig:Signature 
xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod 
Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LdB/ydGxr3VUoTshQtOvQNmMZmt2OHgLax4tSk9Lqb1c+X1h4Uc/RBVXwfI9QrVnITBz85Fi8Bwr&#13;
7wyMjw84cA==</dsig:DigestValue></dsig:Reference><dsig:Reference 
URI="#KeyInfo_ID"><dsig:DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>FkpexxTwhpCPHHsMrKGnBXE5hkZ/x10ArpzjX6ltYfOilvVAubzc9sNPwo6phw//ot1rSKPU5jTB&#13;
LRD7p7t50g==</dsig:DigestValue></dsig:Reference><dsig:Reference 
URI="#QualifyingProperties_ID"><dsig:DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LxB0xAsDxKqeyCflaSUgMQOMhoxP4Gl9GfvlpCiL/gd9rz36qG4roaFRl+4PBC+IxzGiRDOqzQYX&#13;
x6gSn5d1IQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Pqd+9yaeBMytcG1sTTpuq+Wrd3lZSC18j7lv6VQ6LjUSz9VN7uwVNNn1E79mY8H6XUI2jbd/IozM&#13;
oba2KF46ig==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>IpdHZtzSw8TOnp0gfKMaCp30jJAPP8YCAIg4OBvRobIwHBFrG+O9v7peXRRA5nXi+fm4bdemi5jI&#13;
/N2smS7W6lKMMeTzrYNJEmpD/0c/SVCs0M1peZmiWZD/F6GYP6RkhZfTglk9skKsZIme3W5lHL5e&#13;
vTFno50J32oW0chq/jPzD42snoVQmVKS9wqqybGgRrm1W2RSWfziNo7QjXtJuR5eVuCtqpOLrGrS&#13;
J0aLaaNLucia/6cJyZ13mz7131Lj2Y4oJbrbpzvrDY5xDfFDK+bRRMR3DCvTLgKcZZz5zxcAKYL8&#13;
lG64U/tsmd/ZVn+d+fJGH03hPdvY/wMW7MTN1k/6S95PiNdx0cLeP0HLCug9zWiC7vUkrVDrsO9i&#13;
qsvSYKcAH8vQlG1arZgGJn88Hg8EGjmmWXs15ulU3Lm8TOTXl/xi6O4stSgMi9dFSsE1ISHAPaxN&#13;
D3Rqg7Bv7p/iEVn0xXq/C9AI3iwrpHbip8K81uJOsaiZgwR5D40XyYLV9FUPIacRclfT5EJKsx6k&#13;
jYiprWMOMjmnlJwj2vI8zG6sYLVJdQywm2isWu5eHSw39Wof0BYfDeOzh0LrifUcnt86no5fUEOI&#13;
OlNbqOO7rjuxtb+gt1iO2dTHfQhG99BCBQhC7AEMp67fIlPjEOECXldDTpzPMZ1K6cPlk22rpvc=</dsig:SignatureValue><dsig:KeyInfo 
Id="KeyInfo_ID"><dsig:KeyName>184a40b0-78b6-4070-a7d7-1497078a06e4</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9&#13;
Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW&#13;
I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU&#13;
MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX&#13;
oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ&#13;
Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB&#13;
snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z&#13;
Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n&#13;
C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu&#13;
X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z&#13;
VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2&#13;
NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh&#13;
YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz&#13;
Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh&#13;
bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw&#13;
ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ&#13;
RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi&#13;
MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A&#13;
5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6&#13;
drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/&#13;
pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn&#13;
bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy&#13;
JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW&#13;
Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR&#13;
onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz&#13;
GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj&#13;
K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC&#13;
JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc&#13;
2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI&#13;
8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl&#13;
kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o&#13;
97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY&#13;
LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N&#13;
SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E&#13;
aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg&#13;
Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV&#13;
Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC&#13;
AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q&#13;
3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX&#13;
SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D&#13;
pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+&#13;
aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx&#13;
GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P&#13;
TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf&#13;
hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z&#13;
IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0&#13;
FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN&#13;
BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk&#13;
zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw&#13;
LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz&#13;
syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO&#13;
KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK&#13;
GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u&#13;
FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/&#13;
aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX&#13;
3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy&#13;
VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
ns0:Id="QualifyingProperties_ID" 
xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:01:22-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
Id="OpenESignForms_Seal_ID" 
Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
ns0:DeploymentHostAddress="192.1.1.1" 
xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
ns1:DeploymentHostName="open.esignforms.com" 
xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
ns2:DeploymentId="1.1.1.1" 
xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
ns3:SignerAddress="192.1.1.1" 
xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
ns4:SignerAgent="No-Browser-Test" 
xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
ns5:Timestamp="2019-02-13T11:01:22-08:00" 
xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot>


It's particularly odd because hex 13 isn't a typical character (^S).

Any idea what that difference is about for the base64 digests and 
signatures?

David


On 2/13/19 6:03 AM, Sean Mullan wrote:
> On 2/12/19 6:28 PM, Open eSignForms wrote:
>> Thanks for the update, Sean.? I'm a bit perplexed because I found the 
>> original code works under Java 9 and Java 10, so it seems like the 
>> change occurred in Java 11.
>
> Sorry, that was a typo, I meant to say JDK 11.
>
>> I don't see the modified version of the test case.? If you attached 
>> it, it somehow didn't make it through to me.
>>
>> If it's just a matter of making the code more correct, we'd love to 
>> make the changes.? My concern, of course, is that we've already done 
>> millions of XML digital signatures, so we need that to continue to 
>> verify correctly (and even under Java 11, it seems that the verify 
>> code works against previously digitally signed content) even if we 
>> now start digitally signing using more update-to-date code.
>
> The verification of pre-existing signatures should continue to work 
> regardless of how this bug is addressed.
>
>> Please send over the modified test case and I'll take a look.
>
> It is attached to the bug report in the Attachments section: 
> https://bugs.openjdk.java.net/browse/JDK-8218629 (make sure you 
> download the one I added yesterday).
>
> --Sean
>
>>
>> Thanks!
>> David
>>
>> On 2/12/19 2:14 PM, Sean Mullan wrote:
>>> The bug is now at https://bugs.openjdk.java.net/browse/JDK-8218629
>>>
>>> I have started looking at this issue and have some progress I can 
>>> report.
>>>
>>> In JDK 9, we updated the version of the Apache XML Signature 
>>> implementation in the JDK. Some of the marshalling code was 
>>> rewritten such that it will throw Exceptions if legacy DOM level 1 
>>> methods were used to create XML content which is then passed into 
>>> XMLObject and similar XMLSignature types that take DOMStructure 
>>> objects. This is because the DOM level 1 methods do not support 
>>> namespaces.
>>>
>>> I am still evaluating what the best fix is. However, you can 
>>> workaround the issue by always using DOM level 3 methods which are 
>>> namespace aware. For example, use Document.createElementNS instead 
>>> of Document.createElement and Element.createAttributeNS instead of 
>>> Element.createAttribute.
>>>
>>> Using legacy or non-namespace aware XML parsers or implementations 
>>> is not recommended and the XML Signature Best Practices document 
>>> gives some rationale: 
>>> https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces 
>>>
>>> That said, this is a regression in behavior so it would be best if 
>>> we could restore the previous behavior.
>>>
>>> I have attached a modified version of the test case to the bug 
>>> report which no longer throws an Exception. Let me know if this is 
>>> an acceptable workaround. Double-check the namespaces that I used to 
>>> make sure they are correct.
>>>
>>> --Sean
>>>
>>>
>>> On 2/7/19 11:23 AM, Open eSignForms wrote:
>>>
>>>> On 2/7/19 7:49 AM, Sean Mullan wrote:
>>>>> On 2/6/19 4:51 PM, Open eSignForms wrote:
>>>>>> I have a test version of the code that can run standalone and 
>>>>>> shows the bug.? I'm not sure how best to transfer this 
>>>>>> information to the forum for those to play with, but it is 
>>>>>> included below.
>>>>>
>>>>> Thanks, I can reproduce the issue now. I will need to debug 
>>>>> further to see what might be causing this.
>>>>>
>>>>> --Sean

From amir.khassaia at gmail.com  Wed Feb 13 21:16:36 2019
From: amir.khassaia at gmail.com (Amir Khassaia)
Date: Thu, 14 Feb 2019 08:16:36 +1100
Subject: Not possible to disable new TLS extensions for TLS 1.2 connections
In-Reply-To: <3dfb3505-dd0e-3b91-17a0-c6165d7a1069@oracle.com>
References: <CAJ3+Awc9F5phKuMZZ1ohYtkhBHKvydvVioHJGpCkRaThAD6t=g@mail.gmail.com>
 <3dfb3505-dd0e-3b91-17a0-c6165d7a1069@oracle.com>
Message-ID: <CAJ3+AweJFwhxFitO5ALd6SPAhsOrODFFMaKtvd68zejjFKqX+w@mail.gmail.com>

Hi Xuelei,
There were 2 distinct cases of change of behaviour.

   - The "CN=invalid2.invalid, OU="No SNI provided" reliably works without
   SNI in Java 8 but is indeed fixed by having an SNI included which perhaps
   was needed all along. This one is reported by XMPP/TLS connection from
   talk.google.com:5222
   - The aborted handshake case (client_hello traces that I've provided)
   this happened with a hardware device which was replicable with an SSL
   socket handshake program that I referenced in the gist. Unfortunately
   replication requires a specific device model so it wont be possible to see
   it for yourself. The workaround there was to either downgrade JRE to < 11
   or to switch JRE globally to use TLS 1.0 or TLS 1.1 via the system
   property. This is where your proposed enhancement will be of great help as
   it will allow a per connection type decision.


On Wed, Feb 13, 2019 at 3:01 PM Xuelei Fan <xuelei.fan at oracle.com> wrote:

> Hi Amir,
>
> It should be rare now the a TLS vendor cannot ignore unknown extensions.
>
>  > "issuer": "CN=invalid2.invalid, OU="No SNI provided;
>  > please fix your client."",
> The error message encapsulated in the certificate does not sound right
> to me.  Is it caused by the absence of SNI extension?
>
> Did you have a test case that I can reproduce the problem?
>
> Thanks & Regards,
> Xuelei
>
>
> On 1/7/2019 9:27 PM, Amir Khassaia wrote:
> > Xuelei,
> > The certificate in the connection is a red herring and not important.
> > It's actually a very unusual behaviour by talk.google.com
> > <http://talk.google.com> endpoint to encapsulate an error message
> inside
> > a certificate.
> >
> > As per the output I included:
> >
> > /"certificate" : { />/    "version"            : "v3", />/    "serial
> number"      : "00 90 76 89 18 E9 33 93 A0", />/    "signature algorithm":
> "SHA256withRSA", />/    "issuer"             : "CN=invalid2.invalid, OU="No
> SNI provided; />/please fix your client."", />/    "not before"         :
> "2015-01-01 11:00:00.000 AEDT", />/    "not  after"         : "2030-01-01
> 11:00:00.000 AEDT", />/    "subject"            : "CN=invalid2.invalid,
> OU="No SNI provided; />/please fix your client."",/
> >
> > /
> > /
> >
> > This certificate simply masks the TLS interoperability issue as an
> > untrusted certificate issue.
> >
> > The fact is, some of the extensions sent by JSSE are changes to TLS 1.2
> > to support TLS 1.3, this however affects some clients adversely in
> > practice and usually JDK provides properties to turn new enhancements
> > off and work around such behaviour, for the extensions I mentioned this
> > is not provided and hence they are always sent for client sockets unless
> > TLSv1.2 is not in use.
> >
> > The impact to us is that upgrading to JDK11 means for some endpoints or
> > devices that are not 100% compliant to the spec the security is reduced
> > as we have to now work around to drop connections to these to TLSv1.1 or
> > TLS1.0 or not to move to Java 11 at all.
> >
> > My request is simply to have all of the new extensions configurable on
> > individual basis so that they can be turned off if needed for
> > compatibility just like most other security enhancements that were
> > delivered in the past.
> >
> > It appears some of the issues can come from
> >
> > - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can
> > disabled at least
> >
> > -signature_algorithms_cert and supported_versions extensions which seem
> > to be hardcoded for TLS 1.2 (I was not able to conclusively identify
> > which of these caused my troubles)
> >
> > https://tools.ietf.org/html/rfc8446#section-1.3 does say that TLS 1.2
> > clients are affected but in an optional manner.Just today I've
> > encountered another Java 11 interop issue with TLS but this time with a
> > physical device which can have a long shelf life yet running a simple
> > client socket handshake abruptly terminates the connection upon client
> > hello (no server_hello at all), and downgrading the JRE below 11 works
> > fine. I'm including a trace for that as well:
> >
> >
> > javax.net.ssl|DEBUG|01|main|2019-01-0813:40:14.395
> AEDT|SSLCipher.java:437|jdk.tls.keyLimits:   entry = AES/GCM/NoPadding
> KeyUpdate2^37. AES/GCM/NOPADDING:KEYUPDATE =137438953472
> >
> > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433
> > AEDT|ServerNameExtension.java:255|Unable to indicate server name
> >
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> > server_name
> >
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> > status_request
> >
> > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443
> > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not
> > supported by the underlying providers
> >
> > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444
> > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not
> > supported by the underlying providers
> >
> > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449
> > AEDT|AlpnExtension.java:161|No available application protocols
> >
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> > application_layer_protocol_negotiation
> >
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> > status_request_v2
> >
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453
> > AEDT|ClientHello.java:651|Produced ClientHello handshake message (
> >
> > "ClientHello": {
> >
> > "client version"      : "TLSv1.2",
> >
> > "random"              : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24 7F 34 3D
> > 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68",
> >
> > "session id"          : "",
> >
> > "cipher suites"       :
> > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
> > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
> > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
> > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
> > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]",
> >
> > "compression methods" : "00",
> >
> > "extensions"          : [
> >
> > "supported_groups (10)": {
> >
> > "versions": [secp256r1, secp384r1, secp521r1, secp160k1]
> >
> >      },
> >
> > "ec_point_formats (11)": {
> >
> > "formats": [uncompressed]
> >
> >      },
> >
> > "signature_algorithms (13)": {
> >
> > "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
> > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
> > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
> > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
> > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224,
> > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
> >
> >      },
> >
> > "signature_algorithms_cert (50)": {
> >
> > "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
> > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
> > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
> > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
> > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224,
> > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
> >
> >      },
> >
> > "extended_master_secret (23)": {
> >
> >        <empty>
> >
> >      },
> >
> > "supported_versions (43)": {
> >
> > "versions": [TLSv1.2, TLSv1.1]
> >
> >      },
> >
> > "renegotiation_info (65,281)": {
> >
> > "renegotiated connection": [<no renegotiated connection>]
> >
> >      }
> >
> >    ]
> >
> > }
> >
> > )
> >
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455
> > AEDT|Alert.java:232|Received alert message (
> >
> > "Alert": {
> >
> > "level"      : "fatal",
> >
> > "description": "handshake_failure"
> >
> > }
> >
> > )
> >
> > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456
> > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE): Received fatal
> > alert: handshake_failure (
> >
> > "throwable" : {
> >
> >    javax.net.ssl.SSLHandshakeException: Received fatal alert:
> > handshake_failure
> >
> >      at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
> >
> >      at
> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> >
> >      at
> >
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
> >
> >      at
> > java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
> >
> >      at
> >
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
> >
> >      at
> > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
> >
> >      at
> > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
> >
> >      at
> >
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
> >
> >      at
> >
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
> >
> >      at SslSocketClient.main(SslSocketClient.kt:47)}
> >
> >
> > )
> >
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
> > AEDT|SSLSocketImpl.java:1361|close the underlying socket
> >
> > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
> > AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative)
> >
> > Exception in thread "main" javax.net.ssl.SSLHandshakeException: Received
> > fatal alert: handshake_failure
> >
> >    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
> >
> >    at java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> >
> >    at
> >
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
> >
> >    at
> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
> >
> >    at
> >
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
> >
> >    at
> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
> >
> >    at
> > java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
> >
> >    at
> >
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
> >
> >    at
> >
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
> >
> >    at SslSocketClient.main(SslSocketClient.kt:47)
> >
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190214/4107af66/attachment-0001.html>

From yozons at gmail.com  Wed Feb 13 21:23:54 2019
From: yozons at gmail.com (Open eSignForms)
Date: Wed, 13 Feb 2019 13:23:54 -0800
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
 <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
 <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
Message-ID: <32d2fff5-1be5-1201-225e-15ac60982067@gmail.com>

I checked the ETSI XAdES spec 
(http://uri.etsi.org/01903/v1.1.1/ts_101903v010101p.pdf) and it doesn't 
show any namespace on their entries for their QualifyingProperties 
element and all sub-elements under the ETSI example's element <ds:Object>.

But, their specification does show element <QualifyingProperties> should 
be under the namespace "http://uri.etsi.org/01903/v1.1.1#" as you added 
in your fixed code.

That is, when my snapshot element that's digitally signed using the 
below, it fails with the NAMESPACE_ERR exception:

<snapshot *xmlns="http://open.esignforms.com/XMLSchema/2011"* 
timestamp="2019-02-13T11:02:30-08:00" type="document">

But if my snapshot is set up with the ETSI namespace URI, it works:

<snapshot *xmlns="**http://uri.etsi.org/01903/v1.1.1#**" * 
timestamp="2019-02-13T11:02:30-08:00" type="document">

So, it seems that the XMLSignature is noting that the 
<QualifyingProperties> belongs to the default namespace in both cases, 
but of course expects that particular element to belong to the ETSI 
namespace, not ours.

I presume that's correct behavior; I just didn't think that the 
XMLSignature.sign() knew about and was limited to that specific namespace.

If you agree that this is the correct behavior, I think it's not really 
a bug in Java 11, though it fails backwards compatibility.

The only oddity that remains is what I mentioned below with all the 
"&#13;" characters in the digests/signatures that appear in Java 11.? 
They sure look odd compared to simple line breaks that presumably were 
emitted before.

David



On 2/13/19 11:20 AM, Open eSignForms wrote:
> Thanks, Sean.? I was able to find the updated test case source code.
>
> A preliminary review seems to show worthwhile changes to our code.? 
> That is, the namespaces and such seem to make sense as you have them.
>
> In particular, the use of:
>
> domSignContext.putNamespacePrefix(XMLSignature.XMLNS, "dsig");
>
> and adding this namespace to additional elements we added:
>
> ??? ??? ??? String xmlns = "http://uri.etsi.org/01903/v1.1.1#";
>
> seem reasonable and an acceptable workaround for us.? I'm not sure if 
> those were oversights from before, but likely were the result of it 
> being based on Oracle/Java example code from Java 6 days...
>
> We'll incorporate your namespace changes in our code and test, but 
> this seems like it will work as I was able to confirm that your fixed 
> version seems to run on Java 10 and Java 11.
>
> It is interesting that the fixed code, though, generates different 
> output on Java 10 and Java 11.? I'm not positive, but it seems that 
> Java 11 adds '&#13;' to the end of many lines that aren't present in 
> Java 10's output.
>
> Under Java 10, a test run products this result:
>
> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
> timestamp="2019-02-13T11:02:30-08:00" type="document"><![CDATA[<html 
> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
> document</p></body></html>]]><dsig:Signature 
> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod 
> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Zqmii2rv6C+bFM+CSO3s8sAGOrl67HEnv4t8XUgQd5iguf9m7vcVJn3pJz5inCZfx5V9lTtDaj0u 
>
> xbZSyWE5kQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
> URI="#KeyInfo_ID"><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>kZM1pJpRXoeDuolU+kyK41BotQoW7ir5lfg/nNSMoC69bUC2OHzWbQ5Kug0gtrLVIuq5HRdzk6zc
> 2N2jA0WKMQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
> URI="#QualifyingProperties_ID"><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>AFx1CJi739IWZwJL1Y5KU2B+ZioT3ONMBLwLTdT/NTysV/+KYF7lZMgEHaGtLxvc6haIKKKzZisr
> r2YDQVgs5w==</dsig:DigestValue></dsig:Reference><dsig:Reference 
> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>jhVDd7nvr4s2bu7LRNHb7yj2gQRzAE7fXcsgonq2Qsn4EWNfpqNEVUViIy9jh86tTs5ZiakaGAEs
> l9YV1hNnEg==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>izJCFA5lBOjc7zhlc/1Wrsu+/jd0o0aPtemm4hM7aMKJvzkKddhjaHRY9iX4qtMZJtl7L1qj4YGN 
>
> hxHc2Wjuj6F1ZFD9asPf/kumVliAqTwNvhfyVfmpbaZtzQVtOQWhNIC1PivbPfbwTKr1yztLbo0K 
>
> B8TJWWiqHBjgEjlhw8X84buXVsCIUaAkOJG73Q0x9hMDVPf5y5R56xknLwjwzQPdveMI3zKvKvq5 
>
> vj1UPKVqlCjrjPa1HR0g4wEOjL51HCK/EWVbB4LLRAL59KB6ERW01CaRX1crGzQw6wz5eFVWK/0o 
>
> NcIdn4wc7rWPdYfT362iqqJMzIyUQGHmk7FVD/1Nky2wlEvYaRk7PrpbXo8ISSPB+RQM+EWQbYCP 
>
> RVT5oq6d4dnu0cUuj/wG8Ng7FIfSY3C8Ds9cw7CTKi/Dbmw3oE8yaJHNqfjEMAW2tmqQmuC4ZRXG 
>
> 7DfqeNdgiHwoQLdLzD/vj/00SWmcM67NWQNwblbPJ5MhVeFmh/fIbd7bkIyANbw1FAYIj1b+Hf8b 
>
> cZzC+lNecKxzkcY9/VZ3ny4kBBQmxwBLlojBa2ll8B9m+sYN0enRGwy9GG2eBY2Gb53KqAALQAUU 
>
> kjXjJYxrQh64Y2RTAgp01Nbfj7QbvuKW93YDR6cpjNTM7EfJfQM/cz+VHHngFCRr/N0/WmM4j0A=</dsig:SignatureValue><dsig:KeyInfo 
> Id="KeyInfo_ID"><dsig:KeyName>c42c747f-0f03-46a3-8ae8-81fc95464c8f</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9 
>
> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW 
>
> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU 
>
> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX 
>
> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ 
>
> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB 
>
> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z 
>
> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n 
>
> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu 
>
> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z 
>
> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2 
>
> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh 
>
> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz 
>
> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh 
>
> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw 
>
> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ 
>
> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi 
>
> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A 
>
> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6 
>
> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/ 
>
> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn 
>
> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy 
>
> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW 
>
> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR 
>
> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz 
>
> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj 
>
> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC 
>
> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc 
>
> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI 
>
> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl 
>
> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o 
>
> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY 
>
> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N 
>
> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E 
>
> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg 
>
> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV 
>
> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC 
>
> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q 
>
> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX 
>
> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D 
>
> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+ 
>
> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx 
>
> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P 
>
> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf 
>
> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z 
>
> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0 
>
> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN 
>
> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk 
>
> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw 
>
> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz 
>
> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO 
>
> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK 
>
> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u 
>
> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/ 
>
> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX 
>
> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy 
>
> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
> ns0:Id="QualifyingProperties_ID" 
> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:02:30-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
> Id="OpenESignForms_Seal_ID" 
> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
> ns0:DeploymentHostAddress="192.1.1.1" 
> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
> ns1:DeploymentHostName="open.esignforms.com" 
> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
> ns2:DeploymentId="1.1.1.1" 
> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
> ns3:SignerAddress="192.1.1.1" 
> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
> ns4:SignerAgent="No-Browser-Test" 
> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
> ns5:Timestamp="2019-02-13T11:02:30-08:00" 
> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot>
>
> while when run under Java 11 it shows what seems to be the same 
> (clearly, the digest/hashes aren't the same as the 'timestamp' differs 
> because they are actual times) except for lots of '&#13;' added to the 
> digests and signatures:
>
> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
> timestamp="2019-02-13T11:01:22-08:00" type="document"><![CDATA[<html 
> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
> document</p></body></html>]]><dsig:Signature 
> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod 
> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LdB/ydGxr3VUoTshQtOvQNmMZmt2OHgLax4tSk9Lqb1c+X1h4Uc/RBVXwfI9QrVnITBz85Fi8Bwr&#13; 
>
> 7wyMjw84cA==</dsig:DigestValue></dsig:Reference><dsig:Reference 
> URI="#KeyInfo_ID"><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>FkpexxTwhpCPHHsMrKGnBXE5hkZ/x10ArpzjX6ltYfOilvVAubzc9sNPwo6phw//ot1rSKPU5jTB&#13;
> LRD7p7t50g==</dsig:DigestValue></dsig:Reference><dsig:Reference 
> URI="#QualifyingProperties_ID"><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LxB0xAsDxKqeyCflaSUgMQOMhoxP4Gl9GfvlpCiL/gd9rz36qG4roaFRl+4PBC+IxzGiRDOqzQYX&#13;
> x6gSn5d1IQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Pqd+9yaeBMytcG1sTTpuq+Wrd3lZSC18j7lv6VQ6LjUSz9VN7uwVNNn1E79mY8H6XUI2jbd/IozM&#13;
> oba2KF46ig==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>IpdHZtzSw8TOnp0gfKMaCp30jJAPP8YCAIg4OBvRobIwHBFrG+O9v7peXRRA5nXi+fm4bdemi5jI&#13; 
>
> /N2smS7W6lKMMeTzrYNJEmpD/0c/SVCs0M1peZmiWZD/F6GYP6RkhZfTglk9skKsZIme3W5lHL5e&#13; 
>
> vTFno50J32oW0chq/jPzD42snoVQmVKS9wqqybGgRrm1W2RSWfziNo7QjXtJuR5eVuCtqpOLrGrS&#13; 
>
> J0aLaaNLucia/6cJyZ13mz7131Lj2Y4oJbrbpzvrDY5xDfFDK+bRRMR3DCvTLgKcZZz5zxcAKYL8&#13; 
>
> lG64U/tsmd/ZVn+d+fJGH03hPdvY/wMW7MTN1k/6S95PiNdx0cLeP0HLCug9zWiC7vUkrVDrsO9i&#13; 
>
> qsvSYKcAH8vQlG1arZgGJn88Hg8EGjmmWXs15ulU3Lm8TOTXl/xi6O4stSgMi9dFSsE1ISHAPaxN&#13; 
>
> D3Rqg7Bv7p/iEVn0xXq/C9AI3iwrpHbip8K81uJOsaiZgwR5D40XyYLV9FUPIacRclfT5EJKsx6k&#13; 
>
> jYiprWMOMjmnlJwj2vI8zG6sYLVJdQywm2isWu5eHSw39Wof0BYfDeOzh0LrifUcnt86no5fUEOI&#13; 
>
> OlNbqOO7rjuxtb+gt1iO2dTHfQhG99BCBQhC7AEMp67fIlPjEOECXldDTpzPMZ1K6cPlk22rpvc=</dsig:SignatureValue><dsig:KeyInfo 
> Id="KeyInfo_ID"><dsig:KeyName>184a40b0-78b6-4070-a7d7-1497078a06e4</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9&#13; 
>
> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW&#13; 
>
> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU&#13; 
>
> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX&#13; 
>
> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ&#13; 
>
> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB&#13; 
>
> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z&#13; 
>
> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n&#13; 
>
> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu&#13; 
>
> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z&#13; 
>
> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2&#13; 
>
> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh&#13; 
>
> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz&#13; 
>
> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh&#13; 
>
> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw&#13; 
>
> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ&#13; 
>
> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi&#13; 
>
> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A&#13; 
>
> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6&#13; 
>
> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/&#13; 
>
> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn&#13; 
>
> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy&#13; 
>
> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW&#13; 
>
> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR&#13; 
>
> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz&#13; 
>
> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj&#13; 
>
> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC&#13; 
>
> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc&#13; 
>
> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI&#13; 
>
> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl&#13; 
>
> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o&#13; 
>
> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY&#13; 
>
> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N&#13; 
>
> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E&#13; 
>
> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg&#13; 
>
> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV&#13; 
>
> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC&#13; 
>
> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q&#13; 
>
> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX&#13; 
>
> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D&#13; 
>
> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+&#13; 
>
> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx&#13; 
>
> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P&#13; 
>
> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf&#13; 
>
> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z&#13; 
>
> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0&#13; 
>
> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN&#13; 
>
> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk&#13; 
>
> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw&#13; 
>
> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz&#13; 
>
> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO&#13; 
>
> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK&#13; 
>
> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u&#13; 
>
> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/&#13; 
>
> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX&#13; 
>
> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy&#13; 
>
> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
> ns0:Id="QualifyingProperties_ID" 
> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:01:22-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
> Id="OpenESignForms_Seal_ID" 
> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
> ns0:DeploymentHostAddress="192.1.1.1" 
> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
> ns1:DeploymentHostName="open.esignforms.com" 
> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
> ns2:DeploymentId="1.1.1.1" 
> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
> ns3:SignerAddress="192.1.1.1" 
> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
> ns4:SignerAgent="No-Browser-Test" 
> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
> ns5:Timestamp="2019-02-13T11:01:22-08:00" 
> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot>
>
>
> It's particularly odd because hex 13 isn't a typical character (^S).
>
> Any idea what that difference is about for the base64 digests and 
> signatures?
>
> David
>
>
> On 2/13/19 6:03 AM, Sean Mullan wrote:
>> On 2/12/19 6:28 PM, Open eSignForms wrote:
>>> Thanks for the update, Sean.? I'm a bit perplexed because I found 
>>> the original code works under Java 9 and Java 10, so it seems like 
>>> the change occurred in Java 11.
>>
>> Sorry, that was a typo, I meant to say JDK 11.
>>
>>> I don't see the modified version of the test case.? If you attached 
>>> it, it somehow didn't make it through to me.
>>>
>>> If it's just a matter of making the code more correct, we'd love to 
>>> make the changes.? My concern, of course, is that we've already done 
>>> millions of XML digital signatures, so we need that to continue to 
>>> verify correctly (and even under Java 11, it seems that the verify 
>>> code works against previously digitally signed content) even if we 
>>> now start digitally signing using more update-to-date code.
>>
>> The verification of pre-existing signatures should continue to work 
>> regardless of how this bug is addressed.
>>
>>> Please send over the modified test case and I'll take a look.
>>
>> It is attached to the bug report in the Attachments section: 
>> https://bugs.openjdk.java.net/browse/JDK-8218629 (make sure you 
>> download the one I added yesterday).
>>
>> --Sean
>>
>>>
>>> Thanks!
>>> David
>>>
>>> On 2/12/19 2:14 PM, Sean Mullan wrote:
>>>> The bug is now at https://bugs.openjdk.java.net/browse/JDK-8218629
>>>>
>>>> I have started looking at this issue and have some progress I can 
>>>> report.
>>>>
>>>> In JDK 9, we updated the version of the Apache XML Signature 
>>>> implementation in the JDK. Some of the marshalling code was 
>>>> rewritten such that it will throw Exceptions if legacy DOM level 1 
>>>> methods were used to create XML content which is then passed into 
>>>> XMLObject and similar XMLSignature types that take DOMStructure 
>>>> objects. This is because the DOM level 1 methods do not support 
>>>> namespaces.
>>>>
>>>> I am still evaluating what the best fix is. However, you can 
>>>> workaround the issue by always using DOM level 3 methods which are 
>>>> namespace aware. For example, use Document.createElementNS instead 
>>>> of Document.createElement and Element.createAttributeNS instead of 
>>>> Element.createAttribute.
>>>>
>>>> Using legacy or non-namespace aware XML parsers or implementations 
>>>> is not recommended and the XML Signature Best Practices document 
>>>> gives some rationale: 
>>>> https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces 
>>>>
>>>> That said, this is a regression in behavior so it would be best if 
>>>> we could restore the previous behavior.
>>>>
>>>> I have attached a modified version of the test case to the bug 
>>>> report which no longer throws an Exception. Let me know if this is 
>>>> an acceptable workaround. Double-check the namespaces that I used 
>>>> to make sure they are correct.
>>>>
>>>> --Sean
>>>>
>>>>
>>>> On 2/7/19 11:23 AM, Open eSignForms wrote:
>>>>
>>>>> On 2/7/19 7:49 AM, Sean Mullan wrote:
>>>>>> On 2/6/19 4:51 PM, Open eSignForms wrote:
>>>>>>> I have a test version of the code that can run standalone and 
>>>>>>> shows the bug.? I'm not sure how best to transfer this 
>>>>>>> information to the forum for those to play with, but it is 
>>>>>>> included below.
>>>>>>
>>>>>> Thanks, I can reproduce the issue now. I will need to debug 
>>>>>> further to see what might be causing this.
>>>>>>
>>>>>> --Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190213/ef66c5e6/attachment-0001.html>

From xuelei.fan at oracle.com  Wed Feb 13 21:44:31 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 13 Feb 2019 13:44:31 -0800
Subject: Not possible to disable new TLS extensions for TLS 1.2 connections
In-Reply-To: <CAJ3+AweJFwhxFitO5ALd6SPAhsOrODFFMaKtvd68zejjFKqX+w@mail.gmail.com>
References: <CAJ3+Awc9F5phKuMZZ1ohYtkhBHKvydvVioHJGpCkRaThAD6t=g@mail.gmail.com>
 <3dfb3505-dd0e-3b91-17a0-c6165d7a1069@oracle.com>
 <CAJ3+AweJFwhxFitO5ALd6SPAhsOrODFFMaKtvd68zejjFKqX+w@mail.gmail.com>
Message-ID: <283c595b-5ff5-66d7-46fb-f3a60817a508@oracle.com>

Hi Amir,

Could you build OpenJDK by yourself?  If it is doable, I could send your 
a patch to disable the extension so that you can confirm if and which 
extension is the underlying problem.

Thanks,
Xuelei


On 2/13/2019 1:16 PM, Amir Khassaia wrote:
> Hi Xuelei,
> There were 2 distinct cases of change of behaviour.
> 
>   * The "CN=invalid2.invalid, OU="No SNI provided" reliably works
>     without SNI in Java 8 but is indeed fixed by having an SNI included
>     which perhaps was needed all along. This one is reported by XMPP/TLS
>     connection from talk.google.com:5222 <http://talk.google.com:5222>
>   * The aborted handshake case (client_hello traces that I've provided)
>     this happened with a hardware device which was replicable with an
>     SSL socket handshake program that I referenced in the gist.
>     Unfortunately replication requires a specific device model so it
>     wont be possible to see it for yourself. The workaround there was to
>     either downgrade JRE to < 11 or to switch JRE globally to use TLS
>     1.0 or TLS 1.1 via the system property. This is where your proposed
>     enhancement will be of great help as it will allow a per connection
>     type decision.
> 
> 
> On Wed, Feb 13, 2019 at 3:01 PM Xuelei Fan <xuelei.fan at oracle.com 
> <mailto:xuelei.fan at oracle.com>> wrote:
> 
>     Hi Amir,
> 
>     It should be rare now the a TLS vendor cannot ignore unknown extensions.
> 
>      ?> "issuer": "CN=invalid2.invalid, OU="No SNI provided;
>      ?> please fix your client."",
>     The error message encapsulated in the certificate does not sound right
>     to me.? Is it caused by the absence of SNI extension?
> 
>     Did you have a test case that I can reproduce the problem?
> 
>     Thanks & Regards,
>     Xuelei
> 
> 
>     On 1/7/2019 9:27 PM, Amir Khassaia wrote:
>      > Xuelei,
>      > The certificate in the connection is a red herring and not
>     important.
>      > It's actually a very unusual behaviour by talk.google.com
>     <http://talk.google.com>
>      > <http://talk.google.com> endpoint to encapsulate an error message
>     inside
>      > a certificate.
>      >
>      > As per the output I included:
>      >
>      > /"certificate" : { />/? ? "version"? ? ? ? ? ? : "v3", />/   
>     "serial number"? ? ? : "00 90 76 89 18 E9 33 93 A0", />/   
>     "signature algorithm": "SHA256withRSA", />/? ? "issuer"           
>      ?: "CN=invalid2.invalid, OU="No SNI provided; />/please fix your
>     client."", />/? ? "not before"? ? ? ? ?: "2015-01-01 11:00:00.000
>     AEDT", />/? ? "not? after"? ? ? ? ?: "2030-01-01 11:00:00.000 AEDT",
>     />/? ? "subject"? ? ? ? ? ? : "CN=invalid2.invalid, OU="No SNI
>     provided; />/please fix your client."",/
>      >
>      > /
>      > /
>      >
>      > This certificate simply masks the TLS interoperability issue as an
>      > untrusted certificate issue.
>      >
>      > The fact is, some of the extensions sent by JSSE are changes to
>     TLS 1.2
>      > to support TLS 1.3, this however affects some clients adversely in
>      > practice and usually JDK provides properties to turn new
>     enhancements
>      > off and work around such behaviour, for the extensions I
>     mentioned this
>      > is not provided and hence they are always sent for client sockets
>     unless
>      > TLSv1.2 is not in use.
>      >
>      > The impact to us is that upgrading to JDK11 means for some
>     endpoints or
>      > devices that are not 100% compliant to the spec the security is
>     reduced
>      > as we have to now work around to drop connections to these to
>     TLSv1.1 or
>      > TLS1.0 or not to move to Java 11 at all.
>      >
>      > My request is simply to have all of the new extensions
>     configurable on
>      > individual basis so that they can be turned off if needed for
>      > compatibility just like most other security enhancements that were
>      > delivered in the past.
>      >
>      > It appears some of the issues can come from
>      >
>      > - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can
>      > disabled at least
>      >
>      > -signature_algorithms_cert and supported_versions extensions
>     which seem
>      > to be hardcoded for TLS 1.2 (I was not able to conclusively identify
>      > which of these caused my troubles)
>      >
>      > https://tools.ietf.org/html/rfc8446#section-1.3 does say that TLS
>     1.2
>      > clients are affected but in an optional manner.Just today I've
>      > encountered another Java 11 interop issue with TLS but this time
>     with a
>      > physical device which can have a long shelf life yet running a
>     simple
>      > client socket handshake abruptly terminates the connection upon
>     client
>      > hello (no server_hello at all), and downgrading the JRE below 11
>     works
>      > fine. I'm including a trace for that as well:
>      >
>      >
>      > javax.net.ssl|DEBUG|01|main|2019-01-0813:40:14.395 
>     AEDT|SSLCipher.java:437|jdk.tls.keyLimits: ? entry =
>     AES/GCM/NoPadding KeyUpdate2^37. AES/GCM/NOPADDING:KEYUPDATE
>     =137438953472
>      >
>      > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433
>      > AEDT|ServerNameExtension.java:255|Unable to indicate server name
>      >
>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
>      > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
>      > server_name
>      >
>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
>      > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
>      > status_request
>      >
>      > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443
>      > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not
>      > supported by the underlying providers
>      >
>      > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444
>      > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not
>      > supported by the underlying providers
>      >
>      > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449
>      > AEDT|AlpnExtension.java:161|No available application protocols
>      >
>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449
>      > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
>      > application_layer_protocol_negotiation
>      >
>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450
>      > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
>      > status_request_v2
>      >
>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453
>      > AEDT|ClientHello.java:651|Produced ClientHello handshake message (
>      >
>      > "ClientHello": {
>      >
>      > "client version"? ? ? : "TLSv1.2",
>      >
>      > "random"? ? ? ? ? ? ? : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24
>     7F 34 3D
>      > 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68",
>      >
>      > "session id"? ? ? ? ? : "",
>      >
>      > "cipher suites"? ? ? ?:
>      > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
>      > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
>      > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
>      > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
>      > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]",
>      >
>      > "compression methods" : "00",
>      >
>      > "extensions"? ? ? ? ? : [
>      >
>      > "supported_groups (10)": {
>      >
>      > "versions": [secp256r1, secp384r1, secp521r1, secp160k1]
>      >
>      >? ? ? },
>      >
>      > "ec_point_formats (11)": {
>      >
>      > "formats": [uncompressed]
>      >
>      >? ? ? },
>      >
>      > "signature_algorithms (13)": {
>      >
>      > "signature schemes": [ecdsa_secp256r1_sha256,
>     ecdsa_secp384r1_sha384,
>      > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
>      > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
>      > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
>      > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224,
>      > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
>      >
>      >? ? ? },
>      >
>      > "signature_algorithms_cert (50)": {
>      >
>      > "signature schemes": [ecdsa_secp256r1_sha256,
>     ecdsa_secp384r1_sha384,
>      > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
>      > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
>      > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
>      > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, dsa_sha224,
>      > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
>      >
>      >? ? ? },
>      >
>      > "extended_master_secret (23)": {
>      >
>      >? ? ? ? <empty>
>      >
>      >? ? ? },
>      >
>      > "supported_versions (43)": {
>      >
>      > "versions": [TLSv1.2, TLSv1.1]
>      >
>      >? ? ? },
>      >
>      > "renegotiation_info (65,281)": {
>      >
>      > "renegotiated connection": [<no renegotiated connection>]
>      >
>      >? ? ? }
>      >
>      >? ? ]
>      >
>      > }
>      >
>      > )
>      >
>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455
>      > AEDT|Alert.java:232|Received alert message (
>      >
>      > "Alert": {
>      >
>      > "level"? ? ? : "fatal",
>      >
>      > "description": "handshake_failure"
>      >
>      > }
>      >
>      > )
>      >
>      > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456
>      > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE):
>     Received fatal
>      > alert: handshake_failure (
>      >
>      > "throwable" : {
>      >
>      >? ? javax.net.ssl.SSLHandshakeException: Received fatal alert:
>      > handshake_failure
>      >
>      >? ? ? at
>     java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>      >
>      >? ? ? at
>     java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>      >
>      >? ? ? at
>      >
>     java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>      >
>      >? ? ? at
>      >
>     java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
>      >
>      >? ? ? at
>      >
>     java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
>      >
>      >? ? ? at
>      > java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>      >
>      >? ? ? at
>      >
>     java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>      >
>      >? ? ? at
>      >
>     java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>      >
>      >? ? ? at
>      >
>     java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>      >
>      >? ? ? at SslSocketClient.main(SslSocketClient.kt:47)}
>      >
>      >
>      > )
>      >
>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
>      > AEDT|SSLSocketImpl.java:1361|close the underlying socket
>      >
>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
>      > AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative)
>      >
>      > Exception in thread "main" javax.net.ssl.SSLHandshakeException:
>     Received
>      > fatal alert: handshake_failure
>      >
>      >? ? at
>     java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>      >
>      >? ? at
>     java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>      >
>      >? ? at
>      >
>     java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>      >
>      >? ? at
>     java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
>      >
>      >? ? at
>      >
>     java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
>      >
>      >? ? at
>     java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>      >
>      >? ? at
>      >
>     java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>      >
>      >? ? at
>      >
>     java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>      >
>      >? ? at
>      >
>     java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>      >
>      >? ? at SslSocketClient.main(SslSocketClient.kt:47)
>      >
>      >
>      >
>      >
> 

From xuelei.fan at oracle.com  Wed Feb 13 21:51:05 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 13 Feb 2019 13:51:05 -0800
Subject: CSR Review Request, JDK-8218932 Remove the internal package
 com.sun.net.ssl
Message-ID: <6071db41-91d6-6f55-ddeb-658c93a37280@oracle.com>

Hi,

Could I get the CSR reviewed:
    https://bugs.openjdk.java.net/browse/JDK-8218932

The internal package com.sun.net.ssl had been deprecated since JDK 1.4, 
and was not exported in the java.base module since JDK 9.  Application 
cannot use them directly now.  It should be safe to remove them in JDK 13.

If you are using the internal package for some reason, please let me 
know the compatibility impact by the end of Feb 20, 2019.

Thanks,
Xuelei

From amir.khassaia at gmail.com  Wed Feb 13 21:57:20 2019
From: amir.khassaia at gmail.com (Amir Khassaia)
Date: Thu, 14 Feb 2019 08:57:20 +1100
Subject: Not possible to disable new TLS extensions for TLS 1.2 connections
In-Reply-To: <283c595b-5ff5-66d7-46fb-f3a60817a508@oracle.com>
References: <CAJ3+Awc9F5phKuMZZ1ohYtkhBHKvydvVioHJGpCkRaThAD6t=g@mail.gmail.com>
 <3dfb3505-dd0e-3b91-17a0-c6165d7a1069@oracle.com>
 <CAJ3+AweJFwhxFitO5ALd6SPAhsOrODFFMaKtvd68zejjFKqX+w@mail.gmail.com>
 <283c595b-5ff5-66d7-46fb-f3a60817a508@oracle.com>
Message-ID: <CAJ3+AwdFn00eepy+g+zN5fH=v_oUcEDvXOi9ZP27cJBXxOf0yg@mail.gmail.com>

Unfortunately I no longer have the device that replicates the problem :(
and other similar ones never showed in the first place.
Traditionally I would make TLS handshakes stay identical across JDK
versions to ensure compatibility as working with various devices and
vendors would show up a multitude of ways a handshake would fail, including
ones where handshake succeeds but application data encryption fails later
etc.
In each of these JDK tuning would be able to make the handshake
"compatible" with a given device. In this case it could be made almost
identical with the exception of the extensions listed. I can send you
wireshark PCAPs if needed from the session with the device but they will
really just show the same information as already listed.

On Thu, Feb 14, 2019 at 8:44 AM Xuelei Fan <xuelei.fan at oracle.com> wrote:

> Hi Amir,
>
> Could you build OpenJDK by yourself?  If it is doable, I could send your
> a patch to disable the extension so that you can confirm if and which
> extension is the underlying problem.
>
> Thanks,
> Xuelei
>
>
> On 2/13/2019 1:16 PM, Amir Khassaia wrote:
> > Hi Xuelei,
> > There were 2 distinct cases of change of behaviour.
> >
> >   * The "CN=invalid2.invalid, OU="No SNI provided" reliably works
> >     without SNI in Java 8 but is indeed fixed by having an SNI included
> >     which perhaps was needed all along. This one is reported by XMPP/TLS
> >     connection from talk.google.com:5222 <http://talk.google.com:5222>
> >   * The aborted handshake case (client_hello traces that I've provided)
> >     this happened with a hardware device which was replicable with an
> >     SSL socket handshake program that I referenced in the gist.
> >     Unfortunately replication requires a specific device model so it
> >     wont be possible to see it for yourself. The workaround there was to
> >     either downgrade JRE to < 11 or to switch JRE globally to use TLS
> >     1.0 or TLS 1.1 via the system property. This is where your proposed
> >     enhancement will be of great help as it will allow a per connection
> >     type decision.
> >
> >
> > On Wed, Feb 13, 2019 at 3:01 PM Xuelei Fan <xuelei.fan at oracle.com
> > <mailto:xuelei.fan at oracle.com>> wrote:
> >
> >     Hi Amir,
> >
> >     It should be rare now the a TLS vendor cannot ignore unknown
> extensions.
> >
> >       > "issuer": "CN=invalid2.invalid, OU="No SNI provided;
> >       > please fix your client."",
> >     The error message encapsulated in the certificate does not sound
> right
> >     to me.  Is it caused by the absence of SNI extension?
> >
> >     Did you have a test case that I can reproduce the problem?
> >
> >     Thanks & Regards,
> >     Xuelei
> >
> >
> >     On 1/7/2019 9:27 PM, Amir Khassaia wrote:
> >      > Xuelei,
> >      > The certificate in the connection is a red herring and not
> >     important.
> >      > It's actually a very unusual behaviour by talk.google.com
> >     <http://talk.google.com>
> >      > <http://talk.google.com> endpoint to encapsulate an error message
> >     inside
> >      > a certificate.
> >      >
> >      > As per the output I included:
> >      >
> >      > /"certificate" : { />/    "version"            : "v3", />/
> >     "serial number"      : "00 90 76 89 18 E9 33 93 A0", />/
> >     "signature algorithm": "SHA256withRSA", />/    "issuer"
> >       : "CN=invalid2.invalid, OU="No SNI provided; />/please fix your
> >     client."", />/    "not before"         : "2015-01-01 11:00:00.000
> >     AEDT", />/    "not  after"         : "2030-01-01 11:00:00.000 AEDT",
> >     />/    "subject"            : "CN=invalid2.invalid, OU="No SNI
> >     provided; />/please fix your client."",/
> >      >
> >      > /
> >      > /
> >      >
> >      > This certificate simply masks the TLS interoperability issue as an
> >      > untrusted certificate issue.
> >      >
> >      > The fact is, some of the extensions sent by JSSE are changes to
> >     TLS 1.2
> >      > to support TLS 1.3, this however affects some clients adversely in
> >      > practice and usually JDK provides properties to turn new
> >     enhancements
> >      > off and work around such behaviour, for the extensions I
> >     mentioned this
> >      > is not provided and hence they are always sent for client sockets
> >     unless
> >      > TLSv1.2 is not in use.
> >      >
> >      > The impact to us is that upgrading to JDK11 means for some
> >     endpoints or
> >      > devices that are not 100% compliant to the spec the security is
> >     reduced
> >      > as we have to now work around to drop connections to these to
> >     TLSv1.1 or
> >      > TLS1.0 or not to move to Java 11 at all.
> >      >
> >      > My request is simply to have all of the new extensions
> >     configurable on
> >      > individual basis so that they can be turned off if needed for
> >      > compatibility just like most other security enhancements that were
> >      > delivered in the past.
> >      >
> >      > It appears some of the issues can come from
> >      >
> >      > - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can
> >      > disabled at least
> >      >
> >      > -signature_algorithms_cert and supported_versions extensions
> >     which seem
> >      > to be hardcoded for TLS 1.2 (I was not able to conclusively
> identify
> >      > which of these caused my troubles)
> >      >
> >      > https://tools.ietf.org/html/rfc8446#section-1.3 does say that TLS
> >     1.2
> >      > clients are affected but in an optional manner.Just today I've
> >      > encountered another Java 11 interop issue with TLS but this time
> >     with a
> >      > physical device which can have a long shelf life yet running a
> >     simple
> >      > client socket handshake abruptly terminates the connection upon
> >     client
> >      > hello (no server_hello at all), and downgrading the JRE below 11
> >     works
> >      > fine. I'm including a trace for that as well:
> >      >
> >      >
> >      > javax.net.ssl|DEBUG|01|main|2019-01-0813:40:14.395
> >     AEDT|SSLCipher.java:437|jdk.tls.keyLimits:   entry =
> >     AES/GCM/NoPadding KeyUpdate2^37. AES/GCM/NOPADDING:KEYUPDATE
> >     =137438953472
> >      >
> >      > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433
> >      > AEDT|ServerNameExtension.java:255|Unable to indicate server name
> >      >
> >      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
> >      > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> >      > server_name
> >      >
> >      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
> >      > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> >      > status_request
> >      >
> >      > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443
> >      > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not
> >      > supported by the underlying providers
> >      >
> >      > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444
> >      > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not
> >      > supported by the underlying providers
> >      >
> >      > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449
> >      > AEDT|AlpnExtension.java:161|No available application protocols
> >      >
> >      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449
> >      > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> >      > application_layer_protocol_negotiation
> >      >
> >      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450
> >      > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> >      > status_request_v2
> >      >
> >      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453
> >      > AEDT|ClientHello.java:651|Produced ClientHello handshake message (
> >      >
> >      > "ClientHello": {
> >      >
> >      > "client version"      : "TLSv1.2",
> >      >
> >      > "random"              : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24
> >     7F 34 3D
> >      > 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68",
> >      >
> >      > "session id"          : "",
> >      >
> >      > "cipher suites"       :
> >      > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
> >      > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
> >      > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
> >      > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
> >      > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]",
> >      >
> >      > "compression methods" : "00",
> >      >
> >      > "extensions"          : [
> >      >
> >      > "supported_groups (10)": {
> >      >
> >      > "versions": [secp256r1, secp384r1, secp521r1, secp160k1]
> >      >
> >      >      },
> >      >
> >      > "ec_point_formats (11)": {
> >      >
> >      > "formats": [uncompressed]
> >      >
> >      >      },
> >      >
> >      > "signature_algorithms (13)": {
> >      >
> >      > "signature schemes": [ecdsa_secp256r1_sha256,
> >     ecdsa_secp384r1_sha384,
> >      > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
> >      > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
> >      > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
> >      > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224,
> dsa_sha224,
> >      > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
> >      >
> >      >      },
> >      >
> >      > "signature_algorithms_cert (50)": {
> >      >
> >      > "signature schemes": [ecdsa_secp256r1_sha256,
> >     ecdsa_secp384r1_sha384,
> >      > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
> >      > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
> >      > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
> >      > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224,
> dsa_sha224,
> >      > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
> >      >
> >      >      },
> >      >
> >      > "extended_master_secret (23)": {
> >      >
> >      >        <empty>
> >      >
> >      >      },
> >      >
> >      > "supported_versions (43)": {
> >      >
> >      > "versions": [TLSv1.2, TLSv1.1]
> >      >
> >      >      },
> >      >
> >      > "renegotiation_info (65,281)": {
> >      >
> >      > "renegotiated connection": [<no renegotiated connection>]
> >      >
> >      >      }
> >      >
> >      >    ]
> >      >
> >      > }
> >      >
> >      > )
> >      >
> >      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455
> >      > AEDT|Alert.java:232|Received alert message (
> >      >
> >      > "Alert": {
> >      >
> >      > "level"      : "fatal",
> >      >
> >      > "description": "handshake_failure"
> >      >
> >      > }
> >      >
> >      > )
> >      >
> >      > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456
> >      > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE):
> >     Received fatal
> >      > alert: handshake_failure (
> >      >
> >      > "throwable" : {
> >      >
> >      >    javax.net.ssl.SSLHandshakeException: Received fatal alert:
> >      > handshake_failure
> >      >
> >      >      at
> >     java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
> >      >
> >      >      at
> >     java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> >      >
> >      >      at
> >      >
> >
>  java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
> >      >
> >      >      at
> >      >
> >
>  java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
> >      >
> >      >      at
> >      >
> >
>  java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
> >      >
> >      >      at
> >      >
> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
> >      >
> >      >      at
> >      >
> >
>  java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
> >      >
> >      >      at
> >      >
> >
>  java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
> >      >
> >      >      at
> >      >
> >
>  java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
> >      >
> >      >      at SslSocketClient.main(SslSocketClient.kt:47)}
> >      >
> >      >
> >      > )
> >      >
> >      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
> >      > AEDT|SSLSocketImpl.java:1361|close the underlying socket
> >      >
> >      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
> >      > AEDT|SSLSocketImpl.java:1380|close the SSL connection (initiative)
> >      >
> >      > Exception in thread "main" javax.net.ssl.SSLHandshakeException:
> >     Received
> >      > fatal alert: handshake_failure
> >      >
> >      >    at
> >     java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
> >      >
> >      >    at
> >     java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> >      >
> >      >    at
> >      >
> >
>  java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
> >      >
> >      >    at
> >
>  java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
> >      >
> >      >    at
> >      >
> >
>  java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
> >      >
> >      >    at
> >     java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
> >      >
> >      >    at
> >      >
> >
>  java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
> >      >
> >      >    at
> >      >
> >
>  java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
> >      >
> >      >    at
> >      >
> >
>  java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
> >      >
> >      >    at SslSocketClient.main(SslSocketClient.kt:47)
> >      >
> >      >
> >      >
> >      >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190214/9b64c06a/attachment-0001.html>

From openjdk at suche.org  Wed Feb 13 22:04:37 2019
From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=)
Date: Wed, 13 Feb 2019 23:04:37 +0100
Subject: Not possible to disable new TLS extensions for TLS 1.2 connections
In-Reply-To: <283c595b-5ff5-66d7-46fb-f3a60817a508@oracle.com>
References: <CAJ3+Awc9F5phKuMZZ1ohYtkhBHKvydvVioHJGpCkRaThAD6t=g@mail.gmail.com>
 <3dfb3505-dd0e-3b91-17a0-c6165d7a1069@oracle.com>
 <CAJ3+AweJFwhxFitO5ALd6SPAhsOrODFFMaKtvd68zejjFKqX+w@mail.gmail.com>
 <283c595b-5ff5-66d7-46fb-f3a60817a508@oracle.com>
Message-ID: <1d76a7a3-103a-c7c0-8834-3b7e953c7291@suche.org>

Hi,

maybe two points.

1) Older lotus notes server have the problem.
2) The problem can be solved if you disable TLSv1.3 or even TLSv1.2
3) Maybe it would be an good idea to build an set of client hello's with 
different options.
 ???? Or even an generator. Than you send if and check the result since 
the servers with problem
 ???? only reply with an ssl alert. So you can check it without an ssl 
engine or jdk build


Gru? Thomas

Am 13.02.2019 um 22:44:31 schrieb Xuelei Fan:
> Hi Amir,
>
> Could you build OpenJDK by yourself?? If it is doable, I could send 
> your a patch to disable the extension so that you can confirm if and 
> which extension is the underlying problem.
>
> Thanks,
> Xuelei
>
>
> On 2/13/2019 1:16 PM, Amir Khassaia wrote:
>> Hi Xuelei,
>> There were 2 distinct cases of change of behaviour.
>>
>> ? * The "CN=invalid2.invalid, OU="No SNI provided" reliably works
>> ??? without SNI in Java 8 but is indeed fixed by having an SNI included
>> ??? which perhaps was needed all along. This one is reported by XMPP/TLS
>> ??? connection from talk.google.com:5222 <http://talk.google.com:5222>
>> ? * The aborted handshake case (client_hello traces that I've provided)
>> ??? this happened with a hardware device which was replicable with an
>> ??? SSL socket handshake program that I referenced in the gist.
>> ??? Unfortunately replication requires a specific device model so it
>> ??? wont be possible to see it for yourself. The workaround there was to
>> ??? either downgrade JRE to < 11 or to switch JRE globally to use TLS
>> ??? 1.0 or TLS 1.1 via the system property. This is where your proposed
>> ??? enhancement will be of great help as it will allow a per connection
>> ??? type decision.
>>
>>
>> On Wed, Feb 13, 2019 at 3:01 PM Xuelei Fan <xuelei.fan at oracle.com 
>> <mailto:xuelei.fan at oracle.com>> wrote:
>>
>> ??? Hi Amir,
>>
>> ??? It should be rare now the a TLS vendor cannot ignore unknown 
>> extensions.
>>
>> ???? ?> "issuer": "CN=invalid2.invalid, OU="No SNI provided;
>> ???? ?> please fix your client."",
>> ??? The error message encapsulated in the certificate does not sound 
>> right
>> ??? to me.? Is it caused by the absence of SNI extension?
>>
>> ??? Did you have a test case that I can reproduce the problem?
>>
>> ??? Thanks & Regards,
>> ??? Xuelei
>>
>>
>> ??? On 1/7/2019 9:27 PM, Amir Khassaia wrote:
>> ???? > Xuelei,
>> ???? > The certificate in the connection is a red herring and not
>> ??? important.
>> ???? > It's actually a very unusual behaviour by talk.google.com
>> ??? <http://talk.google.com>
>> ???? > <http://talk.google.com> endpoint to encapsulate an error message
>> ??? inside
>> ???? > a certificate.
>> ???? >
>> ???? > As per the output I included:
>> ???? >
>> ???? > /"certificate" : { />/? ? "version"? ? ? ? ? ? : "v3", />/?? 
>> ??? "serial number"? ? ? : "00 90 76 89 18 E9 33 93 A0", />/?? ??? 
>> "signature algorithm": "SHA256withRSA", />/? ? "issuer"?????????? 
>> ???? ?: "CN=invalid2.invalid, OU="No SNI provided; />/please fix your
>> ??? client."", />/? ? "not before"? ? ? ? ?: "2015-01-01 11:00:00.000
>> ??? AEDT", />/? ? "not? after"? ? ? ? ?: "2030-01-01 11:00:00.000 AEDT",
>> ??? />/? ? "subject"? ? ? ? ? ? : "CN=invalid2.invalid, OU="No SNI
>> ??? provided; />/please fix your client."",/
>> ???? >
>> ???? > /
>> ???? > /
>> ???? >
>> ???? > This certificate simply masks the TLS interoperability issue 
>> as an
>> ???? > untrusted certificate issue.
>> ???? >
>> ???? > The fact is, some of the extensions sent by JSSE are changes to
>> ??? TLS 1.2
>> ???? > to support TLS 1.3, this however affects some clients 
>> adversely in
>> ???? > practice and usually JDK provides properties to turn new
>> ??? enhancements
>> ???? > off and work around such behaviour, for the extensions I
>> ??? mentioned this
>> ???? > is not provided and hence they are always sent for client sockets
>> ??? unless
>> ???? > TLSv1.2 is not in use.
>> ???? >
>> ???? > The impact to us is that upgrading to JDK11 means for some
>> ??? endpoints or
>> ???? > devices that are not 100% compliant to the spec the security is
>> ??? reduced
>> ???? > as we have to now work around to drop connections to these to
>> ??? TLSv1.1 or
>> ???? > TLS1.0 or not to move to Java 11 at all.
>> ???? >
>> ???? > My request is simply to have all of the new extensions
>> ??? configurable on
>> ???? > individual basis so that they can be turned off if needed for
>> ???? > compatibility just like most other security enhancements that 
>> were
>> ???? > delivered in the past.
>> ???? >
>> ???? > It appears some of the issues can come from
>> ???? >
>> ???? > - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can
>> ???? > disabled at least
>> ???? >
>> ???? > -signature_algorithms_cert and supported_versions extensions
>> ??? which seem
>> ???? > to be hardcoded for TLS 1.2 (I was not able to conclusively 
>> identify
>> ???? > which of these caused my troubles)
>> ???? >
>> ???? > https://tools.ietf.org/html/rfc8446#section-1.3 does say that TLS
>> ??? 1.2
>> ???? > clients are affected but in an optional manner.Just today I've
>> ???? > encountered another Java 11 interop issue with TLS but this time
>> ??? with a
>> ???? > physical device which can have a long shelf life yet running a
>> ??? simple
>> ???? > client socket handshake abruptly terminates the connection upon
>> ??? client
>> ???? > hello (no server_hello at all), and downgrading the JRE below 11
>> ??? works
>> ???? > fine. I'm including a trace for that as well:
>> ???? >
>> ???? >
>> ???? > javax.net.ssl|DEBUG|01|main|2019-01-0813:40:14.395 
>> AEDT|SSLCipher.java:437|jdk.tls.keyLimits: ? entry =
>> ??? AES/GCM/NoPadding KeyUpdate2^37. AES/GCM/NOPADDING:KEYUPDATE
>> ??? =137438953472
>> ???? >
>> ???? > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433
>> ???? > AEDT|ServerNameExtension.java:255|Unable to indicate server name
>> ???? >
>> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
>> ???? > AEDT|SSLExtensions.java:235|Ignore, context unavailable 
>> extension:
>> ???? > server_name
>> ???? >
>> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
>> ???? > AEDT|SSLExtensions.java:235|Ignore, context unavailable 
>> extension:
>> ???? > status_request
>> ???? >
>> ???? > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443
>> ???? > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is 
>> not
>> ???? > supported by the underlying providers
>> ???? >
>> ???? > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444
>> ???? > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not
>> ???? > supported by the underlying providers
>> ???? >
>> ???? > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449
>> ???? > AEDT|AlpnExtension.java:161|No available application protocols
>> ???? >
>> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449
>> ???? > AEDT|SSLExtensions.java:235|Ignore, context unavailable 
>> extension:
>> ???? > application_layer_protocol_negotiation
>> ???? >
>> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450
>> ???? > AEDT|SSLExtensions.java:235|Ignore, context unavailable 
>> extension:
>> ???? > status_request_v2
>> ???? >
>> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453
>> ???? > AEDT|ClientHello.java:651|Produced ClientHello handshake 
>> message (
>> ???? >
>> ???? > "ClientHello": {
>> ???? >
>> ???? > "client version"? ? ? : "TLSv1.2",
>> ???? >
>> ???? > "random"? ? ? ? ? ? ? : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24
>> ??? 7F 34 3D
>> ???? > 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68",
>> ???? >
>> ???? > "session id"? ? ? ? ? : "",
>> ???? >
>> ???? > "cipher suites"? ? ? ?:
>> ???? > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
>> ???? > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
>> ???? > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
>> ???? > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
>> ???? > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]",
>> ???? >
>> ???? > "compression methods" : "00",
>> ???? >
>> ???? > "extensions"? ? ? ? ? : [
>> ???? >
>> ???? > "supported_groups (10)": {
>> ???? >
>> ???? > "versions": [secp256r1, secp384r1, secp521r1, secp160k1]
>> ???? >
>> ???? >? ? ? },
>> ???? >
>> ???? > "ec_point_formats (11)": {
>> ???? >
>> ???? > "formats": [uncompressed]
>> ???? >
>> ???? >? ? ? },
>> ???? >
>> ???? > "signature_algorithms (13)": {
>> ???? >
>> ???? > "signature schemes": [ecdsa_secp256r1_sha256,
>> ??? ecdsa_secp384r1_sha384,
>> ???? > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
>> ???? > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
>> ???? > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
>> ???? > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, 
>> dsa_sha224,
>> ???? > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
>> ???? >
>> ???? >? ? ? },
>> ???? >
>> ???? > "signature_algorithms_cert (50)": {
>> ???? >
>> ???? > "signature schemes": [ecdsa_secp256r1_sha256,
>> ??? ecdsa_secp384r1_sha384,
>> ???? > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
>> ???? > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
>> ???? > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
>> ???? > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224, 
>> dsa_sha224,
>> ???? > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
>> ???? >
>> ???? >? ? ? },
>> ???? >
>> ???? > "extended_master_secret (23)": {
>> ???? >
>> ???? >? ? ? ? <empty>
>> ???? >
>> ???? >? ? ? },
>> ???? >
>> ???? > "supported_versions (43)": {
>> ???? >
>> ???? > "versions": [TLSv1.2, TLSv1.1]
>> ???? >
>> ???? >? ? ? },
>> ???? >
>> ???? > "renegotiation_info (65,281)": {
>> ???? >
>> ???? > "renegotiated connection": [<no renegotiated connection>]
>> ???? >
>> ???? >? ? ? }
>> ???? >
>> ???? >? ? ]
>> ???? >
>> ???? > }
>> ???? >
>> ???? > )
>> ???? >
>> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455
>> ???? > AEDT|Alert.java:232|Received alert message (
>> ???? >
>> ???? > "Alert": {
>> ???? >
>> ???? > "level"? ? ? : "fatal",
>> ???? >
>> ???? > "description": "handshake_failure"
>> ???? >
>> ???? > }
>> ???? >
>> ???? > )
>> ???? >
>> ???? > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456
>> ???? > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE):
>> ??? Received fatal
>> ???? > alert: handshake_failure (
>> ???? >
>> ???? > "throwable" : {
>> ???? >
>> ???? >? ? javax.net.ssl.SSLHandshakeException: Received fatal alert:
>> ???? > handshake_failure
>> ???? >
>> ???? >? ? ? at
>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>> ???? >
>> ???? >? ? ? at
>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>> ???? >
>> ???? >? ? ? at
>> ???? >
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>> ???? >
>> ???? >? ? ? at
>> ???? >
>> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
>> ???? >
>> ???? >? ? ? at
>> ???? >
>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
>> ???? >
>> ???? >? ? ? at
>> ???? > 
>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>> ???? >
>> ???? >? ? ? at
>> ???? >
>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>> ???? >
>> ???? >? ? ? at
>> ???? >
>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>> ???? >
>> ???? >? ? ? at
>> ???? >
>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>> ???? >
>> ???? >? ? ? at SslSocketClient.main(SslSocketClient.kt:47)}
>> ???? >
>> ???? >
>> ???? > )
>> ???? >
>> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
>> ???? > AEDT|SSLSocketImpl.java:1361|close the underlying socket
>> ???? >
>> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
>> ???? > AEDT|SSLSocketImpl.java:1380|close the SSL connection 
>> (initiative)
>> ???? >
>> ???? > Exception in thread "main" javax.net.ssl.SSLHandshakeException:
>> ??? Received
>> ???? > fatal alert: handshake_failure
>> ???? >
>> ???? >? ? at
>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>> ???? >
>> ???? >? ? at
>> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>> ???? >
>> ???? >? ? at
>> ???? >
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>> ???? >
>> ???? >? ? at
>> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
>> ???? >
>> ???? >? ? at
>> ???? >
>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
>> ???? >
>> ???? >? ? at
>> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>> ???? >
>> ???? >? ? at
>> ???? >
>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>> ???? >
>> ???? >? ? at
>> ???? >
>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>> ???? >
>> ???? >? ? at
>> ???? >
>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>> ???? >
>> ???? >? ? at SslSocketClient.main(SslSocketClient.kt:47)
>> ???? >
>> ???? >
>> ???? >
>> ???? >
>>

From lance.andersen at oracle.com  Wed Feb 13 22:05:09 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 13 Feb 2019 17:05:09 -0500
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <3aeba9a64a434a968fc1d82a44077745@sap.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <CA+3eh102cMGphPPbABv2ef_M5Py5+Mg-FRU94HcpKUH3gaV6+w@mail.gmail.com>
 <fd756aff51134b15a40fe55247d4a87e@sap.com>
 <CA+3eh13dP-tCdq4H4z3KWJZQzfMJYqDNkx9fMh3tNfL08RCtDg@mail.gmail.com>
 <7b513a34196141f595cd5d194fb9d8a2@sap.com>
 <fa4078d9-7aec-f122-e9ca-7b816e115c9b@oracle.com>
 <CA+3eh10kDtTEpcRsUWhQEkEyRyTdbvxxmZ8U-G97OeUG2kkU3A@mail.gmail.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
Message-ID: <F146FB1D-726B-416F-97FA-7ED3CD9FCF44@oracle.com>

Hi Christoph,


Just starting to take a peek at this and noticed one quick thing in your test: 
------------
Paths.get(System.getProperty("test.dir", "."), "testPosix.zip")
??????

You do not need the test.dir property  or the permission added to test.policy to access it,  just reference the jar and it will be created in user.dir which is also writable.

Best
Lance

> On Feb 12, 2019, at 4:57 PM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi Alan, all,
> 
> here comes the next proposal for POSIX support in jdk.zipfs - which hopefully represents the converged solution, at least in its overall design.
> 
> http://cr.openjdk.java.net/~clanger/webrevs/8213031.6/
> 
> With that patch, the behavior is the following:
> a) A ZipFileSystem instance by default does NOT support the PosixFileAttributeView. However, it is possible to query for a known attribute named "zip:storedPermissions". Its value can be null to represent no  permission information or any set of PosixFileAttribute.
> b) A ZipFileSystem instance can be created with the property "posix"=true. In that case, PosixFileAttributeView is supported with default values.
> 	-> owner: A UserPrincipal with the name of System.getProperty("user.name") if property access is allowed, "<zipfs_default>" otherwise
> 	-> group: A GroupPrincipal with the name "<zipfs_default>".
> 	-> permissions: Set.of(OWNER_READ, OWNER_WRITE, GROUP_READ)
> 
> 	The default values can be modified by using the properties "defaultOwner", "defaultGroup" and "defaultPermissions".
> 
> Implementation wise the ZipFileAttributeView always extends PosixFileAttributeView but behaves different, depending on how it was obtained.
> 
> Within ZipFileSystem, the Entry inner class is not static any more but always has a reference to the Enclosing ZipFileSystem. That's needed because default owner/group/permission can be set on ZipFileSystem instance level now and the Entry, implementing the FileAttributes needs to know where it belongs to. This seems somewhat logical anyway.
> 
> The new test "TestPosix" is quite extensive. I had to add 2 permissions to test.policy to allow testing in a restricted environment.
> 
> Module-info and CSR have been adopted, too.
> 
> Thanks in advance for reviewing.
> 
> Best regards
> Christoph
> 
>> -----Original Message-----
>> From: Langer, Christoph
>> Sent: Montag, 21. Januar 2019 10:17
>> To: 'Alan Bateman' <Alan.Bateman at oracle.com>
>> Cc: nio-dev <nio-dev at openjdk.java.net>; OpenJDK Dev list <security-
>> dev at openjdk.java.net>; Java Core Libs <core-libs-dev at openjdk.java.net>;
>> Volker Simonis <volker.simonis at gmail.com>
>> Subject: RE: RFR 8213031: (zipfs) Add support for POSIX file permissions
>> 
>> Hi Alan,
>> 
>> first of all, thank you for your input on this.
>> 
>>> I think the approach to explore are:
>>> 
>>> 1. zipfs supports PosixFileAttributeView without subsetting. If
>>> readAttribute(file, BasicFileAttributes.class) succeeds then
>>> readAttribute(file, PosixFileAttributes.class) should also succeed, even
>>> if there aren't permissions encoded in the zip entry's external file
>>> attributes. It would mean that owner and group return default values,
>>> and permissions may return a default value. It does mean you can't
>>> distinguish the default value from "no permissions" but there is
>>> precedence for that, e.g. mount a FAT32 file system on Linux or Unix
>>> systems and `stat` a file to have the stat structure populated with
>>> default uid, gid and mode bits.
>> 
>> OK, I can see the point that in a PosixFileAttributeView as it is, there's no
>> place for optionality/null values. However, with this approach the benefits
>> would be that Files::get/setPosixPermissions would work and that's why I
>> think we should pursue this. The challenge will be to find reasonable
>> defaults.
>> 
>>> 2. zipfs defines a new FileAttributeView that defines read and write
>>> access to permissions stored in a zip entry's external file attribute.
>>> As it's a new view then it can define the behavior for the case that the
>>> zip entry doesn't have permissions. Furthermore it does not need to
>>> extend BasicFileAttributeView so doesn't need to be concerned with bulk
>>> access, nor concerned with group/owner. As you know, the attributes API
>>> allows for both type safe and dynamic access so you have a choice as to
>>> whether to support both or just dynamic access. With the first then
>>> jdk.zipfs would export a package with a public interface that defines
>>> the view. If someone wants type safe access to the permissions attribute
>>> then you need to import the class. The alternative is to not export any
>>> packages but just define the view in the module-info. The view its name
>>> and define the name/type of the permissions attribute, it will also
>>> define how it behaves when the external attributes aren't populated. In
>>> usage terms it means reading the permissions will be something like
>>> Files.readAttribute(file, "zip:permissions") and casting the value to
>>> Set<PosixFilePermission> - not pretty but it avoids depending on a
>>> JDK-specific API.
>> 
>> For this approach, there are 2 things I dislike. The first is that I don't think we
>> should export named packages from module jdk.zipfs that people would
>> develop Java code against while not being in the Java API. And secondly, this
>> way would not support using Files::set/getPosixPermissions since the
>> specification/implementation of that utility method explicitly refers to
>> PosixFileAttributeView.
>> 
>> I can imagine something like this:
>> Zipfs by default implements an own view that offers dynamic, not type safe
>> access to "zip:permissions" and we'll document this. If a user of zipfs wants
>> to see full PosixFileAttributeView support with default values, then we
>> should allow for a creation attribute for the zipfs that can control this. Maybe
>> we can even allow specifying default values for user, group and permissions
>> via zipfs attributes.
>> 
>> I'll work to develop the patch into this direction unless you tell me that this
>> idea is bogus (if so, then I hope it be soon ??)
>> 
>> Thanks
>> Christoph
>> 
>> 
> 

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190213/e6266e76/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190213/e6266e76/oracle_sig_logo-0001.gif>

From amir.khassaia at gmail.com  Wed Feb 13 22:08:22 2019
From: amir.khassaia at gmail.com (Amir Khassaia)
Date: Thu, 14 Feb 2019 09:08:22 +1100
Subject: Not possible to disable new TLS extensions for TLS 1.2 connections
In-Reply-To: <1d76a7a3-103a-c7c0-8834-3b7e953c7291@suche.org>
References: <CAJ3+Awc9F5phKuMZZ1ohYtkhBHKvydvVioHJGpCkRaThAD6t=g@mail.gmail.com>
 <3dfb3505-dd0e-3b91-17a0-c6165d7a1069@oracle.com>
 <CAJ3+AweJFwhxFitO5ALd6SPAhsOrODFFMaKtvd68zejjFKqX+w@mail.gmail.com>
 <283c595b-5ff5-66d7-46fb-f3a60817a508@oracle.com>
 <1d76a7a3-103a-c7c0-8834-3b7e953c7291@suche.org>
Message-ID: <CAJ3+Awehpfrs91J6F2bhpX3o0YjJizvDon0k6V+aiLwPDCR4ww@mail.gmail.com>

Hi Thomas,
Can you confirm its tied to new extensions to TLS 1.2 client hello and
whether you diagnosed which one was the problem in Lotus Notes case ?

On Thu, Feb 14, 2019 at 9:05 AM Thomas Lu?nig <openjdk at suche.org> wrote:

> Hi,
>
> maybe two points.
>
> 1) Older lotus notes server have the problem.
> 2) The problem can be solved if you disable TLSv1.3 or even TLSv1.2
> 3) Maybe it would be an good idea to build an set of client hello's with
> different options.
>       Or even an generator. Than you send if and check the result since
> the servers with problem
>       only reply with an ssl alert. So you can check it without an ssl
> engine or jdk build
>
>
> Gru? Thomas
>
> Am 13.02.2019 um 22:44:31 schrieb Xuelei Fan:
> > Hi Amir,
> >
> > Could you build OpenJDK by yourself?  If it is doable, I could send
> > your a patch to disable the extension so that you can confirm if and
> > which extension is the underlying problem.
> >
> > Thanks,
> > Xuelei
> >
> >
> > On 2/13/2019 1:16 PM, Amir Khassaia wrote:
> >> Hi Xuelei,
> >> There were 2 distinct cases of change of behaviour.
> >>
> >>   * The "CN=invalid2.invalid, OU="No SNI provided" reliably works
> >>     without SNI in Java 8 but is indeed fixed by having an SNI included
> >>     which perhaps was needed all along. This one is reported by XMPP/TLS
> >>     connection from talk.google.com:5222 <http://talk.google.com:5222>
> >>   * The aborted handshake case (client_hello traces that I've provided)
> >>     this happened with a hardware device which was replicable with an
> >>     SSL socket handshake program that I referenced in the gist.
> >>     Unfortunately replication requires a specific device model so it
> >>     wont be possible to see it for yourself. The workaround there was to
> >>     either downgrade JRE to < 11 or to switch JRE globally to use TLS
> >>     1.0 or TLS 1.1 via the system property. This is where your proposed
> >>     enhancement will be of great help as it will allow a per connection
> >>     type decision.
> >>
> >>
> >> On Wed, Feb 13, 2019 at 3:01 PM Xuelei Fan <xuelei.fan at oracle.com
> >> <mailto:xuelei.fan at oracle.com>> wrote:
> >>
> >>     Hi Amir,
> >>
> >>     It should be rare now the a TLS vendor cannot ignore unknown
> >> extensions.
> >>
> >>       > "issuer": "CN=invalid2.invalid, OU="No SNI provided;
> >>       > please fix your client."",
> >>     The error message encapsulated in the certificate does not sound
> >> right
> >>     to me.  Is it caused by the absence of SNI extension?
> >>
> >>     Did you have a test case that I can reproduce the problem?
> >>
> >>     Thanks & Regards,
> >>     Xuelei
> >>
> >>
> >>     On 1/7/2019 9:27 PM, Amir Khassaia wrote:
> >>      > Xuelei,
> >>      > The certificate in the connection is a red herring and not
> >>     important.
> >>      > It's actually a very unusual behaviour by talk.google.com
> >>     <http://talk.google.com>
> >>      > <http://talk.google.com> endpoint to encapsulate an error
> message
> >>     inside
> >>      > a certificate.
> >>      >
> >>      > As per the output I included:
> >>      >
> >>      > /"certificate" : { />/    "version"            : "v3", />/
> >>     "serial number"      : "00 90 76 89 18 E9 33 93 A0", />/
> >> "signature algorithm": "SHA256withRSA", />/    "issuer"
> >>       : "CN=invalid2.invalid, OU="No SNI provided; />/please fix your
> >>     client."", />/    "not before"         : "2015-01-01 11:00:00.000
> >>     AEDT", />/    "not  after"         : "2030-01-01 11:00:00.000 AEDT",
> >>     />/    "subject"            : "CN=invalid2.invalid, OU="No SNI
> >>     provided; />/please fix your client."",/
> >>      >
> >>      > /
> >>      > /
> >>      >
> >>      > This certificate simply masks the TLS interoperability issue
> >> as an
> >>      > untrusted certificate issue.
> >>      >
> >>      > The fact is, some of the extensions sent by JSSE are changes to
> >>     TLS 1.2
> >>      > to support TLS 1.3, this however affects some clients
> >> adversely in
> >>      > practice and usually JDK provides properties to turn new
> >>     enhancements
> >>      > off and work around such behaviour, for the extensions I
> >>     mentioned this
> >>      > is not provided and hence they are always sent for client sockets
> >>     unless
> >>      > TLSv1.2 is not in use.
> >>      >
> >>      > The impact to us is that upgrading to JDK11 means for some
> >>     endpoints or
> >>      > devices that are not 100% compliant to the spec the security is
> >>     reduced
> >>      > as we have to now work around to drop connections to these to
> >>     TLSv1.1 or
> >>      > TLS1.0 or not to move to Java 11 at all.
> >>      >
> >>      > My request is simply to have all of the new extensions
> >>     configurable on
> >>      > individual basis so that they can be turned off if needed for
> >>      > compatibility just like most other security enhancements that
> >> were
> >>      > delivered in the past.
> >>      >
> >>      > It appears some of the issues can come from
> >>      >
> >>      > - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these can
> >>      > disabled at least
> >>      >
> >>      > -signature_algorithms_cert and supported_versions extensions
> >>     which seem
> >>      > to be hardcoded for TLS 1.2 (I was not able to conclusively
> >> identify
> >>      > which of these caused my troubles)
> >>      >
> >>      > https://tools.ietf.org/html/rfc8446#section-1.3 does say that
> TLS
> >>     1.2
> >>      > clients are affected but in an optional manner.Just today I've
> >>      > encountered another Java 11 interop issue with TLS but this time
> >>     with a
> >>      > physical device which can have a long shelf life yet running a
> >>     simple
> >>      > client socket handshake abruptly terminates the connection upon
> >>     client
> >>      > hello (no server_hello at all), and downgrading the JRE below 11
> >>     works
> >>      > fine. I'm including a trace for that as well:
> >>      >
> >>      >
> >>      > javax.net.ssl|DEBUG|01|main|2019-01-0813:40:14.395
> >> AEDT|SSLCipher.java:437|jdk.tls.keyLimits:   entry =
> >>     AES/GCM/NoPadding KeyUpdate2^37. AES/GCM/NOPADDING:KEYUPDATE
> >>     =137438953472
> >>      >
> >>      > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433
> >>      > AEDT|ServerNameExtension.java:255|Unable to indicate server name
> >>      >
> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
> >>      > AEDT|SSLExtensions.java:235|Ignore, context unavailable
> >> extension:
> >>      > server_name
> >>      >
> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
> >>      > AEDT|SSLExtensions.java:235|Ignore, context unavailable
> >> extension:
> >>      > status_request
> >>      >
> >>      > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443
> >>      > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is
> >> not
> >>      > supported by the underlying providers
> >>      >
> >>      > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444
> >>      > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not
> >>      > supported by the underlying providers
> >>      >
> >>      > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449
> >>      > AEDT|AlpnExtension.java:161|No available application protocols
> >>      >
> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449
> >>      > AEDT|SSLExtensions.java:235|Ignore, context unavailable
> >> extension:
> >>      > application_layer_protocol_negotiation
> >>      >
> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450
> >>      > AEDT|SSLExtensions.java:235|Ignore, context unavailable
> >> extension:
> >>      > status_request_v2
> >>      >
> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453
> >>      > AEDT|ClientHello.java:651|Produced ClientHello handshake
> >> message (
> >>      >
> >>      > "ClientHello": {
> >>      >
> >>      > "client version"      : "TLSv1.2",
> >>      >
> >>      > "random"              : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24
> >>     7F 34 3D
> >>      > 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68",
> >>      >
> >>      > "session id"          : "",
> >>      >
> >>      > "cipher suites"       :
> >>      > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
> >>      > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
> >>      > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
> >>      > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
> >>      > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]",
> >>      >
> >>      > "compression methods" : "00",
> >>      >
> >>      > "extensions"          : [
> >>      >
> >>      > "supported_groups (10)": {
> >>      >
> >>      > "versions": [secp256r1, secp384r1, secp521r1, secp160k1]
> >>      >
> >>      >      },
> >>      >
> >>      > "ec_point_formats (11)": {
> >>      >
> >>      > "formats": [uncompressed]
> >>      >
> >>      >      },
> >>      >
> >>      > "signature_algorithms (13)": {
> >>      >
> >>      > "signature schemes": [ecdsa_secp256r1_sha256,
> >>     ecdsa_secp384r1_sha384,
> >>      > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
> >>      > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
> >>      > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
> >>      > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224,
> >> dsa_sha224,
> >>      > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
> >>      >
> >>      >      },
> >>      >
> >>      > "signature_algorithms_cert (50)": {
> >>      >
> >>      > "signature schemes": [ecdsa_secp256r1_sha256,
> >>     ecdsa_secp384r1_sha384,
> >>      > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256, rsa_pss_rsae_sha384,
> >>      > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
> >>      > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
> >>      > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224,
> >> dsa_sha224,
> >>      > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
> >>      >
> >>      >      },
> >>      >
> >>      > "extended_master_secret (23)": {
> >>      >
> >>      >        <empty>
> >>      >
> >>      >      },
> >>      >
> >>      > "supported_versions (43)": {
> >>      >
> >>      > "versions": [TLSv1.2, TLSv1.1]
> >>      >
> >>      >      },
> >>      >
> >>      > "renegotiation_info (65,281)": {
> >>      >
> >>      > "renegotiated connection": [<no renegotiated connection>]
> >>      >
> >>      >      }
> >>      >
> >>      >    ]
> >>      >
> >>      > }
> >>      >
> >>      > )
> >>      >
> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455
> >>      > AEDT|Alert.java:232|Received alert message (
> >>      >
> >>      > "Alert": {
> >>      >
> >>      > "level"      : "fatal",
> >>      >
> >>      > "description": "handshake_failure"
> >>      >
> >>      > }
> >>      >
> >>      > )
> >>      >
> >>      > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456
> >>      > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE):
> >>     Received fatal
> >>      > alert: handshake_failure (
> >>      >
> >>      > "throwable" : {
> >>      >
> >>      >    javax.net.ssl.SSLHandshakeException: Received fatal alert:
> >>      > handshake_failure
> >>      >
> >>      >      at
> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
> >>      >
> >>      >      at
> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> >>      >
> >>      >      at
> >>      >
> >>
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
> >>      >
> >>      >      at
> >>      >
> >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
> >>      >
> >>      >      at
> >>      >
> >>
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
> >>      >
> >>      >      at
> >>      >
> >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
> >>      >
> >>      >      at
> >>      >
> >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
> >>      >
> >>      >      at
> >>      >
> >>
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
> >>      >
> >>      >      at
> >>      >
> >>
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
> >>      >
> >>      >      at SslSocketClient.main(SslSocketClient.kt:47)}
> >>      >
> >>      >
> >>      > )
> >>      >
> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
> >>      > AEDT|SSLSocketImpl.java:1361|close the underlying socket
> >>      >
> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
> >>      > AEDT|SSLSocketImpl.java:1380|close the SSL connection
> >> (initiative)
> >>      >
> >>      > Exception in thread "main" javax.net.ssl.SSLHandshakeException:
> >>     Received
> >>      > fatal alert: handshake_failure
> >>      >
> >>      >    at
> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
> >>      >
> >>      >    at
> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
> >>      >
> >>      >    at
> >>      >
> >>
> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
> >>      >
> >>      >    at
> >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
> >>      >
> >>      >    at
> >>      >
> >>
> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
> >>      >
> >>      >    at
> >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
> >>      >
> >>      >    at
> >>      >
> >> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
> >>      >
> >>      >    at
> >>      >
> >>
> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
> >>      >
> >>      >    at
> >>      >
> >>
> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
> >>      >
> >>      >    at SslSocketClient.main(SslSocketClient.kt:47)
> >>      >
> >>      >
> >>      >
> >>      >
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190214/1a808acd/attachment-0001.html>

From openjdk at suche.org  Wed Feb 13 22:22:27 2019
From: openjdk at suche.org (=?UTF-8?Q?Thomas_Lu=c3=9fnig?=)
Date: Wed, 13 Feb 2019 23:22:27 +0100
Subject: Not possible to disable new TLS extensions for TLS 1.2 connections
In-Reply-To: <CAJ3+Awehpfrs91J6F2bhpX3o0YjJizvDon0k6V+aiLwPDCR4ww@mail.gmail.com>
References: <CAJ3+Awc9F5phKuMZZ1ohYtkhBHKvydvVioHJGpCkRaThAD6t=g@mail.gmail.com>
 <3dfb3505-dd0e-3b91-17a0-c6165d7a1069@oracle.com>
 <CAJ3+AweJFwhxFitO5ALd6SPAhsOrODFFMaKtvd68zejjFKqX+w@mail.gmail.com>
 <283c595b-5ff5-66d7-46fb-f3a60817a508@oracle.com>
 <1d76a7a3-103a-c7c0-8834-3b7e953c7291@suche.org>
 <CAJ3+Awehpfrs91J6F2bhpX3o0YjJizvDon0k6V+aiLwPDCR4ww@mail.gmail.com>
Message-ID: <ed1de7ed-9326-7ccd-8a62-5cf4636da15b@suche.org>

Hi,

i check the old mails. In your case the problem was about the EC-Group 
extensions. If the server receive an unknown group he break the 
handshake with an alert. What was interesting is the fact it did not 
break after client hello but after Client-RSA-Key with alert 
illgegalParameter. I managed to establish the connection by disable all 
cipher suites using ec (only for this destination) not an good but an 
working solution.
Maybe you can provide an ssl debug log or pcap so that is is possible to 
see if the same type of error happen.

Gru? Thomas

Sequence was:

Client-Hello (SSLv3 - TLSv1.2)
Server-Hello(SSLv3)
Server-Certificates(SSLv3)
Client-RSA-Key(TLSv1.2)
Server-Alert(SSLv3 , FATAL , IllegalParameter)


p.s. for the Problem with exception about unsupported group in jdk10 
(fixed in 11) i found an workaround by only offering RSA and no EC suites
 ?to the server that send 65535 as EC group that was causing the trouble.

Am 13.02.2019 um 23:08:22 schrieb Amir Khassaia:
> Hi Thomas,
> Can you confirm its tied to new extensions to TLS 1.2 client hello and 
> whether you diagnosed which one was the problem in Lotus Notes case ?
>
> On Thu, Feb 14, 2019 at 9:05 AM Thomas Lu?nig <openjdk at suche.org 
> <mailto:openjdk at suche.org>> wrote:
>
>     Hi,
>
>     maybe two points.
>
>     1) Older lotus notes server have the problem.
>     2) The problem can be solved if you disable TLSv1.3 or even TLSv1.2
>     3) Maybe it would be an good idea to build an set of client
>     hello's with
>     different options.
>     ????? Or even an generator. Than you send if and check the result
>     since
>     the servers with problem
>     ????? only reply with an ssl alert. So you can check it without an
>     ssl
>     engine or jdk build
>
>
>     Gru? Thomas
>
>     Am 13.02.2019 um 22:44:31 schrieb Xuelei Fan:
>     > Hi Amir,
>     >
>     > Could you build OpenJDK by yourself?? If it is doable, I could send
>     > your a patch to disable the extension so that you can confirm if
>     and
>     > which extension is the underlying problem.
>     >
>     > Thanks,
>     > Xuelei
>     >
>     >
>     > On 2/13/2019 1:16 PM, Amir Khassaia wrote:
>     >> Hi Xuelei,
>     >> There were 2 distinct cases of change of behaviour.
>     >>
>     >> ? * The "CN=invalid2.invalid, OU="No SNI provided" reliably works
>     >> ??? without SNI in Java 8 but is indeed fixed by having an SNI
>     included
>     >> ??? which perhaps was needed all along. This one is reported by
>     XMPP/TLS
>     >> ??? connection from talk.google.com:5222
>     <http://talk.google.com:5222> <http://talk.google.com:5222>
>     >> ? * The aborted handshake case (client_hello traces that I've
>     provided)
>     >> ??? this happened with a hardware device which was replicable
>     with an
>     >> ??? SSL socket handshake program that I referenced in the gist.
>     >> ??? Unfortunately replication requires a specific device model
>     so it
>     >> ??? wont be possible to see it for yourself. The workaround
>     there was to
>     >> ??? either downgrade JRE to < 11 or to switch JRE globally to
>     use TLS
>     >> ??? 1.0 or TLS 1.1 via the system property. This is where your
>     proposed
>     >> ??? enhancement will be of great help as it will allow a per
>     connection
>     >> ??? type decision.
>     >>
>     >>
>     >> On Wed, Feb 13, 2019 at 3:01 PM Xuelei Fan
>     <xuelei.fan at oracle.com <mailto:xuelei.fan at oracle.com>
>     >> <mailto:xuelei.fan at oracle.com <mailto:xuelei.fan at oracle.com>>>
>     wrote:
>     >>
>     >> ??? Hi Amir,
>     >>
>     >> ??? It should be rare now the a TLS vendor cannot ignore unknown
>     >> extensions.
>     >>
>     >> ???? ?> "issuer": "CN=invalid2.invalid, OU="No SNI provided;
>     >> ???? ?> please fix your client."",
>     >> ??? The error message encapsulated in the certificate does not
>     sound
>     >> right
>     >> ??? to me.? Is it caused by the absence of SNI extension?
>     >>
>     >> ??? Did you have a test case that I can reproduce the problem?
>     >>
>     >> ??? Thanks & Regards,
>     >> ??? Xuelei
>     >>
>     >>
>     >> ??? On 1/7/2019 9:27 PM, Amir Khassaia wrote:
>     >> ???? > Xuelei,
>     >> ???? > The certificate in the connection is a red herring and not
>     >> ??? important.
>     >> ???? > It's actually a very unusual behaviour by
>     talk.google.com <http://talk.google.com>
>     >> ??? <http://talk.google.com>
>     >> ???? > <http://talk.google.com> endpoint to encapsulate an
>     error message
>     >> ??? inside
>     >> ???? > a certificate.
>     >> ???? >
>     >> ???? > As per the output I included:
>     >> ???? >
>     >> ???? > /"certificate" : { />/? ? "version" ? ? ? : "v3", />/
>     >> ??? "serial number"? ? ? : "00 90 76 89 18 E9 33 93 A0", />/
>     >> "signature algorithm": "SHA256withRSA", />/ "issuer"
>     >> ???? ?: "CN=invalid2.invalid, OU="No SNI provided; />/please
>     fix your
>     >> ??? client."", />/? ? "not before"? ? ? ? ?: "2015-01-01
>     11:00:00.000
>     >> ??? AEDT", />/? ? "not? after"? ? ? ? ?: "2030-01-01
>     11:00:00.000 AEDT",
>     >> ??? />/? ? "subject"? ? ? ? ? ? : "CN=invalid2.invalid, OU="No SNI
>     >> ??? provided; />/please fix your client."",/
>     >> ???? >
>     >> ???? > /
>     >> ???? > /
>     >> ???? >
>     >> ???? > This certificate simply masks the TLS interoperability
>     issue
>     >> as an
>     >> ???? > untrusted certificate issue.
>     >> ???? >
>     >> ???? > The fact is, some of the extensions sent by JSSE are
>     changes to
>     >> ??? TLS 1.2
>     >> ???? > to support TLS 1.3, this however affects some clients
>     >> adversely in
>     >> ???? > practice and usually JDK provides properties to turn new
>     >> ??? enhancements
>     >> ???? > off and work around such behaviour, for the extensions I
>     >> ??? mentioned this
>     >> ???? > is not provided and hence they are always sent for
>     client sockets
>     >> ??? unless
>     >> ???? > TLSv1.2 is not in use.
>     >> ???? >
>     >> ???? > The impact to us is that upgrading to JDK11 means for some
>     >> ??? endpoints or
>     >> ???? > devices that are not 100% compliant to the spec the
>     security is
>     >> ??? reduced
>     >> ???? > as we have to now work around to drop connections to
>     these to
>     >> ??? TLSv1.1 or
>     >> ???? > TLS1.0 or not to move to Java 11 at all.
>     >> ???? >
>     >> ???? > My request is simply to have all of the new extensions
>     >> ??? configurable on
>     >> ???? > individual basis so that they can be turned off if
>     needed for
>     >> ???? > compatibility just like most other security enhancements
>     that
>     >> were
>     >> ???? > delivered in the past.
>     >> ???? >
>     >> ???? > It appears some of the issues can come from
>     >> ???? >
>     >> ???? > - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but
>     these can
>     >> ???? > disabled at least
>     >> ???? >
>     >> ???? > -signature_algorithms_cert and supported_versions extensions
>     >> ??? which seem
>     >> ???? > to be hardcoded for TLS 1.2 (I was not able to conclusively
>     >> identify
>     >> ???? > which of these caused my troubles)
>     >> ???? >
>     >> ???? > https://tools.ietf.org/html/rfc8446#section-1.3 does say
>     that TLS
>     >> ??? 1.2
>     >> ???? > clients are affected but in an optional manner.Just
>     today I've
>     >> ???? > encountered another Java 11 interop issue with TLS but
>     this time
>     >> ??? with a
>     >> ???? > physical device which can have a long shelf life yet
>     running a
>     >> ??? simple
>     >> ???? > client socket handshake abruptly terminates the
>     connection upon
>     >> ??? client
>     >> ???? > hello (no server_hello at all), and downgrading the JRE
>     below 11
>     >> ??? works
>     >> ???? > fine. I'm including a trace for that as well:
>     >> ???? >
>     >> ???? >
>     >> ???? > javax.net.ssl|DEBUG|01|main|2019-01-0813:40:14.395
>     >> AEDT|SSLCipher.java:437|jdk.tls.keyLimits: ? entry =
>     >> ??? AES/GCM/NoPadding KeyUpdate2^37. AES/GCM/NOPADDING:KEYUPDATE
>     >> ??? =137438953472
>     >> ???? >
>     >> ???? > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433
>     >> ???? > AEDT|ServerNameExtension.java:255|Unable to indicate
>     server name
>     >> ???? >
>     >> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
>     >> ???? > AEDT|SSLExtensions.java:235|Ignore, context unavailable
>     >> extension:
>     >> ???? > server_name
>     >> ???? >
>     >> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
>     >> ???? > AEDT|SSLExtensions.java:235|Ignore, context unavailable
>     >> extension:
>     >> ???? > status_request
>     >> ???? >
>     >> ???? > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443
>     >> ???? > AEDT|SignatureScheme.java:282|Signature algorithm,
>     ed25519, is
>     >> not
>     >> ???? > supported by the underlying providers
>     >> ???? >
>     >> ???? > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444
>     >> ???? > AEDT|SignatureScheme.java:282|Signature algorithm,
>     ed448, is not
>     >> ???? > supported by the underlying providers
>     >> ???? >
>     >> ???? > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449
>     >> ???? > AEDT|AlpnExtension.java:161|No available application
>     protocols
>     >> ???? >
>     >> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449
>     >> ???? > AEDT|SSLExtensions.java:235|Ignore, context unavailable
>     >> extension:
>     >> ???? > application_layer_protocol_negotiation
>     >> ???? >
>     >> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450
>     >> ???? > AEDT|SSLExtensions.java:235|Ignore, context unavailable
>     >> extension:
>     >> ???? > status_request_v2
>     >> ???? >
>     >> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453
>     >> ???? > AEDT|ClientHello.java:651|Produced ClientHello handshake
>     >> message (
>     >> ???? >
>     >> ???? > "ClientHello": {
>     >> ???? >
>     >> ???? > "client version"? ? ? : "TLSv1.2",
>     >> ???? >
>     >> ???? > "random"? ? ? ? ? ? ? : "1A BA E8 FC 59 00 AB DF 9A 1A
>     07 94 24
>     >> ??? 7F 34 3D
>     >> ???? > 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68",
>     >> ???? >
>     >> ???? > "session id"? ? ? ? ? : "",
>     >> ???? >
>     >> ???? > "cipher suites"? ? ? ?:
>     >> ???? > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
>     >> ???? > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
>     >> ???? > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
>     >> ???? > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
>     >> ???? > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]",
>     >> ???? >
>     >> ???? > "compression methods" : "00",
>     >> ???? >
>     >> ???? > "extensions"? ? ? ? ? : [
>     >> ???? >
>     >> ???? > "supported_groups (10)": {
>     >> ???? >
>     >> ???? > "versions": [secp256r1, secp384r1, secp521r1, secp160k1]
>     >> ???? >
>     >> ???? >? ? ? },
>     >> ???? >
>     >> ???? > "ec_point_formats (11)": {
>     >> ???? >
>     >> ???? > "formats": [uncompressed]
>     >> ???? >
>     >> ???? >? ? ? },
>     >> ???? >
>     >> ???? > "signature_algorithms (13)": {
>     >> ???? >
>     >> ???? > "signature schemes": [ecdsa_secp256r1_sha256,
>     >> ??? ecdsa_secp384r1_sha384,
>     >> ???? > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256,
>     rsa_pss_rsae_sha384,
>     >> ???? > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
>     >> ???? > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
>     >> ???? > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224,
>     >> dsa_sha224,
>     >> ???? > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
>     >> ???? >
>     >> ???? >? ? ? },
>     >> ???? >
>     >> ???? > "signature_algorithms_cert (50)": {
>     >> ???? >
>     >> ???? > "signature schemes": [ecdsa_secp256r1_sha256,
>     >> ??? ecdsa_secp384r1_sha384,
>     >> ???? > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256,
>     rsa_pss_rsae_sha384,
>     >> ???? > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
>     >> ???? > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
>     >> ???? > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224,
>     >> dsa_sha224,
>     >> ???? > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
>     >> ???? >
>     >> ???? >? ? ? },
>     >> ???? >
>     >> ???? > "extended_master_secret (23)": {
>     >> ???? >
>     >> ???? >? ? ? ? <empty>
>     >> ???? >
>     >> ???? >? ? ? },
>     >> ???? >
>     >> ???? > "supported_versions (43)": {
>     >> ???? >
>     >> ???? > "versions": [TLSv1.2, TLSv1.1]
>     >> ???? >
>     >> ???? >? ? ? },
>     >> ???? >
>     >> ???? > "renegotiation_info (65,281)": {
>     >> ???? >
>     >> ???? > "renegotiated connection": [<no renegotiated connection>]
>     >> ???? >
>     >> ???? >? ? ? }
>     >> ???? >
>     >> ???? >? ? ]
>     >> ???? >
>     >> ???? > }
>     >> ???? >
>     >> ???? > )
>     >> ???? >
>     >> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455
>     >> ???? > AEDT|Alert.java:232|Received alert message (
>     >> ???? >
>     >> ???? > "Alert": {
>     >> ???? >
>     >> ???? > "level"? ? ? : "fatal",
>     >> ???? >
>     >> ???? > "description": "handshake_failure"
>     >> ???? >
>     >> ???? > }
>     >> ???? >
>     >> ???? > )
>     >> ???? >
>     >> ???? > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456
>     >> ???? > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE):
>     >> ??? Received fatal
>     >> ???? > alert: handshake_failure (
>     >> ???? >
>     >> ???? > "throwable" : {
>     >> ???? >
>     >> ???? >? ? javax.net.ssl.SSLHandshakeException: Received fatal
>     alert:
>     >> ???? > handshake_failure
>     >> ???? >
>     >> ???? >? ? ? at
>     >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>     >> ???? >
>     >> ???? >? ? ? at
>     >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>     >> ???? >
>     >> ???? >? ? ? at
>     >> ???? >
>     >>
>     java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>     >> ???? >
>     >> ???? >? ? ? at
>     >> ???? >
>     >>
>     java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
>     >> ???? >
>     >> ???? >? ? ? at
>     >> ???? >
>     >>
>     java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
>     >> ???? >
>     >> ???? >? ? ? at
>     >> ???? >
>     >>
>     java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>     >> ???? >
>     >> ???? >? ? ? at
>     >> ???? >
>     >>
>     java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>     >> ???? >
>     >> ???? >? ? ? at
>     >> ???? >
>     >>
>     java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>     >> ???? >
>     >> ???? >? ? ? at
>     >> ???? >
>     >>
>     java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>     >> ???? >
>     >> ???? >? ? ? at SslSocketClient.main(SslSocketClient.kt:47)}
>     >> ???? >
>     >> ???? >
>     >> ???? > )
>     >> ???? >
>     >> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
>     >> ???? > AEDT|SSLSocketImpl.java:1361|close the underlying socket
>     >> ???? >
>     >> ???? > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
>     >> ???? > AEDT|SSLSocketImpl.java:1380|close the SSL connection
>     >> (initiative)
>     >> ???? >
>     >> ???? > Exception in thread "main"
>     javax.net.ssl.SSLHandshakeException:
>     >> ??? Received
>     >> ???? > fatal alert: handshake_failure
>     >> ???? >
>     >> ???? >? ? at
>     >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>     >> ???? >
>     >> ???? >? ? at
>     >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>     >> ???? >
>     >> ???? >? ? at
>     >> ???? >
>     >>
>     java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>     >> ???? >
>     >> ???? >? ? at
>     >>
>     java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
>     >> ???? >
>     >> ???? >? ? at
>     >> ???? >
>     >>
>     java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
>     >> ???? >
>     >> ???? >? ? at
>     >>
>     java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>     >> ???? >
>     >> ???? >? ? at
>     >> ???? >
>     >>
>     java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>     >> ???? >
>     >> ???? >? ? at
>     >> ???? >
>     >>
>     java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>     >> ???? >
>     >> ???? >? ? at
>     >> ???? >
>     >>
>     java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>     >> ???? >
>     >> ???? >? ? at SslSocketClient.main(SslSocketClient.kt:47)
>     >> ???? >
>     >> ???? >
>     >> ???? >
>     >> ???? >
>     >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190213/936397d8/attachment-0001.html>

From christoph.langer at sap.com  Wed Feb 13 22:30:45 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Wed, 13 Feb 2019 22:30:45 +0000
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <F146FB1D-726B-416F-97FA-7ED3CD9FCF44@oracle.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <CA+3eh102cMGphPPbABv2ef_M5Py5+Mg-FRU94HcpKUH3gaV6+w@mail.gmail.com>
 <fd756aff51134b15a40fe55247d4a87e@sap.com>
 <CA+3eh13dP-tCdq4H4z3KWJZQzfMJYqDNkx9fMh3tNfL08RCtDg@mail.gmail.com>
 <7b513a34196141f595cd5d194fb9d8a2@sap.com>
 <fa4078d9-7aec-f122-e9ca-7b816e115c9b@oracle.com>
 <CA+3eh10kDtTEpcRsUWhQEkEyRyTdbvxxmZ8U-G97OeUG2kkU3A@mail.gmail.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <F146FB1D-726B-416F-97FA-7ED3CD9FCF44@oracle.com>
Message-ID: <818ca9a7fe2445638dddc2481f95f9f8@sap.com>

Hi Lance,

thanks for looking.

> Just starting to take a peek at this and noticed one quick thing in your test:
> ------------
> Paths.get(System.getProperty("test.dir", "."), "testPosix.zip")
> ??????
> 
> You do not need the test.dir property ?or the permission added to test.policy
> to access it, ?just reference the jar and it will be created in user.dir which is
> also writable.

Hm, I thought I didn't want to mess around in "user.dir" as it can be some more global directory where you wouldn't want to leave artefacts... To me "test.dir" feels cleaner. Are there other opinions about that?

Thanks
Christoph


From amir.khassaia at gmail.com  Wed Feb 13 22:35:48 2019
From: amir.khassaia at gmail.com (Amir Khassaia)
Date: Thu, 14 Feb 2019 09:35:48 +1100
Subject: Not possible to disable new TLS extensions for TLS 1.2 connections
In-Reply-To: <ed1de7ed-9326-7ccd-8a62-5cf4636da15b@suche.org>
References: <CAJ3+Awc9F5phKuMZZ1ohYtkhBHKvydvVioHJGpCkRaThAD6t=g@mail.gmail.com>
 <3dfb3505-dd0e-3b91-17a0-c6165d7a1069@oracle.com>
 <CAJ3+AweJFwhxFitO5ALd6SPAhsOrODFFMaKtvd68zejjFKqX+w@mail.gmail.com>
 <283c595b-5ff5-66d7-46fb-f3a60817a508@oracle.com>
 <1d76a7a3-103a-c7c0-8834-3b7e953c7291@suche.org>
 <CAJ3+Awehpfrs91J6F2bhpX3o0YjJizvDon0k6V+aiLwPDCR4ww@mail.gmail.com>
 <ed1de7ed-9326-7ccd-8a62-5cf4636da15b@suche.org>
Message-ID: <CAJ3+AwcDvJgzjybKd-fOs1fh1aKyCSAXE5fC5hu8LxEQiFjTyg@mail.gmail.com>

While this is somewhat similar its still a little different to what I was
asking because you can control named groups right now with the system
property, eg. jdk.tls.namedGroups (yes its global not ideal) and also at
the socket level but at least you dont have to drop TLS level.
For the other extensions I mentioned, you cannot control them at all you
have to drop TLS level, even a system property is better but of course
something per connection eg, SSLParameters is ideal.



On Thu, Feb 14, 2019 at 9:22 AM Thomas Lu?nig <openjdk at suche.org> wrote:

> Hi,
>
> i check the old mails. In your case the problem was about the EC-Group
> extensions. If the server receive an unknown group he break the handshake
> with an alert. What was interesting is the fact it did not break after
> client hello but after Client-RSA-Key with alert illgegalParameter. I
> managed to establish the connection by disable all cipher suites using ec
> (only for this destination) not an good but an working solution.
> Maybe you can provide an ssl debug log or pcap so that is is possible to
> see if the same type of error happen.
>
> Gru? Thomas
>
> Sequence was:
>
> Client-Hello (SSLv3 - TLSv1.2)
> Server-Hello(SSLv3)
> Server-Certificates(SSLv3)
> Client-RSA-Key(TLSv1.2)
> Server-Alert(SSLv3 , FATAL , IllegalParameter)
>
>
> p.s. for the Problem with exception about unsupported group in jdk10
> (fixed in 11) i found an workaround by only offering RSA and no EC suites
>  to the server that send 65535 as EC group that was causing the trouble.
> Am 13.02.2019 um 23:08:22 schrieb Amir Khassaia:
>
> Hi Thomas,
> Can you confirm its tied to new extensions to TLS 1.2 client hello and
> whether you diagnosed which one was the problem in Lotus Notes case ?
>
> On Thu, Feb 14, 2019 at 9:05 AM Thomas Lu?nig <openjdk at suche.org> wrote:
>
>> Hi,
>>
>> maybe two points.
>>
>> 1) Older lotus notes server have the problem.
>> 2) The problem can be solved if you disable TLSv1.3 or even TLSv1.2
>> 3) Maybe it would be an good idea to build an set of client hello's with
>> different options.
>>       Or even an generator. Than you send if and check the result since
>> the servers with problem
>>       only reply with an ssl alert. So you can check it without an ssl
>> engine or jdk build
>>
>>
>> Gru? Thomas
>>
>> Am 13.02.2019 um 22:44:31 schrieb Xuelei Fan:
>> > Hi Amir,
>> >
>> > Could you build OpenJDK by yourself?  If it is doable, I could send
>> > your a patch to disable the extension so that you can confirm if and
>> > which extension is the underlying problem.
>> >
>> > Thanks,
>> > Xuelei
>> >
>> >
>> > On 2/13/2019 1:16 PM, Amir Khassaia wrote:
>> >> Hi Xuelei,
>> >> There were 2 distinct cases of change of behaviour.
>> >>
>> >>   * The "CN=invalid2.invalid, OU="No SNI provided" reliably works
>> >>     without SNI in Java 8 but is indeed fixed by having an SNI included
>> >>     which perhaps was needed all along. This one is reported by
>> XMPP/TLS
>> >>     connection from talk.google.com:5222 <http://talk.google.com:5222>
>> >>   * The aborted handshake case (client_hello traces that I've provided)
>> >>     this happened with a hardware device which was replicable with an
>> >>     SSL socket handshake program that I referenced in the gist.
>> >>     Unfortunately replication requires a specific device model so it
>> >>     wont be possible to see it for yourself. The workaround there was
>> to
>> >>     either downgrade JRE to < 11 or to switch JRE globally to use TLS
>> >>     1.0 or TLS 1.1 via the system property. This is where your proposed
>> >>     enhancement will be of great help as it will allow a per connection
>> >>     type decision.
>> >>
>> >>
>> >> On Wed, Feb 13, 2019 at 3:01 PM Xuelei Fan <xuelei.fan at oracle.com
>> >> <mailto:xuelei.fan at oracle.com>> wrote:
>> >>
>> >>     Hi Amir,
>> >>
>> >>     It should be rare now the a TLS vendor cannot ignore unknown
>> >> extensions.
>> >>
>> >>       > "issuer": "CN=invalid2.invalid, OU="No SNI provided;
>> >>       > please fix your client."",
>> >>     The error message encapsulated in the certificate does not sound
>> >> right
>> >>     to me.  Is it caused by the absence of SNI extension?
>> >>
>> >>     Did you have a test case that I can reproduce the problem?
>> >>
>> >>     Thanks & Regards,
>> >>     Xuelei
>> >>
>> >>
>> >>     On 1/7/2019 9:27 PM, Amir Khassaia wrote:
>> >>      > Xuelei,
>> >>      > The certificate in the connection is a red herring and not
>> >>     important.
>> >>      > It's actually a very unusual behaviour by talk.google.com
>> >>     <http://talk.google.com>
>> >>      > <http://talk.google.com> endpoint to encapsulate an error
>> message
>> >>     inside
>> >>      > a certificate.
>> >>      >
>> >>      > As per the output I included:
>> >>      >
>> >>      > /"certificate" : { />/    "version"            : "v3", />/
>> >>     "serial number"      : "00 90 76 89 18 E9 33 93 A0", />/
>> >> "signature algorithm": "SHA256withRSA", />/    "issuer"
>> >>       : "CN=invalid2.invalid, OU="No SNI provided; />/please fix your
>> >>     client."", />/    "not before"         : "2015-01-01 11:00:00.000
>> >>     AEDT", />/    "not  after"         : "2030-01-01 11:00:00.000
>> AEDT",
>> >>     />/    "subject"            : "CN=invalid2.invalid, OU="No SNI
>> >>     provided; />/please fix your client."",/
>> >>      >
>> >>      > /
>> >>      > /
>> >>      >
>> >>      > This certificate simply masks the TLS interoperability issue
>> >> as an
>> >>      > untrusted certificate issue.
>> >>      >
>> >>      > The fact is, some of the extensions sent by JSSE are changes to
>> >>     TLS 1.2
>> >>      > to support TLS 1.3, this however affects some clients
>> >> adversely in
>> >>      > practice and usually JDK provides properties to turn new
>> >>     enhancements
>> >>      > off and work around such behaviour, for the extensions I
>> >>     mentioned this
>> >>      > is not provided and hence they are always sent for client
>> sockets
>> >>     unless
>> >>      > TLSv1.2 is not in use.
>> >>      >
>> >>      > The impact to us is that upgrading to JDK11 means for some
>> >>     endpoints or
>> >>      > devices that are not 100% compliant to the spec the security is
>> >>     reduced
>> >>      > as we have to now work around to drop connections to these to
>> >>     TLSv1.1 or
>> >>      > TLS1.0 or not to move to Java 11 at all.
>> >>      >
>> >>      > My request is simply to have all of the new extensions
>> >>     configurable on
>> >>      > individual basis so that they can be turned off if needed for
>> >>      > compatibility just like most other security enhancements that
>> >> were
>> >>      > delivered in the past.
>> >>      >
>> >>      > It appears some of the issues can come from
>> >>      >
>> >>      > - inclusion of RSASSA-PSS alg in TLS 1.2 handshakes but these
>> can
>> >>      > disabled at least
>> >>      >
>> >>      > -signature_algorithms_cert and supported_versions extensions
>> >>     which seem
>> >>      > to be hardcoded for TLS 1.2 (I was not able to conclusively
>> >> identify
>> >>      > which of these caused my troubles)
>> >>      >
>> >>      > https://tools.ietf.org/html/rfc8446#section-1.3 does say that
>> TLS
>> >>     1.2
>> >>      > clients are affected but in an optional manner.Just today I've
>> >>      > encountered another Java 11 interop issue with TLS but this time
>> >>     with a
>> >>      > physical device which can have a long shelf life yet running a
>> >>     simple
>> >>      > client socket handshake abruptly terminates the connection upon
>> >>     client
>> >>      > hello (no server_hello at all), and downgrading the JRE below 11
>> >>     works
>> >>      > fine. I'm including a trace for that as well:
>> >>      >
>> >>      >
>> >>      > javax.net.ssl|DEBUG|01|main|2019-01-0813:40:14.395
>> >> AEDT|SSLCipher.java:437|jdk.tls.keyLimits:   entry =
>> >>     AES/GCM/NoPadding KeyUpdate2^37. AES/GCM/NOPADDING:KEYUPDATE
>> >>     =137438953472
>> >>      >
>> >>      > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.433
>> >>      > AEDT|ServerNameExtension.java:255|Unable to indicate server name
>> >>      >
>> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
>> >>      > AEDT|SSLExtensions.java:235|Ignore, context unavailable
>> >> extension:
>> >>      > server_name
>> >>      >
>> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.433
>> >>      > AEDT|SSLExtensions.java:235|Ignore, context unavailable
>> >> extension:
>> >>      > status_request
>> >>      >
>> >>      > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.443
>> >>      > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is
>> >> not
>> >>      > supported by the underlying providers
>> >>      >
>> >>      > javax.net.ssl|WARNING|01|main|2019-01-08 13:40:14.444
>> >>      > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not
>> >>      > supported by the underlying providers
>> >>      >
>> >>      > javax.net.ssl|INFO|01|main|2019-01-08 13:40:14.449
>> >>      > AEDT|AlpnExtension.java:161|No available application protocols
>> >>      >
>> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.449
>> >>      > AEDT|SSLExtensions.java:235|Ignore, context unavailable
>> >> extension:
>> >>      > application_layer_protocol_negotiation
>> >>      >
>> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.450
>> >>      > AEDT|SSLExtensions.java:235|Ignore, context unavailable
>> >> extension:
>> >>      > status_request_v2
>> >>      >
>> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.453
>> >>      > AEDT|ClientHello.java:651|Produced ClientHello handshake
>> >> message (
>> >>      >
>> >>      > "ClientHello": {
>> >>      >
>> >>      > "client version"      : "TLSv1.2",
>> >>      >
>> >>      > "random"              : "1A BA E8 FC 59 00 AB DF 9A 1A 07 94 24
>> >>     7F 34 3D
>> >>      > 0B D2 7D 10 72 52 54 CD 44 43 62 E8 8B 42 C6 68",
>> >>      >
>> >>      > "session id"          : "",
>> >>      >
>> >>      > "cipher suites"       :
>> >>      > "[TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
>> >>      > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
>> >>      > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
>> >>      > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
>> >>      > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F)]",
>> >>      >
>> >>      > "compression methods" : "00",
>> >>      >
>> >>      > "extensions"          : [
>> >>      >
>> >>      > "supported_groups (10)": {
>> >>      >
>> >>      > "versions": [secp256r1, secp384r1, secp521r1, secp160k1]
>> >>      >
>> >>      >      },
>> >>      >
>> >>      > "ec_point_formats (11)": {
>> >>      >
>> >>      > "formats": [uncompressed]
>> >>      >
>> >>      >      },
>> >>      >
>> >>      > "signature_algorithms (13)": {
>> >>      >
>> >>      > "signature schemes": [ecdsa_secp256r1_sha256,
>> >>     ecdsa_secp384r1_sha384,
>> >>      > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256,
>> rsa_pss_rsae_sha384,
>> >>      > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
>> >>      > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
>> >>      > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224,
>> >> dsa_sha224,
>> >>      > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
>> >>      >
>> >>      >      },
>> >>      >
>> >>      > "signature_algorithms_cert (50)": {
>> >>      >
>> >>      > "signature schemes": [ecdsa_secp256r1_sha256,
>> >>     ecdsa_secp384r1_sha384,
>> >>      > ecdsa_secp512r1_sha512, rsa_pss_rsae_sha256,
>> rsa_pss_rsae_sha384,
>> >>      > rsa_pss_rsae_sha512, rsa_pss_pss_sha256, rsa_pss_pss_sha384,
>> >>      > rsa_pss_pss_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
>> >>      > rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha224, rsa_sha224,
>> >> dsa_sha224,
>> >>      > ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1, rsa_md5]
>> >>      >
>> >>      >      },
>> >>      >
>> >>      > "extended_master_secret (23)": {
>> >>      >
>> >>      >        <empty>
>> >>      >
>> >>      >      },
>> >>      >
>> >>      > "supported_versions (43)": {
>> >>      >
>> >>      > "versions": [TLSv1.2, TLSv1.1]
>> >>      >
>> >>      >      },
>> >>      >
>> >>      > "renegotiation_info (65,281)": {
>> >>      >
>> >>      > "renegotiated connection": [<no renegotiated connection>]
>> >>      >
>> >>      >      }
>> >>      >
>> >>      >    ]
>> >>      >
>> >>      > }
>> >>      >
>> >>      > )
>> >>      >
>> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.455
>> >>      > AEDT|Alert.java:232|Received alert message (
>> >>      >
>> >>      > "Alert": {
>> >>      >
>> >>      > "level"      : "fatal",
>> >>      >
>> >>      > "description": "handshake_failure"
>> >>      >
>> >>      > }
>> >>      >
>> >>      > )
>> >>      >
>> >>      > javax.net.ssl|ERROR|01|main|2019-01-08 13:40:14.456
>> >>      > AEDT|TransportContext.java:313|Fatal (HANDSHAKE_FAILURE):
>> >>     Received fatal
>> >>      > alert: handshake_failure (
>> >>      >
>> >>      > "throwable" : {
>> >>      >
>> >>      >    javax.net.ssl.SSLHandshakeException: Received fatal alert:
>> >>      > handshake_failure
>> >>      >
>> >>      >      at
>> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>> >>      >
>> >>      >      at
>> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>> >>      >
>> >>      >      at
>> >>      >
>> >>
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>> >>      >
>> >>      >      at
>> >>      >
>> >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
>> >>      >
>> >>      >      at
>> >>      >
>> >>
>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
>> >>      >
>> >>      >      at
>> >>      >
>> >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>> >>      >
>> >>      >      at
>> >>      >
>> >>
>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>> >>      >
>> >>      >      at
>> >>      >
>> >>
>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>> >>      >
>> >>      >      at
>> >>      >
>> >>
>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>> >>      >
>> >>      >      at SslSocketClient.main(SslSocketClient.kt:47)}
>> >>      >
>> >>      >
>> >>      > )
>> >>      >
>> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
>> >>      > AEDT|SSLSocketImpl.java:1361|close the underlying socket
>> >>      >
>> >>      > javax.net.ssl|DEBUG|01|main|2019-01-08 13:40:14.457
>> >>      > AEDT|SSLSocketImpl.java:1380|close the SSL connection
>> >> (initiative)
>> >>      >
>> >>      > Exception in thread "main" javax.net.ssl.SSLHandshakeException:
>> >>     Received
>> >>      > fatal alert: handshake_failure
>> >>      >
>> >>      >    at
>> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:128)
>> >>      >
>> >>      >    at
>> >> java.base/sun.security.ssl.Alert.createSSLException(Alert.java:117)
>> >>      >
>> >>      >    at
>> >>      >
>> >>
>> java.base/sun.security.ssl.TransportContext.fatal(TransportContext.java:308)
>> >>      >
>> >>      >    at
>> >> java.base/sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:279)
>> >>      >
>> >>      >    at
>> >>      >
>> >>
>> java.base/sun.security.ssl.TransportContext.dispatch(TransportContext.java:181)
>> >>      >
>> >>      >    at
>> >> java.base/sun.security.ssl.SSLTransport.decode(SSLTransport.java:164)
>> >>      >
>> >>      >    at
>> >>      >
>> >>
>> java.base/sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1152)
>> >>      >
>> >>      >    at
>> >>      >
>> >>
>> java.base/sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1063)
>> >>      >
>> >>      >    at
>> >>      >
>> >>
>> java.base/sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:402)
>> >>      >
>> >>      >    at SslSocketClient.main(SslSocketClient.kt:47)
>> >>      >
>> >>      >
>> >>      >
>> >>      >
>> >>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190214/4eae79d7/attachment-0001.html>

From lance.andersen at oracle.com  Wed Feb 13 22:53:15 2019
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 13 Feb 2019 17:53:15 -0500
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <818ca9a7fe2445638dddc2481f95f9f8@sap.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <CA+3eh102cMGphPPbABv2ef_M5Py5+Mg-FRU94HcpKUH3gaV6+w@mail.gmail.com>
 <fd756aff51134b15a40fe55247d4a87e@sap.com>
 <CA+3eh13dP-tCdq4H4z3KWJZQzfMJYqDNkx9fMh3tNfL08RCtDg@mail.gmail.com>
 <7b513a34196141f595cd5d194fb9d8a2@sap.com>
 <fa4078d9-7aec-f122-e9ca-7b816e115c9b@oracle.com>
 <CA+3eh10kDtTEpcRsUWhQEkEyRyTdbvxxmZ8U-G97OeUG2kkU3A@mail.gmail.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <F146FB1D-726B-416F-97FA-7ED3CD9FCF44@oracle.com>
 <818ca9a7fe2445638dddc2481f95f9f8@sap.com>
Message-ID: <3854DFE0-C244-4920-9554-65F6401438BF@oracle.com>

Hi Christoph
> On Feb 13, 2019, at 5:30 PM, Langer, Christoph <christoph.langer at sap.com> wrote:
> 
> Hi Lance,
> 
> thanks for looking.
> 
>> Just starting to take a peek at this and noticed one quick thing in your test:
>> ------------
>> Paths.get(System.getProperty("test.dir", "."), "testPosix.zip")
>> ??????
>> 
>> You do not need the test.dir property  or the permission added to test.policy
>> to access it,  just reference the jar and it will be created in user.dir which is
>> also writable.
> 
> Hm, I thought I didn't want to mess around in "user.dir" as it can be some more global directory where you wouldn't want to leave artefacts... To me "test.dir" feels cleaner. Are there other opinions about that?

user.dir points to the scratch directory that test uses, so it is where you want to create the tests.  Workspaces can sometimes be read only:

For example:
??????
    @Test
    public void test000() throws IOException {
        System.out.println("test.dir = " +
                System.getProperty("test.dir", "."));
        System.out.println("user.dir = " +
                System.getProperty("user.dir", "."));
        System.out.println(
                Paths.get(System.getProperty("test.dir", "."), "basic.jar").toAbsolutePath()
        );
    }

-----------------

Results in:
--------------------
test.dir = .
user.dir = /Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch
/Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch/./basic.jar

Please see http://openjdk.java.net/jtreg/tag-spec.html for the system properties.  I do not see test.dir there.
?????????

I would just do:

?????????
Path foo = Path.of("test.zip");
System.out.println("test.zip path=" + foo.toAbsolutePath());

--------------------------

which results in the output: 
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>test.zip path=/Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch/test.zip

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190213/1bc8e9e4/attachment.html>

From yozons at gmail.com  Wed Feb 13 23:06:04 2019
From: yozons at gmail.com (Open eSignForms)
Date: Wed, 13 Feb 2019 15:06:04 -0800
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <32d2fff5-1be5-1201-225e-15ac60982067@gmail.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
 <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
 <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
 <32d2fff5-1be5-1201-225e-15ac60982067@gmail.com>
Message-ID: <648d666c-60a4-bc09-ecd9-f993255040e2@gmail.com>

Well, I have found that my verify routines are failing.? I added the 
following lines to the main() test method of your fixed code after the 
signature is done to attempt to validate the generated signed XML:

 ??? ??? ??? try {
 ??? ??? ??? ??? System.err.println("Verifying signedXml...");
 ??? ??? ??? ??? xmldsig.verify(signedXml, signatureKey);
 ??? ??? ??? ??? System.err.println("Verified signedXml...");
 ??? ??? ??? } catch(Exception ve) {
System.err.println("XmlDigitalSignature.main() signature verification 
exception: " + ve.getMessage());
 ??? ??? ??? }

This basically submits the created 'signedXml' returned just above with 
the same keys.? I also had to update the method "verify(String 
signedXml, SignatureKey signatureKey)" where it sets the ID attribute to 
include the namespace added in the fixed code:

 ??? ??? ??? 
qualifyingPropertiesElement.setIdAttribute*NS("http://uri.etsi.org/01903/v1.1.1#"*,"Id", 
true); // mark our id as the "Id" attribute

This then fails showing 2 out of 4 references validated, the others failing:

XmlDigitalSignature.verify(SignatureKey) SERIOUS-ERROR Failed core 
validation; SignatureValue validated: true
 ?-> Reference[0] validated: true
 ?-> Reference[1] validated: true
 ?-> Reference[2] validated: false
 ?-> Reference[3] validated: false
XmlDigitalSignature.verify(SignatureKey) SERIOUS-ERROR exception: 
Invalid signature. SignatureValue validated; XML data payload validated; 
OpenESignForms Seal validated; Unexpected Reference[2] INVALID; 
Unexpected Reference[3] INVALID

In my test code I was able to show the references subscripts 0-3 being:

 ?-> Reference[0] before validate(): *r.getId(): Payload_Reference_ID*; 
r.getURI():
 ?-> Reference[0] validated: true

 ?-> Reference[1] before validate(): r.getId(): null; *r.getURI(): 
#KeyInfo_ID*
 ?-> Reference[1] validated: true

 ?-> Reference[2] before validate(): r.getId(): null; *r.getURI(): 
#QualifyingProperties_ID*
 ?-> Reference[2] validated: false

 ?-> Reference[3] before validate(): r.getId(): null; *r.getURI(): 
#OpenESignForms_Seal_ID*
 ?-> Reference[3] validated: false

So, the namespace changes made allow the digital signature to be 
applied, but now I'm stuck on how to verify these last two references.? 
It seems that references related to Payload_Reference_ID and #KeyInfo_ID 
validate, but #QualifyingProperties_ID and #OpenESignForms_Seal_ID are 
failing.

I'm not sure how those references work with respect to the namespace 
changes you suggested.

In fact, the fixed code no longer validates the digital signature under 
Java 8 once the namespaces were added.? Any ideas?

Thanks, David


On 2/13/19 1:23 PM, Open eSignForms wrote:
>
> I checked the ETSI XAdES spec 
> (http://uri.etsi.org/01903/v1.1.1/ts_101903v010101p.pdf) and it 
> doesn't show any namespace on their entries for their 
> QualifyingProperties element and all sub-elements under the ETSI 
> example's element <ds:Object>.
>
> But, their specification does show element <QualifyingProperties> 
> should be under the namespace "http://uri.etsi.org/01903/v1.1.1#" as 
> you added in your fixed code.
>
> That is, when my snapshot element that's digitally signed using the 
> below, it fails with the NAMESPACE_ERR exception:
>
> <snapshot *xmlns="http://open.esignforms.com/XMLSchema/2011"* 
> timestamp="2019-02-13T11:02:30-08:00" type="document">
>
> But if my snapshot is set up with the ETSI namespace URI, it works:
>
> <snapshot *xmlns="**http://uri.etsi.org/01903/v1.1.1#**" * 
> timestamp="2019-02-13T11:02:30-08:00" type="document">
>
> So, it seems that the XMLSignature is noting that the 
> <QualifyingProperties> belongs to the default namespace in both cases, 
> but of course expects that particular element to belong to the ETSI 
> namespace, not ours.
>
> I presume that's correct behavior; I just didn't think that the 
> XMLSignature.sign() knew about and was limited to that specific namespace.
>
> If you agree that this is the correct behavior, I think it's not 
> really a bug in Java 11, though it fails backwards compatibility.
>
> The only oddity that remains is what I mentioned below with all the 
> "&#13;" characters in the digests/signatures that appear in Java 11.? 
> They sure look odd compared to simple line breaks that presumably were 
> emitted before.
>
> David
>
>
>
> On 2/13/19 11:20 AM, Open eSignForms wrote:
>> Thanks, Sean.? I was able to find the updated test case source code.
>>
>> A preliminary review seems to show worthwhile changes to our code.? 
>> That is, the namespaces and such seem to make sense as you have them.
>>
>> In particular, the use of:
>>
>> domSignContext.putNamespacePrefix(XMLSignature.XMLNS, "dsig");
>>
>> and adding this namespace to additional elements we added:
>>
>> ??? ??? ??? String xmlns = "http://uri.etsi.org/01903/v1.1.1#";
>>
>> seem reasonable and an acceptable workaround for us.? I'm not sure if 
>> those were oversights from before, but likely were the result of it 
>> being based on Oracle/Java example code from Java 6 days...
>>
>> We'll incorporate your namespace changes in our code and test, but 
>> this seems like it will work as I was able to confirm that your fixed 
>> version seems to run on Java 10 and Java 11.
>>
>> It is interesting that the fixed code, though, generates different 
>> output on Java 10 and Java 11.? I'm not positive, but it seems that 
>> Java 11 adds '&#13;' to the end of many lines that aren't present in 
>> Java 10's output.
>>
>> Under Java 10, a test run products this result:
>>
>> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
>> timestamp="2019-02-13T11:02:30-08:00" type="document"><![CDATA[<html 
>> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
>> document</p></body></html>]]><dsig:Signature 
>> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
>> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod 
>> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
>> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Zqmii2rv6C+bFM+CSO3s8sAGOrl67HEnv4t8XUgQd5iguf9m7vcVJn3pJz5inCZfx5V9lTtDaj0u 
>>
>> xbZSyWE5kQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>> URI="#KeyInfo_ID"><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>kZM1pJpRXoeDuolU+kyK41BotQoW7ir5lfg/nNSMoC69bUC2OHzWbQ5Kug0gtrLVIuq5HRdzk6zc
>> 2N2jA0WKMQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>> URI="#QualifyingProperties_ID"><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>AFx1CJi739IWZwJL1Y5KU2B+ZioT3ONMBLwLTdT/NTysV/+KYF7lZMgEHaGtLxvc6haIKKKzZisr
>> r2YDQVgs5w==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>jhVDd7nvr4s2bu7LRNHb7yj2gQRzAE7fXcsgonq2Qsn4EWNfpqNEVUViIy9jh86tTs5ZiakaGAEs
>> l9YV1hNnEg==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>izJCFA5lBOjc7zhlc/1Wrsu+/jd0o0aPtemm4hM7aMKJvzkKddhjaHRY9iX4qtMZJtl7L1qj4YGN 
>>
>> hxHc2Wjuj6F1ZFD9asPf/kumVliAqTwNvhfyVfmpbaZtzQVtOQWhNIC1PivbPfbwTKr1yztLbo0K 
>>
>> B8TJWWiqHBjgEjlhw8X84buXVsCIUaAkOJG73Q0x9hMDVPf5y5R56xknLwjwzQPdveMI3zKvKvq5 
>>
>> vj1UPKVqlCjrjPa1HR0g4wEOjL51HCK/EWVbB4LLRAL59KB6ERW01CaRX1crGzQw6wz5eFVWK/0o 
>>
>> NcIdn4wc7rWPdYfT362iqqJMzIyUQGHmk7FVD/1Nky2wlEvYaRk7PrpbXo8ISSPB+RQM+EWQbYCP 
>>
>> RVT5oq6d4dnu0cUuj/wG8Ng7FIfSY3C8Ds9cw7CTKi/Dbmw3oE8yaJHNqfjEMAW2tmqQmuC4ZRXG 
>>
>> 7DfqeNdgiHwoQLdLzD/vj/00SWmcM67NWQNwblbPJ5MhVeFmh/fIbd7bkIyANbw1FAYIj1b+Hf8b 
>>
>> cZzC+lNecKxzkcY9/VZ3ny4kBBQmxwBLlojBa2ll8B9m+sYN0enRGwy9GG2eBY2Gb53KqAALQAUU 
>>
>> kjXjJYxrQh64Y2RTAgp01Nbfj7QbvuKW93YDR6cpjNTM7EfJfQM/cz+VHHngFCRr/N0/WmM4j0A=</dsig:SignatureValue><dsig:KeyInfo 
>> Id="KeyInfo_ID"><dsig:KeyName>c42c747f-0f03-46a3-8ae8-81fc95464c8f</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9 
>>
>> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW 
>>
>> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU 
>>
>> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX 
>>
>> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ 
>>
>> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB 
>>
>> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z 
>>
>> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n 
>>
>> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu 
>>
>> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z 
>>
>> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2 
>>
>> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh 
>>
>> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz 
>>
>> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh 
>>
>> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw 
>>
>> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ 
>>
>> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi 
>>
>> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A 
>>
>> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6 
>>
>> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/ 
>>
>> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn 
>>
>> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy 
>>
>> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW 
>>
>> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR 
>>
>> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz 
>>
>> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj 
>>
>> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC 
>>
>> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc 
>>
>> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI 
>>
>> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl 
>>
>> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o 
>>
>> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY 
>>
>> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N 
>>
>> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E 
>>
>> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg 
>>
>> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV 
>>
>> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC 
>>
>> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q 
>>
>> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX 
>>
>> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D 
>>
>> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+ 
>>
>> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx 
>>
>> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P 
>>
>> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf 
>>
>> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z 
>>
>> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0 
>>
>> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN 
>>
>> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk 
>>
>> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw 
>>
>> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz 
>>
>> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO 
>>
>> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK 
>>
>> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u 
>>
>> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/ 
>>
>> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX 
>>
>> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy 
>>
>> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
>> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
>> ns0:Id="QualifyingProperties_ID" 
>> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:02:30-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
>> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
>> Id="OpenESignForms_Seal_ID" 
>> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
>> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
>> ns0:DeploymentHostAddress="192.1.1.1" 
>> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
>> ns1:DeploymentHostName="open.esignforms.com" 
>> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
>> ns2:DeploymentId="1.1.1.1" 
>> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
>> ns3:SignerAddress="192.1.1.1" 
>> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
>> ns4:SignerAgent="No-Browser-Test" 
>> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
>> ns5:Timestamp="2019-02-13T11:02:30-08:00" 
>> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
>> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot>
>>
>> while when run under Java 11 it shows what seems to be the same 
>> (clearly, the digest/hashes aren't the same as the 'timestamp' 
>> differs because they are actual times) except for lots of '&#13;' 
>> added to the digests and signatures:
>>
>> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
>> timestamp="2019-02-13T11:01:22-08:00" type="document"><![CDATA[<html 
>> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
>> document</p></body></html>]]><dsig:Signature 
>> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
>> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod 
>> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
>> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LdB/ydGxr3VUoTshQtOvQNmMZmt2OHgLax4tSk9Lqb1c+X1h4Uc/RBVXwfI9QrVnITBz85Fi8Bwr&#13; 
>>
>> 7wyMjw84cA==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>> URI="#KeyInfo_ID"><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>FkpexxTwhpCPHHsMrKGnBXE5hkZ/x10ArpzjX6ltYfOilvVAubzc9sNPwo6phw//ot1rSKPU5jTB&#13;
>> LRD7p7t50g==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>> URI="#QualifyingProperties_ID"><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LxB0xAsDxKqeyCflaSUgMQOMhoxP4Gl9GfvlpCiL/gd9rz36qG4roaFRl+4PBC+IxzGiRDOqzQYX&#13;
>> x6gSn5d1IQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Pqd+9yaeBMytcG1sTTpuq+Wrd3lZSC18j7lv6VQ6LjUSz9VN7uwVNNn1E79mY8H6XUI2jbd/IozM&#13;
>> oba2KF46ig==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>IpdHZtzSw8TOnp0gfKMaCp30jJAPP8YCAIg4OBvRobIwHBFrG+O9v7peXRRA5nXi+fm4bdemi5jI&#13; 
>>
>> /N2smS7W6lKMMeTzrYNJEmpD/0c/SVCs0M1peZmiWZD/F6GYP6RkhZfTglk9skKsZIme3W5lHL5e&#13; 
>>
>> vTFno50J32oW0chq/jPzD42snoVQmVKS9wqqybGgRrm1W2RSWfziNo7QjXtJuR5eVuCtqpOLrGrS&#13; 
>>
>> J0aLaaNLucia/6cJyZ13mz7131Lj2Y4oJbrbpzvrDY5xDfFDK+bRRMR3DCvTLgKcZZz5zxcAKYL8&#13; 
>>
>> lG64U/tsmd/ZVn+d+fJGH03hPdvY/wMW7MTN1k/6S95PiNdx0cLeP0HLCug9zWiC7vUkrVDrsO9i&#13; 
>>
>> qsvSYKcAH8vQlG1arZgGJn88Hg8EGjmmWXs15ulU3Lm8TOTXl/xi6O4stSgMi9dFSsE1ISHAPaxN&#13; 
>>
>> D3Rqg7Bv7p/iEVn0xXq/C9AI3iwrpHbip8K81uJOsaiZgwR5D40XyYLV9FUPIacRclfT5EJKsx6k&#13; 
>>
>> jYiprWMOMjmnlJwj2vI8zG6sYLVJdQywm2isWu5eHSw39Wof0BYfDeOzh0LrifUcnt86no5fUEOI&#13; 
>>
>> OlNbqOO7rjuxtb+gt1iO2dTHfQhG99BCBQhC7AEMp67fIlPjEOECXldDTpzPMZ1K6cPlk22rpvc=</dsig:SignatureValue><dsig:KeyInfo 
>> Id="KeyInfo_ID"><dsig:KeyName>184a40b0-78b6-4070-a7d7-1497078a06e4</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9&#13; 
>>
>> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW&#13; 
>>
>> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU&#13; 
>>
>> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX&#13; 
>>
>> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ&#13; 
>>
>> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB&#13; 
>>
>> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z&#13; 
>>
>> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n&#13; 
>>
>> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu&#13; 
>>
>> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z&#13; 
>>
>> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2&#13; 
>>
>> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh&#13; 
>>
>> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz&#13; 
>>
>> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh&#13; 
>>
>> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw&#13; 
>>
>> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ&#13; 
>>
>> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi&#13; 
>>
>> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A&#13; 
>>
>> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6&#13; 
>>
>> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/&#13; 
>>
>> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn&#13; 
>>
>> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy&#13; 
>>
>> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW&#13; 
>>
>> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR&#13; 
>>
>> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz&#13; 
>>
>> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj&#13; 
>>
>> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC&#13; 
>>
>> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc&#13; 
>>
>> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI&#13; 
>>
>> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl&#13; 
>>
>> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o&#13; 
>>
>> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY&#13; 
>>
>> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N&#13; 
>>
>> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E&#13; 
>>
>> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg&#13; 
>>
>> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV&#13; 
>>
>> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC&#13; 
>>
>> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q&#13; 
>>
>> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX&#13; 
>>
>> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D&#13; 
>>
>> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+&#13; 
>>
>> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx&#13; 
>>
>> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P&#13; 
>>
>> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf&#13; 
>>
>> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z&#13; 
>>
>> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0&#13; 
>>
>> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN&#13; 
>>
>> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk&#13; 
>>
>> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw&#13; 
>>
>> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz&#13; 
>>
>> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO&#13; 
>>
>> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK&#13; 
>>
>> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u&#13; 
>>
>> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/&#13; 
>>
>> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX&#13; 
>>
>> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy&#13; 
>>
>> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
>> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
>> ns0:Id="QualifyingProperties_ID" 
>> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:01:22-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
>> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
>> Id="OpenESignForms_Seal_ID" 
>> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
>> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
>> ns0:DeploymentHostAddress="192.1.1.1" 
>> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
>> ns1:DeploymentHostName="open.esignforms.com" 
>> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
>> ns2:DeploymentId="1.1.1.1" 
>> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
>> ns3:SignerAddress="192.1.1.1" 
>> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
>> ns4:SignerAgent="No-Browser-Test" 
>> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
>> ns5:Timestamp="2019-02-13T11:01:22-08:00" 
>> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
>> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot>
>>
>>
>> It's particularly odd because hex 13 isn't a typical character (^S).
>>
>> Any idea what that difference is about for the base64 digests and 
>> signatures?
>>
>> David
>>
>>
>> On 2/13/19 6:03 AM, Sean Mullan wrote:
>>> On 2/12/19 6:28 PM, Open eSignForms wrote:
>>>> Thanks for the update, Sean.? I'm a bit perplexed because I found 
>>>> the original code works under Java 9 and Java 10, so it seems like 
>>>> the change occurred in Java 11.
>>>
>>> Sorry, that was a typo, I meant to say JDK 11.
>>>
>>>> I don't see the modified version of the test case.? If you attached 
>>>> it, it somehow didn't make it through to me.
>>>>
>>>> If it's just a matter of making the code more correct, we'd love to 
>>>> make the changes.? My concern, of course, is that we've already 
>>>> done millions of XML digital signatures, so we need that to 
>>>> continue to verify correctly (and even under Java 11, it seems that 
>>>> the verify code works against previously digitally signed content) 
>>>> even if we now start digitally signing using more update-to-date code.
>>>
>>> The verification of pre-existing signatures should continue to work 
>>> regardless of how this bug is addressed.
>>>
>>>> Please send over the modified test case and I'll take a look.
>>>
>>> It is attached to the bug report in the Attachments section: 
>>> https://bugs.openjdk.java.net/browse/JDK-8218629 (make sure you 
>>> download the one I added yesterday).
>>>
>>> --Sean
>>>
>>>>
>>>> Thanks!
>>>> David
>>>>
>>>> On 2/12/19 2:14 PM, Sean Mullan wrote:
>>>>> The bug is now at https://bugs.openjdk.java.net/browse/JDK-8218629
>>>>>
>>>>> I have started looking at this issue and have some progress I can 
>>>>> report.
>>>>>
>>>>> In JDK 9, we updated the version of the Apache XML Signature 
>>>>> implementation in the JDK. Some of the marshalling code was 
>>>>> rewritten such that it will throw Exceptions if legacy DOM level 1 
>>>>> methods were used to create XML content which is then passed into 
>>>>> XMLObject and similar XMLSignature types that take DOMStructure 
>>>>> objects. This is because the DOM level 1 methods do not support 
>>>>> namespaces.
>>>>>
>>>>> I am still evaluating what the best fix is. However, you can 
>>>>> workaround the issue by always using DOM level 3 methods which are 
>>>>> namespace aware. For example, use Document.createElementNS instead 
>>>>> of Document.createElement and Element.createAttributeNS instead of 
>>>>> Element.createAttribute.
>>>>>
>>>>> Using legacy or non-namespace aware XML parsers or implementations 
>>>>> is not recommended and the XML Signature Best Practices document 
>>>>> gives some rationale: 
>>>>> https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces 
>>>>>
>>>>> That said, this is a regression in behavior so it would be best if 
>>>>> we could restore the previous behavior.
>>>>>
>>>>> I have attached a modified version of the test case to the bug 
>>>>> report which no longer throws an Exception. Let me know if this is 
>>>>> an acceptable workaround. Double-check the namespaces that I used 
>>>>> to make sure they are correct.
>>>>>
>>>>> --Sean
>>>>>
>>>>>
>>>>> On 2/7/19 11:23 AM, Open eSignForms wrote:
>>>>>
>>>>>> On 2/7/19 7:49 AM, Sean Mullan wrote:
>>>>>>> On 2/6/19 4:51 PM, Open eSignForms wrote:
>>>>>>>> I have a test version of the code that can run standalone and 
>>>>>>>> shows the bug.? I'm not sure how best to transfer this 
>>>>>>>> information to the forum for those to play with, but it is 
>>>>>>>> included below.
>>>>>>>
>>>>>>> Thanks, I can reproduce the issue now. I will need to debug 
>>>>>>> further to see what might be causing this.
>>>>>>>
>>>>>>> --Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190213/e4f835ed/attachment-0001.html>

From amir.khassaia at gmail.com  Wed Feb 13 23:58:09 2019
From: amir.khassaia at gmail.com (Amir Khassaia)
Date: Thu, 14 Feb 2019 10:58:09 +1100
Subject: javax.net.debug output lost client hello extensions in JDK 11.0.2
Message-ID: <CAJ3+AwfCXfrZ12piB7zBjQHP9i5VpbEnK8UTP3vfrLGjQ9W22Q@mail.gmail.com>

Hi, I'd like to report a bug that may confuse others as they diagnose TLS
handshakes.

The extension logging seems to be affected in JDK 11.0.2, these come up as
empty in client hello (see below) from Oracle JDK 11.0.2
==========================
javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:48.620
AEDT|SSLCipher.java:437|jdk.tls.keyLimits:  entry = AES/GCM/NoPadding
KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
javax.net.ssl|WARNING|01|main|2019-02-14 10:51:50.357
AEDT|ServerNameExtension.java:255|Unable to indicate server name
javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.357
AEDT|SSLExtensions.java:256|Ignore, context unavailable extension:
server_name
javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.358
AEDT|SSLExtensions.java:256|Ignore, context unavailable extension:
status_request
javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.361
AEDT|SupportedGroupsExtension.java:841|Ignore inactive or disabled named
group: secp160k1
javax.net.ssl|WARNING|01|main|2019-02-14 10:51:50.486
AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not
supported by the underlying providers
javax.net.ssl|WARNING|01|main|2019-02-14 10:51:50.486
AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported
by the underlying providers
javax.net.ssl|INFO|01|main|2019-02-14 10:51:50.513
AEDT|AlpnExtension.java:161|No available application protocols
javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.514
AEDT|SSLExtensions.java:256|Ignore, context unavailable extension:
application_layer_protocol_negotiation
javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.514
AEDT|SSLExtensions.java:256|Ignore, context unavailable extension:
status_request_v2
javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.516
AEDT|ClientHello.java:651|Produced ClientHello handshake message (
"ClientHello": {
  "client version"      : "TLSv1.2",
  "random"              : "3E 3B 04 98 F4 65 C7 CF 2B B2 30 EA AE CE 7D C5
51 45 C4 A9 CB D6 F2 39 3F 52 46 77 BE 28 EC 06",
  "session id"          : "",
  "cipher suites"       :
"[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B),
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F),
TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C),
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D),
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031),
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E),
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2),
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025),
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067),
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040),
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009),
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013),
TLS_RSA_WITH_AES_128_CBC_SHA(0x002F),
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004),
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E),
TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033),
TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032)]",
  "compression methods" : "00",
  "extensions"          : [

  ]
}
)

Notice empty extensions, these are actually there on the wire (checked with
wireshark).

This previously appeared to work, just checked with OpenJDK 11.0.1 and I
get them:

javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:54.261
AEDT|SSLCipher.java:437|jdk.tls.keyLimits:  entry = AES/GCM/NoPadding
KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
javax.net.ssl|WARNING|01|main|2019-02-14 10:54:56.491
AEDT|ServerNameExtension.java:255|Unable to indicate server name
javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.492
AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
server_name
javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.492
AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
status_request
javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.494
AEDT|SupportedGroupsExtension.java:841|Ignore inactive or disabled named
group: secp160k1
javax.net.ssl|WARNING|01|main|2019-02-14 10:54:56.546
AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not
supported by the underlying providers
javax.net.ssl|WARNING|01|main|2019-02-14 10:54:56.546
AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not supported
by the underlying providers
javax.net.ssl|INFO|01|main|2019-02-14 10:54:56.575
AEDT|AlpnExtension.java:161|No available application protocols
javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.576
AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
application_layer_protocol_negotiation
javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.576
AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
status_request_v2
javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.577
AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
renegotiation_info
javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.582
AEDT|ClientHello.java:651|Produced ClientHello handshake message (
"ClientHello": {
  "client version"      : "TLSv1.2",
  "random"              : "4E 23 00 5E 22 D3 0D 78 D0 97 B5 E1 16 FB E3 92
B5 90 B0 8E 30 89 BC 72 BA F1 B7 94 71 E7 E8 80",
  "session id"          : "",
  "cipher suites"       :
"[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B),
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F),
TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C),
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D),
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031),
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E),
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2),
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025),
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067),
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040),
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009),
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013),
TLS_RSA_WITH_AES_128_CBC_SHA(0x002F),
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004),
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E),
TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033),
TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032),
TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
  "compression methods" : "00",
  "extensions"          : [
    "supported_groups (10)": {
      "versions": [secp256r1, secp384r1, secp521r1]
    },
    "ec_point_formats (11)": {
      "formats": [uncompressed]
    },
    "signature_algorithms (13)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
ecdsa_secp512r1_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
    },
    "signature_algorithms_cert (50)": {
      "signature schemes": [ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
ecdsa_secp512r1_sha512, rsa_pkcs1_sha256, rsa_pkcs1_sha384,
rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, rsa_pkcs1_sha1, dsa_sha1]
    },
    "extended_master_secret (23)": {
      <empty>
    },
    "supported_versions (43)": {
      "versions": [TLSv1.2, TLSv1.1, TLSv1]
    }
  ]
}
)

Regards,
Amir
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190214/1d6ef80f/attachment.html>

From xuelei.fan at oracle.com  Thu Feb 14 03:25:59 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 13 Feb 2019 19:25:59 -0800
Subject: javax.net.debug output lost client hello extensions in JDK 11.0.2
In-Reply-To: <CAJ3+AwfCXfrZ12piB7zBjQHP9i5VpbEnK8UTP3vfrLGjQ9W22Q@mail.gmail.com>
References: <CAJ3+AwfCXfrZ12piB7zBjQHP9i5VpbEnK8UTP3vfrLGjQ9W22Q@mail.gmail.com>
Message-ID: <50a86743-cfba-ddaa-7773-f9cc1cbd3b4f@oracle.com>

This bug will be addressed in JDK 11.0.3 and 12.  See also:
    https://bugs.openjdk.java.net/browse/JDK-8210974

Thanks,
Xuelei

On 2/13/2019 3:58 PM, Amir Khassaia wrote:
> 
> Hi, I'd like to report a bug that may confuse others as they diagnose 
> TLS handshakes.
> 
> The extension logging seems to be affected in JDK 11.0.2, these come up 
> as empty in client hello (see below) from Oracle JDK 11.0.2
> ==========================
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:48.620 
> AEDT|SSLCipher.java:437|jdk.tls.keyLimits:? entry = AES/GCM/NoPadding 
> KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
> javax.net.ssl|WARNING|01|main|2019-02-14 10:51:50.357 
> AEDT|ServerNameExtension.java:255|Unable to indicate server name
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.357 
> AEDT|SSLExtensions.java:256|Ignore, context unavailable extension: 
> server_name
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.358 
> AEDT|SSLExtensions.java:256|Ignore, context unavailable extension: 
> status_request
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.361 
> AEDT|SupportedGroupsExtension.java:841|Ignore inactive or disabled named 
> group: secp160k1
> javax.net.ssl|WARNING|01|main|2019-02-14 10:51:50.486 
> AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not 
> supported by the underlying providers
> javax.net.ssl|WARNING|01|main|2019-02-14 10:51:50.486 
> AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not 
> supported by the underlying providers
> javax.net.ssl|INFO|01|main|2019-02-14 10:51:50.513 
> AEDT|AlpnExtension.java:161|No available application protocols
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.514 
> AEDT|SSLExtensions.java:256|Ignore, context unavailable extension: 
> application_layer_protocol_negotiation
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.514 
> AEDT|SSLExtensions.java:256|Ignore, context unavailable extension: 
> status_request_v2
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.516 
> AEDT|ClientHello.java:651|Produced ClientHello handshake message (
> "ClientHello": {
>  ? "client version"? ? ? : "TLSv1.2",
>  ? "random"? ? ? ? ? ? ? : "3E 3B 04 98 F4 65 C7 CF 2B B2 30 EA AE CE 7D 
> C5 51 45 C4 A9 CB D6 F2 39 3F 52 46 77 BE 28 EC 06",
>  ? "session id"? ? ? ? ? : "",
>  ? "cipher suites"? ? ? ?: 
> "[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), 
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), 
> TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), 
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), 
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), 
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), 
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), 
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), 
> TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), 
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), 
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), 
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), 
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), 
> TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), 
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), 
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), 
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032)]",
>  ? "compression methods" : "00",
>  ? "extensions"? ? ? ? ? : [
>  ? ]
> }
> )
> 
> Notice empty extensions, these are actually there on the wire (checked 
> with wireshark).
> 
> This previously appeared to work, just checked with OpenJDK 11.0.1 and I 
> get them:
> 
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:54.261 
> AEDT|SSLCipher.java:437|jdk.tls.keyLimits:? entry = AES/GCM/NoPadding 
> KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
> javax.net.ssl|WARNING|01|main|2019-02-14 10:54:56.491 
> AEDT|ServerNameExtension.java:255|Unable to indicate server name
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.492 
> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: 
> server_name
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.492 
> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: 
> status_request
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.494 
> AEDT|SupportedGroupsExtension.java:841|Ignore inactive or disabled named 
> group: secp160k1
> javax.net.ssl|WARNING|01|main|2019-02-14 10:54:56.546 
> AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not 
> supported by the underlying providers
> javax.net.ssl|WARNING|01|main|2019-02-14 10:54:56.546 
> AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not 
> supported by the underlying providers
> javax.net.ssl|INFO|01|main|2019-02-14 10:54:56.575 
> AEDT|AlpnExtension.java:161|No available application protocols
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.576 
> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: 
> application_layer_protocol_negotiation
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.576 
> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: 
> status_request_v2
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.577 
> AEDT|SSLExtensions.java:235|Ignore, context unavailable extension: 
> renegotiation_info
> javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.582 
> AEDT|ClientHello.java:651|Produced ClientHello handshake message (
> "ClientHello": {
>  ? "client version"? ? ? : "TLSv1.2",
>  ? "random"? ? ? ? ? ? ? : "4E 23 00 5E 22 D3 0D 78 D0 97 B5 E1 16 FB E3 
> 92 B5 90 B0 8E 30 89 BC 72 BA F1 B7 94 71 E7 E8 80",
>  ? "session id"? ? ? ? ? : "",
>  ? "cipher suites"? ? ? ?: 
> "[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B), 
> TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F), 
> TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C), 
> TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D), 
> TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031), 
> TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E), 
> TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2), 
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023), 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027), 
> TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C), 
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025), 
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029), 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067), 
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040), 
> TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009), 
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013), 
> TLS_RSA_WITH_AES_128_CBC_SHA(0x002F), 
> TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004), 
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E), 
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033), 
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032), 
> TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
>  ? "compression methods" : "00",
>  ? "extensions"? ? ? ? ? : [
>  ? ? "supported_groups (10)": {
>  ? ? ? "versions": [secp256r1, secp384r1, secp521r1]
>  ? ? },
>  ? ? "ec_point_formats (11)": {
>  ? ? ? "formats": [uncompressed]
>  ? ? },
>  ? ? "signature_algorithms (13)": {
>  ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, 
> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pkcs1_sha256, 
> rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, 
> rsa_pkcs1_sha1, dsa_sha1]
>  ? ? },
>  ? ? "signature_algorithms_cert (50)": {
>  ? ? ? "signature schemes": [ecdsa_secp256r1_sha256, 
> ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pkcs1_sha256, 
> rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1, 
> rsa_pkcs1_sha1, dsa_sha1]
>  ? ? },
>  ? ? "extended_master_secret (23)": {
>  ? ? ? <empty>
>  ? ? },
>  ? ? "supported_versions (43)": {
>  ? ? ? "versions": [TLSv1.2, TLSv1.1, TLSv1]
>  ? ? }
>  ? ]
> }
> )
> 
> Regards,
> Amir
> 
> 
> 

From amir.khassaia at gmail.com  Thu Feb 14 04:29:56 2019
From: amir.khassaia at gmail.com (Amir Khassaia)
Date: Thu, 14 Feb 2019 15:29:56 +1100
Subject: javax.net.debug output lost client hello extensions in JDK 11.0.2
In-Reply-To: <50a86743-cfba-ddaa-7773-f9cc1cbd3b4f@oracle.com>
References: <CAJ3+AwfCXfrZ12piB7zBjQHP9i5VpbEnK8UTP3vfrLGjQ9W22Q@mail.gmail.com>
 <50a86743-cfba-ddaa-7773-f9cc1cbd3b4f@oracle.com>
Message-ID: <CAJ3+Awe5K35j_aArMST3UShpcHRiNHxXA+12qMJXBt=zygSMaQ@mail.gmail.com>

Thanks Xuelei, I clearly missed the report somehow

On Thu, Feb 14, 2019 at 2:26 PM Xuelei Fan <xuelei.fan at oracle.com> wrote:

> This bug will be addressed in JDK 11.0.3 and 12.  See also:
>     https://bugs.openjdk.java.net/browse/JDK-8210974
>
> Thanks,
> Xuelei
>
> On 2/13/2019 3:58 PM, Amir Khassaia wrote:
> >
> > Hi, I'd like to report a bug that may confuse others as they diagnose
> > TLS handshakes.
> >
> > The extension logging seems to be affected in JDK 11.0.2, these come up
> > as empty in client hello (see below) from Oracle JDK 11.0.2
> > ==========================
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:48.620
> > AEDT|SSLCipher.java:437|jdk.tls.keyLimits:  entry = AES/GCM/NoPadding
> > KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
> > javax.net.ssl|WARNING|01|main|2019-02-14 10:51:50.357
> > AEDT|ServerNameExtension.java:255|Unable to indicate server name
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.357
> > AEDT|SSLExtensions.java:256|Ignore, context unavailable extension:
> > server_name
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.358
> > AEDT|SSLExtensions.java:256|Ignore, context unavailable extension:
> > status_request
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.361
> > AEDT|SupportedGroupsExtension.java:841|Ignore inactive or disabled named
> > group: secp160k1
> > javax.net.ssl|WARNING|01|main|2019-02-14 10:51:50.486
> > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not
> > supported by the underlying providers
> > javax.net.ssl|WARNING|01|main|2019-02-14 10:51:50.486
> > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not
> > supported by the underlying providers
> > javax.net.ssl|INFO|01|main|2019-02-14 10:51:50.513
> > AEDT|AlpnExtension.java:161|No available application protocols
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.514
> > AEDT|SSLExtensions.java:256|Ignore, context unavailable extension:
> > application_layer_protocol_negotiation
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.514
> > AEDT|SSLExtensions.java:256|Ignore, context unavailable extension:
> > status_request_v2
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:51:50.516
> > AEDT|ClientHello.java:651|Produced ClientHello handshake message (
> > "ClientHello": {
> >    "client version"      : "TLSv1.2",
> >    "random"              : "3E 3B 04 98 F4 65 C7 CF 2B B2 30 EA AE CE 7D
> > C5 51 45 C4 A9 CB D6 F2 39 3F 52 46 77 BE 28 EC 06",
> >    "session id"          : "",
> >    "cipher suites"       :
> > "[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B),
> > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F),
> > TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C),
> > TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D),
> > TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031),
> > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E),
> > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2),
> > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
> > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
> > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
> > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025),
> > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
> > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067),
> > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040),
> > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009),
> > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013),
> > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F),
> > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004),
> > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E),
> > TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033),
> > TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032)]",
> >    "compression methods" : "00",
> >    "extensions"          : [
> >    ]
> > }
> > )
> >
> > Notice empty extensions, these are actually there on the wire (checked
> > with wireshark).
> >
> > This previously appeared to work, just checked with OpenJDK 11.0.1 and I
> > get them:
> >
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:54.261
> > AEDT|SSLCipher.java:437|jdk.tls.keyLimits:  entry = AES/GCM/NoPadding
> > KeyUpdate 2^37. AES/GCM/NOPADDING:KEYUPDATE = 137438953472
> > javax.net.ssl|WARNING|01|main|2019-02-14 10:54:56.491
> > AEDT|ServerNameExtension.java:255|Unable to indicate server name
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.492
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> > server_name
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.492
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> > status_request
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.494
> > AEDT|SupportedGroupsExtension.java:841|Ignore inactive or disabled named
> > group: secp160k1
> > javax.net.ssl|WARNING|01|main|2019-02-14 10:54:56.546
> > AEDT|SignatureScheme.java:282|Signature algorithm, ed25519, is not
> > supported by the underlying providers
> > javax.net.ssl|WARNING|01|main|2019-02-14 10:54:56.546
> > AEDT|SignatureScheme.java:282|Signature algorithm, ed448, is not
> > supported by the underlying providers
> > javax.net.ssl|INFO|01|main|2019-02-14 10:54:56.575
> > AEDT|AlpnExtension.java:161|No available application protocols
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.576
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> > application_layer_protocol_negotiation
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.576
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> > status_request_v2
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.577
> > AEDT|SSLExtensions.java:235|Ignore, context unavailable extension:
> > renegotiation_info
> > javax.net.ssl|DEBUG|01|main|2019-02-14 10:54:56.582
> > AEDT|ClientHello.java:651|Produced ClientHello handshake message (
> > "ClientHello": {
> >    "client version"      : "TLSv1.2",
> >    "random"              : "4E 23 00 5E 22 D3 0D 78 D0 97 B5 E1 16 FB E3
> > 92 B5 90 B0 8E 30 89 BC 72 BA F1 B7 94 71 E7 E8 80",
> >    "session id"          : "",
> >    "cipher suites"       :
> > "[TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256(0xC02B),
> > TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256(0xC02F),
> > TLS_RSA_WITH_AES_128_GCM_SHA256(0x009C),
> > TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256(0xC02D),
> > TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256(0xC031),
> > TLS_DHE_RSA_WITH_AES_128_GCM_SHA256(0x009E),
> > TLS_DHE_DSS_WITH_AES_128_GCM_SHA256(0x00A2),
> > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256(0xC023),
> > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256(0xC027),
> > TLS_RSA_WITH_AES_128_CBC_SHA256(0x003C),
> > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256(0xC025),
> > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256(0xC029),
> > TLS_DHE_RSA_WITH_AES_128_CBC_SHA256(0x0067),
> > TLS_DHE_DSS_WITH_AES_128_CBC_SHA256(0x0040),
> > TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA(0xC009),
> > TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA(0xC013),
> > TLS_RSA_WITH_AES_128_CBC_SHA(0x002F),
> > TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA(0xC004),
> > TLS_ECDH_RSA_WITH_AES_128_CBC_SHA(0xC00E),
> > TLS_DHE_RSA_WITH_AES_128_CBC_SHA(0x0033),
> > TLS_DHE_DSS_WITH_AES_128_CBC_SHA(0x0032),
> > TLS_EMPTY_RENEGOTIATION_INFO_SCSV(0x00FF)]",
> >    "compression methods" : "00",
> >    "extensions"          : [
> >      "supported_groups (10)": {
> >        "versions": [secp256r1, secp384r1, secp521r1]
> >      },
> >      "ec_point_formats (11)": {
> >        "formats": [uncompressed]
> >      },
> >      "signature_algorithms (13)": {
> >        "signature schemes": [ecdsa_secp256r1_sha256,
> > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pkcs1_sha256,
> > rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1,
> > rsa_pkcs1_sha1, dsa_sha1]
> >      },
> >      "signature_algorithms_cert (50)": {
> >        "signature schemes": [ecdsa_secp256r1_sha256,
> > ecdsa_secp384r1_sha384, ecdsa_secp512r1_sha512, rsa_pkcs1_sha256,
> > rsa_pkcs1_sha384, rsa_pkcs1_sha512, dsa_sha256, ecdsa_sha1,
> > rsa_pkcs1_sha1, dsa_sha1]
> >      },
> >      "extended_master_secret (23)": {
> >        <empty>
> >      },
> >      "supported_versions (43)": {
> >        "versions": [TLSv1.2, TLSv1.1, TLSv1]
> >      }
> >    ]
> > }
> > )
> >
> > Regards,
> > Amir
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190214/d5390e32/attachment.html>

From christoph.langer at sap.com  Thu Feb 14 07:54:16 2019
From: christoph.langer at sap.com (Langer, Christoph)
Date: Thu, 14 Feb 2019 07:54:16 +0000
Subject: RFR 8213031: (zipfs) Add support for POSIX file permissions
In-Reply-To: <3854DFE0-C244-4920-9554-65F6401438BF@oracle.com>
References: <dc9419b66a4942038022f0f24a52c0af@sap.com>
 <CA+3eh102cMGphPPbABv2ef_M5Py5+Mg-FRU94HcpKUH3gaV6+w@mail.gmail.com>
 <fd756aff51134b15a40fe55247d4a87e@sap.com>
 <CA+3eh13dP-tCdq4H4z3KWJZQzfMJYqDNkx9fMh3tNfL08RCtDg@mail.gmail.com>
 <7b513a34196141f595cd5d194fb9d8a2@sap.com>
 <fa4078d9-7aec-f122-e9ca-7b816e115c9b@oracle.com>
 <CA+3eh10kDtTEpcRsUWhQEkEyRyTdbvxxmZ8U-G97OeUG2kkU3A@mail.gmail.com>
 <46af4f9d-60f9-c60d-e6f1-8fb97df3ba2e@oracle.com>
 <bcab3f64c89f479c983fd9197c673822@sap.com>
 <5d28b0715d2041ff892a3c44e024f120@sap.com>
 <8e9231ff-b7d5-bc2f-2643-713f3c670a1d@oracle.com>
 <af6b23e04a2548179460a006b34a3afc@sap.com>
 <3aeba9a64a434a968fc1d82a44077745@sap.com>
 <F146FB1D-726B-416F-97FA-7ED3CD9FCF44@oracle.com>
 <818ca9a7fe2445638dddc2481f95f9f8@sap.com>
 <3854DFE0-C244-4920-9554-65F6401438BF@oracle.com>
Message-ID: <fffd5a1521ef426c992dd3c8fa971185@sap.com>

Hi Lance,

thanks for the detailed explanation, sounds great. I?ll work that in in my next edition ??

Best regards
Christoph


From: Lance Andersen <lance.andersen at oracle.com>
Sent: Mittwoch, 13. Februar 2019 23:53
To: Langer, Christoph <christoph.langer at sap.com>
Cc: Alan Bateman <Alan.Bateman at oracle.com>; nio-dev <nio-dev at openjdk.java.net>; Java Core Libs <core-libs-dev at openjdk.java.net>; OpenJDK Dev list <security-dev at openjdk.java.net>; Volker Simonis <volker.simonis at gmail.com>
Subject: Re: RFR 8213031: (zipfs) Add support for POSIX file permissions

Hi Christoph
On Feb 13, 2019, at 5:30 PM, Langer, Christoph <christoph.langer at sap.com<mailto:christoph.langer at sap.com>> wrote:

Hi Lance,

thanks for looking.


Just starting to take a peek at this and noticed one quick thing in your test:
------------
Paths.get(System.getProperty("test.dir", "."), "testPosix.zip")
??????

You do not need the test.dir property  or the permission added to test.policy
to access it,  just reference the jar and it will be created in user.dir which is
also writable.

Hm, I thought I didn't want to mess around in "user.dir" as it can be some more global directory where you wouldn't want to leave artefacts... To me "test.dir" feels cleaner. Are there other opinions about that?

user.dir points to the scratch directory that test uses, so it is where you want to create the tests.  Workspaces can sometimes be read only:

For example:
??????

    @Test
    public void test000() throws IOException {
        System.out.println("test.dir = " +
                System.getProperty("test.dir", "."));
        System.out.println("user.dir = " +
                System.getProperty("user.dir", "."));
        System.out.println(
                Paths.get(System.getProperty("test.dir", "."), "basic.jar").toAbsolutePath()
        );
    }

-----------------

Results in:
--------------------
test.dir = .
user.dir = /Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch
/Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch/./basic.jar

Please see http://openjdk.java.net/jtreg/tag-spec.html for the system properties.  I do not see test.dir there.
?????????

I would just do:

?????????

Path foo = Path.of("test.zip");
System.out.println("test.zip path=" + foo.toAbsolutePath());

--------------------------

which results in the output:
test.zip path=/Users/ljanders/Documents/hg-workspaces/openjdk-jdk/jdk-zip-api/build/macosx-x64/JTwork/scratch/test.zip

Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190214/70812ffb/attachment-0001.html>

From sean.mullan at oracle.com  Thu Feb 14 18:24:09 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 14 Feb 2019 13:24:09 -0500
Subject: RFR [13] JDK-4919790 : Errors in alert ssl message does not
 reflect the actual certificate status
In-Reply-To: <3c720033-6206-0a49-86d7-5ee407f995a9@oracle.com>
References: <3c720033-6206-0a49-86d7-5ee407f995a9@oracle.com>
Message-ID: <3f17ece6-f40d-6f0c-ef23-9c3590ac01d8@oracle.com>

On 2/11/19 2:32 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the update reviewed?
>  ?? http://cr.openjdk.java.net/~xuelei/4919790/webrev.00/

721                     alert = Alert.UNSUPPORTED_CERTIFCATE;

Can we fix this typo while we are cleaning this up? 
s/CERTIFCATE/CERTIFICATE/

Also, I was a bit curious about these lines (not part of your fix):

  711                 if (reason == BasicReason.REVOKED) {
  712                     alert = chc.staplingActive ?
  713                             Alert.BAD_CERT_STATUS_RESPONSE :
  714                             Alert.CERTIFICATE_REVOKED;

If a certificate is revoked, why would you set the alert status to 
BAD_CERT_STATUS_RESPONSE if stapling is enabled?

Also, bug needs a noreg label.

--Sean

> It had been a while that the SunJSSE provider use certificate_unknown or 
> certificate_revoked (or bad_certificate_status_response for OCSP 
> stapling) as the certificate issues alert.? Other certificate alert like 
> certificate_expired are not used.
> 
> The bug was reported in JDK 6.? With the introducing of 
> CertPathValidatorException.BasicReason in JDK 7. Now we can handle the 
> alert more accuracy.
> 
> Note: please don't rely on the certificate alert type for application 
> development.? The alert type may be changed and different per the 
> provider preference.
> 
> No new regression test as the update is simple and straightforward.
> 
> Thanks,
> Xuelei

From sean.mullan at oracle.com  Thu Feb 14 19:08:35 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 14 Feb 2019 14:08:35 -0500
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
 <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
 <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
Message-ID: <74045499-137b-87c4-ab59-8edb4801aa4b@oracle.com>

On 2/13/19 2:20 PM, Open eSignForms wrote:
> Thanks, Sean.? I was able to find the updated test case source code.
> 
> A preliminary review seems to show worthwhile changes to our code.? That 
> is, the namespaces and such seem to make sense as you have them.
> 
> In particular, the use of:
> 
> domSignContext.putNamespacePrefix(XMLSignature.XMLNS, "dsig");
> 
> and adding this namespace to additional elements we added:
> 
>  ??? ??? ??? String xmlns = "http://uri.etsi.org/01903/v1.1.1#";
> 
> seem reasonable and an acceptable workaround for us.? I'm not sure if 
> those were oversights from before, but likely were the result of it 
> being based on Oracle/Java example code from Java 6 days...
> 
> We'll incorporate your namespace changes in our code and test, but this 
> seems like it will work as I was able to confirm that your fixed version 
> seems to run on Java 10 and Java 11.
> 
> It is interesting that the fixed code, though, generates different 
> output on Java 10 and Java 11.? I'm not positive, but it seems that Java 
> 11 adds '&#13;' to the end of many lines that aren't present in Java 
> 10's output.

This is the ASCII code for a carriage return, encoded in XML. I don't 
know why that behavior is different in JDK 11. This would be a question 
for the XML developers. I have copied Joe Wang, to see if he might know.

--Sean

> 
> Under Java 10, a test run products this result:
> 
> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
> timestamp="2019-02-13T11:02:30-08:00" type="document"><![CDATA[<html 
> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
> document</p></body></html>]]><dsig:Signature 
> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod 
> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Zqmii2rv6C+bFM+CSO3s8sAGOrl67HEnv4t8XUgQd5iguf9m7vcVJn3pJz5inCZfx5V9lTtDaj0u 
> 
> xbZSyWE5kQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
> URI="#KeyInfo_ID"><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>kZM1pJpRXoeDuolU+kyK41BotQoW7ir5lfg/nNSMoC69bUC2OHzWbQ5Kug0gtrLVIuq5HRdzk6zc 
> 
> 2N2jA0WKMQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
> URI="#QualifyingProperties_ID"><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>AFx1CJi739IWZwJL1Y5KU2B+ZioT3ONMBLwLTdT/NTysV/+KYF7lZMgEHaGtLxvc6haIKKKzZisr 
> 
> r2YDQVgs5w==</dsig:DigestValue></dsig:Reference><dsig:Reference 
> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>jhVDd7nvr4s2bu7LRNHb7yj2gQRzAE7fXcsgonq2Qsn4EWNfpqNEVUViIy9jh86tTs5ZiakaGAEs 
> 
> l9YV1hNnEg==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>izJCFA5lBOjc7zhlc/1Wrsu+/jd0o0aPtemm4hM7aMKJvzkKddhjaHRY9iX4qtMZJtl7L1qj4YGN 
> 
> hxHc2Wjuj6F1ZFD9asPf/kumVliAqTwNvhfyVfmpbaZtzQVtOQWhNIC1PivbPfbwTKr1yztLbo0K 
> 
> B8TJWWiqHBjgEjlhw8X84buXVsCIUaAkOJG73Q0x9hMDVPf5y5R56xknLwjwzQPdveMI3zKvKvq5 
> 
> vj1UPKVqlCjrjPa1HR0g4wEOjL51HCK/EWVbB4LLRAL59KB6ERW01CaRX1crGzQw6wz5eFVWK/0o 
> 
> NcIdn4wc7rWPdYfT362iqqJMzIyUQGHmk7FVD/1Nky2wlEvYaRk7PrpbXo8ISSPB+RQM+EWQbYCP 
> 
> RVT5oq6d4dnu0cUuj/wG8Ng7FIfSY3C8Ds9cw7CTKi/Dbmw3oE8yaJHNqfjEMAW2tmqQmuC4ZRXG 
> 
> 7DfqeNdgiHwoQLdLzD/vj/00SWmcM67NWQNwblbPJ5MhVeFmh/fIbd7bkIyANbw1FAYIj1b+Hf8b 
> 
> cZzC+lNecKxzkcY9/VZ3ny4kBBQmxwBLlojBa2ll8B9m+sYN0enRGwy9GG2eBY2Gb53KqAALQAUU 
> 
> kjXjJYxrQh64Y2RTAgp01Nbfj7QbvuKW93YDR6cpjNTM7EfJfQM/cz+VHHngFCRr/N0/WmM4j0A=</dsig:SignatureValue><dsig:KeyInfo 
> Id="KeyInfo_ID"><dsig:KeyName>c42c747f-0f03-46a3-8ae8-81fc95464c8f</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9 
> 
> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW 
> 
> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU 
> 
> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX 
> 
> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ 
> 
> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB 
> 
> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z 
> 
> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n 
> 
> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu 
> 
> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z 
> 
> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2 
> 
> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh 
> 
> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz 
> 
> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh 
> 
> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw 
> 
> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ 
> 
> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi 
> 
> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A 
> 
> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6 
> 
> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/ 
> 
> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn 
> 
> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy 
> 
> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW 
> 
> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR 
> 
> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz 
> 
> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj 
> 
> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC 
> 
> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc 
> 
> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI 
> 
> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl 
> 
> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o 
> 
> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY 
> 
> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N 
> 
> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E 
> 
> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg 
> 
> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV 
> 
> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC 
> 
> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q 
> 
> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX 
> 
> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D 
> 
> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+ 
> 
> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx 
> 
> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P 
> 
> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf 
> 
> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z 
> 
> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0 
> 
> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN 
> 
> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk 
> 
> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw 
> 
> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz 
> 
> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO 
> 
> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK 
> 
> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u 
> 
> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/ 
> 
> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX 
> 
> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy 
> 
> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
> ns0:Id="QualifyingProperties_ID" 
> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:02:30-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
> Id="OpenESignForms_Seal_ID" 
> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
> ns0:DeploymentHostAddress="192.1.1.1" 
> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
> ns1:DeploymentHostName="open.esignforms.com" 
> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
> ns2:DeploymentId="1.1.1.1" 
> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
> ns3:SignerAddress="192.1.1.1" 
> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
> ns4:SignerAgent="No-Browser-Test" 
> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
> ns5:Timestamp="2019-02-13T11:02:30-08:00" 
> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot> 
> 
> 
> while when run under Java 11 it shows what seems to be the same 
> (clearly, the digest/hashes aren't the same as the 'timestamp' differs 
> because they are actual times) except for lots of '&#13;' added to the 
> digests and signatures:
> 
> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
> timestamp="2019-02-13T11:01:22-08:00" type="document"><![CDATA[<html 
> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
> document</p></body></html>]]><dsig:Signature 
> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod 
> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LdB/ydGxr3VUoTshQtOvQNmMZmt2OHgLax4tSk9Lqb1c+X1h4Uc/RBVXwfI9QrVnITBz85Fi8Bwr&#13; 
> 
> 7wyMjw84cA==</dsig:DigestValue></dsig:Reference><dsig:Reference 
> URI="#KeyInfo_ID"><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>FkpexxTwhpCPHHsMrKGnBXE5hkZ/x10ArpzjX6ltYfOilvVAubzc9sNPwo6phw//ot1rSKPU5jTB&#13; 
> 
> LRD7p7t50g==</dsig:DigestValue></dsig:Reference><dsig:Reference 
> URI="#QualifyingProperties_ID"><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LxB0xAsDxKqeyCflaSUgMQOMhoxP4Gl9GfvlpCiL/gd9rz36qG4roaFRl+4PBC+IxzGiRDOqzQYX&#13; 
> 
> x6gSn5d1IQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Pqd+9yaeBMytcG1sTTpuq+Wrd3lZSC18j7lv6VQ6LjUSz9VN7uwVNNn1E79mY8H6XUI2jbd/IozM&#13; 
> 
> oba2KF46ig==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>IpdHZtzSw8TOnp0gfKMaCp30jJAPP8YCAIg4OBvRobIwHBFrG+O9v7peXRRA5nXi+fm4bdemi5jI&#13; 
> 
> /N2smS7W6lKMMeTzrYNJEmpD/0c/SVCs0M1peZmiWZD/F6GYP6RkhZfTglk9skKsZIme3W5lHL5e&#13; 
> 
> vTFno50J32oW0chq/jPzD42snoVQmVKS9wqqybGgRrm1W2RSWfziNo7QjXtJuR5eVuCtqpOLrGrS&#13; 
> 
> J0aLaaNLucia/6cJyZ13mz7131Lj2Y4oJbrbpzvrDY5xDfFDK+bRRMR3DCvTLgKcZZz5zxcAKYL8&#13; 
> 
> lG64U/tsmd/ZVn+d+fJGH03hPdvY/wMW7MTN1k/6S95PiNdx0cLeP0HLCug9zWiC7vUkrVDrsO9i&#13; 
> 
> qsvSYKcAH8vQlG1arZgGJn88Hg8EGjmmWXs15ulU3Lm8TOTXl/xi6O4stSgMi9dFSsE1ISHAPaxN&#13; 
> 
> D3Rqg7Bv7p/iEVn0xXq/C9AI3iwrpHbip8K81uJOsaiZgwR5D40XyYLV9FUPIacRclfT5EJKsx6k&#13; 
> 
> jYiprWMOMjmnlJwj2vI8zG6sYLVJdQywm2isWu5eHSw39Wof0BYfDeOzh0LrifUcnt86no5fUEOI&#13; 
> 
> OlNbqOO7rjuxtb+gt1iO2dTHfQhG99BCBQhC7AEMp67fIlPjEOECXldDTpzPMZ1K6cPlk22rpvc=</dsig:SignatureValue><dsig:KeyInfo 
> Id="KeyInfo_ID"><dsig:KeyName>184a40b0-78b6-4070-a7d7-1497078a06e4</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9&#13; 
> 
> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW&#13; 
> 
> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU&#13; 
> 
> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX&#13; 
> 
> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ&#13; 
> 
> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB&#13; 
> 
> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z&#13; 
> 
> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n&#13; 
> 
> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu&#13; 
> 
> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z&#13; 
> 
> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2&#13; 
> 
> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh&#13; 
> 
> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz&#13; 
> 
> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh&#13; 
> 
> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw&#13; 
> 
> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ&#13; 
> 
> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi&#13; 
> 
> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A&#13; 
> 
> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6&#13; 
> 
> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/&#13; 
> 
> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn&#13; 
> 
> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy&#13; 
> 
> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW&#13; 
> 
> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR&#13; 
> 
> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz&#13; 
> 
> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj&#13; 
> 
> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC&#13; 
> 
> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc&#13; 
> 
> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI&#13; 
> 
> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl&#13; 
> 
> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o&#13; 
> 
> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY&#13; 
> 
> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N&#13; 
> 
> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E&#13; 
> 
> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg&#13; 
> 
> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV&#13; 
> 
> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC&#13; 
> 
> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q&#13; 
> 
> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX&#13; 
> 
> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D&#13; 
> 
> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+&#13; 
> 
> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx&#13; 
> 
> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P&#13; 
> 
> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf&#13; 
> 
> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z&#13; 
> 
> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0&#13; 
> 
> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN&#13; 
> 
> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk&#13; 
> 
> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw&#13; 
> 
> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz&#13; 
> 
> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO&#13; 
> 
> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK&#13; 
> 
> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u&#13; 
> 
> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/&#13; 
> 
> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX&#13; 
> 
> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy&#13; 
> 
> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
> ns0:Id="QualifyingProperties_ID" 
> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:01:22-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
> Id="OpenESignForms_Seal_ID" 
> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
> ns0:DeploymentHostAddress="192.1.1.1" 
> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
> ns1:DeploymentHostName="open.esignforms.com" 
> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
> ns2:DeploymentId="1.1.1.1" 
> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
> ns3:SignerAddress="192.1.1.1" 
> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
> ns4:SignerAgent="No-Browser-Test" 
> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
> ns5:Timestamp="2019-02-13T11:01:22-08:00" 
> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot> 
> 
> 
> 
> It's particularly odd because hex 13 isn't a typical character (^S).
> 
> Any idea what that difference is about for the base64 digests and 
> signatures?
> 
> David
> 
> 
> On 2/13/19 6:03 AM, Sean Mullan wrote:
>> On 2/12/19 6:28 PM, Open eSignForms wrote:
>>> Thanks for the update, Sean.? I'm a bit perplexed because I found the 
>>> original code works under Java 9 and Java 10, so it seems like the 
>>> change occurred in Java 11.
>>
>> Sorry, that was a typo, I meant to say JDK 11.
>>
>>> I don't see the modified version of the test case.? If you attached 
>>> it, it somehow didn't make it through to me.
>>>
>>> If it's just a matter of making the code more correct, we'd love to 
>>> make the changes.? My concern, of course, is that we've already done 
>>> millions of XML digital signatures, so we need that to continue to 
>>> verify correctly (and even under Java 11, it seems that the verify 
>>> code works against previously digitally signed content) even if we 
>>> now start digitally signing using more update-to-date code.
>>
>> The verification of pre-existing signatures should continue to work 
>> regardless of how this bug is addressed.
>>
>>> Please send over the modified test case and I'll take a look.
>>
>> It is attached to the bug report in the Attachments section: 
>> https://bugs.openjdk.java.net/browse/JDK-8218629 (make sure you 
>> download the one I added yesterday).
>>
>> --Sean
>>
>>>
>>> Thanks!
>>> David
>>>
>>> On 2/12/19 2:14 PM, Sean Mullan wrote:
>>>> The bug is now at https://bugs.openjdk.java.net/browse/JDK-8218629
>>>>
>>>> I have started looking at this issue and have some progress I can 
>>>> report.
>>>>
>>>> In JDK 9, we updated the version of the Apache XML Signature 
>>>> implementation in the JDK. Some of the marshalling code was 
>>>> rewritten such that it will throw Exceptions if legacy DOM level 1 
>>>> methods were used to create XML content which is then passed into 
>>>> XMLObject and similar XMLSignature types that take DOMStructure 
>>>> objects. This is because the DOM level 1 methods do not support 
>>>> namespaces.
>>>>
>>>> I am still evaluating what the best fix is. However, you can 
>>>> workaround the issue by always using DOM level 3 methods which are 
>>>> namespace aware. For example, use Document.createElementNS instead 
>>>> of Document.createElement and Element.createAttributeNS instead of 
>>>> Element.createAttribute.
>>>>
>>>> Using legacy or non-namespace aware XML parsers or implementations 
>>>> is not recommended and the XML Signature Best Practices document 
>>>> gives some rationale: 
>>>> https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces 
>>>>
>>>> That said, this is a regression in behavior so it would be best if 
>>>> we could restore the previous behavior.
>>>>
>>>> I have attached a modified version of the test case to the bug 
>>>> report which no longer throws an Exception. Let me know if this is 
>>>> an acceptable workaround. Double-check the namespaces that I used to 
>>>> make sure they are correct.
>>>>
>>>> --Sean
>>>>
>>>>
>>>> On 2/7/19 11:23 AM, Open eSignForms wrote:
>>>>
>>>>> On 2/7/19 7:49 AM, Sean Mullan wrote:
>>>>>> On 2/6/19 4:51 PM, Open eSignForms wrote:
>>>>>>> I have a test version of the code that can run standalone and 
>>>>>>> shows the bug.? I'm not sure how best to transfer this 
>>>>>>> information to the forum for those to play with, but it is 
>>>>>>> included below.
>>>>>>
>>>>>> Thanks, I can reproduce the issue now. I will need to debug 
>>>>>> further to see what might be causing this.
>>>>>>
>>>>>> --Sean

From jamil.j.nimeh at oracle.com  Thu Feb 14 19:17:29 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 14 Feb 2019 11:17:29 -0800
Subject: RFR [13] JDK-4919790 : Errors in alert ssl message does not
 reflect the actual certificate status
In-Reply-To: <3f17ece6-f40d-6f0c-ef23-9c3590ac01d8@oracle.com>
References: <3c720033-6206-0a49-86d7-5ee407f995a9@oracle.com>
 <3f17ece6-f40d-6f0c-ef23-9c3590ac01d8@oracle.com>
Message-ID: <8f5bab05-5376-0d8b-a3e5-6a8d75aab2da@oracle.com>



On 2/14/2019 10:24 AM, Sean Mullan wrote:
> On 2/11/19 2:32 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the update reviewed?
>> ??? http://cr.openjdk.java.net/~xuelei/4919790/webrev.00/
>
> 721???????????????????? alert = Alert.UNSUPPORTED_CERTIFCATE;
>
> Can we fix this typo while we are cleaning this up? 
> s/CERTIFCATE/CERTIFICATE/
>
> Also, I was a bit curious about these lines (not part of your fix):
>
> ?711???????????????? if (reason == BasicReason.REVOKED) {
> ?712???????????????????? alert = chc.staplingActive ?
> ?713???????????????????????????? Alert.BAD_CERT_STATUS_RESPONSE :
> ?714???????????????????????????? Alert.CERTIFICATE_REVOKED;
>
> If a certificate is revoked, why would you set the alert status to 
> BAD_CERT_STATUS_RESPONSE if stapling is enabled?
I think that was something I did back when we did OCSP stapling in JDK 
9.? IIRC, RFC 6066 says that clients receiving stapled responses must 
check them and alert with bad_certificate_status_response "if the 
response is not satisfactory" (their words, not mine).? Back then I 
interpreted "unsatisfactory" to mean both structurally wrong or 
revoked.? Perhaps that was too broad an interpretation.

It's probably worth seeing how a couple other clients handle this case.? 
I know I had tested with them back in pre-JDK9 days, but I don't recall 
the results.? I might have some old packet captures lying about still 
also, I just need to dig them up.
>
> Also, bug needs a noreg label.
>
> --Sean
>
>> It had been a while that the SunJSSE provider use certificate_unknown 
>> or certificate_revoked (or bad_certificate_status_response for OCSP 
>> stapling) as the certificate issues alert.? Other certificate alert 
>> like certificate_expired are not used.
>>
>> The bug was reported in JDK 6.? With the introducing of 
>> CertPathValidatorException.BasicReason in JDK 7. Now we can handle 
>> the alert more accuracy.
>>
>> Note: please don't rely on the certificate alert type for application 
>> development.? The alert type may be changed and different per the 
>> provider preference.
>>
>> No new regression test as the update is simple and straightforward.
>>
>> Thanks,
>> Xuelei


From jamil.j.nimeh at oracle.com  Thu Feb 14 19:20:40 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 14 Feb 2019 11:20:40 -0800
Subject: RFR [13] JDK-4919790 : Errors in alert ssl message does not
 reflect the actual certificate status
In-Reply-To: <8f5bab05-5376-0d8b-a3e5-6a8d75aab2da@oracle.com>
References: <3c720033-6206-0a49-86d7-5ee407f995a9@oracle.com>
 <3f17ece6-f40d-6f0c-ef23-9c3590ac01d8@oracle.com>
 <8f5bab05-5376-0d8b-a3e5-6a8d75aab2da@oracle.com>
Message-ID: <4d51eef9-c4ba-bdec-20ea-02d14a4c62fa@oracle.com>

Whoops, forgot to look at RFC 6961.? Over there, both revoked and 
structural failures are both supposed to yield 
bad_certificate_status_response alerts.? I think what we have is 
conformant with the spec.

--Jamil

On 2/14/2019 11:17 AM, Jamil Nimeh wrote:
>
>
> On 2/14/2019 10:24 AM, Sean Mullan wrote:
>> On 2/11/19 2:32 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Could I get the update reviewed?
>>> ??? http://cr.openjdk.java.net/~xuelei/4919790/webrev.00/
>>
>> 721???????????????????? alert = Alert.UNSUPPORTED_CERTIFCATE;
>>
>> Can we fix this typo while we are cleaning this up? 
>> s/CERTIFCATE/CERTIFICATE/
>>
>> Also, I was a bit curious about these lines (not part of your fix):
>>
>> ?711???????????????? if (reason == BasicReason.REVOKED) {
>> ?712???????????????????? alert = chc.staplingActive ?
>> ?713???????????????????????????? Alert.BAD_CERT_STATUS_RESPONSE :
>> ?714???????????????????????????? Alert.CERTIFICATE_REVOKED;
>>
>> If a certificate is revoked, why would you set the alert status to 
>> BAD_CERT_STATUS_RESPONSE if stapling is enabled?
> I think that was something I did back when we did OCSP stapling in JDK 
> 9.? IIRC, RFC 6066 says that clients receiving stapled responses must 
> check them and alert with bad_certificate_status_response "if the 
> response is not satisfactory" (their words, not mine).? Back then I 
> interpreted "unsatisfactory" to mean both structurally wrong or 
> revoked. Perhaps that was too broad an interpretation.
>
> It's probably worth seeing how a couple other clients handle this 
> case.? I know I had tested with them back in pre-JDK9 days, but I 
> don't recall the results.? I might have some old packet captures lying 
> about still also, I just need to dig them up.
>>
>> Also, bug needs a noreg label.
>>
>> --Sean
>>
>>> It had been a while that the SunJSSE provider use 
>>> certificate_unknown or certificate_revoked (or 
>>> bad_certificate_status_response for OCSP stapling) as the 
>>> certificate issues alert.? Other certificate alert like 
>>> certificate_expired are not used.
>>>
>>> The bug was reported in JDK 6.? With the introducing of 
>>> CertPathValidatorException.BasicReason in JDK 7. Now we can handle 
>>> the alert more accuracy.
>>>
>>> Note: please don't rely on the certificate alert type for 
>>> application development.? The alert type may be changed and 
>>> different per the provider preference.
>>>
>>> No new regression test as the update is simple and straightforward.
>>>
>>> Thanks,
>>> Xuelei
>


From sean.mullan at oracle.com  Thu Feb 14 19:29:52 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 14 Feb 2019 14:29:52 -0500
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <648d666c-60a4-bc09-ecd9-f993255040e2@gmail.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
 <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
 <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
 <32d2fff5-1be5-1201-225e-15ac60982067@gmail.com>
 <648d666c-60a4-bc09-ecd9-f993255040e2@gmail.com>
Message-ID: <ba795b7d-6100-208e-e463-1c3894612245@oracle.com>

I will need more time to look into this. In the meantime, another 
workaround is to just specify null as the namespace to the 
createElementNS and setAttributeNS methods. I tried this out on your 
example and it works fine on JDK 11. This should generate signatures 
just like you were creating before. They won't have the correct ETSI 
namespace and may instead inherit the XML Signature namespace, but if 
you haven't seen problems with that, then it might be ok. It's typically 
more of an issue if you are moving signed content from one document to 
another and an ancestor namespace can be inherited and break or 
invalidate the signature, although exclusive C14N is designed to protect 
against that.


--Sean

On 2/13/19 6:06 PM, Open eSignForms wrote:
> Well, I have found that my verify routines are failing.? I added the 
> following lines to the main() test method of your fixed code after the 
> signature is done to attempt to validate the generated signed XML:
> 
>  ??? ??? ??? try {
>  ??? ??? ??? ??? System.err.println("Verifying signedXml...");
>  ??? ??? ??? ??? xmldsig.verify(signedXml, signatureKey);
>  ??? ??? ??? ??? System.err.println("Verified signedXml...");
>  ??? ??? ??? } catch(Exception ve) {
> System.err.println("XmlDigitalSignature.main() signature verification 
> exception: " + ve.getMessage());
>  ??? ??? ??? }
> 
> This basically submits the created 'signedXml' returned just above with 
> the same keys.? I also had to update the method "verify(String 
> signedXml, SignatureKey signatureKey)" where it sets the ID attribute to 
> include the namespace added in the fixed code:
> 
>              
> qualifyingPropertiesElement.setIdAttribute*NS("http://uri.etsi.org/01903/v1.1.1#"*,"Id", 
> true); // mark our id as the "Id" attribute
> 
> This then fails showing 2 out of 4 references validated, the others failing:
> 
> XmlDigitalSignature.verify(SignatureKey) SERIOUS-ERROR Failed core 
> validation; SignatureValue validated: true
>  ?-> Reference[0] validated: true
>  ?-> Reference[1] validated: true
>  ?-> Reference[2] validated: false
>  ?-> Reference[3] validated: false
> XmlDigitalSignature.verify(SignatureKey) SERIOUS-ERROR exception: 
> Invalid signature. SignatureValue validated; XML data payload validated; 
> OpenESignForms Seal validated; Unexpected Reference[2] INVALID; 
> Unexpected Reference[3] INVALID
> 
> In my test code I was able to show the references subscripts 0-3 being:
> 
>  ?-> Reference[0] before validate(): *r.getId(): Payload_Reference_ID*; 
> r.getURI():
>  ?-> Reference[0] validated: true
> 
>  ?-> Reference[1] before validate(): r.getId(): null; *r.getURI(): 
> #KeyInfo_ID*
>  ?-> Reference[1] validated: true
> 
>  ?-> Reference[2] before validate(): r.getId(): null; *r.getURI(): 
> #QualifyingProperties_ID*
>  ?-> Reference[2] validated: false
> 
>  ?-> Reference[3] before validate(): r.getId(): null; *r.getURI(): 
> #OpenESignForms_Seal_ID*
>  ?-> Reference[3] validated: false
> 
> So, the namespace changes made allow the digital signature to be 
> applied, but now I'm stuck on how to verify these last two references.  
> It seems that references related to Payload_Reference_ID and #KeyInfo_ID 
> validate, but #QualifyingProperties_ID and #OpenESignForms_Seal_ID are 
> failing.
> 
> I'm not sure how those references work with respect to the namespace 
> changes you suggested.
> 
> In fact, the fixed code no longer validates the digital signature under 
> Java 8 once the namespaces were added.? Any ideas?
> 
> Thanks, David
> 
> 
> On 2/13/19 1:23 PM, Open eSignForms wrote:
>>
>> I checked the ETSI XAdES spec 
>> (http://uri.etsi.org/01903/v1.1.1/ts_101903v010101p.pdf) and it 
>> doesn't show any namespace on their entries for their 
>> QualifyingProperties element and all sub-elements under the ETSI 
>> example's element <ds:Object>.
>>
>> But, their specification does show element <QualifyingProperties> 
>> should be under the namespace "http://uri.etsi.org/01903/v1.1.1#" as 
>> you added in your fixed code.
>>
>> That is, when my snapshot element that's digitally signed using the 
>> below, it fails with the NAMESPACE_ERR exception:
>>
>> <snapshot *xmlns="http://open.esignforms.com/XMLSchema/2011"* 
>> timestamp="2019-02-13T11:02:30-08:00" type="document">
>>
>> But if my snapshot is set up with the ETSI namespace URI, it works:
>>
>> <snapshot *xmlns="**http://uri.etsi.org/01903/v1.1.1#**" * 
>> timestamp="2019-02-13T11:02:30-08:00" type="document">
>>
>> So, it seems that the XMLSignature is noting that the 
>> <QualifyingProperties> belongs to the default namespace in both cases, 
>> but of course expects that particular element to belong to the ETSI 
>> namespace, not ours.
>>
>> I presume that's correct behavior; I just didn't think that the 
>> XMLSignature.sign() knew about and was limited to that specific namespace.
>>
>> If you agree that this is the correct behavior, I think it's not 
>> really a bug in Java 11, though it fails backwards compatibility.
>>
>> The only oddity that remains is what I mentioned below with all the 
>> "&#13;" characters in the digests/signatures that appear in Java 11.  
>> They sure look odd compared to simple line breaks that presumably were 
>> emitted before.
>>
>> David
>>
>>
>>
>> On 2/13/19 11:20 AM, Open eSignForms wrote:
>>> Thanks, Sean.? I was able to find the updated test case source code.
>>>
>>> A preliminary review seems to show worthwhile changes to our code.  
>>> That is, the namespaces and such seem to make sense as you have them.
>>>
>>> In particular, the use of:
>>>
>>> domSignContext.putNamespacePrefix(XMLSignature.XMLNS, "dsig");
>>>
>>> and adding this namespace to additional elements we added:
>>>
>>> ??? ??? ??? String xmlns = "http://uri.etsi.org/01903/v1.1.1#";
>>>
>>> seem reasonable and an acceptable workaround for us.? I'm not sure if 
>>> those were oversights from before, but likely were the result of it 
>>> being based on Oracle/Java example code from Java 6 days...
>>>
>>> We'll incorporate your namespace changes in our code and test, but 
>>> this seems like it will work as I was able to confirm that your fixed 
>>> version seems to run on Java 10 and Java 11.
>>>
>>> It is interesting that the fixed code, though, generates different 
>>> output on Java 10 and Java 11.? I'm not positive, but it seems that 
>>> Java 11 adds '&#13;' to the end of many lines that aren't present in 
>>> Java 10's output.
>>>
>>> Under Java 10, a test run products this result:
>>>
>>> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
>>> timestamp="2019-02-13T11:02:30-08:00" type="document"><![CDATA[<html 
>>> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
>>> document</p></body></html>]]><dsig:Signature 
>>> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
>>> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
>>> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Zqmii2rv6C+bFM+CSO3s8sAGOrl67HEnv4t8XUgQd5iguf9m7vcVJn3pJz5inCZfx5V9lTtDaj0u 
>>>
>>> xbZSyWE5kQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>>> URI="#KeyInfo_ID"><dsig:DigestMethod 
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>kZM1pJpRXoeDuolU+kyK41BotQoW7ir5lfg/nNSMoC69bUC2OHzWbQ5Kug0gtrLVIuq5HRdzk6zc
>>> 2N2jA0WKMQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>>> URI="#QualifyingProperties_ID"><dsig:DigestMethod 
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>AFx1CJi739IWZwJL1Y5KU2B+ZioT3ONMBLwLTdT/NTysV/+KYF7lZMgEHaGtLxvc6haIKKKzZisr
>>> r2YDQVgs5w==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>>> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>jhVDd7nvr4s2bu7LRNHb7yj2gQRzAE7fXcsgonq2Qsn4EWNfpqNEVUViIy9jh86tTs5ZiakaGAEs
>>> l9YV1hNnEg==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>izJCFA5lBOjc7zhlc/1Wrsu+/jd0o0aPtemm4hM7aMKJvzkKddhjaHRY9iX4qtMZJtl7L1qj4YGN 
>>>
>>> hxHc2Wjuj6F1ZFD9asPf/kumVliAqTwNvhfyVfmpbaZtzQVtOQWhNIC1PivbPfbwTKr1yztLbo0K 
>>>
>>> B8TJWWiqHBjgEjlhw8X84buXVsCIUaAkOJG73Q0x9hMDVPf5y5R56xknLwjwzQPdveMI3zKvKvq5 
>>>
>>> vj1UPKVqlCjrjPa1HR0g4wEOjL51HCK/EWVbB4LLRAL59KB6ERW01CaRX1crGzQw6wz5eFVWK/0o 
>>>
>>> NcIdn4wc7rWPdYfT362iqqJMzIyUQGHmk7FVD/1Nky2wlEvYaRk7PrpbXo8ISSPB+RQM+EWQbYCP 
>>>
>>> RVT5oq6d4dnu0cUuj/wG8Ng7FIfSY3C8Ds9cw7CTKi/Dbmw3oE8yaJHNqfjEMAW2tmqQmuC4ZRXG 
>>>
>>> 7DfqeNdgiHwoQLdLzD/vj/00SWmcM67NWQNwblbPJ5MhVeFmh/fIbd7bkIyANbw1FAYIj1b+Hf8b 
>>>
>>> cZzC+lNecKxzkcY9/VZ3ny4kBBQmxwBLlojBa2ll8B9m+sYN0enRGwy9GG2eBY2Gb53KqAALQAUU 
>>>
>>> kjXjJYxrQh64Y2RTAgp01Nbfj7QbvuKW93YDR6cpjNTM7EfJfQM/cz+VHHngFCRr/N0/WmM4j0A=</dsig:SignatureValue><dsig:KeyInfo 
>>> Id="KeyInfo_ID"><dsig:KeyName>c42c747f-0f03-46a3-8ae8-81fc95464c8f</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9 
>>>
>>> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW 
>>>
>>> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU 
>>>
>>> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX 
>>>
>>> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ 
>>>
>>> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB 
>>>
>>> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z 
>>>
>>> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n 
>>>
>>> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu 
>>>
>>> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z 
>>>
>>> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2 
>>>
>>> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh 
>>>
>>> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz 
>>>
>>> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh 
>>>
>>> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw 
>>>
>>> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ 
>>>
>>> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi 
>>>
>>> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A 
>>>
>>> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6 
>>>
>>> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/ 
>>>
>>> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn 
>>>
>>> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy 
>>>
>>> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW 
>>>
>>> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR 
>>>
>>> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz 
>>>
>>> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj 
>>>
>>> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC 
>>>
>>> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc 
>>>
>>> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI 
>>>
>>> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl 
>>>
>>> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o 
>>>
>>> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY 
>>>
>>> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N 
>>>
>>> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E 
>>>
>>> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg 
>>>
>>> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV 
>>>
>>> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC 
>>>
>>> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q 
>>>
>>> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX 
>>>
>>> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D 
>>>
>>> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+ 
>>>
>>> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx 
>>>
>>> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P 
>>>
>>> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf 
>>>
>>> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z 
>>>
>>> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0 
>>>
>>> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN 
>>>
>>> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk 
>>>
>>> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw 
>>>
>>> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz 
>>>
>>> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO 
>>>
>>> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK 
>>>
>>> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u 
>>>
>>> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/ 
>>>
>>> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX 
>>>
>>> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy 
>>>
>>> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
>>> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
>>> ns0:Id="QualifyingProperties_ID" 
>>> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:02:30-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
>>> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
>>> Id="OpenESignForms_Seal_ID" 
>>> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
>>> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
>>> ns0:DeploymentHostAddress="192.1.1.1" 
>>> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
>>> ns1:DeploymentHostName="open.esignforms.com" 
>>> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
>>> ns2:DeploymentId="1.1.1.1" 
>>> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
>>> ns3:SignerAddress="192.1.1.1" 
>>> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
>>> ns4:SignerAgent="No-Browser-Test" 
>>> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
>>> ns5:Timestamp="2019-02-13T11:02:30-08:00" 
>>> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
>>> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot>
>>>
>>> while when run under Java 11 it shows what seems to be the same 
>>> (clearly, the digest/hashes aren't the same as the 'timestamp' 
>>> differs because they are actual times) except for lots of '&#13;' 
>>> added to the digests and signatures:
>>>
>>> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
>>> timestamp="2019-02-13T11:01:22-08:00" type="document"><![CDATA[<html 
>>> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
>>> document</p></body></html>]]><dsig:Signature 
>>> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
>>> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
>>> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LdB/ydGxr3VUoTshQtOvQNmMZmt2OHgLax4tSk9Lqb1c+X1h4Uc/RBVXwfI9QrVnITBz85Fi8Bwr&#13; 
>>>
>>> 7wyMjw84cA==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>>> URI="#KeyInfo_ID"><dsig:DigestMethod 
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>FkpexxTwhpCPHHsMrKGnBXE5hkZ/x10ArpzjX6ltYfOilvVAubzc9sNPwo6phw//ot1rSKPU5jTB&#13;
>>> LRD7p7t50g==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>>> URI="#QualifyingProperties_ID"><dsig:DigestMethod 
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LxB0xAsDxKqeyCflaSUgMQOMhoxP4Gl9GfvlpCiL/gd9rz36qG4roaFRl+4PBC+IxzGiRDOqzQYX&#13;
>>> x6gSn5d1IQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>>> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Pqd+9yaeBMytcG1sTTpuq+Wrd3lZSC18j7lv6VQ6LjUSz9VN7uwVNNn1E79mY8H6XUI2jbd/IozM&#13;
>>> oba2KF46ig==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>IpdHZtzSw8TOnp0gfKMaCp30jJAPP8YCAIg4OBvRobIwHBFrG+O9v7peXRRA5nXi+fm4bdemi5jI&#13; 
>>>
>>> /N2smS7W6lKMMeTzrYNJEmpD/0c/SVCs0M1peZmiWZD/F6GYP6RkhZfTglk9skKsZIme3W5lHL5e&#13; 
>>>
>>> vTFno50J32oW0chq/jPzD42snoVQmVKS9wqqybGgRrm1W2RSWfziNo7QjXtJuR5eVuCtqpOLrGrS&#13; 
>>>
>>> J0aLaaNLucia/6cJyZ13mz7131Lj2Y4oJbrbpzvrDY5xDfFDK+bRRMR3DCvTLgKcZZz5zxcAKYL8&#13; 
>>>
>>> lG64U/tsmd/ZVn+d+fJGH03hPdvY/wMW7MTN1k/6S95PiNdx0cLeP0HLCug9zWiC7vUkrVDrsO9i&#13; 
>>>
>>> qsvSYKcAH8vQlG1arZgGJn88Hg8EGjmmWXs15ulU3Lm8TOTXl/xi6O4stSgMi9dFSsE1ISHAPaxN&#13; 
>>>
>>> D3Rqg7Bv7p/iEVn0xXq/C9AI3iwrpHbip8K81uJOsaiZgwR5D40XyYLV9FUPIacRclfT5EJKsx6k&#13; 
>>>
>>> jYiprWMOMjmnlJwj2vI8zG6sYLVJdQywm2isWu5eHSw39Wof0BYfDeOzh0LrifUcnt86no5fUEOI&#13; 
>>>
>>> OlNbqOO7rjuxtb+gt1iO2dTHfQhG99BCBQhC7AEMp67fIlPjEOECXldDTpzPMZ1K6cPlk22rpvc=</dsig:SignatureValue><dsig:KeyInfo 
>>> Id="KeyInfo_ID"><dsig:KeyName>184a40b0-78b6-4070-a7d7-1497078a06e4</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9&#13; 
>>>
>>> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW&#13; 
>>>
>>> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU&#13; 
>>>
>>> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX&#13; 
>>>
>>> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ&#13; 
>>>
>>> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB&#13; 
>>>
>>> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z&#13; 
>>>
>>> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n&#13; 
>>>
>>> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu&#13; 
>>>
>>> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z&#13; 
>>>
>>> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2&#13; 
>>>
>>> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh&#13; 
>>>
>>> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz&#13; 
>>>
>>> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh&#13; 
>>>
>>> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw&#13; 
>>>
>>> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ&#13; 
>>>
>>> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi&#13; 
>>>
>>> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A&#13; 
>>>
>>> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6&#13; 
>>>
>>> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/&#13; 
>>>
>>> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn&#13; 
>>>
>>> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy&#13; 
>>>
>>> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW&#13; 
>>>
>>> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR&#13; 
>>>
>>> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz&#13; 
>>>
>>> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj&#13; 
>>>
>>> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC&#13; 
>>>
>>> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc&#13; 
>>>
>>> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI&#13; 
>>>
>>> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl&#13; 
>>>
>>> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o&#13; 
>>>
>>> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY&#13; 
>>>
>>> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N&#13; 
>>>
>>> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E&#13; 
>>>
>>> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg&#13; 
>>>
>>> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV&#13; 
>>>
>>> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC&#13; 
>>>
>>> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q&#13; 
>>>
>>> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX&#13; 
>>>
>>> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D&#13; 
>>>
>>> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+&#13; 
>>>
>>> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx&#13; 
>>>
>>> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P&#13; 
>>>
>>> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf&#13; 
>>>
>>> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z&#13; 
>>>
>>> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0&#13; 
>>>
>>> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN&#13; 
>>>
>>> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk&#13; 
>>>
>>> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw&#13; 
>>>
>>> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz&#13; 
>>>
>>> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO&#13; 
>>>
>>> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK&#13; 
>>>
>>> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u&#13; 
>>>
>>> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/&#13; 
>>>
>>> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX&#13; 
>>>
>>> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy&#13; 
>>>
>>> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
>>> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
>>> ns0:Id="QualifyingProperties_ID" 
>>> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:01:22-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
>>> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
>>> Id="OpenESignForms_Seal_ID" 
>>> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
>>> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
>>> ns0:DeploymentHostAddress="192.1.1.1" 
>>> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
>>> ns1:DeploymentHostName="open.esignforms.com" 
>>> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
>>> ns2:DeploymentId="1.1.1.1" 
>>> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
>>> ns3:SignerAddress="192.1.1.1" 
>>> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
>>> ns4:SignerAgent="No-Browser-Test" 
>>> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
>>> ns5:Timestamp="2019-02-13T11:01:22-08:00" 
>>> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
>>> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot>
>>>
>>>
>>> It's particularly odd because hex 13 isn't a typical character (^S).
>>>
>>> Any idea what that difference is about for the base64 digests and 
>>> signatures?
>>>
>>> David
>>>
>>>
>>> On 2/13/19 6:03 AM, Sean Mullan wrote:
>>>> On 2/12/19 6:28 PM, Open eSignForms wrote:
>>>>> Thanks for the update, Sean.? I'm a bit perplexed because I found 
>>>>> the original code works under Java 9 and Java 10, so it seems like 
>>>>> the change occurred in Java 11.
>>>>
>>>> Sorry, that was a typo, I meant to say JDK 11.
>>>>
>>>>> I don't see the modified version of the test case.? If you attached 
>>>>> it, it somehow didn't make it through to me.
>>>>>
>>>>> If it's just a matter of making the code more correct, we'd love to 
>>>>> make the changes.? My concern, of course, is that we've already 
>>>>> done millions of XML digital signatures, so we need that to 
>>>>> continue to verify correctly (and even under Java 11, it seems that 
>>>>> the verify code works against previously digitally signed content) 
>>>>> even if we now start digitally signing using more update-to-date code.
>>>>
>>>> The verification of pre-existing signatures should continue to work 
>>>> regardless of how this bug is addressed.
>>>>
>>>>> Please send over the modified test case and I'll take a look.
>>>>
>>>> It is attached to the bug report in the Attachments section: 
>>>> https://bugs.openjdk.java.net/browse/JDK-8218629 (make sure you 
>>>> download the one I added yesterday).
>>>>
>>>> --Sean
>>>>
>>>>>
>>>>> Thanks!
>>>>> David
>>>>>
>>>>> On 2/12/19 2:14 PM, Sean Mullan wrote:
>>>>>> The bug is now at https://bugs.openjdk.java.net/browse/JDK-8218629
>>>>>>
>>>>>> I have started looking at this issue and have some progress I can 
>>>>>> report.
>>>>>>
>>>>>> In JDK 9, we updated the version of the Apache XML Signature 
>>>>>> implementation in the JDK. Some of the marshalling code was 
>>>>>> rewritten such that it will throw Exceptions if legacy DOM level 1 
>>>>>> methods were used to create XML content which is then passed into 
>>>>>> XMLObject and similar XMLSignature types that take DOMStructure 
>>>>>> objects. This is because the DOM level 1 methods do not support 
>>>>>> namespaces.
>>>>>>
>>>>>> I am still evaluating what the best fix is. However, you can 
>>>>>> workaround the issue by always using DOM level 3 methods which are 
>>>>>> namespace aware. For example, use Document.createElementNS instead 
>>>>>> of Document.createElement and Element.createAttributeNS instead of 
>>>>>> Element.createAttribute.
>>>>>>
>>>>>> Using legacy or non-namespace aware XML parsers or implementations 
>>>>>> is not recommended and the XML Signature Best Practices document 
>>>>>> gives some rationale: 
>>>>>> https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces 
>>>>>>
>>>>>> That said, this is a regression in behavior so it would be best if 
>>>>>> we could restore the previous behavior.
>>>>>>
>>>>>> I have attached a modified version of the test case to the bug 
>>>>>> report which no longer throws an Exception. Let me know if this is 
>>>>>> an acceptable workaround. Double-check the namespaces that I used 
>>>>>> to make sure they are correct.
>>>>>>
>>>>>> --Sean
>>>>>>
>>>>>>
>>>>>> On 2/7/19 11:23 AM, Open eSignForms wrote:
>>>>>>
>>>>>>> On 2/7/19 7:49 AM, Sean Mullan wrote:
>>>>>>>> On 2/6/19 4:51 PM, Open eSignForms wrote:
>>>>>>>>> I have a test version of the code that can run standalone and 
>>>>>>>>> shows the bug.? I'm not sure how best to transfer this 
>>>>>>>>> information to the forum for those to play with, but it is 
>>>>>>>>> included below.
>>>>>>>>
>>>>>>>> Thanks, I can reproduce the issue now. I will need to debug 
>>>>>>>> further to see what might be causing this.
>>>>>>>>
>>>>>>>> --Sean

From xuelei.fan at oracle.com  Thu Feb 14 19:38:34 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 14 Feb 2019 11:38:34 -0800
Subject: RFR [13] JDK-4919790 : Errors in alert ssl message does not
 reflect the actual certificate status
In-Reply-To: <3f17ece6-f40d-6f0c-ef23-9c3590ac01d8@oracle.com>
References: <3c720033-6206-0a49-86d7-5ee407f995a9@oracle.com>
 <3f17ece6-f40d-6f0c-ef23-9c3590ac01d8@oracle.com>
Message-ID: <973bb5b9-8cbd-281f-3606-88a2c8cd270d@oracle.com>

On 2/14/2019 10:24 AM, Sean Mullan wrote:
> On 2/11/19 2:32 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the update reviewed?
>> ??? http://cr.openjdk.java.net/~xuelei/4919790/webrev.00/
> 
> 721???????????????????? alert = Alert.UNSUPPORTED_CERTIFCATE;
> 
> Can we fix this typo while we are cleaning this up? 
> s/CERTIFCATE/CERTIFICATE/
> 
Good catch!  Here is the updated webrev:
     http://cr.openjdk.java.net/~xuelei/4919790/webrev.01/


> Also, I was a bit curious about these lines (not part of your fix):
> 
>  ?711???????????????? if (reason == BasicReason.REVOKED) {
>  ?712???????????????????? alert = chc.staplingActive ?
>  ?713???????????????????????????? Alert.BAD_CERT_STATUS_RESPONSE :
>  ?714???????????????????????????? Alert.CERTIFICATE_REVOKED;
> 
> If a certificate is revoked, why would you set the alert status to 
> BAD_CERT_STATUS_RESPONSE if stapling is enabled?
> 
See Jamil's reply.  The spec is a little bit wired to me although.

Note that the new added items are not controlled by OCSP stapling, so we 
can use the original reason.

> Also, bug needs a noreg label.
> 
Added.

Thanks,
Xuelei

> --Sean
> 
>> It had been a while that the SunJSSE provider use certificate_unknown 
>> or certificate_revoked (or bad_certificate_status_response for OCSP 
>> stapling) as the certificate issues alert.? Other certificate alert 
>> like certificate_expired are not used.
>>
>> The bug was reported in JDK 6.? With the introducing of 
>> CertPathValidatorException.BasicReason in JDK 7. Now we can handle the 
>> alert more accuracy.
>>
>> Note: please don't rely on the certificate alert type for application 
>> development.? The alert type may be changed and different per the 
>> provider preference.
>>
>> No new regression test as the update is simple and straightforward.
>>
>> Thanks,
>> Xuelei

From sean.mullan at oracle.com  Thu Feb 14 19:49:38 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 14 Feb 2019 14:49:38 -0500
Subject: RFR [13] JDK-4919790 : Errors in alert ssl message does not
 reflect the actual certificate status
In-Reply-To: <4d51eef9-c4ba-bdec-20ea-02d14a4c62fa@oracle.com>
References: <3c720033-6206-0a49-86d7-5ee407f995a9@oracle.com>
 <3f17ece6-f40d-6f0c-ef23-9c3590ac01d8@oracle.com>
 <8f5bab05-5376-0d8b-a3e5-6a8d75aab2da@oracle.com>
 <4d51eef9-c4ba-bdec-20ea-02d14a4c62fa@oracle.com>
Message-ID: <f6453708-20e3-5219-c78f-4dcdac2e2121@oracle.com>

On 2/14/19 2:20 PM, Jamil Nimeh wrote:
> Whoops, forgot to look at RFC 6961.? Over there, both revoked and 
> structural failures are both supposed to yield 
> bad_certificate_status_response alerts.? I think what we have is 
> conformant with the spec.

Ok, thanks for checking, let's leave the code as is.

--Sean

From sean.mullan at oracle.com  Thu Feb 14 19:51:00 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 14 Feb 2019 14:51:00 -0500
Subject: RFR [13] JDK-4919790 : Errors in alert ssl message does not
 reflect the actual certificate status
In-Reply-To: <973bb5b9-8cbd-281f-3606-88a2c8cd270d@oracle.com>
References: <3c720033-6206-0a49-86d7-5ee407f995a9@oracle.com>
 <3f17ece6-f40d-6f0c-ef23-9c3590ac01d8@oracle.com>
 <973bb5b9-8cbd-281f-3606-88a2c8cd270d@oracle.com>
Message-ID: <0db4154e-be7f-379f-82e1-00334e87d405@oracle.com>

On 2/14/19 2:38 PM, Xuelei Fan wrote:
> Good catch!? Here is the updated webrev:
> http://cr.openjdk.java.net/~xuelei/4919790/webrev.01/

Looks good.

--Sean

From mandy.chung at oracle.com  Thu Feb 14 20:40:20 2019
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 14 Feb 2019 12:40:20 -0800
Subject: CSR Review Request, JDK-8218932 Remove the internal package
 com.sun.net.ssl
In-Reply-To: <6071db41-91d6-6f55-ddeb-658c93a37280@oracle.com>
References: <6071db41-91d6-6f55-ddeb-658c93a37280@oracle.com>
Message-ID: <b1b2e5e4-3cbc-b230-a0ce-896b2a1da67b@oracle.com>



On 2/13/19 1:51 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the CSR reviewed:
>  ?? https://bugs.openjdk.java.net/browse/JDK-8218932
> 
> The internal package com.sun.net.ssl had been deprecated since JDK 1.4, 
> and was not exported in the java.base module since JDK 9.? Application 
> cannot use them directly now.? It should be safe to remove them in JDK 13.
> 
> If you are using the internal package for some reason, please let me 
> know the compatibility impact by the end of Feb 20, 2019.
For those who are not aware of the jdeps tool:

jdeps -jdkinternals will flag static references to JDK internal
APIs and output some suggestion if a replacement API is known
like this:

JDK Internal API                         Suggested Replacement
----------------                         ---------------------
com.sun.net.ssl.HostnameVerifier         Use javax.net.ssl @since 1.4
com.sun.net.ssl.internal.ssl.Provider    Use 
java.security.Security.getProvider(provider-name) @since 1.3

Run jdeps on your libraries to find out any use of JDK internal
APIs.

Mandy

From yozons at gmail.com  Thu Feb 14 20:53:57 2019
From: yozons at gmail.com (Open eSignForms)
Date: Thu, 14 Feb 2019 12:53:57 -0800
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <ba795b7d-6100-208e-e463-1c3894612245@oracle.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
 <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
 <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
 <32d2fff5-1be5-1201-225e-15ac60982067@gmail.com>
 <648d666c-60a4-bc09-ecd9-f993255040e2@gmail.com>
 <ba795b7d-6100-208e-e463-1c3894612245@oracle.com>
Message-ID: <cb4f5d6f-cfee-a9f6-0163-5f49147b2b55@gmail.com>

Thanks.? I sent over the latest code that I was testing on yesterday.

I changed our code to use null instead of 
"http://uri.etsi.org/01903/v1.4.1#" -- as well as removed the "xades:" 
prefixes (with or without prefixes never resolved anything for me, 
though the prefix made the XML look better than all the generated 
prefixes).? It still signs fine, but the verify fails, and it only fails 
in reference #3 which is the ETSI/XAdES element.

XmlDigitalSignature.verify(SignatureKey) SERIOUS-ERROR Failed core 
validation; SignatureValue validated: true
 ?-> Reference[0] before validate(): r.getId(): Payload_Reference_ID; 
r.getURI():
 ?-> Reference[0] validated: true
 ?-> Reference[1] before validate(): r.getId(): null; r.getURI(): 
#KeyInfo_ID
 ?-> Reference[1] validated: true
*?-> Reference[2] before validate(): r.getId(): null; r.getURI(): 
#QualifyingProperties_ID**
**?-> Reference[2] validated: false**
*?-> Reference[3] before validate(): r.getId(): null; r.getURI(): 
#OpenESignForms_Seal_ID
 ?-> Reference[3] validated: true

It's not clear why that section can generate the signature fine, but 
can't validate it.

Before removing the namespace spec on that element, it appeared fine in 
the signed XML, but fails verification:

 ??? <ds:Object>
 ??????? <xades:QualifyingProperties 
xmlns:xades="http://uri.etsi.org/01903/v1.4.1#" 
xades:Id="QualifyingProperties_ID">
 ??????????? <xades:SignedProperties>
 ??????????????? <xades:SignedSignatureProperties>
<xades:SigningTime>2019-02-14T10:46:44-08:00</xades:SigningTime>
 ??????????????? </xades:SignedSignatureProperties>
 ??????????????? <xades:SignedDataObjectProperties>
 ??????????????????? <xades:DataObjectFormat 
xades:ObjectReference="#Payload_Reference_ID">
<xades:Description>description</xades:Description>
<xades:MimeType>text/html</xades:MimeType>
 ??????????????????? </xades:DataObjectFormat>
 ??????????????? </xades:SignedDataObjectProperties>
 ??????????? </xades:SignedProperties>
 ??????????? <xades:UnsignedProperties/>
 ??????? </xades:QualifyingProperties>
 ??? </ds:Object>

With the namespace removed, it also looks normal and fine to me, but 
still fails verification:

 ??? <ds:Object>
 ??????? <QualifyingProperties Id="QualifyingProperties_ID" xmlns="">
 ??????????? <SignedProperties>
 ??????????????? <SignedSignatureProperties>
<SigningTime>2019-02-14T11:33:27-08:00</SigningTime>
 ??????????????? </SignedSignatureProperties>
 ??????????????? <SignedDataObjectProperties>
 ??????????????????? <DataObjectFormat 
ObjectReference="#Payload_Reference_ID">
<Description>description</Description>
 ??????????????????????? <MimeType>text/html</MimeType>
 ??????????????????? </DataObjectFormat>
 ??????????????? </SignedDataObjectProperties>
 ??????????? </SignedProperties>
 ??????? </QualifyingProperties>
 ??? </ds:Object>



On 2/14/19 11:29 AM, Sean Mullan wrote:
> I will need more time to look into this. In the meantime, another 
> workaround is to just specify null as the namespace to the 
> createElementNS and setAttributeNS methods. I tried this out on your 
> example and it works fine on JDK 11. This should generate signatures 
> just like you were creating before. They won't have the correct ETSI 
> namespace and may instead inherit the XML Signature namespace, but if 
> you haven't seen problems with that, then it might be ok. It's 
> typically more of an issue if you are moving signed content from one 
> document to another and an ancestor namespace can be inherited and 
> break or invalidate the signature, although exclusive C14N is designed 
> to protect against that.
>
>
> --Sean
>
> On 2/13/19 6:06 PM, Open eSignForms wrote:
>> Well, I have found that my verify routines are failing.? I added the 
>> following lines to the main() test method of your fixed code after 
>> the signature is done to attempt to validate the generated signed XML:
>>
>> ???? ??? ??? try {
>> ???? ??? ??? ??? System.err.println("Verifying signedXml...");
>> ???? ??? ??? ??? xmldsig.verify(signedXml, signatureKey);
>> ???? ??? ??? ??? System.err.println("Verified signedXml...");
>> ???? ??? ??? } catch(Exception ve) {
>> System.err.println("XmlDigitalSignature.main() signature verification 
>> exception: " + ve.getMessage());
>> ???? ??? ??? }
>>
>> This basically submits the created 'signedXml' returned just above 
>> with the same keys.? I also had to update the method "verify(String 
>> signedXml, SignatureKey signatureKey)" where it sets the ID attribute 
>> to include the namespace added in the fixed code:
>>
>> qualifyingPropertiesElement.setIdAttribute*NS("http://uri.etsi.org/01903/v1.1.1#"*,"Id", 
>> true); // mark our id as the "Id" attribute
>>
>> This then fails showing 2 out of 4 references validated, the others 
>> failing:
>>
>> XmlDigitalSignature.verify(SignatureKey) SERIOUS-ERROR Failed core 
>> validation; SignatureValue validated: true
>> ??-> Reference[0] validated: true
>> ??-> Reference[1] validated: true
>> ??-> Reference[2] validated: false
>> ??-> Reference[3] validated: false
>> XmlDigitalSignature.verify(SignatureKey) SERIOUS-ERROR exception: 
>> Invalid signature. SignatureValue validated; XML data payload 
>> validated; OpenESignForms Seal validated; Unexpected Reference[2] 
>> INVALID; Unexpected Reference[3] INVALID
>>
>> In my test code I was able to show the references subscripts 0-3 being:
>>
>> ??-> Reference[0] before validate(): *r.getId(): 
>> Payload_Reference_ID*; r.getURI():
>> ??-> Reference[0] validated: true
>>
>> ??-> Reference[1] before validate(): r.getId(): null; *r.getURI(): 
>> #KeyInfo_ID*
>> ??-> Reference[1] validated: true
>>
>> ??-> Reference[2] before validate(): r.getId(): null; *r.getURI(): 
>> #QualifyingProperties_ID*
>> ??-> Reference[2] validated: false
>>
>> ??-> Reference[3] before validate(): r.getId(): null; *r.getURI(): 
>> #OpenESignForms_Seal_ID*
>> ??-> Reference[3] validated: false
>>
>> So, the namespace changes made allow the digital signature to be 
>> applied, but now I'm stuck on how to verify these last two 
>> references.? It seems that references related to Payload_Reference_ID 
>> and #KeyInfo_ID validate, but #QualifyingProperties_ID and 
>> #OpenESignForms_Seal_ID are failing.
>>
>> I'm not sure how those references work with respect to the namespace 
>> changes you suggested.
>>
>> In fact, the fixed code no longer validates the digital signature 
>> under Java 8 once the namespaces were added.? Any ideas?
>>
>> Thanks, David
>>
>>
>> On 2/13/19 1:23 PM, Open eSignForms wrote:
>>>
>>> I checked the ETSI XAdES spec 
>>> (http://uri.etsi.org/01903/v1.1.1/ts_101903v010101p.pdf) and it 
>>> doesn't show any namespace on their entries for their 
>>> QualifyingProperties element and all sub-elements under the ETSI 
>>> example's element <ds:Object>.
>>>
>>> But, their specification does show element <QualifyingProperties> 
>>> should be under the namespace "http://uri.etsi.org/01903/v1.1.1#" as 
>>> you added in your fixed code.
>>>
>>> That is, when my snapshot element that's digitally signed using the 
>>> below, it fails with the NAMESPACE_ERR exception:
>>>
>>> <snapshot *xmlns="http://open.esignforms.com/XMLSchema/2011"* 
>>> timestamp="2019-02-13T11:02:30-08:00" type="document">
>>>
>>> But if my snapshot is set up with the ETSI namespace URI, it works:
>>>
>>> <snapshot *xmlns="**http://uri.etsi.org/01903/v1.1.1#**" * 
>>> timestamp="2019-02-13T11:02:30-08:00" type="document">
>>>
>>> So, it seems that the XMLSignature is noting that the 
>>> <QualifyingProperties> belongs to the default namespace in both 
>>> cases, but of course expects that particular element to belong to 
>>> the ETSI namespace, not ours.
>>>
>>> I presume that's correct behavior; I just didn't think that the 
>>> XMLSignature.sign() knew about and was limited to that specific 
>>> namespace.
>>>
>>> If you agree that this is the correct behavior, I think it's not 
>>> really a bug in Java 11, though it fails backwards compatibility.
>>>
>>> The only oddity that remains is what I mentioned below with all the 
>>> "&#13;" characters in the digests/signatures that appear in Java 
>>> 11.? They sure look odd compared to simple line breaks that 
>>> presumably were emitted before.
>>>
>>> David
>>>
>>>
>>>
>>> On 2/13/19 11:20 AM, Open eSignForms wrote:
>>>> Thanks, Sean.? I was able to find the updated test case source code.
>>>>
>>>> A preliminary review seems to show worthwhile changes to our code.? 
>>>> That is, the namespaces and such seem to make sense as you have them.
>>>>
>>>> In particular, the use of:
>>>>
>>>> domSignContext.putNamespacePrefix(XMLSignature.XMLNS, "dsig");
>>>>
>>>> and adding this namespace to additional elements we added:
>>>>
>>>> ??? ??? ??? String xmlns = "http://uri.etsi.org/01903/v1.1.1#";
>>>>
>>>> seem reasonable and an acceptable workaround for us.? I'm not sure 
>>>> if those were oversights from before, but likely were the result of 
>>>> it being based on Oracle/Java example code from Java 6 days...
>>>>
>>>> We'll incorporate your namespace changes in our code and test, but 
>>>> this seems like it will work as I was able to confirm that your 
>>>> fixed version seems to run on Java 10 and Java 11.
>>>>
>>>> It is interesting that the fixed code, though, generates different 
>>>> output on Java 10 and Java 11.? I'm not positive, but it seems that 
>>>> Java 11 adds '&#13;' to the end of many lines that aren't present 
>>>> in Java 10's output.
>>>>
>>>> Under Java 10, a test run products this result:
>>>>
>>>> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
>>>> timestamp="2019-02-13T11:02:30-08:00" 
>>>> type="document"><![CDATA[<html 
>>>> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy 
>>>> HTML document</p></body></html>]]><dsig:Signature 
>>>> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
>>>> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod 
>>>> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
>>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
>>>> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Zqmii2rv6C+bFM+CSO3s8sAGOrl67HEnv4t8XUgQd5iguf9m7vcVJn3pJz5inCZfx5V9lTtDaj0u 
>>>>
>>>> xbZSyWE5kQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>>>> URI="#KeyInfo_ID"><dsig:DigestMethod 
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>kZM1pJpRXoeDuolU+kyK41BotQoW7ir5lfg/nNSMoC69bUC2OHzWbQ5Kug0gtrLVIuq5HRdzk6zc
>>>> 2N2jA0WKMQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>>>> URI="#QualifyingProperties_ID"><dsig:DigestMethod 
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>AFx1CJi739IWZwJL1Y5KU2B+ZioT3ONMBLwLTdT/NTysV/+KYF7lZMgEHaGtLxvc6haIKKKzZisr
>>>> r2YDQVgs5w==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>>>> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>jhVDd7nvr4s2bu7LRNHb7yj2gQRzAE7fXcsgonq2Qsn4EWNfpqNEVUViIy9jh86tTs5ZiakaGAEs
>>>> l9YV1hNnEg==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>izJCFA5lBOjc7zhlc/1Wrsu+/jd0o0aPtemm4hM7aMKJvzkKddhjaHRY9iX4qtMZJtl7L1qj4YGN 
>>>>
>>>> hxHc2Wjuj6F1ZFD9asPf/kumVliAqTwNvhfyVfmpbaZtzQVtOQWhNIC1PivbPfbwTKr1yztLbo0K 
>>>>
>>>> B8TJWWiqHBjgEjlhw8X84buXVsCIUaAkOJG73Q0x9hMDVPf5y5R56xknLwjwzQPdveMI3zKvKvq5 
>>>>
>>>> vj1UPKVqlCjrjPa1HR0g4wEOjL51HCK/EWVbB4LLRAL59KB6ERW01CaRX1crGzQw6wz5eFVWK/0o 
>>>>
>>>> NcIdn4wc7rWPdYfT362iqqJMzIyUQGHmk7FVD/1Nky2wlEvYaRk7PrpbXo8ISSPB+RQM+EWQbYCP 
>>>>
>>>> RVT5oq6d4dnu0cUuj/wG8Ng7FIfSY3C8Ds9cw7CTKi/Dbmw3oE8yaJHNqfjEMAW2tmqQmuC4ZRXG 
>>>>
>>>> 7DfqeNdgiHwoQLdLzD/vj/00SWmcM67NWQNwblbPJ5MhVeFmh/fIbd7bkIyANbw1FAYIj1b+Hf8b 
>>>>
>>>> cZzC+lNecKxzkcY9/VZ3ny4kBBQmxwBLlojBa2ll8B9m+sYN0enRGwy9GG2eBY2Gb53KqAALQAUU 
>>>>
>>>> kjXjJYxrQh64Y2RTAgp01Nbfj7QbvuKW93YDR6cpjNTM7EfJfQM/cz+VHHngFCRr/N0/WmM4j0A=</dsig:SignatureValue><dsig:KeyInfo 
>>>> Id="KeyInfo_ID"><dsig:KeyName>c42c747f-0f03-46a3-8ae8-81fc95464c8f</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9 
>>>>
>>>> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW 
>>>>
>>>> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU 
>>>>
>>>> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX 
>>>>
>>>> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ 
>>>>
>>>> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB 
>>>>
>>>> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z 
>>>>
>>>> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n 
>>>>
>>>> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu 
>>>>
>>>> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z 
>>>>
>>>> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2 
>>>>
>>>> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh 
>>>>
>>>> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz 
>>>>
>>>> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh 
>>>>
>>>> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw 
>>>>
>>>> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ 
>>>>
>>>> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi 
>>>>
>>>> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A 
>>>>
>>>> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6 
>>>>
>>>> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/ 
>>>>
>>>> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn 
>>>>
>>>> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy 
>>>>
>>>> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW 
>>>>
>>>> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR 
>>>>
>>>> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz 
>>>>
>>>> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj 
>>>>
>>>> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC 
>>>>
>>>> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc 
>>>>
>>>> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI 
>>>>
>>>> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl 
>>>>
>>>> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o 
>>>>
>>>> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY 
>>>>
>>>> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N 
>>>>
>>>> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E 
>>>>
>>>> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg 
>>>>
>>>> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV 
>>>>
>>>> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC 
>>>>
>>>> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q 
>>>>
>>>> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX 
>>>>
>>>> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D 
>>>>
>>>> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+ 
>>>>
>>>> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx 
>>>>
>>>> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P 
>>>>
>>>> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf 
>>>>
>>>> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z 
>>>>
>>>> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0 
>>>>
>>>> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN 
>>>>
>>>> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk 
>>>>
>>>> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw 
>>>>
>>>> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz 
>>>>
>>>> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO 
>>>>
>>>> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK 
>>>>
>>>> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u 
>>>>
>>>> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/ 
>>>>
>>>> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX 
>>>>
>>>> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy 
>>>>
>>>> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
>>>> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
>>>> ns0:Id="QualifyingProperties_ID" 
>>>> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:02:30-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
>>>> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
>>>> Id="OpenESignForms_Seal_ID" 
>>>> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
>>>> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns0:DeploymentHostAddress="192.1.1.1" 
>>>> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns1:DeploymentHostName="open.esignforms.com" 
>>>> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns2:DeploymentId="1.1.1.1" 
>>>> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns3:SignerAddress="192.1.1.1" 
>>>> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns4:SignerAgent="No-Browser-Test" 
>>>> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns5:Timestamp="2019-02-13T11:02:30-08:00" 
>>>> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot>
>>>>
>>>> while when run under Java 11 it shows what seems to be the same 
>>>> (clearly, the digest/hashes aren't the same as the 'timestamp' 
>>>> differs because they are actual times) except for lots of '&#13;' 
>>>> added to the digests and signatures:
>>>>
>>>> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
>>>> timestamp="2019-02-13T11:01:22-08:00" 
>>>> type="document"><![CDATA[<html 
>>>> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy 
>>>> HTML document</p></body></html>]]><dsig:Signature 
>>>> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
>>>> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod 
>>>> Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
>>>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
>>>> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
>>>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LdB/ydGxr3VUoTshQtOvQNmMZmt2OHgLax4tSk9Lqb1c+X1h4Uc/RBVXwfI9QrVnITBz85Fi8Bwr&#13; 
>>>>
>>>> 7wyMjw84cA==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>>>> URI="#KeyInfo_ID"><dsig:DigestMethod 
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>FkpexxTwhpCPHHsMrKGnBXE5hkZ/x10ArpzjX6ltYfOilvVAubzc9sNPwo6phw//ot1rSKPU5jTB&#13;
>>>> LRD7p7t50g==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>>>> URI="#QualifyingProperties_ID"><dsig:DigestMethod 
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LxB0xAsDxKqeyCflaSUgMQOMhoxP4Gl9GfvlpCiL/gd9rz36qG4roaFRl+4PBC+IxzGiRDOqzQYX&#13;
>>>> x6gSn5d1IQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>>>> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
>>>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Pqd+9yaeBMytcG1sTTpuq+Wrd3lZSC18j7lv6VQ6LjUSz9VN7uwVNNn1E79mY8H6XUI2jbd/IozM&#13;
>>>> oba2KF46ig==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>IpdHZtzSw8TOnp0gfKMaCp30jJAPP8YCAIg4OBvRobIwHBFrG+O9v7peXRRA5nXi+fm4bdemi5jI&#13; 
>>>>
>>>> /N2smS7W6lKMMeTzrYNJEmpD/0c/SVCs0M1peZmiWZD/F6GYP6RkhZfTglk9skKsZIme3W5lHL5e&#13; 
>>>>
>>>> vTFno50J32oW0chq/jPzD42snoVQmVKS9wqqybGgRrm1W2RSWfziNo7QjXtJuR5eVuCtqpOLrGrS&#13; 
>>>>
>>>> J0aLaaNLucia/6cJyZ13mz7131Lj2Y4oJbrbpzvrDY5xDfFDK+bRRMR3DCvTLgKcZZz5zxcAKYL8&#13; 
>>>>
>>>> lG64U/tsmd/ZVn+d+fJGH03hPdvY/wMW7MTN1k/6S95PiNdx0cLeP0HLCug9zWiC7vUkrVDrsO9i&#13; 
>>>>
>>>> qsvSYKcAH8vQlG1arZgGJn88Hg8EGjmmWXs15ulU3Lm8TOTXl/xi6O4stSgMi9dFSsE1ISHAPaxN&#13; 
>>>>
>>>> D3Rqg7Bv7p/iEVn0xXq/C9AI3iwrpHbip8K81uJOsaiZgwR5D40XyYLV9FUPIacRclfT5EJKsx6k&#13; 
>>>>
>>>> jYiprWMOMjmnlJwj2vI8zG6sYLVJdQywm2isWu5eHSw39Wof0BYfDeOzh0LrifUcnt86no5fUEOI&#13; 
>>>>
>>>> OlNbqOO7rjuxtb+gt1iO2dTHfQhG99BCBQhC7AEMp67fIlPjEOECXldDTpzPMZ1K6cPlk22rpvc=</dsig:SignatureValue><dsig:KeyInfo 
>>>> Id="KeyInfo_ID"><dsig:KeyName>184a40b0-78b6-4070-a7d7-1497078a06e4</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9&#13; 
>>>>
>>>> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW&#13; 
>>>>
>>>> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU&#13; 
>>>>
>>>> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX&#13; 
>>>>
>>>> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ&#13; 
>>>>
>>>> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB&#13; 
>>>>
>>>> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z&#13; 
>>>>
>>>> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n&#13; 
>>>>
>>>> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu&#13; 
>>>>
>>>> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z&#13; 
>>>>
>>>> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2&#13; 
>>>>
>>>> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh&#13; 
>>>>
>>>> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz&#13; 
>>>>
>>>> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh&#13; 
>>>>
>>>> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw&#13; 
>>>>
>>>> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ&#13; 
>>>>
>>>> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi&#13; 
>>>>
>>>> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A&#13; 
>>>>
>>>> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6&#13; 
>>>>
>>>> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/&#13; 
>>>>
>>>> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn&#13; 
>>>>
>>>> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy&#13; 
>>>>
>>>> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW&#13; 
>>>>
>>>> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR&#13; 
>>>>
>>>> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz&#13; 
>>>>
>>>> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj&#13; 
>>>>
>>>> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC&#13; 
>>>>
>>>> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc&#13; 
>>>>
>>>> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI&#13; 
>>>>
>>>> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl&#13; 
>>>>
>>>> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o&#13; 
>>>>
>>>> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY&#13; 
>>>>
>>>> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N&#13; 
>>>>
>>>> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E&#13; 
>>>>
>>>> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg&#13; 
>>>>
>>>> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV&#13; 
>>>>
>>>> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC&#13; 
>>>>
>>>> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q&#13; 
>>>>
>>>> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX&#13; 
>>>>
>>>> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D&#13; 
>>>>
>>>> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+&#13; 
>>>>
>>>> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx&#13; 
>>>>
>>>> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P&#13; 
>>>>
>>>> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf&#13; 
>>>>
>>>> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z&#13; 
>>>>
>>>> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0&#13; 
>>>>
>>>> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN&#13; 
>>>>
>>>> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk&#13; 
>>>>
>>>> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw&#13; 
>>>>
>>>> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz&#13; 
>>>>
>>>> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO&#13; 
>>>>
>>>> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK&#13; 
>>>>
>>>> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u&#13; 
>>>>
>>>> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/&#13; 
>>>>
>>>> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX&#13; 
>>>>
>>>> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy&#13; 
>>>>
>>>> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
>>>> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
>>>> ns0:Id="QualifyingProperties_ID" 
>>>> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:01:22-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
>>>> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
>>>> Id="OpenESignForms_Seal_ID" 
>>>> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
>>>> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns0:DeploymentHostAddress="192.1.1.1" 
>>>> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns1:DeploymentHostName="open.esignforms.com" 
>>>> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns2:DeploymentId="1.1.1.1" 
>>>> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns3:SignerAddress="192.1.1.1" 
>>>> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns4:SignerAgent="No-Browser-Test" 
>>>> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns5:Timestamp="2019-02-13T11:01:22-08:00" 
>>>> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
>>>> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot>
>>>>
>>>>
>>>> It's particularly odd because hex 13 isn't a typical character (^S).
>>>>
>>>> Any idea what that difference is about for the base64 digests and 
>>>> signatures?
>>>>
>>>> David
>>>>
>>>>
>>>> On 2/13/19 6:03 AM, Sean Mullan wrote:
>>>>> On 2/12/19 6:28 PM, Open eSignForms wrote:
>>>>>> Thanks for the update, Sean.? I'm a bit perplexed because I found 
>>>>>> the original code works under Java 9 and Java 10, so it seems 
>>>>>> like the change occurred in Java 11.
>>>>>
>>>>> Sorry, that was a typo, I meant to say JDK 11.
>>>>>
>>>>>> I don't see the modified version of the test case.? If you 
>>>>>> attached it, it somehow didn't make it through to me.
>>>>>>
>>>>>> If it's just a matter of making the code more correct, we'd love 
>>>>>> to make the changes.? My concern, of course, is that we've 
>>>>>> already done millions of XML digital signatures, so we need that 
>>>>>> to continue to verify correctly (and even under Java 11, it seems 
>>>>>> that the verify code works against previously digitally signed 
>>>>>> content) even if we now start digitally signing using more 
>>>>>> update-to-date code.
>>>>>
>>>>> The verification of pre-existing signatures should continue to 
>>>>> work regardless of how this bug is addressed.
>>>>>
>>>>>> Please send over the modified test case and I'll take a look.
>>>>>
>>>>> It is attached to the bug report in the Attachments section: 
>>>>> https://bugs.openjdk.java.net/browse/JDK-8218629 (make sure you 
>>>>> download the one I added yesterday).
>>>>>
>>>>> --Sean
>>>>>
>>>>>>
>>>>>> Thanks!
>>>>>> David
>>>>>>
>>>>>> On 2/12/19 2:14 PM, Sean Mullan wrote:
>>>>>>> The bug is now at https://bugs.openjdk.java.net/browse/JDK-8218629
>>>>>>>
>>>>>>> I have started looking at this issue and have some progress I 
>>>>>>> can report.
>>>>>>>
>>>>>>> In JDK 9, we updated the version of the Apache XML Signature 
>>>>>>> implementation in the JDK. Some of the marshalling code was 
>>>>>>> rewritten such that it will throw Exceptions if legacy DOM level 
>>>>>>> 1 methods were used to create XML content which is then passed 
>>>>>>> into XMLObject and similar XMLSignature types that take 
>>>>>>> DOMStructure objects. This is because the DOM level 1 methods do 
>>>>>>> not support namespaces.
>>>>>>>
>>>>>>> I am still evaluating what the best fix is. However, you can 
>>>>>>> workaround the issue by always using DOM level 3 methods which 
>>>>>>> are namespace aware. For example, use Document.createElementNS 
>>>>>>> instead of Document.createElement and Element.createAttributeNS 
>>>>>>> instead of Element.createAttribute.
>>>>>>>
>>>>>>> Using legacy or non-namespace aware XML parsers or 
>>>>>>> implementations is not recommended and the XML Signature Best 
>>>>>>> Practices document gives some rationale: 
>>>>>>> https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces 
>>>>>>>
>>>>>>> That said, this is a regression in behavior so it would be best 
>>>>>>> if we could restore the previous behavior.
>>>>>>>
>>>>>>> I have attached a modified version of the test case to the bug 
>>>>>>> report which no longer throws an Exception. Let me know if this 
>>>>>>> is an acceptable workaround. Double-check the namespaces that I 
>>>>>>> used to make sure they are correct.
>>>>>>>
>>>>>>> --Sean
>>>>>>>
>>>>>>>
>>>>>>> On 2/7/19 11:23 AM, Open eSignForms wrote:
>>>>>>>
>>>>>>>> On 2/7/19 7:49 AM, Sean Mullan wrote:
>>>>>>>>> On 2/6/19 4:51 PM, Open eSignForms wrote:
>>>>>>>>>> I have a test version of the code that can run standalone and 
>>>>>>>>>> shows the bug.? I'm not sure how best to transfer this 
>>>>>>>>>> information to the forum for those to play with, but it is 
>>>>>>>>>> included below.
>>>>>>>>>
>>>>>>>>> Thanks, I can reproduce the issue now. I will need to debug 
>>>>>>>>> further to see what might be causing this.
>>>>>>>>>
>>>>>>>>> --Sean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190214/1e45ded8/attachment-0001.html>

From huizhe.wang at oracle.com  Thu Feb 14 22:54:53 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 14 Feb 2019 14:54:53 -0800
Subject: XML Digital Signature throws NAMESPACE_ERR exception under OpenJDK
 11 that works under Java SE 8, 9 and 10
In-Reply-To: <74045499-137b-87c4-ab59-8edb4801aa4b@oracle.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
 <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
 <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
 <74045499-137b-87c4-ab59-8edb4801aa4b@oracle.com>
Message-ID: <5C65F1BD.5060002@oracle.com>



On 2/14/19, 11:08 AM, Sean Mullan wrote:
> On 2/13/19 2:20 PM, Open eSignForms wrote:
>> Thanks, Sean.  I was able to find the updated test case source code.
>>
>> A preliminary review seems to show worthwhile changes to our code.  
>> That is, the namespaces and such seem to make sense as you have them.
>>
>> In particular, the use of:
>>
>> domSignContext.putNamespacePrefix(XMLSignature.XMLNS, "dsig");
>>
>> and adding this namespace to additional elements we added:
>>
>>              String xmlns = "http://uri.etsi.org/01903/v1.1.1#";
>>
>> seem reasonable and an acceptable workaround for us.  I'm not sure if 
>> those were oversights from before, but likely were the result of it 
>> being based on Oracle/Java example code from Java 6 days...
>>
>> We'll incorporate your namespace changes in our code and test, but 
>> this seems like it will work as I was able to confirm that your fixed 
>> version seems to run on Java 10 and Java 11.
>>
>> It is interesting that the fixed code, though, generates different 
>> output on Java 10 and Java 11.  I'm not positive, but it seems that 
>> Java 11 adds '&#13;' to the end of many lines that aren't present in 
>> Java 10's output.
>
> This is the ASCII code for a carriage return, encoded in XML. I don't 
> know why that behavior is different in JDK 11. This would be a 
> question for the XML developers. I have copied Joe Wang, to see if he 
> might know.

Hi Sean,

There hasn't been functional change to that area between JDK 10 and 11 
that I'm aware of. If you believe there's a behavior change, or you 
could isolate the issue down to the java.xml/xml processor, please file 
a bug.  I'll be happy to investigate.

Thanks,
Joe
>
> --Sean
>
>>
>> Under Java 10, a test run products this result:
>>
>> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
>> timestamp="2019-02-13T11:02:30-08:00" type="document"><![CDATA[<html 
>> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
>> document</p></body></html>]]><dsig:Signature 
>> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
>> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
>> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Zqmii2rv6C+bFM+CSO3s8sAGOrl67HEnv4t8XUgQd5iguf9m7vcVJn3pJz5inCZfx5V9lTtDaj0u 
>>
>> xbZSyWE5kQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>> URI="#KeyInfo_ID"><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>kZM1pJpRXoeDuolU+kyK41BotQoW7ir5lfg/nNSMoC69bUC2OHzWbQ5Kug0gtrLVIuq5HRdzk6zc 
>>
>> 2N2jA0WKMQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>> URI="#QualifyingProperties_ID"><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>AFx1CJi739IWZwJL1Y5KU2B+ZioT3ONMBLwLTdT/NTysV/+KYF7lZMgEHaGtLxvc6haIKKKzZisr 
>>
>> r2YDQVgs5w==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>jhVDd7nvr4s2bu7LRNHb7yj2gQRzAE7fXcsgonq2Qsn4EWNfpqNEVUViIy9jh86tTs5ZiakaGAEs 
>>
>> l9YV1hNnEg==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>izJCFA5lBOjc7zhlc/1Wrsu+/jd0o0aPtemm4hM7aMKJvzkKddhjaHRY9iX4qtMZJtl7L1qj4YGN 
>>
>> hxHc2Wjuj6F1ZFD9asPf/kumVliAqTwNvhfyVfmpbaZtzQVtOQWhNIC1PivbPfbwTKr1yztLbo0K 
>>
>> B8TJWWiqHBjgEjlhw8X84buXVsCIUaAkOJG73Q0x9hMDVPf5y5R56xknLwjwzQPdveMI3zKvKvq5 
>>
>> vj1UPKVqlCjrjPa1HR0g4wEOjL51HCK/EWVbB4LLRAL59KB6ERW01CaRX1crGzQw6wz5eFVWK/0o 
>>
>> NcIdn4wc7rWPdYfT362iqqJMzIyUQGHmk7FVD/1Nky2wlEvYaRk7PrpbXo8ISSPB+RQM+EWQbYCP 
>>
>> RVT5oq6d4dnu0cUuj/wG8Ng7FIfSY3C8Ds9cw7CTKi/Dbmw3oE8yaJHNqfjEMAW2tmqQmuC4ZRXG 
>>
>> 7DfqeNdgiHwoQLdLzD/vj/00SWmcM67NWQNwblbPJ5MhVeFmh/fIbd7bkIyANbw1FAYIj1b+Hf8b 
>>
>> cZzC+lNecKxzkcY9/VZ3ny4kBBQmxwBLlojBa2ll8B9m+sYN0enRGwy9GG2eBY2Gb53KqAALQAUU 
>>
>> kjXjJYxrQh64Y2RTAgp01Nbfj7QbvuKW93YDR6cpjNTM7EfJfQM/cz+VHHngFCRr/N0/WmM4j0A=</dsig:SignatureValue><dsig:KeyInfo 
>> Id="KeyInfo_ID"><dsig:KeyName>c42c747f-0f03-46a3-8ae8-81fc95464c8f</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9 
>>
>> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW 
>>
>> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU 
>>
>> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX 
>>
>> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ 
>>
>> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB 
>>
>> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z 
>>
>> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n 
>>
>> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu 
>>
>> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z 
>>
>> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2 
>>
>> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh 
>>
>> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz 
>>
>> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh 
>>
>> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw 
>>
>> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ 
>>
>> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi 
>>
>> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A 
>>
>> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6 
>>
>> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/ 
>>
>> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn 
>>
>> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy 
>>
>> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW 
>>
>> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR 
>>
>> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz 
>>
>> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj 
>>
>> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC 
>>
>> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc 
>>
>> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI 
>>
>> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl 
>>
>> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o 
>>
>> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY 
>>
>> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N 
>>
>> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E 
>>
>> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg 
>>
>> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV 
>>
>> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC 
>>
>> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q 
>>
>> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX 
>>
>> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D 
>>
>> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+ 
>>
>> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx 
>>
>> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P 
>>
>> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf 
>>
>> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z 
>>
>> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0 
>>
>> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN 
>>
>> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk 
>>
>> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw 
>>
>> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz 
>>
>> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO 
>>
>> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK 
>>
>> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u 
>>
>> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/ 
>>
>> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX 
>>
>> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy 
>>
>> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
>> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
>> ns0:Id="QualifyingProperties_ID" 
>> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:02:30-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
>> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
>> Id="OpenESignForms_Seal_ID" 
>> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
>> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
>> ns0:DeploymentHostAddress="192.1.1.1" 
>> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
>> ns1:DeploymentHostName="open.esignforms.com" 
>> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
>> ns2:DeploymentId="1.1.1.1" 
>> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
>> ns3:SignerAddress="192.1.1.1" 
>> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
>> ns4:SignerAgent="No-Browser-Test" 
>> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
>> ns5:Timestamp="2019-02-13T11:02:30-08:00" 
>> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
>> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot> 
>>
>>
>> while when run under Java 11 it shows what seems to be the same 
>> (clearly, the digest/hashes aren't the same as the 'timestamp' 
>> differs because they are actual times) except for lots of '&#13;' 
>> added to the digests and signatures:
>>
>> <snapshot xmlns="http://open.esignforms.com/XMLSchema/2011" 
>> timestamp="2019-02-13T11:01:22-08:00" type="document"><![CDATA[<html 
>> xmlns="http://www.w3.org/1999/xhtml"><head></head><body><p>Dummy HTML 
>> document</p></body></html>]]><dsig:Signature 
>> xmlns:dsig="http://www.w3.org/2000/09/xmldsig#" 
>> Id="OpenESignForms_Seal"><dsig:SignedInfo><dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11#WithComments"/><dsig:SignatureMethod 
>> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512"/><dsig:Reference 
>> Id="Payload_Reference_ID" URI=""><dsig:Transforms><dsig:Transform 
>> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></dsig:Transforms><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LdB/ydGxr3VUoTshQtOvQNmMZmt2OHgLax4tSk9Lqb1c+X1h4Uc/RBVXwfI9QrVnITBz85Fi8Bwr&#13; 
>>
>> 7wyMjw84cA==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>> URI="#KeyInfo_ID"><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>FkpexxTwhpCPHHsMrKGnBXE5hkZ/x10ArpzjX6ltYfOilvVAubzc9sNPwo6phw//ot1rSKPU5jTB&#13; 
>>
>> LRD7p7t50g==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>> URI="#QualifyingProperties_ID"><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>LxB0xAsDxKqeyCflaSUgMQOMhoxP4Gl9GfvlpCiL/gd9rz36qG4roaFRl+4PBC+IxzGiRDOqzQYX&#13; 
>>
>> x6gSn5d1IQ==</dsig:DigestValue></dsig:Reference><dsig:Reference 
>> URI="#OpenESignForms_Seal_ID"><dsig:DigestMethod 
>> Algorithm="http://www.w3.org/2001/04/xmlenc#sha512"/><dsig:DigestValue>Pqd+9yaeBMytcG1sTTpuq+Wrd3lZSC18j7lv6VQ6LjUSz9VN7uwVNNn1E79mY8H6XUI2jbd/IozM&#13; 
>>
>> oba2KF46ig==</dsig:DigestValue></dsig:Reference></dsig:SignedInfo><dsig:SignatureValue>IpdHZtzSw8TOnp0gfKMaCp30jJAPP8YCAIg4OBvRobIwHBFrG+O9v7peXRRA5nXi+fm4bdemi5jI&#13; 
>>
>> /N2smS7W6lKMMeTzrYNJEmpD/0c/SVCs0M1peZmiWZD/F6GYP6RkhZfTglk9skKsZIme3W5lHL5e&#13; 
>>
>> vTFno50J32oW0chq/jPzD42snoVQmVKS9wqqybGgRrm1W2RSWfziNo7QjXtJuR5eVuCtqpOLrGrS&#13; 
>>
>> J0aLaaNLucia/6cJyZ13mz7131Lj2Y4oJbrbpzvrDY5xDfFDK+bRRMR3DCvTLgKcZZz5zxcAKYL8&#13; 
>>
>> lG64U/tsmd/ZVn+d+fJGH03hPdvY/wMW7MTN1k/6S95PiNdx0cLeP0HLCug9zWiC7vUkrVDrsO9i&#13; 
>>
>> qsvSYKcAH8vQlG1arZgGJn88Hg8EGjmmWXs15ulU3Lm8TOTXl/xi6O4stSgMi9dFSsE1ISHAPaxN&#13; 
>>
>> D3Rqg7Bv7p/iEVn0xXq/C9AI3iwrpHbip8K81uJOsaiZgwR5D40XyYLV9FUPIacRclfT5EJKsx6k&#13; 
>>
>> jYiprWMOMjmnlJwj2vI8zG6sYLVJdQywm2isWu5eHSw39Wof0BYfDeOzh0LrifUcnt86no5fUEOI&#13; 
>>
>> OlNbqOO7rjuxtb+gt1iO2dTHfQhG99BCBQhC7AEMp67fIlPjEOECXldDTpzPMZ1K6cPlk22rpvc=</dsig:SignatureValue><dsig:KeyInfo 
>> Id="KeyInfo_ID"><dsig:KeyName>184a40b0-78b6-4070-a7d7-1497078a06e4</dsig:KeyName><dsig:KeyValue><dsig:RSAKeyValue><dsig:Modulus>kPCr+Fy0NInaICpnzDpGLkNQ93kd0NzZfTBfQOb3PUH1Bt4OrBWcvYoch7wUm6k1Il3apsi7s2B9&#13; 
>>
>> Geqbh7tzF41MwvTWBNCQg3Kw3FKcF0jzKZ7D+na8Ndc52YPmsjU9zjpf+SDfKqb0NIDe3Bo3csWW&#13; 
>>
>> I42CkF3sI9AFknogovrfRM7ITJatA6WRHU8Kv6Qee8VfXZ1XAdKzWcc9EWbj74Kagiz8bMeATujU&#13; 
>>
>> MCI/XQb1luwvlrVxZUtnfLL9WD6Nvmj3uDYK52z5E80vqTKIq7EJvmlR7kcEdH1NuxDQSWCJQgQX&#13; 
>>
>> oU2TzuB0Nmov7P/pZ40JPF72Knb18Rgu4aRSMiaKKw+jzFHpw75VlQn2YkdfjNMwfUaEaZ4wuHoJ&#13; 
>>
>> Qjud79jilbam++eUQFRxjcXK9Nl/z01KtmuV1mPhm97LRaKQlsbBxa56pncrkAmF0cuIipPzo9aB&#13; 
>>
>> snJZkUQuwQtD/moDkUm84v5SOU1hn4RpWdGAkaJ1ubIrnKfF0qKmbCOcO69SEL5zP0JXEgSZ+D6z&#13; 
>>
>> Vv7VkAJizdJ91KKs4y/ypel4lurNcyBd3hzw8xpz9joMl8DOTLCcLhGp350Vrccbh9vauAcRcK/n&#13; 
>>
>> C+yaPI/mghmN2D2yZ3LZ3Z6k78Jl9BUV7PL5YyuxQmZjVP07lJvi6glLUm23o+c3c4D7rgHL4gM=</dsig:Modulus><dsig:Exponent>AQAB</dsig:Exponent></dsig:RSAKeyValue></dsig:KeyValue><dsig:X509Data><dsig:X509Certificate>MIIKvTCCCKWgAwIBAgIJAPaU10x5GhRQMA0GCSqGSIb3DQEBDQUAMIHYMU0wSwYDVQQDDERPcGVu&#13; 
>>
>> X2VTaWduRm9ybXNfaHR0cHM6Ly9sb2NhbGhvc3QubG9jYWxkb21haW4vb3Blbi1lU2lnbkZvcm1z&#13; 
>>
>> VmFhZGluNzE6MDgGA1UECgwxRGVwbG95bWVudElEL2FhMGUyYjllLWM5ZDItNDk0NS04ZWVmLWI2&#13; 
>>
>> NDhiZDYzYWFjNDE8MDoGA1UECwwzU2lnbmF0dXJlS2V5SUQvMDJkYmMwMDktMTAyYi00ZWE3LTlh&#13; 
>>
>> YzgtNzYwZThiMzY4NTlmMQ0wCwYDVQQGEwRudWxsMB4XDTE0MTIxNjAzMjc1NVoXDTI0MTIxNjAz&#13; 
>>
>> Mjc1NVowgdgxTTBLBgNVBAMMRE9wZW5fZVNpZ25Gb3Jtc19odHRwczovL2xvY2FsaG9zdC5sb2Nh&#13; 
>>
>> bGRvbWFpbi9vcGVuLWVTaWduRm9ybXNWYWFkaW43MTowOAYDVQQKDDFEZXBsb3ltZW50SUQvYWEw&#13; 
>>
>> ZTJiOWUtYzlkMi00OTQ1LThlZWYtYjY0OGJkNjNhYWM0MTwwOgYDVQQLDDNTaWduYXR1cmVLZXlJ&#13; 
>>
>> RC8wMmRiYzAwOS0xMDJiLTRlYTctOWFjOC03NjBlOGIzNjg1OWYxDTALBgNVBAYTBG51bGwwggIi&#13; 
>>
>> MA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q3Nl9MF9A&#13; 
>>
>> 5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwXSPMpnsP6&#13; 
>>
>> drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0DpZEdTwq/&#13; 
>>
>> pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+aPe4Ngrn&#13; 
>>
>> bPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXxGC7hpFIy&#13; 
>>
>> JoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/PTUq2a5XW&#13; 
>>
>> Y+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGfhGlZ0YCR&#13; 
>>
>> onW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1zIF3eHPDz&#13; 
>>
>> GnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0FRXs8vlj&#13; 
>>
>> K7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABo4IEhjCCBIIwggIzBgNVHQ4EggIqBIIC&#13; 
>>
>> JjCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBAJDwq/hctDSJ2iAqZ8w6Ri5DUPd5HdDc&#13; 
>>
>> 2X0wX0Dm9z1B9QbeDqwVnL2KHIe8FJupNSJd2qbIu7NgfRnqm4e7cxeNTML01gTQkINysNxSnBdI&#13; 
>>
>> 8ymew/p2vDXXOdmD5rI1Pc46X/kg3yqm9DSA3twaN3LFliONgpBd7CPQBZJ6IKL630TOyEyWrQOl&#13; 
>>
>> kR1PCr+kHnvFX12dVwHSs1nHPRFm4++CmoIs/GzHgE7o1DAiP10G9ZbsL5a1cWVLZ3yy/Vg+jb5o&#13; 
>>
>> 97g2Cuds+RPNL6kyiKuxCb5pUe5HBHR9TbsQ0ElgiUIEF6FNk87gdDZqL+z/6WeNCTxe9ip29fEY&#13; 
>>
>> LuGkUjImiisPo8xR6cO+VZUJ9mJHX4zTMH1GhGmeMLh6CUI7ne/Y4pW2pvvnlEBUcY3FyvTZf89N&#13; 
>>
>> SrZrldZj4Zvey0WikJbGwcWueqZ3K5AJhdHLiIqT86PWgbJyWZFELsELQ/5qA5FJvOL+UjlNYZ+E&#13; 
>>
>> aVnRgJGidbmyK5ynxdKipmwjnDuvUhC+cz9CVxIEmfg+s1b+1ZACYs3SfdSirOMv8qXpeJbqzXMg&#13; 
>>
>> Xd4c8PMac/Y6DJfAzkywnC4Rqd+dFa3HG4fb2rgHEXCv5wvsmjyP5oIZjdg9smdy2d2epO/CZfQV&#13; 
>>
>> Fezy+WMrsUJmY1T9O5Sb4uoJS1Jtt6PnN3OA+64By+IDAgMBAAEwggI3BgNVHSMEggIuMIICKoCC&#13; 
>>
>> AiYwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCQ8Kv4XLQ0idogKmfMOkYuQ1D3eR3Q&#13; 
>>
>> 3Nl9MF9A5vc9QfUG3g6sFZy9ihyHvBSbqTUiXdqmyLuzYH0Z6puHu3MXjUzC9NYE0JCDcrDcUpwX&#13; 
>>
>> SPMpnsP6drw11znZg+ayNT3OOl/5IN8qpvQ0gN7cGjdyxZYjjYKQXewj0AWSeiCi+t9EzshMlq0D&#13; 
>>
>> pZEdTwq/pB57xV9dnVcB0rNZxz0RZuPvgpqCLPxsx4BO6NQwIj9dBvWW7C+WtXFlS2d8sv1YPo2+&#13; 
>>
>> aPe4NgrnbPkTzS+pMoirsQm+aVHuRwR0fU27ENBJYIlCBBehTZPO4HQ2ai/s/+lnjQk8XvYqdvXx&#13; 
>>
>> GC7hpFIyJoorD6PMUenDvlWVCfZiR1+M0zB9RoRpnjC4eglCO53v2OKVtqb755RAVHGNxcr02X/P&#13; 
>>
>> TUq2a5XWY+Gb3stFopCWxsHFrnqmdyuQCYXRy4iKk/Oj1oGyclmRRC7BC0P+agORSbzi/lI5TWGf&#13; 
>>
>> hGlZ0YCRonW5siucp8XSoqZsI5w7r1IQvnM/QlcSBJn4PrNW/tWQAmLN0n3UoqzjL/Kl6XiW6s1z&#13; 
>>
>> IF3eHPDzGnP2OgyXwM5MsJwuEanfnRWtxxuH29q4BxFwr+cL7Jo8j+aCGY3YPbJnctndnqTvwmX0&#13; 
>>
>> FRXs8vljK7FCZmNU/TuUm+LqCUtSbbej5zdzgPuuAcviAwIDAQABMA4GA1UdDwEB/wQEAwIGwDAN&#13; 
>>
>> BgkqhkiG9w0BAQ0FAAOCAgEAOu3Y4o7P4wel6zcwGIHfwuTuL/IX9qzYnxtPNkEHL8D8v3P4Tovk&#13; 
>>
>> zDHOou4Ai5yycZninbaoK2WJr80p2HNfISY51fCJZ+Z16xmBlPmunnLI23cTAJGnZlI6WtsZLXQw&#13; 
>>
>> LX91VkqKlRL73+MZECxO0m5I4hxNu8CeOIcQ7aCLvnkO8AEeCa9zAwmiL2tJ8coJvELvqS9Zaiaz&#13; 
>>
>> syix8IWETtrZ+vv+85rASl5PSkCb0AX3eipJoqRgGazWraV7NBwDZgPEYXNQq1/jbQoirjJIzNQO&#13; 
>>
>> KEgH3wViGFVwnW4YJ4dzbtVd6EVaHZGmYb666FpwNPz6OBLgX1sjvDTMTYGYo/VrIN02neYEvBtK&#13; 
>>
>> GrZ5Gw7l7BOyKe92F3iQ3q90/kOBmGnEn8agkKlynv5IlJR8xOCxG1U9e8GFfmAwFS5hYtf0Gh/u&#13; 
>>
>> FRqnOepWQKuZ3kBBR+6KttbE58aD2kVuB36et5Dij1nxr+ihL7e4V42KsQQn/VBDrMoU5xW+yZH/&#13; 
>>
>> aAEgpbfUm5detK5oFqs5JIILFiyUXQCrvYuNZFx4vDqrsDmmAaaAPBlcybCUXseqh4hThyrOJ0dX&#13; 
>>
>> 3xaXcwd32t1+/aOa7jgJRTgSklxhhcRCMHI9HWNlLgUWmvZ2O5G70reY4Kyg1NAS56qX48Xbckvy&#13; 
>>
>> VMfem/JPPYT/veThnefIgQk=</dsig:X509Certificate></dsig:X509Data></dsig:KeyInfo><dsig:Object><QualifyingProperties 
>> xmlns:ns0="http://uri.etsi.org/01903/v1.1.1#" 
>> ns0:Id="QualifyingProperties_ID" 
>> xmlns="http://uri.etsi.org/01903/v1.1.1#"><SignedProperties><SignedSignatureProperties><SigningTime>2019-02-13T11:01:22-08:00</SigningTime></SignedSignatureProperties><SignedDataObjectProperties><DataObjectFormat 
>> ns0:ObjectReference="#Payload_Reference_ID"><Description>description</Description><MimeType>text/html</MimeType></DataObjectFormat></SignedDataObjectProperties></SignedProperties></QualifyingProperties></dsig:Object><dsig:Object><dsig:SignatureProperties><dsig:SignatureProperty 
>> Id="OpenESignForms_Seal_ID" 
>> Target="#OpenESignForms_Seal"><OpenESignForms_XmlDigitalSignatureSeal 
>> xmlns:ns0="http://open.esignforms.com/XMLSchema/2011" 
>> ns0:DeploymentHostAddress="192.1.1.1" 
>> xmlns:ns1="http://open.esignforms.com/XMLSchema/2011" 
>> ns1:DeploymentHostName="open.esignforms.com" 
>> xmlns:ns2="http://open.esignforms.com/XMLSchema/2011" 
>> ns2:DeploymentId="1.1.1.1" 
>> xmlns:ns3="http://open.esignforms.com/XMLSchema/2011" 
>> ns3:SignerAddress="192.1.1.1" 
>> xmlns:ns4="http://open.esignforms.com/XMLSchema/2011" 
>> ns4:SignerAgent="No-Browser-Test" 
>> xmlns:ns5="http://open.esignforms.com/XMLSchema/2011" 
>> ns5:Timestamp="2019-02-13T11:01:22-08:00" 
>> xmlns:ns6="http://open.esignforms.com/XMLSchema/2011" 
>> ns6:Version="19.1.19"/></dsig:SignatureProperty></dsig:SignatureProperties></dsig:Object></dsig:Signature></snapshot> 
>>
>>
>>
>> It's particularly odd because hex 13 isn't a typical character (^S).
>>
>> Any idea what that difference is about for the base64 digests and 
>> signatures?
>>
>> David
>>
>>
>> On 2/13/19 6:03 AM, Sean Mullan wrote:
>>> On 2/12/19 6:28 PM, Open eSignForms wrote:
>>>> Thanks for the update, Sean.  I'm a bit perplexed because I found 
>>>> the original code works under Java 9 and Java 10, so it seems like 
>>>> the change occurred in Java 11.
>>>
>>> Sorry, that was a typo, I meant to say JDK 11.
>>>
>>>> I don't see the modified version of the test case.  If you attached 
>>>> it, it somehow didn't make it through to me.
>>>>
>>>> If it's just a matter of making the code more correct, we'd love to 
>>>> make the changes.  My concern, of course, is that we've already 
>>>> done millions of XML digital signatures, so we need that to 
>>>> continue to verify correctly (and even under Java 11, it seems that 
>>>> the verify code works against previously digitally signed content) 
>>>> even if we now start digitally signing using more update-to-date code.
>>>
>>> The verification of pre-existing signatures should continue to work 
>>> regardless of how this bug is addressed.
>>>
>>>> Please send over the modified test case and I'll take a look.
>>>
>>> It is attached to the bug report in the Attachments section: 
>>> https://bugs.openjdk.java.net/browse/JDK-8218629 (make sure you 
>>> download the one I added yesterday).
>>>
>>> --Sean
>>>
>>>>
>>>> Thanks!
>>>> David
>>>>
>>>> On 2/12/19 2:14 PM, Sean Mullan wrote:
>>>>> The bug is now at https://bugs.openjdk.java.net/browse/JDK-8218629
>>>>>
>>>>> I have started looking at this issue and have some progress I can 
>>>>> report.
>>>>>
>>>>> In JDK 9, we updated the version of the Apache XML Signature 
>>>>> implementation in the JDK. Some of the marshalling code was 
>>>>> rewritten such that it will throw Exceptions if legacy DOM level 1 
>>>>> methods were used to create XML content which is then passed into 
>>>>> XMLObject and similar XMLSignature types that take DOMStructure 
>>>>> objects. This is because the DOM level 1 methods do not support 
>>>>> namespaces.
>>>>>
>>>>> I am still evaluating what the best fix is. However, you can 
>>>>> workaround the issue by always using DOM level 3 methods which are 
>>>>> namespace aware. For example, use Document.createElementNS instead 
>>>>> of Document.createElement and Element.createAttributeNS instead of 
>>>>> Element.createAttribute.
>>>>>
>>>>> Using legacy or non-namespace aware XML parsers or implementations 
>>>>> is not recommended and the XML Signature Best Practices document 
>>>>> gives some rationale: 
>>>>> https://www.w3.org/TR/xmldsig-bestpractices/#signing-xml-without-namespaces 
>>>>>
>>>>> That said, this is a regression in behavior so it would be best if 
>>>>> we could restore the previous behavior.
>>>>>
>>>>> I have attached a modified version of the test case to the bug 
>>>>> report which no longer throws an Exception. Let me know if this is 
>>>>> an acceptable workaround. Double-check the namespaces that I used 
>>>>> to make sure they are correct.
>>>>>
>>>>> --Sean
>>>>>
>>>>>
>>>>> On 2/7/19 11:23 AM, Open eSignForms wrote:
>>>>>
>>>>>> On 2/7/19 7:49 AM, Sean Mullan wrote:
>>>>>>> On 2/6/19 4:51 PM, Open eSignForms wrote:
>>>>>>>> I have a test version of the code that can run standalone and 
>>>>>>>> shows the bug.  I'm not sure how best to transfer this 
>>>>>>>> information to the forum for those to play with, but it is 
>>>>>>>> included below.
>>>>>>>
>>>>>>> Thanks, I can reproduce the issue now. I will need to debug 
>>>>>>> further to see what might be causing this.
>>>>>>>
>>>>>>> --Sean

From andimullaraj at gmail.com  Fri Feb 15 08:33:57 2019
From: andimullaraj at gmail.com (Andi Mullaraj)
Date: Fri, 15 Feb 2019 00:33:57 -0800
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
Message-ID: <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>

Hi Dean,

Thanks for sharing your experience. I took a look at your links and the
model and implementation seems quite distant from the classic
Selector/SelectableChannel though. You seem to allocate a thread per each
Selector (which I agree is too much of a cost to pay), then fire actively
[listener.selectorFired()] from that thread towards a SelectorListener ...

We can come back to implementation details later, but first I would like to
ask: any reason we cannot have an SSLSelector which extends the
java.nio.channels.Selector, an SSLSocketChannel extending a
java.nio.channels.SocketChannel, and so on? I believe we can, and in this
doc https://github.com/rouplex/rouplex-niossl/blob/master/README.md I have
provided the set of base classes that do just that. Since this is a dev
group I am sharing a code snippet from the doc:

As an example, an existing application which is using SocketChannel with a
Selector for their communications, would be turned into a secure one, by
simply replacing:

Selector selector = Selector.open();
SocketChannel socketChannel = SocketChannel.open();
socketChannel.register(selector, SelectionKey.OP_READ);

while(true) {
    selector.select();
    for (SocketChannel sc : selector.selectedKeys() {
        sc.read(...)
    }
}

with:

Selector selector = SSLSelector.open(); // notice the SSL
SocketChannel socketChannel = SSLSocketChannel.open();  // notice the SSL
socketChannel.register(selector, SelectionKey.OP_READ);

while(true) {
    selector.select();
    for (SocketChannel sc : selector.selectedKeys() {
        sc.read(...)
    }
}

How much cooler and easier than that can it get redressing your existing
service using (performant) plain communications with (performant) secure
ones? Or create a new (and secure) one using the exact knowledge you
already have and never having to think SSLEngine again?

As I have already mentioned I have worked on such implementation but would
like to first discuss with the group the merits and possible
problems/shortcomings of adopting the inheritance model from the plain
counterparts.

Thanks in advance,
--Andi


On Wed, Feb 13, 2019 at 8:22 AM Dean Hiller <dhiller at twitter.com> wrote:

> I would highly suggest implementing your own for a much better
> understanding.
>
> I did implement something like what you want and in so doing realized I
> like their decision.  ie. See the heirarchy here
>
> https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/webpieces/nio/api/channels
>
> The TCPChannel could be SSL or not SSL as there are two implementations.
>
> If you do want an implementation that does what you want though, this
> library does exactly that
>
> https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2
>
> which is used in the webpieces webserver
> https://github.com/deanhiller/webpieces
>
> That nio library is standalone even though it is in the webpieces repo.  I
> mean, every component in webpieces is another stand-alone piece.
>
> The downside is the library owns a thread which typical java libraries
> avoid.  ie. it has to have a thread to poll the selector and read from all
> the sockets to be fed to the thread pools, etc.  I think that is the main
> reason they decided not to have this type of library.  They prefer not to
> be running threads(which I agree, the jdk shouldn't).
>
> later,
> Dean
>
>
>
>
> On Tue, Feb 12, 2019 at 7:54 PM Sean Mullan <sean.mullan at oracle.com>
> wrote:
>
>> Hi Andi,
>>
>> TLS/JSSE topics are best discussed on the security-dev alias, so I am
>> copying that list for more discussion and -bcc-ing core-libs-dev.
>>
>> --Sean
>>
>> On 2/11/19 3:29 PM, Andi Mullaraj wrote:
>> > Hi java-core community,
>> >
>> > I have been directed to this channel to discuss matters related to Java
>> > performant ssl communications.  Maybe this is a topic that has been
>> > discussed in the past, in which case I would appreciate if someone
>> pointed
>> > me to that particular topic.
>> >
>> > Back in 2002 I personally applauded the java.nio.channels (jdk1.4)
>> package,
>> > realizing that there was no way to port this to the secure
>> communications,
>> > due to lack of a comparable implementation for SSL.  But I thought it
>> was
>> > going to just be matter of time.  A couple of years ago I had to go back
>> > search for it, and was kind of surprised to find the following in
>> >
>> http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG
>> > :
>> >
>> > --- begin quote ---
>> > Newcomers to the API may wonder "Why not just have an SSLSocketChannel
>> > which extends java.nio.channels.SocketChannel?" There are two main
>> reasons:
>> >
>> > 1. There were a lot of very difficult questions about what a
>> > SSLSocketChannel should be, including its class hierarchy and how it
>> should
>> > interoperate with Selectors and other types of SocketChannels. Each
>> > proposal brought up more questions than answers. It was noted that any
>> new
>> > API abstraction extended to work with SSL/TLS would require the same
>> > significant analysis and could result in large and complex APIs.
>> > 2. Any JSSE implementation of a new API would be free to choose the
>> "best"
>> > I/O & compute strategy, but hiding any of these details is inappropriate
>> > for those applications needing full control. Any specific implementation
>> > would be inappropriate for some application segment.
>> > --- end quote ---
>> >
>> > It has been a while since this was stated, and I would really like to
>> > revisit it.  I personally believe that the question #1 has a quite
>> natural
>> > answer, while #2 should not really be a concern if we adhere to the spi
>> > model where users can bring their own implementation if needed.  I know
>> > because I have also implemented it (but would like to discuss that in a
>> > later stage, if it comes to it).
>> >
>> > The benefit of such implementation would be immense.  Imagine many Java
>> > services written with nio and which struggle to move to SSL due to the
>> > great complexity of using SSLEngine (zookeeper service to name one),
>> while
>> > all they would need to do (if SSLSocketChannels were available) is to
>> > instantiate an instance of SSLSocketChannel/SSLSelector when the
>> security
>> > is required and the rest would stay the same (as in case of plain
>> > communication using SocketChannel/Selector).  Another important use
>> case is
>> > the advent of IOT, where millions of devices, with relatively low
>> > throughput would want to protect their communication via SSL.
>> >
>> > The ways I have seen the community deal with this are mainly:
>> >
>> > 1. Go through the pain of learning SSLEngine (and hope to get it right)
>> > 2. Build their services around tested libraries (like Jetty, which
>> handle
>> > the SSL offload but don't resurface it in SocketChannel/Selector
>> paradigm,
>> > that also come with their huge set of dependencies, bringing in
>> unavoidable
>> > version collisions)
>> > 3. Use proxies (nginx, ha) to deal with the high number of SSL
>> connections
>> > and divide the load by scaling horizontally in the back end (making for
>> a
>> > harder deployment model)
>> >
>> > We can make this a lot easier!
>> >
>> > Any feedback is greatly appreciated,
>> > Best,
>> >
>> > Andi Mullaraj
>> >
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190215/e55f7681/attachment-0001.html>

From philipp.kunz at paratix.ch  Fri Feb 15 09:34:45 2019
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Fri, 15 Feb 2019 10:34:45 +0100
Subject: RFR 8180573: Refactor sun/security/tools shell tests to plain
 java tests
In-Reply-To: <2B9C2E12-4BCE-4FFE-84FF-F21CE5FAC56F@oracle.com>
References: <2B9C2E12-4BCE-4FFE-84FF-F21CE5FAC56F@oracle.com>
Message-ID: <1550223285.2497.12.camel@paratix.ch>

Hi Max,

I don't know if it is important enough, certainly not a serious issue.
In your patch, for example in?DiffEnd.java and a few other tests,
Strings are encoded to byte streams with String.getBytes() which uses
the default platform character set to encode the strings.
Manifests, however, always use UTF-8 as the character set to encode. In
my opinion, getBytes(java.nio.charset.StandardCharsets.UTF_8) would be
appropriate to specify the encoding in a platform-independent way.
Now the manifests used in the tests use so few different characters
that this might not even make a real difference because the first
around 100 characters or so of most character sets are the same in most
encodings.
I suspect that the encoding might also have been platform-dependent in
at least some of the previous shell tests and therefore this aspect
might as well be addressed separately and is not strictly necessary to
just properly convert shell tests to java.

Regards,
Philipp


On Wed, 2019-02-13 at 11:01 +0800, Weijun Wang wrote:
> Please review the fix at
> 
>    https://cr.openjdk.java.net/~weijun/8180573/webrev.00/
> 
> Notes:
> 
> - Most changes are just .sh -> .java
> 
> - StorePasswordsByShell.sh combined into StorePasswords.java
> 
> - In most cases, JarUtils is called to create a jar file. Sometimes the jar command is called because of delicate differences, for example, jar adds directory entries also.
> 
> - The i18n tests are completely manual described in i18n.html. Old i18n.java is useless, now is also empty.
> 
> - Copyright year updated to 2019, @bug unchanged.
> 
> Two files not converted yet:
> 
> - ./keytool/console.sh
> 
> This is a manual test calling old versions of JDK.
> 
> - ./keytool/ListKeychainStore.sh
> 
> I tried on this one but "security list-keychains -s ..." has no effect on mach5 machines when calling by ProcessTools. No idea why, I've created a separate bug (JDK-8218886) for it.
> 
> Thanks,
> Max
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190215/4aa93c16/attachment.html>

From david.lloyd at redhat.com  Fri Feb 15 12:56:00 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Fri, 15 Feb 2019 06:56:00 -0600
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
 <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
Message-ID: <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>

Then your selector can only be used for SSL things.  What if someone
decides to take the exact same approach to solve some other
higher-OSI-layer protocol decoding?  Now you have to choose which kind
of protocol you want your selector to support.  Note that with a plain
selector and plain sockets, you *need* a thread to support the event
loop anyway, I mean it has to run somewhere.  And with SSL, you also
need an extra thread or thread pool to handle SSL authentication
tasks, no matter whether you make a subclass of Selector.

On Fri, Feb 15, 2019 at 2:35 AM Andi Mullaraj <andimullaraj at gmail.com> wrote:
>
> Hi Dean,
>
> Thanks for sharing your experience. I took a look at your links and the model and implementation seems quite distant from the classic Selector/SelectableChannel though. You seem to allocate a thread per each Selector (which I agree is too much of a cost to pay), then fire actively [listener.selectorFired()] from that thread towards a SelectorListener ...
>
> We can come back to implementation details later, but first I would like to ask: any reason we cannot have an SSLSelector which extends the java.nio.channels.Selector, an SSLSocketChannel extending a java.nio.channels.SocketChannel, and so on? I believe we can, and in this doc https://github.com/rouplex/rouplex-niossl/blob/master/README.md I have provided the set of base classes that do just that. Since this is a dev group I am sharing a code snippet from the doc:
>
> As an example, an existing application which is using SocketChannel with a Selector for their communications, would be turned into a secure one, by simply replacing:
>
> Selector selector = Selector.open();
> SocketChannel socketChannel = SocketChannel.open();
> socketChannel.register(selector, SelectionKey.OP_READ);
>
> while(true) {
>     selector.select();
>     for (SocketChannel sc : selector.selectedKeys() {
>         sc.read(...)
>     }
> }
>
> with:
>
> Selector selector = SSLSelector.open(); // notice the SSL
> SocketChannel socketChannel = SSLSocketChannel.open();  // notice the SSL
> socketChannel.register(selector, SelectionKey.OP_READ);
>
> while(true) {
>     selector.select();
>     for (SocketChannel sc : selector.selectedKeys() {
>         sc.read(...)
>     }
> }
>
> How much cooler and easier than that can it get redressing your existing service using (performant) plain communications with (performant) secure ones? Or create a new (and secure) one using the exact knowledge you already have and never having to think SSLEngine again?
>
> As I have already mentioned I have worked on such implementation but would like to first discuss with the group the merits and possible problems/shortcomings of adopting the inheritance model from the plain counterparts.
>
> Thanks in advance,
> --Andi
>
>
> On Wed, Feb 13, 2019 at 8:22 AM Dean Hiller <dhiller at twitter.com> wrote:
>>
>> I would highly suggest implementing your own for a much better understanding.
>>
>> I did implement something like what you want and in so doing realized I like their decision.  ie. See the heirarchy here
>> https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/webpieces/nio/api/channels
>>
>> The TCPChannel could be SSL or not SSL as there are two implementations.
>>
>> If you do want an implementation that does what you want though, this library does exactly that
>> https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2
>>
>> which is used in the webpieces webserver
>> https://github.com/deanhiller/webpieces
>>
>> That nio library is standalone even though it is in the webpieces repo.  I mean, every component in webpieces is another stand-alone piece.
>>
>> The downside is the library owns a thread which typical java libraries avoid.  ie. it has to have a thread to poll the selector and read from all the sockets to be fed to the thread pools, etc.  I think that is the main reason they decided not to have this type of library.  They prefer not to be running threads(which I agree, the jdk shouldn't).
>>
>> later,
>> Dean
>>
>>
>>
>>
>> On Tue, Feb 12, 2019 at 7:54 PM Sean Mullan <sean.mullan at oracle.com> wrote:
>>>
>>> Hi Andi,
>>>
>>> TLS/JSSE topics are best discussed on the security-dev alias, so I am
>>> copying that list for more discussion and -bcc-ing core-libs-dev.
>>>
>>> --Sean
>>>
>>> On 2/11/19 3:29 PM, Andi Mullaraj wrote:
>>> > Hi java-core community,
>>> >
>>> > I have been directed to this channel to discuss matters related to Java
>>> > performant ssl communications.  Maybe this is a topic that has been
>>> > discussed in the past, in which case I would appreciate if someone pointed
>>> > me to that particular topic.
>>> >
>>> > Back in 2002 I personally applauded the java.nio.channels (jdk1.4) package,
>>> > realizing that there was no way to port this to the secure communications,
>>> > due to lack of a comparable implementation for SSL.  But I thought it was
>>> > going to just be matter of time.  A couple of years ago I had to go back
>>> > search for it, and was kind of surprised to find the following in
>>> > http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG
>>> > :
>>> >
>>> > --- begin quote ---
>>> > Newcomers to the API may wonder "Why not just have an SSLSocketChannel
>>> > which extends java.nio.channels.SocketChannel?" There are two main reasons:
>>> >
>>> > 1. There were a lot of very difficult questions about what a
>>> > SSLSocketChannel should be, including its class hierarchy and how it should
>>> > interoperate with Selectors and other types of SocketChannels. Each
>>> > proposal brought up more questions than answers. It was noted that any new
>>> > API abstraction extended to work with SSL/TLS would require the same
>>> > significant analysis and could result in large and complex APIs.
>>> > 2. Any JSSE implementation of a new API would be free to choose the "best"
>>> > I/O & compute strategy, but hiding any of these details is inappropriate
>>> > for those applications needing full control. Any specific implementation
>>> > would be inappropriate for some application segment.
>>> > --- end quote ---
>>> >
>>> > It has been a while since this was stated, and I would really like to
>>> > revisit it.  I personally believe that the question #1 has a quite natural
>>> > answer, while #2 should not really be a concern if we adhere to the spi
>>> > model where users can bring their own implementation if needed.  I know
>>> > because I have also implemented it (but would like to discuss that in a
>>> > later stage, if it comes to it).
>>> >
>>> > The benefit of such implementation would be immense.  Imagine many Java
>>> > services written with nio and which struggle to move to SSL due to the
>>> > great complexity of using SSLEngine (zookeeper service to name one), while
>>> > all they would need to do (if SSLSocketChannels were available) is to
>>> > instantiate an instance of SSLSocketChannel/SSLSelector when the security
>>> > is required and the rest would stay the same (as in case of plain
>>> > communication using SocketChannel/Selector).  Another important use case is
>>> > the advent of IOT, where millions of devices, with relatively low
>>> > throughput would want to protect their communication via SSL.
>>> >
>>> > The ways I have seen the community deal with this are mainly:
>>> >
>>> > 1. Go through the pain of learning SSLEngine (and hope to get it right)
>>> > 2. Build their services around tested libraries (like Jetty, which handle
>>> > the SSL offload but don't resurface it in SocketChannel/Selector paradigm,
>>> > that also come with their huge set of dependencies, bringing in unavoidable
>>> > version collisions)
>>> > 3. Use proxies (nginx, ha) to deal with the high number of SSL connections
>>> > and divide the load by scaling horizontally in the back end (making for a
>>> > harder deployment model)
>>> >
>>> > We can make this a lot easier!
>>> >
>>> > Any feedback is greatly appreciated,
>>> > Best,
>>> >
>>> > Andi Mullaraj
>>> >



-- 
- DML

From weijun.wang at oracle.com  Fri Feb 15 13:31:49 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 15 Feb 2019 21:31:49 +0800
Subject: RFR 8180573: Refactor sun/security/tools shell tests to plain
 java tests
In-Reply-To: <1550223285.2497.12.camel@paratix.ch>
References: <2B9C2E12-4BCE-4FFE-84FF-F21CE5FAC56F@oracle.com>
 <1550223285.2497.12.camel@paratix.ch>
Message-ID: <0BF4117D-E0D6-4A2F-B959-D59466E093CB@oracle.com>

Hi Philipp,

In most cases, it's just about creating a non-empty file; in some case, the content is relevant. For the former, I will change it to something like "new byte[10]"; for the latter, I'll use getBytes(UTF_8).

Thanks,
Max


> On Feb 15, 2019, at 5:34 PM, Philipp Kunz <philipp.kunz at paratix.ch> wrote:
> 
> Hi Max,
> 
> I don't know if it is important enough, certainly not a serious issue.
> In your patch, for example in DiffEnd.java and a few other tests, Strings are encoded to byte streams with String.getBytes() which uses the default platform character set to encode the strings.
> Manifests, however, always use UTF-8 as the character set to encode. In my opinion, getBytes(java.nio.charset.StandardCharsets.UTF_8) would be appropriate to specify the encoding in a platform-independent way.
> Now the manifests used in the tests use so few different characters that this might not even make a real difference because the first around 100 characters or so of most character sets are the same in most encodings.
> I suspect that the encoding might also have been platform-dependent in at least some of the previous shell tests and therefore this aspect might as well be addressed separately and is not strictly necessary to just properly convert shell tests to java.
> 
> Regards,
> Philipp
> 
> 
> On Wed, 2019-02-13 at 11:01 +0800, Weijun Wang wrote:
>> Please review the fix at
>> 
>>    
>> https://cr.openjdk.java.net/~weijun/8180573/webrev.00/
>> 
>> 
>> Notes:
>> 
>> - Most changes are just .sh -> .java
>> 
>> - StorePasswordsByShell.sh combined into StorePasswords.java
>> 
>> - In most cases, JarUtils is called to create a jar file. Sometimes the jar command is called because of delicate differences, for example, jar adds directory entries also.
>> 
>> - The i18n tests are completely manual described in i18n.html. Old i18n.java is useless, now is also empty.
>> 
>> - Copyright year updated to 2019, @bug unchanged.
>> 
>> Two files not converted yet:
>> 
>> - ./keytool/console.sh
>> 
>> This is a manual test calling old versions of JDK.
>> 
>> - ./keytool/ListKeychainStore.sh
>> 
>> I tried on this one but "security list-keychains -s ..." has no effect on mach5 machines when calling by ProcessTools. No idea why, I've created a separate bug (JDK-8218886) for it.
>> 
>> Thanks,
>> Max
>> 
>> 


From valerie.peng at oracle.com  Fri Feb 15 20:04:40 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Fri, 15 Feb 2019 12:04:40 -0800
Subject: [13] RFR JDK-8218780 "Update MUSCLE PCSC-Lite header files"
Message-ID: <902a2671-051a-9d29-f49f-5b29b3fe173d@oracle.com>

Hi Sean (Coffey),

Can you please help reviewing this fix? It's about updating the PC/SC 
lite header files under the MUSCLE directory inside smartcardio module. 
The header files are from https://pcsclite.apdu.fr/ and minor 
adjustments are made to pcsc_md.h and pcsc.c to match the header update 
and replace the old types, i.e. LPTSTR/LPCTSTR, with new ones to avoid 
compilation fails on MacOs.

Bug: https://bugs.openjdk.java.net/browse/JDK-8218780

Webrev: http://cr.openjdk.java.net/~valeriep/8218780/webrev.00/

Mach5 run is clean.

Thanks,
Valerie

From yozons at gmail.com  Fri Feb 15 20:11:57 2019
From: yozons at gmail.com (Open eSignForms)
Date: Fri, 15 Feb 2019 12:11:57 -0800
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <ea7a7809-665d-c8aa-9ebf-f2a54abbaf92@oracle.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
 <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
 <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
 <32d2fff5-1be5-1201-225e-15ac60982067@gmail.com>
 <648d666c-60a4-bc09-ecd9-f993255040e2@gmail.com>
 <ba795b7d-6100-208e-e463-1c3894612245@oracle.com>
 <cb4f5d6f-cfee-a9f6-0163-5f49147b2b55@gmail.com>
 <fb50c811-9404-9bc4-1aa3-6b06b5785763@oracle.com>
 <5360b44b-9f06-4107-fd9d-165f0b356952@gmail.com>
 <C726A215-FF1B-4827-ADF1-6B87C0EB2355@oracle.com>
 <166893ef-5c96-ba36-3a94-114dd2caeccf@gmail.com>
 <ea7a7809-665d-c8aa-9ebf-f2a54abbaf92@oracle.com>
Message-ID: <8a01a47e-0984-b732-7cac-ec76e35b11ab@gmail.com>

XML namespaces are pretty confusing.? From what little I gather, 
unprefixed attributes don't belong to any namespace, not even the 
default one.

I think I can see the bug in the debugging output.

On Java 8 and 10 and 11, I'd guess that the marshaling/canonicalization 
has issues when combining differently namespaced objects.

In my working code (also works on Java 11), when my ETSI/XADES 
QualifyingProperties element is created specifying my namespace (the 
default namespace for the XML document that I'm signing), it works 
fine.? If I change my document's default namespace to be the XADES one, 
it also works.? But I cannot make them work when both are in use.? The 
reason seems to be as follows.

1) The signedXML generated looks great and sensible, with the xades 
namespace as expected.

 ??? <ds:Object>
 ??????? <xades:QualifyingProperties Id="QualifyingProperties_ID" 
Target="#OpenESignForms_Seal" 
*xmlns:xades="http://uri.etsi.org/01903/v1.4.1#"*>
 ??????????? <xades:SignedProperties>
 ??????????????? <xades:SignedSignatureProperties>
<xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime>
 ??????????????? </xades:SignedSignatureProperties>
 ??????????????? <xades:SignedDataObjectProperties>
 ??????????????????? <xades:DataObjectFormat 
ObjectReference="#Payload_Reference_ID">
<xades:Description>description</xades:Description>
<xades:MimeType>text/html</xades:MimeType>
 ??????????????????? </xades:DataObjectFormat>
 ??????????????? </xades:SignedDataObjectProperties>
 ??????????? </xades:SignedProperties>
 ??????? </xades:QualifyingProperties>
 ??? </ds:Object>

2) But using the debugging options, it shows this element during SIGNING 
(presuming canonicalization) that makes /*no sense*/. It's added both 
the default namespace, the 'dsig' namespace, but doesn't include the 
xades namespace.? Wwhat does the 'xades' prefix even refer to in this 
XML for the signing digest?

 ??? <xades:QualifyingProperties 
*xmlns="http://open.esignforms.com/XMLSchema/2011" 
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"*Id="QualifyingProperties_ID" 
Target="#OpenESignForms_Seal">
 ??????? <xades:SignedProperties>
 ??????????? <xades:SignedSignatureProperties>
<xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime>
 ??????????? </xades:SignedSignatureProperties>
 ??????????? <xades:SignedDataObjectProperties>
 ??????????????? <xades:DataObjectFormat 
ObjectReference="#Payload_Reference_ID">
<xades:Description>description</xades:Description>
<xades:MimeType>text/html</xades:MimeType>
 ??????????????? </xades:DataObjectFormat>
 ??????????? </xades:SignedDataObjectProperties>
 ??????? </xades:SignedProperties>
 ??? </xades:QualifyingProperties>

3) And again, the debugger shows this element during VERIFICATION 
(presuming canonicalization) that is excessive, but at least makes some 
sense (though there are no default elements nor 'dsig' elements).? It's 
added all three namespaces: our default namespace, the 'dsig' namespace 
AND the 'xades' namespace.

 ?? <xades:QualifyingProperties 
*xmlns="http://open.esignforms.com/XMLSchema/2011" 
xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
xmlns:xades="http://uri.etsi.org/01903/v1.4.1#"* 
Id="QualifyingProperties_ID" Target="#OpenESignForms_Seal">
 ??????? <xades:SignedProperties>
 ??????????? <xades:SignedSignatureProperties>
<xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime>
 ??????????? </xades:SignedSignatureProperties>
 ??????????? <xades:SignedDataObjectProperties>
 ??????????????? <xades:DataObjectFormat 
ObjectReference="#Payload_Reference_ID">
<xades:Description>description</xades:Description>
<xades:MimeType>text/html</xades:MimeType>
 ??????????????? </xades:DataObjectFormat>
 ??????????? </xades:SignedDataObjectProperties>
 ??????? </xades:SignedProperties>
 ??? </xades:QualifyingProperties

So the libraries are oddly creating two distinct canonicalized XML for 
digesting, with the signing phase seeming to miss the important 'xades' 
namespace declaration entirely.? This is no doubt why this is the only 
Reference that fails verification as the two.? I'm guessing that the 
verification digest is correct when using multiple namespaced 
objects/references, but the signing digest is not since it doesn't 
include the 'xades' namespace declaration.

This seems to hold true for Java 8, 10 and 11.? That is, by specifying 
null namespaces on atrributes, the code fails the same under under Java 
11, and the debugging output shows the same odd namespaces above.? If I 
use a single namespace, then it signs fine under Java 8, 10 and 11.

David


On 2/15/19 11:12 AM, Sean Mullan wrote:
> On 2/14/19 9:32 PM, Open eSignForms wrote:
>>
>> Yes, indeed that's the issue.? But I don't know why/how all those 
>> xmlns attributes are added, since I don't directly add them.
>>
>> I found the only way I can make it work under Java 8, 10 and 11 is to 
>> use my common namespace (XML_NAMESPACE_2011 = 
>> "http://open.esignforms.com/XMLSchema/2011") for all the XADES 
>> elements with the null namespace on all their attributes.? Even if I 
>> put that same namespace on the attributes, it then fails.
>>
>> When I do that, the signed XML generates clean looking XML like this:
>>
>> ??? <ds:Object>
>> ??????? <QualifyingProperties Id="QualifyingProperties_ID" 
>> Target="#OpenESignForms_Seal">
>> <SignedProperties><SignedSignatureProperties>
>> <SigningTime>2019-02-14T17:37:39-08:00</SigningTime>
>> ??????????? </SignedSignatureProperties>
>> ??????????? <SignedDataObjectProperties>
>> ??????????????? <DataObjectFormat 
>> ObjectReference="#Payload_Reference_ID">
>> <Description>description</Description>
>> ??????????????????? <MimeType>text/html</MimeType>
>> ??????????????? </DataObjectFormat>
>> ??????????? </SignedDataObjectProperties>
>> ??????????? </SignedProperties>
>> ??????? </QualifyingProperties>
>> ??? </ds:Object>
>> ??? <ds:Object>
>> ??????? <ds:SignatureProperties>
>> ??????????? <ds:SignatureProperty*Id="OpenESignForms_Seal_ID" 
>> Target="#OpenESignForms_Seal"*>
>> ??????????????? <OpenESignForms_XmlDigitalSignatureSeal 
>> DeploymentHostAddress="192.1.1.1" 
>> DeploymentHostName="open.esignforms.com" DeploymentId="1.1.1.1" 
>> SignerAddress="192.1.1.1" SignerAgent="No-Browser-Test" 
>> Timestamp="2019-02-14T17:37:39-08:00" Version="19.1.19"/>
>> ??????????? </ds:SignatureProperty>
>> ??????? </ds:SignatureProperties>
>> ??? </ds:Object>
>>
>> But even above, as you can see, the second ds:Object shows 
>> ds:SignatureProperty, yet the Id and Target attributes do not include 
>> a 'ds:' prefix, which it's my understanding to mean that they default 
>> to our XML payload's default namespace.
>>
> I don't think that's correct, I think attributes w/o a prefix by 
> default belong to the namespace of the element in which they are 
> defined, which in this case is SignatureProperties and the dsig namespace.
>
> Regarding below, I would forget about JDK 11 for the time being and 
> focus on generating a signature with proper XMLNS definitions on JDK 
> 10. If you have any problems verifying with that on JDK 10 or prior, 
> let me know. The reason is that we will likely be restoring JDK 11 
> (and later) to the same state it was in for JDK 10. There were some 
> changes to the marshalling code in JDK 11 which is causing these and 
> other problems which will likely be backed out.
>
> --Sean
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190215/8cbcc672/attachment-0001.html>

From sean.mullan at oracle.com  Fri Feb 15 21:21:51 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 15 Feb 2019 16:21:51 -0500
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <8a01a47e-0984-b732-7cac-ec76e35b11ab@gmail.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
 <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
 <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
 <32d2fff5-1be5-1201-225e-15ac60982067@gmail.com>
 <648d666c-60a4-bc09-ecd9-f993255040e2@gmail.com>
 <ba795b7d-6100-208e-e463-1c3894612245@oracle.com>
 <cb4f5d6f-cfee-a9f6-0163-5f49147b2b55@gmail.com>
 <fb50c811-9404-9bc4-1aa3-6b06b5785763@oracle.com>
 <5360b44b-9f06-4107-fd9d-165f0b356952@gmail.com>
 <C726A215-FF1B-4827-ADF1-6B87C0EB2355@oracle.com>
 <166893ef-5c96-ba36-3a94-114dd2caeccf@gmail.com>
 <ea7a7809-665d-c8aa-9ebf-f2a54abbaf92@oracle.com>
 <8a01a47e-0984-b732-7cac-ec76e35b11ab@gmail.com>
Message-ID: <c92d46fc-a60f-a0b2-e670-e4fb78efe332@oracle.com>

I know what the problem is.

You also need to add the actual namespace attribute to your element, for 
example:

qualifyingPropertiesElement.setAttributeNS(
 ??????? "http://www.w3.org/2000/xmlns/", "xmlns", 
"http://uri.etsi.org/01903/v1.1.1#");

You only need to do that on the top-most parent element in that namespace.

When I made that change to your code, everything generated and verified 
for me correctly (on JDK 10 anyway, JDK 11 may still have some issues).

--Sean

On 2/15/19 3:11 PM, Open eSignForms wrote:
>
> XML namespaces are pretty confusing.? From what little I gather, 
> unprefixed attributes don't belong to any namespace, not even the 
> default one.
>
> I think I can see the bug in the debugging output.
>
> On Java 8 and 10 and 11, I'd guess that the 
> marshaling/canonicalization has issues when combining differently 
> namespaced objects.
>
> In my working code (also works on Java 11), when my ETSI/XADES 
> QualifyingProperties element is created specifying my namespace (the 
> default namespace for the XML document that I'm signing), it works 
> fine.? If I change my document's default namespace to be the XADES 
> one, it also works.? But I cannot make them work when both are in 
> use.? The reason seems to be as follows.
>
> 1) The signedXML generated looks great and sensible, with the xades 
> namespace as expected.
>
> ??? <ds:Object>
> ??????? <xades:QualifyingProperties Id="QualifyingProperties_ID" 
> Target="#OpenESignForms_Seal" 
> *xmlns:xades="http://uri.etsi.org/01903/v1.4.1#"*>
> ??????????? <xades:SignedProperties>
> ??????????????? <xades:SignedSignatureProperties>
> <xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime>
> ??????????????? </xades:SignedSignatureProperties>
> ??????????????? <xades:SignedDataObjectProperties>
> ??????????????????? <xades:DataObjectFormat 
> ObjectReference="#Payload_Reference_ID">
> <xades:Description>description</xades:Description>
> <xades:MimeType>text/html</xades:MimeType>
> ??????????????????? </xades:DataObjectFormat>
> ??????????????? </xades:SignedDataObjectProperties>
> ??????????? </xades:SignedProperties>
> ??????? </xades:QualifyingProperties>
> ??? </ds:Object>
>
> 2) But using the debugging options, it shows this element during 
> SIGNING (presuming canonicalization) that makes /*no sense*/.? It's 
> added both the default namespace, the 'dsig' namespace, but doesn't 
> include the xades namespace. Wwhat does the 'xades' prefix even refer 
> to in this XML for the signing digest?
>
> ??? <xades:QualifyingProperties 
> *xmlns="http://open.esignforms.com/XMLSchema/2011" 
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"* 
> Id="QualifyingProperties_ID" Target="#OpenESignForms_Seal">
> ??????? <xades:SignedProperties>
> ??????????? <xades:SignedSignatureProperties>
> <xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime>
> ??????????? </xades:SignedSignatureProperties>
> ??????????? <xades:SignedDataObjectProperties>
> ??????????????? <xades:DataObjectFormat 
> ObjectReference="#Payload_Reference_ID">
> <xades:Description>description</xades:Description>
> <xades:MimeType>text/html</xades:MimeType>
> ??????????????? </xades:DataObjectFormat>
> ??????????? </xades:SignedDataObjectProperties>
> ??????? </xades:SignedProperties>
> ??? </xades:QualifyingProperties>
>
> 3) And again, the debugger shows this element during VERIFICATION 
> (presuming canonicalization) that is excessive, but at least makes 
> some sense (though there are no default elements nor 'dsig' 
> elements).? It's added all three namespaces: our default namespace, 
> the 'dsig' namespace AND the 'xades' namespace.
>
> ?? <xades:QualifyingProperties 
> *xmlns="http://open.esignforms.com/XMLSchema/2011" 
> xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
> xmlns:xades="http://uri.etsi.org/01903/v1.4.1#"* 
> Id="QualifyingProperties_ID" Target="#OpenESignForms_Seal">
> ??????? <xades:SignedProperties>
> ??????????? <xades:SignedSignatureProperties>
> <xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime>
> ??????????? </xades:SignedSignatureProperties>
> ??????????? <xades:SignedDataObjectProperties>
> ??????????????? <xades:DataObjectFormat 
> ObjectReference="#Payload_Reference_ID">
> <xades:Description>description</xades:Description>
> <xades:MimeType>text/html</xades:MimeType>
> ??????????????? </xades:DataObjectFormat>
> ??????????? </xades:SignedDataObjectProperties>
> ??????? </xades:SignedProperties>
> ??? </xades:QualifyingProperties
>
> So the libraries are oddly creating two distinct canonicalized XML for 
> digesting, with the signing phase seeming to miss the important 
> 'xades' namespace declaration entirely.? This is no doubt why this is 
> the only Reference that fails verification as the two.? I'm guessing 
> that the verification digest is correct when using multiple namespaced 
> objects/references, but the signing digest is not since it doesn't 
> include the 'xades' namespace declaration.
>
> This seems to hold true for Java 8, 10 and 11.? That is, by specifying 
> null namespaces on atrributes, the code fails the same under under 
> Java 11, and the debugging output shows the same odd namespaces 
> above.? If I use a single namespace, then it signs fine under Java 8, 
> 10 and 11.
>
> David
>
>
> On 2/15/19 11:12 AM, Sean Mullan wrote:
>> On 2/14/19 9:32 PM, Open eSignForms wrote:
>>>
>>> Yes, indeed that's the issue.? But I don't know why/how all those 
>>> xmlns attributes are added, since I don't directly add them.
>>>
>>> I found the only way I can make it work under Java 8, 10 and 11 is 
>>> to use my common namespace (XML_NAMESPACE_2011 = 
>>> "http://open.esignforms.com/XMLSchema/2011") for all the XADES 
>>> elements with the null namespace on all their attributes.? Even if I 
>>> put that same namespace on the attributes, it then fails.
>>>
>>> When I do that, the signed XML generates clean looking XML like this:
>>>
>>> ??? <ds:Object>
>>> ??????? <QualifyingProperties Id="QualifyingProperties_ID" 
>>> Target="#OpenESignForms_Seal">
>>> <SignedProperties><SignedSignatureProperties>
>>> <SigningTime>2019-02-14T17:37:39-08:00</SigningTime>
>>> ??????????? </SignedSignatureProperties>
>>> ??????????? <SignedDataObjectProperties>
>>> ??????????????? <DataObjectFormat 
>>> ObjectReference="#Payload_Reference_ID">
>>> <Description>description</Description>
>>> <MimeType>text/html</MimeType>
>>> ??????????????? </DataObjectFormat>
>>> ??????????? </SignedDataObjectProperties>
>>> ??????????? </SignedProperties>
>>> ??????? </QualifyingProperties>
>>> ??? </ds:Object>
>>> ??? <ds:Object>
>>> ??????? <ds:SignatureProperties>
>>> ??????????? <ds:SignatureProperty*Id="OpenESignForms_Seal_ID" 
>>> Target="#OpenESignForms_Seal"*>
>>> ??????????????? <OpenESignForms_XmlDigitalSignatureSeal 
>>> DeploymentHostAddress="192.1.1.1" 
>>> DeploymentHostName="open.esignforms.com" DeploymentId="1.1.1.1" 
>>> SignerAddress="192.1.1.1" SignerAgent="No-Browser-Test" 
>>> Timestamp="2019-02-14T17:37:39-08:00" Version="19.1.19"/>
>>> ??????????? </ds:SignatureProperty>
>>> ??????? </ds:SignatureProperties>
>>> ??? </ds:Object>
>>>
>>> But even above, as you can see, the second ds:Object shows 
>>> ds:SignatureProperty, yet the Id and Target attributes do not 
>>> include a 'ds:' prefix, which it's my understanding to mean that 
>>> they default to our XML payload's default namespace.
>>>
>> I don't think that's correct, I think attributes w/o a prefix by 
>> default belong to the namespace of the element in which they are 
>> defined, which in this case is SignatureProperties and the dsig 
>> namespace.
>>
>> Regarding below, I would forget about JDK 11 for the time being and 
>> focus on generating a signature with proper XMLNS definitions on JDK 
>> 10. If you have any problems verifying with that on JDK 10 or prior, 
>> let me know. The reason is that we will likely be restoring JDK 11 
>> (and later) to the same state it was in for JDK 10. There were some 
>> changes to the marshalling code in JDK 11 which is causing these and 
>> other problems which will likely be backed out.
>>
>> --Sean
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190215/d67b4375/attachment-0001.html>

From sean.mullan at oracle.com  Fri Feb 15 21:27:04 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 15 Feb 2019 16:27:04 -0500
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <5C65F1BD.5060002@oracle.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <d1e89aa4-6c5b-629c-b8b9-a148fff1ecb2@oracle.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
 <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
 <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
 <74045499-137b-87c4-ab59-8edb4801aa4b@oracle.com>
 <5C65F1BD.5060002@oracle.com>
Message-ID: <bba92092-f60a-c87b-4f34-de01f1d3966d@oracle.com>

On 2/14/19 5:54 PM, Joe Wang wrote:
>> his is the ASCII code for a carriage return, encoded in XML. I don't 
>> know why that behavior is different in JDK 11. This would be a 
>> question for the XML developers. I have copied Joe Wang, to see if he 
>> might know.
> 
> Hi Sean,
> 
> There hasn't been functional change to that area between JDK 10 and 11 
> that I'm aware of. If you believe there's a behavior change, or you 
> could isolate the issue down to the java.xml/xml processor, please file 
> a bug.? I'll be happy to investigate.

Never mind, I determined that this was a change in the way XML signature 
data was being base64 encoded. It seems like an innocuous change though 
and doesn't appear to break anything.

--Sean

From Nico.Williams at twosigma.com  Fri Feb 15 21:45:02 2019
From: Nico.Williams at twosigma.com (Nico Williams)
Date: Fri, 15 Feb 2019 21:45:02 +0000
Subject: RFR 6722928: Support SSPI as a native GSS-API provider
In-Reply-To: <EF109C45-C842-47B5-B14E-4A76DF6826D0@oracle.com>
References: <7875DFBB-B208-4556-AC49-6E8584EFDBB9@oracle.com>
 <B696ED17-9B7D-4ED4-BA7F-FAB49E455E89@oracle.com>
 <20181204203436.GA22527@twosigma.com>
 <EA6A3F91-8001-4317-8513-6EDE65EC6E79@oracle.com>
 <20181206184824.GB22527@twosigma.com>
 <32999A4A-F6AA-4D6C-A664-F55160744F59@oracle.com>
 <20181212004054.GG22527@twosigma.com>
 <D265F857-2EE9-43B0-9259-CCB9F1C83028@oracle.com>
 <20190117190436.GD27060@twosigma.com>
 <EF109C45-C842-47B5-B14E-4A76DF6826D0@oracle.com>
Message-ID: <20190215214502.GB4046@twosigma.com>

On Tue, Jan 22, 2019 at 10:52:59AM +0800, Weijun Wang wrote:
> Webrev updated again at
> 
>   https://cr.openjdk.java.net/~weijun/6722928/webrev.04/

> This time I updated gssapi.h to make use of gss_const_xyz_t types. The types
> in NativeFunc.h and sspi.cpp are updated as well. (I wish there is an
> automatic tool to check the consistence).

Thanks.  It's not quite right though.  See below.

> Several Windows API calls (QueryContextAttributes, MakeSignature,
> VerifySignature, EncryptMessage, DecryptMessage) need an explicit cast (from
> const *p to *p) because they don't announce the pointer to be const, but I
> think it's safe.

Thanks for the warning.  I'll double-check, but it seems likely to be safe,
yes.

 - sspi.cpp:61

   61 #define SEC_SUCCESS(status) (*minor_status = status, (status) >= SEC_E_OK)
                                   ^^^^^^^^^^^^^^^^^^^^^^

   Please add parenthesis around the whole assignment expression.

 - sspi.cpp:129

   129 static long
   130 secondsUntil(int inputIsUTC, TimeStamp *time)

   There's no need to return a signed number, and you assign it to OM_uint32
   variables anyways, and we don't care if some credential expired in the past.

   So just make this return an unsigned integral type, preferably just
   OM_uint32.

   So just rewrite as:

    static OM_uint32
    secondsUntil(int inputIsUTC, TimeStamp *time)
    {
        // time is local time
        ULARGE_INTEGER uiLocal;
        FILETIME now;
        GetSystemTimeAsFileTime(&now);
        if (!inputIsUTC) {
            FILETIME nowLocal;
            if (FileTimeToLocalFileTime(&now, &nowLocal) == 0) {
                return -1;
            }
            now = nowLocal;
        }
        uiLocal.HighPart = now.dwHighDateTime;
        uiLocal.LowPart = now.dwLowDateTime;
        long diff = (long)((time->QuadPart - uiLocal.QuadPart) / 10000000);
        if (diff < 0)
            return 0;
        if (sizeof(long) > sizeof(OM_uint32) && diff > (long)~(OM_uint32)0)
            return GSS_C_INDEFINITE;
        return diff;
    }

 - sspi.cpp:NewContext()

   Please fully-initialize all fields of the allocated context structure before
   returning it.

   Or else use new gss_ctx_id_struct() syntax, or specify a constructor.

 - sspi.cpp:169

   -->165     out->phCred = NULL;
      166     out->cbMaxMessage = pkgInfo->cbMaxToken;
      167     PP("pkgInfo->cbMaxToken: %ld", pkgInfo->cbMaxToken);
      168     FreeContextBuffer(pkgInfo);
   -->169     out->phCred = NULL;

   Dup code.

 - sspi.cpp:flagSspi2Gss() and flagGss2Sspi()

   I realize that this would be a change to the Java bindings, so this is just
   a note, but, we should add support for GSS_C_DELEG_POLICY_FLAG.

 - sspi.cpp:getTGTEndTime()

   Please immediately write to the `endTime' output parameter upon entry.

 - sspi.cpp:getTGTEndTime()

   You leak the logonHandle.  You have to close it with
   LsaDeregisterLogonProcess() before returning after LsaConnectUntrusted()
   returns successfully.

 - sspi.cpp:getTGTEndTime()

   Maybe just make this return OM_uint32 and simplify the one call site, making
   it return 86400 seconds (1 day) or whatever for the error case, else the
   secondsUntil() the time indicated by the LSA in response to the
   KerbRetrieveTicketMessage request.

 - sspi.cpp:316,355

   It is rather concerning that get_full_name() can return its input or a
   modified copy of its input.  At the call sites there's no check to see if
   the returned value is allocated, and it's hard to analyze if you're
   ultimately leaking or double-freeing.

   This isn't performance-critical code, so just always allocate a copy.

 - sspi.cpp:315

   314     // input has realm, no need to add one
   315     if (wcschr(input, '@')) {

   This is not going to work with UPNs.  You should probably implement proper
   RFC1864 name format support, including backslash-quoting.

 - sspi.cpp:315

   315     if (wcschr(input, '@')) {
                             ^

   I don't know if it is necessary that this be L'@' or if the compiler will do
   the right thing because the `wc' argument of `wcschr()' is a `wchar_t'.

   Elsewhere you do use wide character literals, so I assume even if type
   promotion works correctly for char->WCHAR (does it?) you might want to be
   consistent.

 - sspi.cpp:328

   328         // Solution #2: Or just use an empty string (and hope referral works).
   329         // This does not work now because ServicePermission check is based on
   330         // the exported name. Unless we update ServicePermission check to
   331         // be friendly with referral we need a realm.
   332         //realm = L"";

   Yes, ServicePermission is a bit of a disaster.  I hope after we integrate
   our contribution we can clean it up somewhat.

 - sspi.cpp:337

   337         realm = _wgetenv(L"USERDNSDOMAIN");

   This is actually probably the best thing to do.  Referrals should get chased
   from there.

   Or we could get the realm from the user's principal name and use that.

 - sspi.cpp:344

   There's no wide string version of strdup()??  Ugh.

   wchar_t/WCHAR is cancer.

   I worry that adding any more wchar_t-using code makes worse the legacy
   cleanup as Windows starts to prefer UTF-8.  But whatever.

 - sspi.cpp:351

   351     wcscpy_s(fullname + oldlen + 1, wcslen(realm) + 1, realm);

   It would be safer to use wcscat_s().

 - sspi.cpp:362

   362 #define CHECK_OUTPUT(x)  if (!x) return GSS_S_CALL_INACCESSIBLE_WRITE;

   I would much prefer the more standard and safer do { ... } while (0)
   construction:

    362 #define CHECK_OUTPUT(x)  \
        do { if (!x) return GSS_S_CALL_INACCESSIBLE_WRITE; } while (0)

   I would do this for all your macros.

   I'm also not sure it's worth having these macros.

 - sspi.cpp:398-405

   I don't believe there's an exported name token format for SPNEGO MNs.  In
   principle any MNs produced by SPNEGO should be for the negotiated mechanism.
   What you should do here instead is check that the exported name token is for
   Kerberos, and if not return an error immediately.

   And your gss_export_name() correctly always puts the Kerberos mechanism OID
   in exported name tokens.

 - sspi.cpp:412

   412     len = MultiByteToWideChar(CP_ACP, 0, input, len, value, len+1);
                                     ^^^^^^

   Please use CP_UTF8 when en-widening the string in an exported Kerberos name
   token.

 - sspi.cpp:465

   465     // Initialized as different
   466     *name_equal = 0;

   No need to comment the obvious :)

 - sspi.cpp:gss_compare_name()

   Just a note: your `struct gss_name_struct' doesn't keep track of import name
   type, so you can't check that here.  That's OK.  It's not worth trying to
   keep track of it -- I'm just pointing this out.

 - sspi.cpp:527

   527     int len = (int)wcslen(fullname);

   You don't need that cast.  But you should check first that `wcslen()' did
   not return a value larger than `INT_MAX'.

   You only even need an `int len' because `WideCharToMultiByte()' returns
   `int'...

   I'd write this like:

    527     int len;
            size_t namelen = wcslen(fullname);
            if (namelen > 255)
                goto err;
            // 04 01 00 ** 06 ** OID len:int32 name
            // ...
            //

 - sspi.cpp:545

   545         len = WideCharToMultiByte(CP_ACP, 0, fullname, len,
                                         ^^^^^^

   s/CP_ACP/CP_UTF8/

   It's clear that the intent of RFC2743 was to have name strings be in some
   standard encoding, not the locale's, though RFC2743 says "Latin-1", which
   isn't precise enough, and useless anyways.  Otherwise, if we needed to use
   the codepage being used by the application we'd have to first determine what
   that is.  The application here is Java, which will be using UTF-8 anyways,
   no? so just do that.  Definitely not ANSI.

 - sspi.cpp:532,574

   You can't assume the length of a multi-byte string will be the same number
   of `char' as the number of `wchar_t' in the wide-char version of the string.

   Determinining the correct length is a bit tricky, though since we should be
   converting to UTF-8 (see above), you can assume that 4x is enough, use
   4*len for the buffer allocation, then take the correct length from
   WideCharToMultiByte().

 - sspi.cpp:630-644

   This should be done after successfully acquiring a credential.  Before that,
   if actual_mechs != NULL then set *actual_mechs = GSS_C_NO_OID_SET.

 - sspi.cpp:gss_acquire_cred()

   It would be good to set *minor_status in more cases.

 - sspi.cpp:607

   606     TimeStamp ts;
   607     ts.QuadPart = 0;

   Huh?  TimeStamp is a typedef of SECURITY_INTEGER, and SECURITY_INTEGER is a
   struct of the same shape and size as FILETIME, and has no QuadPart field.

   What am I missing?

 - sspi.cpp:651

   651     ts.QuadPart = 0;

   You've already initialized this at 607.

 - sspi.cpp:704-711

   As mentioned above, you could move this all into a utility function.  And
   there's no need to support anything other than unsigned expiration times.
   GSS only uses OM_uint32 for those.  If a credential is expired you'll get
   GSS_S_NO_CRED, not a negative expiration time.  (You might get
   GSS_S_COMPLETE and a zero lifetime_rec, but that would be a race condition.)

 - sspi.cpp:767

   I would prefer that all output parameters be initialized early (to zero,
   GSS_C_NO_NAME, etc.) before any work is done that might cause failure.

 - sspi.cpp:813

   I would prefer that *minor_status is always set to something, even zero.

   Meaningful minor status values would be nice, but that can come later.

 - sspi.cpp:871

   s/CP_ACP/CP_UTF8/

 - sspi.cpp:870-872

   Check errors here:

   870     gss_display_name(&minor, target_name, &tn, NULL);

   Wrong buffer length here:

   871     int len = MultiByteToWideChar(CP_ACP, 0, (LPCCH)tn.value, (int)tn.length,
   872             outName, (int)tn.length);
                            ^^^^^^^^^^^^^^

   Replace that with with `sizeof(outName) - 1' please (the `- 1' is
   important).

   873     if (len == 0) {
   874         return GSS_S_FAILURE;
   875     }

 - sspi.cpp:897-898

   897     } else {
   898         if (!pc->phCred) {
   ...
   932         }
   933     }

   You can de-indent all of of 899-931 by re-writing as:

   897     } else if (!pc->phCred) {
   ...
   931     }

 - sspi.cpp:844

   844     if (input_token->length == 0) {

   Technically-speaking input_token can be NULL here.  Maybe the Java JNI
   bindings for GSS always pass in a token?  But I'd still change this to
   `input_token == NULL || input_token->length == 0'.

   Similarly at 889.  And 936.  ...

 - sspi.cpp:596

   596                  const gss_OID_set desired_mech,

   Nit: since it's an OID set, the name for this argument is `desired_mechs'.

 - sspi.cpp:841

   841     BOOLEAN isSPNEGO = isSameOID(mech_type, &SPNEGO_OID);

   Watch out!  mech_type can be GSS_C_NO_OID (NULL)!

   isSameOid() will dereference that.

   If the Java JNI bindings for GSS just happen to always pass in a mech_type,
   that's OK, but I think you should not assume this and be safe.

 - sspi.cpp:954

   Should you check if there's an output token before doing this:

   954         ss = CompleteAuthToken(&pc->hCtxt, &outBuffDesc);

   ?

 - sspi.cpp:874 and others

   delete `output_token->value' and set it to NULL (and the length to 0) before
   returning errors after 865.

 - sspi.cpp:878,962-963

   The local variable `pfDone' is set but not used.  Drop it.

   (The compiler should have warned about this, no?)

 - sspi.cpp:964-966

   Change this:

   964     outFlag = flagSspi2Gss(outFlag);
   965 
   966     *ret_flags = (OM_uint32)outFlag;

   to:

   964     *ret_flags = flagSspi2Gss(outFlag);

   You don't use outFlag again.  Setting it to a different kind of set of flags
   seems like a trap for someone to fall into in the future.

 - sspi.cpp:948

   948     if (!SEC_SUCCESS(ss)) {
   949         return GSS_S_FAILURE;
   950     }
   951 
   952     if ((SEC_I_COMPLETE_NEEDED == ss)
   953             || (SEC_I_COMPLETE_AND_CONTINUE == ss)) {

   I can't find documentation on SEC_SUCCES().  I don't know if it treats
   SEC_I_COMPLETE_NEEDED as an error or not...  I gues it must not.  Can you
   confirm?

 - sspi.cpp:967-970

   Does QueryContextAttributes() initialize its output parameter if it fails:

   967     // Ignore the result of the next call. Might fail before context established.
   968     QueryContextAttributes(
   969             &pc->hCtxt, SECPKG_ATTR_SIZES, &pc->SecPkgContextSizes);

   ?

   If not then you'll print garbage at 970:

   970     PP("cbMaxToken: %ld. cbMaxSignature: %ld. cbBlockSize: %ld. cbSecurityTrailer: %ld",
   971             pc->SecPkgContextSizes.cbMaxToken,
   972             pc->SecPkgContextSizes.cbMaxSignature,
   973             pc->SecPkgContextSizes.cbBlockSize,
   974             pc->SecPkgContextSizes.cbSecurityTrailer);

   Though if you properly initialize the context, then these should all be
   zeroes.

   Similarly at 979 and 980.

 - sspi.cpp:979-983

   Move 980:

       979         ss = QueryContextAttributes(&pc->hCtxt, SECPKG_ATTR_NATIVE_NAMES, &pc->nnames);
   --->980         PP("Names. %ls %ls", pc->nnames.sClientName, pc->nnames.sServerName);
       981         if (!SEC_SUCCESS(ss)) {
       982             return GSS_S_FAILURE;
       983         }

   to after the SEC_SUCCESS():

   979         ss = QueryContextAttributes(&pc->hCtxt, SECPKG_ATTR_NATIVE_NAMES, &pc->nnames);
   980         if (!SEC_SUCCESS(ss)) {
   981             return GSS_S_FAILURE;
   982         }
   983         PP("Names. %ls %ls", pc->nnames.sClientName, pc->nnames.sServerName);

 - sspi.cpp:1067

   Since you don't initialize output parameters early in this function, you
   might goto err and delete garbage:

   1067 err:
   1068     if (n1 != NULL) {
   1069         if (n1->name != NULL) {
   1070             delete[] n1->name;
   1071         }
   1072         delete n1;
   1073         n1 = NULL;
   1074     }
   1075     if (n2 != NULL) {
   1076         if (n2->name != NULL) {

   Just initialize all output parameters early.

 - sspi.cpp:1002

   It should be simple now to implement this...

   1002     PP(">>>> Calling UNIMPLEMENTED gss_accept_sec_context...");
   1003     return GSS_S_FAILURE;

 - gssapi.h:gss_acquire_cred()

        @@ -387,13 +399,13 @@
         
         /* Function Prototypes */
         
         GSS_DLLIMP OM_uint32 gss_acquire_cred(
                 OM_uint32 *,            /* minor_status */
        -        gss_name_t,             /* desired_name */
        +        gss_const_name_t,       /* desired_name */
                 OM_uint32,              /* time_req */
        -        gss_OID_set,            /* desired_mechs */
   ---->+        const gss_OID_set,      /* desired_mechs */
                 gss_cred_usage_t,       /* cred_usage */
                 gss_cred_id_t *,        /* output_cred_handle */
                 gss_OID_set *,          /* actual_mechs */
                 OM_uint32 *             /* time_rec */
         );

   That needs to be `gss_const_OID_set', not `const gss_OID_set'.

   There's a number of these.  Just search for "const gss_" -- any time you see
   that in a function prototype, it's wrong.

 - gssapi.h:gss_init_sec_context()

        @@ -403,100 +415,100 @@
                 gss_cred_id_t *         /* cred_handle */
         );
         
         GSS_DLLIMP OM_uint32 gss_init_sec_context(
                 OM_uint32 *,            /* minor_status */
        -        gss_cred_id_t,          /* claimant_cred_handle */
        +        gss_const_cred_id_t,    /* claimant_cred_handle */
                 gss_ctx_id_t *,         /* context_handle */
        -        gss_name_t,             /* target_name */
        -        gss_OID,                /* mech_type (used to be const) */
        +        gss_const_name_t,       /* target_name */
   ---->+        const gss_OID,          /* mech_type (used to be const) */
                 OM_uint32,              /* req_flags */
                 OM_uint32,              /* time_req */
        -        gss_channel_bindings_t, /* input_chan_bindings */
        -        gss_buffer_t,           /* input_token */
   ---->+        const gss_channel_bindings_t, /* input_chan_bindings */
   ---->+        const gss_buffer_t,           /* input_token */
                 gss_OID *,              /* actual_mech_type */
                 gss_buffer_t,           /* output_token */
                 OM_uint32 *,            /* ret_flags */
                 OM_uint32 *             /* time_rec */
         );

   These too need to be the correct gss_const_* types.

   I won't list all of these...

 - NativeFunc.h

   Same issues here.  E.g.,

        @@ -55,42 +55,42 @@
                                         (OM_uint32 *minor_status,
                                         gss_name_t *name);
         
         typedef OM_uint32 (*IMPORT_NAME_FN_PTR)
                                         (OM_uint32 *minor_status,
        -                                gss_buffer_t input_name_buffer,
        -                                gss_OID input_name_type,
   ---->+                                const gss_buffer_t input_name_buffer,
   ---->+                                const gss_OID input_name_type,
                                         gss_name_t *output_name);

   Though you got many right too:

         typedef OM_uint32 (*COMPARE_NAME_FN_PTR)
                                         (OM_uint32 *minor_status,
        -                                gss_name_t name1,
        -                                gss_name_t name2,
        +                                gss_const_name_t name1,
        +                                gss_const_name_t name2,
                                         int *name_equal);

Done.

This looks much better.  Just a bit more work!

Nico
-- 

From sean.mullan at oracle.com  Fri Feb 15 22:16:39 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 15 Feb 2019 17:16:39 -0500
Subject: RFR: 8159525: Add @FunctionalInterface annotation to PrivilegedAction
 and PrivilegedExceptionAction
Message-ID: <33b56653-0465-2dd1-6aab-7a1aaf988508@oracle.com>

This probably should have been done a while ago, but these interfaces 
are both good examples of functional interfaces, so adding the 
annotation is still justified (and simple).

CSR: https://bugs.openjdk.java.net/browse/JDK-8219145

(Diffs are also in the CSR).

Thanks,
Sean

From yozons at gmail.com  Fri Feb 15 22:33:51 2019
From: yozons at gmail.com (Open eSignForms)
Date: Fri, 15 Feb 2019 14:33:51 -0800
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <c92d46fc-a60f-a0b2-e670-e4fb78efe332@oracle.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <f44821ed-5445-0c19-cd42-315f10b58e05@gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
 <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
 <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
 <32d2fff5-1be5-1201-225e-15ac60982067@gmail.com>
 <648d666c-60a4-bc09-ecd9-f993255040e2@gmail.com>
 <ba795b7d-6100-208e-e463-1c3894612245@oracle.com>
 <cb4f5d6f-cfee-a9f6-0163-5f49147b2b55@gmail.com>
 <fb50c811-9404-9bc4-1aa3-6b06b5785763@oracle.com>
 <5360b44b-9f06-4107-fd9d-165f0b356952@gmail.com>
 <C726A215-FF1B-4827-ADF1-6B87C0EB2355@oracle.com>
 <166893ef-5c96-ba36-3a94-114dd2caeccf@gmail.com>
 <ea7a7809-665d-c8aa-9ebf-f2a54abbaf92@oracle.com>
 <8a01a47e-0984-b732-7cac-ec76e35b11ab@gmail.com>
 <c92d46fc-a60f-a0b2-e670-e4fb78efe332@oracle.com>
Message-ID: <a36dc64c-b76a-6a3b-929a-03cc81beaa6d@gmail.com>

That seems to work, though I used this code instead:

qualifyingPropertiesElement.setAttributeNS("http://www.w3.org/2000/xmlns/","xmlns:xades", 
"http://uri.etsi.org/01903/v1.4.1#");

That's because my xades elements all carry that prefix.? It does seem to 
work.? It's a bit odd to have to code it since the signed XML generates 
it in the expected way, as does the signature validation code.? In the 
end, as long as it works, I'm happy again!

Thanks for all your help.? After I try to push this back into our actual 
code, I'll report back since I need to make sure that this works not 
only on newly signed data using Java 11, but also continues to work on 
previously signed content.? I think it will from prior testing.

Thanks,
David

On 2/15/19 1:21 PM, Sean Mullan wrote:
> I know what the problem is.
>
> You also need to add the actual namespace attribute to your element, 
> for example:
>
> qualifyingPropertiesElement.setAttributeNS(
> "http://www.w3.org/2000/xmlns/", "xmlns", 
> "http://uri.etsi.org/01903/v1.1.1#");
>
> You only need to do that on the top-most parent element in that namespace.
>
> When I made that change to your code, everything generated and 
> verified for me correctly (on JDK 10 anyway, JDK 11 may still have 
> some issues).
>
> --Sean
>
> On 2/15/19 3:11 PM, Open eSignForms wrote:
>>
>> XML namespaces are pretty confusing.? From what little I gather, 
>> unprefixed attributes don't belong to any namespace, not even the 
>> default one.
>>
>> I think I can see the bug in the debugging output.
>>
>> On Java 8 and 10 and 11, I'd guess that the 
>> marshaling/canonicalization has issues when combining differently 
>> namespaced objects.
>>
>> In my working code (also works on Java 11), when my ETSI/XADES 
>> QualifyingProperties element is created specifying my namespace (the 
>> default namespace for the XML document that I'm signing), it works 
>> fine.? If I change my document's default namespace to be the XADES 
>> one, it also works.? But I cannot make them work when both are in 
>> use.? The reason seems to be as follows.
>>
>> 1) The signedXML generated looks great and sensible, with the xades 
>> namespace as expected.
>>
>> ??? <ds:Object>
>> ??????? <xades:QualifyingProperties Id="QualifyingProperties_ID" 
>> Target="#OpenESignForms_Seal" 
>> *xmlns:xades="http://uri.etsi.org/01903/v1.4.1#"*>
>> ??????????? <xades:SignedProperties>
>> ??????????????? <xades:SignedSignatureProperties>
>> <xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime>
>> ??????????????? </xades:SignedSignatureProperties>
>> ??????????????? <xades:SignedDataObjectProperties>
>> ??????????????????? <xades:DataObjectFormat 
>> ObjectReference="#Payload_Reference_ID">
>> <xades:Description>description</xades:Description>
>> <xades:MimeType>text/html</xades:MimeType>
>> ??????????????????? </xades:DataObjectFormat>
>> ??????????????? </xades:SignedDataObjectProperties>
>> ??????????? </xades:SignedProperties>
>> ??????? </xades:QualifyingProperties>
>> ??? </ds:Object>
>>
>> 2) But using the debugging options, it shows this element during 
>> SIGNING (presuming canonicalization) that makes /*no sense*/.? It's 
>> added both the default namespace, the 'dsig' namespace, but doesn't 
>> include the xades namespace. Wwhat does the 'xades' prefix even refer 
>> to in this XML for the signing digest?
>>
>> ??? <xades:QualifyingProperties 
>> *xmlns="http://open.esignforms.com/XMLSchema/2011" 
>> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"* 
>> Id="QualifyingProperties_ID" Target="#OpenESignForms_Seal">
>> ??????? <xades:SignedProperties>
>> ??????????? <xades:SignedSignatureProperties>
>> <xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime>
>> ??????????? </xades:SignedSignatureProperties>
>> ??????????? <xades:SignedDataObjectProperties>
>> ??????????????? <xades:DataObjectFormat 
>> ObjectReference="#Payload_Reference_ID">
>> <xades:Description>description</xades:Description>
>> <xades:MimeType>text/html</xades:MimeType>
>> ??????????????? </xades:DataObjectFormat>
>> ??????????? </xades:SignedDataObjectProperties>
>> ??????? </xades:SignedProperties>
>> ??? </xades:QualifyingProperties>
>>
>> 3) And again, the debugger shows this element during VERIFICATION 
>> (presuming canonicalization) that is excessive, but at least makes 
>> some sense (though there are no default elements nor 'dsig' 
>> elements).? It's added all three namespaces: our default namespace, 
>> the 'dsig' namespace AND the 'xades' namespace.
>>
>> ?? <xades:QualifyingProperties 
>> *xmlns="http://open.esignforms.com/XMLSchema/2011" 
>> xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
>> xmlns:xades="http://uri.etsi.org/01903/v1.4.1#"* 
>> Id="QualifyingProperties_ID" Target="#OpenESignForms_Seal">
>> ??????? <xades:SignedProperties>
>> ??????????? <xades:SignedSignatureProperties>
>> <xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime>
>> ??????????? </xades:SignedSignatureProperties>
>> ??????????? <xades:SignedDataObjectProperties>
>> ??????????????? <xades:DataObjectFormat 
>> ObjectReference="#Payload_Reference_ID">
>> <xades:Description>description</xades:Description>
>> <xades:MimeType>text/html</xades:MimeType>
>> ??????????????? </xades:DataObjectFormat>
>> ??????????? </xades:SignedDataObjectProperties>
>> ??????? </xades:SignedProperties>
>> ??? </xades:QualifyingProperties
>>
>> So the libraries are oddly creating two distinct canonicalized XML 
>> for digesting, with the signing phase seeming to miss the important 
>> 'xades' namespace declaration entirely.? This is no doubt why this is 
>> the only Reference that fails verification as the two.? I'm guessing 
>> that the verification digest is correct when using multiple 
>> namespaced objects/references, but the signing digest is not since it 
>> doesn't include the 'xades' namespace declaration.
>>
>> This seems to hold true for Java 8, 10 and 11.? That is, by 
>> specifying null namespaces on atrributes, the code fails the same 
>> under under Java 11, and the debugging output shows the same odd 
>> namespaces above.? If I use a single namespace, then it signs fine 
>> under Java 8, 10 and 11.
>>
>> David
>>
>>
>> On 2/15/19 11:12 AM, Sean Mullan wrote:
>>> On 2/14/19 9:32 PM, Open eSignForms wrote:
>>>>
>>>> Yes, indeed that's the issue.? But I don't know why/how all those 
>>>> xmlns attributes are added, since I don't directly add them.
>>>>
>>>> I found the only way I can make it work under Java 8, 10 and 11 is 
>>>> to use my common namespace (XML_NAMESPACE_2011 = 
>>>> "http://open.esignforms.com/XMLSchema/2011") for all the XADES 
>>>> elements with the null namespace on all their attributes.? Even if 
>>>> I put that same namespace on the attributes, it then fails.
>>>>
>>>> When I do that, the signed XML generates clean looking XML like this:
>>>>
>>>> ??? <ds:Object>
>>>> ??????? <QualifyingProperties Id="QualifyingProperties_ID" 
>>>> Target="#OpenESignForms_Seal">
>>>> <SignedProperties><SignedSignatureProperties>
>>>> <SigningTime>2019-02-14T17:37:39-08:00</SigningTime>
>>>> ??????????? </SignedSignatureProperties>
>>>> ??????????? <SignedDataObjectProperties>
>>>> ??????????????? <DataObjectFormat 
>>>> ObjectReference="#Payload_Reference_ID">
>>>> <Description>description</Description>
>>>> <MimeType>text/html</MimeType>
>>>> ??????????????? </DataObjectFormat>
>>>> ??????????? </SignedDataObjectProperties>
>>>> ??????????? </SignedProperties>
>>>> ??????? </QualifyingProperties>
>>>> ??? </ds:Object>
>>>> ??? <ds:Object>
>>>> ??????? <ds:SignatureProperties>
>>>> ??????????? <ds:SignatureProperty*Id="OpenESignForms_Seal_ID" 
>>>> Target="#OpenESignForms_Seal"*>
>>>> ??????????????? <OpenESignForms_XmlDigitalSignatureSeal 
>>>> DeploymentHostAddress="192.1.1.1" 
>>>> DeploymentHostName="open.esignforms.com" DeploymentId="1.1.1.1" 
>>>> SignerAddress="192.1.1.1" SignerAgent="No-Browser-Test" 
>>>> Timestamp="2019-02-14T17:37:39-08:00" Version="19.1.19"/>
>>>> ??????????? </ds:SignatureProperty>
>>>> ??????? </ds:SignatureProperties>
>>>> ??? </ds:Object>
>>>>
>>>> But even above, as you can see, the second ds:Object shows 
>>>> ds:SignatureProperty, yet the Id and Target attributes do not 
>>>> include a 'ds:' prefix, which it's my understanding to mean that 
>>>> they default to our XML payload's default namespace.
>>>>
>>> I don't think that's correct, I think attributes w/o a prefix by 
>>> default belong to the namespace of the element in which they are 
>>> defined, which in this case is SignatureProperties and the dsig 
>>> namespace.
>>>
>>> Regarding below, I would forget about JDK 11 for the time being and 
>>> focus on generating a signature with proper XMLNS definitions on JDK 
>>> 10. If you have any problems verifying with that on JDK 10 or prior, 
>>> let me know. The reason is that we will likely be restoring JDK 11 
>>> (and later) to the same state it was in for JDK 10. There were some 
>>> changes to the marshalling code in JDK 11 which is causing these and 
>>> other problems which will likely be backed out.
>>>
>>> --Sean
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190215/5d1a55bb/attachment.html>

From andimullaraj at gmail.com  Sat Feb 16 22:18:19 2019
From: andimullaraj at gmail.com (Andi Mullaraj)
Date: Sat, 16 Feb 2019 14:18:19 -0800
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
 <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
 <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>
Message-ID: <CADvBZ+3NCqhbywEm9W4Wm-Omf2CmX3DyRZKwLM0H=thTYzGNBg@mail.gmail.com>

Hi David,

Thanks for following up. Addressing your questions and statements

1. Then your selector can only be used for SSL things.

The SSLSelector I am proposing may select on (plain)
SocketChannels/ServerSocketChannels, (secure)
SSLSocketChannels/SSLServerSocketChannels, and any mixture of them.

2. What if someone decides to take the exact same approach to solve some
other higher-OSI-layer protocol decoding? Now you have to choose which kind
of protocol you want your selector to support.

They create their own selector. I have hard time imagining one selector
implementation being able to support various protocols at once. In the
current discussion (and if one day this or a similar implementation makes
it into jdk), the selector provider will know how to create (plain)
SocketChannels as well as (secure) SSLSocketChannels.

3. Note that with a plain selector and plain sockets, you *need* a thread
to support the event loop anyway, I mean it has to run somewhere.

I don't have enough knowledge here, but I am thinking it will depend on the
OS ... if the OS provides similar hooks, then I'd say no other threads are
needed -- the thread selecting would be entering a wait() until some
notifier wakes it up ... not vital to the SSL part though.

4. And with SSL, you also need an extra thread or thread pool to handle SSL
authentication tasks, no matter whether you make a subclass of Selector.

True. Resisting the temptation to get into implementation details, I would
say it is the SSLSocketChannel that needs the thread pool (since the calls
to select() should not deal with any crypto etc). In that case the user can
bring its own thread pool (or executor), or use a default one shared by all
channels of that selector provider, depending on their needs.

Best,
--Andi


On Fri, Feb 15, 2019 at 4:56 AM David Lloyd <david.lloyd at redhat.com> wrote:

> Then your selector can only be used for SSL things.  What if someone
> decides to take the exact same approach to solve some other
> higher-OSI-layer protocol decoding?  Now you have to choose which kind
> of protocol you want your selector to support.  Note that with a plain
> selector and plain sockets, you *need* a thread to support the event
> loop anyway, I mean it has to run somewhere.  And with SSL, you also
> need an extra thread or thread pool to handle SSL authentication
> tasks, no matter whether you make a subclass of Selector.
>
> On Fri, Feb 15, 2019 at 2:35 AM Andi Mullaraj <andimullaraj at gmail.com>
> wrote:
> >
> > Hi Dean,
> >
> > Thanks for sharing your experience. I took a look at your links and the
> model and implementation seems quite distant from the classic
> Selector/SelectableChannel though. You seem to allocate a thread per each
> Selector (which I agree is too much of a cost to pay), then fire actively
> [listener.selectorFired()] from that thread towards a SelectorListener ...
> >
> > We can come back to implementation details later, but first I would like
> to ask: any reason we cannot have an SSLSelector which extends the
> java.nio.channels.Selector, an SSLSocketChannel extending a
> java.nio.channels.SocketChannel, and so on? I believe we can, and in this
> doc https://github.com/rouplex/rouplex-niossl/blob/master/README.md I
> have provided the set of base classes that do just that. Since this is a
> dev group I am sharing a code snippet from the doc:
> >
> > As an example, an existing application which is using SocketChannel with
> a Selector for their communications, would be turned into a secure one, by
> simply replacing:
> >
> > Selector selector = Selector.open();
> > SocketChannel socketChannel = SocketChannel.open();
> > socketChannel.register(selector, SelectionKey.OP_READ);
> >
> > while(true) {
> >     selector.select();
> >     for (SocketChannel sc : selector.selectedKeys() {
> >         sc.read(...)
> >     }
> > }
> >
> > with:
> >
> > Selector selector = SSLSelector.open(); // notice the SSL
> > SocketChannel socketChannel = SSLSocketChannel.open();  // notice the SSL
> > socketChannel.register(selector, SelectionKey.OP_READ);
> >
> > while(true) {
> >     selector.select();
> >     for (SocketChannel sc : selector.selectedKeys() {
> >         sc.read(...)
> >     }
> > }
> >
> > How much cooler and easier than that can it get redressing your existing
> service using (performant) plain communications with (performant) secure
> ones? Or create a new (and secure) one using the exact knowledge you
> already have and never having to think SSLEngine again?
> >
> > As I have already mentioned I have worked on such implementation but
> would like to first discuss with the group the merits and possible
> problems/shortcomings of adopting the inheritance model from the plain
> counterparts.
> >
> > Thanks in advance,
> > --Andi
> >
> >
> > On Wed, Feb 13, 2019 at 8:22 AM Dean Hiller <dhiller at twitter.com> wrote:
> >>
> >> I would highly suggest implementing your own for a much better
> understanding.
> >>
> >> I did implement something like what you want and in so doing realized I
> like their decision.  ie. See the heirarchy here
> >>
> https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2/src/main/java/org/webpieces/nio/api/channels
> >>
> >> The TCPChannel could be SSL or not SSL as there are two implementations.
> >>
> >> If you do want an implementation that does what you want though, this
> library does exactly that
> >>
> https://github.com/deanhiller/webpieces/tree/master/core/core-channelmanager2
> >>
> >> which is used in the webpieces webserver
> >> https://github.com/deanhiller/webpieces
> >>
> >> That nio library is standalone even though it is in the webpieces
> repo.  I mean, every component in webpieces is another stand-alone piece.
> >>
> >> The downside is the library owns a thread which typical java libraries
> avoid.  ie. it has to have a thread to poll the selector and read from all
> the sockets to be fed to the thread pools, etc.  I think that is the main
> reason they decided not to have this type of library.  They prefer not to
> be running threads(which I agree, the jdk shouldn't).
> >>
> >> later,
> >> Dean
> >>
> >>
> >>
> >>
> >> On Tue, Feb 12, 2019 at 7:54 PM Sean Mullan <sean.mullan at oracle.com>
> wrote:
> >>>
> >>> Hi Andi,
> >>>
> >>> TLS/JSSE topics are best discussed on the security-dev alias, so I am
> >>> copying that list for more discussion and -bcc-ing core-libs-dev.
> >>>
> >>> --Sean
> >>>
> >>> On 2/11/19 3:29 PM, Andi Mullaraj wrote:
> >>> > Hi java-core community,
> >>> >
> >>> > I have been directed to this channel to discuss matters related to
> Java
> >>> > performant ssl communications.  Maybe this is a topic that has been
> >>> > discussed in the past, in which case I would appreciate if someone
> pointed
> >>> > me to that particular topic.
> >>> >
> >>> > Back in 2002 I personally applauded the java.nio.channels (jdk1.4)
> package,
> >>> > realizing that there was no way to port this to the secure
> communications,
> >>> > due to lack of a comparable implementation for SSL.  But I thought
> it was
> >>> > going to just be matter of time.  A couple of years ago I had to go
> back
> >>> > search for it, and was kind of surprised to find the following in
> >>> >
> http://docs.oracle.com/javase/7/docs/technotes/guides/security/jsse/JSSERefGuide.html#SSLENG
> >>> > :
> >>> >
> >>> > --- begin quote ---
> >>> > Newcomers to the API may wonder "Why not just have an
> SSLSocketChannel
> >>> > which extends java.nio.channels.SocketChannel?" There are two main
> reasons:
> >>> >
> >>> > 1. There were a lot of very difficult questions about what a
> >>> > SSLSocketChannel should be, including its class hierarchy and how it
> should
> >>> > interoperate with Selectors and other types of SocketChannels. Each
> >>> > proposal brought up more questions than answers. It was noted that
> any new
> >>> > API abstraction extended to work with SSL/TLS would require the same
> >>> > significant analysis and could result in large and complex APIs.
> >>> > 2. Any JSSE implementation of a new API would be free to choose the
> "best"
> >>> > I/O & compute strategy, but hiding any of these details is
> inappropriate
> >>> > for those applications needing full control. Any specific
> implementation
> >>> > would be inappropriate for some application segment.
> >>> > --- end quote ---
> >>> >
> >>> > It has been a while since this was stated, and I would really like to
> >>> > revisit it.  I personally believe that the question #1 has a quite
> natural
> >>> > answer, while #2 should not really be a concern if we adhere to the
> spi
> >>> > model where users can bring their own implementation if needed.  I
> know
> >>> > because I have also implemented it (but would like to discuss that
> in a
> >>> > later stage, if it comes to it).
> >>> >
> >>> > The benefit of such implementation would be immense.  Imagine many
> Java
> >>> > services written with nio and which struggle to move to SSL due to
> the
> >>> > great complexity of using SSLEngine (zookeeper service to name one),
> while
> >>> > all they would need to do (if SSLSocketChannels were available) is to
> >>> > instantiate an instance of SSLSocketChannel/SSLSelector when the
> security
> >>> > is required and the rest would stay the same (as in case of plain
> >>> > communication using SocketChannel/Selector).  Another important use
> case is
> >>> > the advent of IOT, where millions of devices, with relatively low
> >>> > throughput would want to protect their communication via SSL.
> >>> >
> >>> > The ways I have seen the community deal with this are mainly:
> >>> >
> >>> > 1. Go through the pain of learning SSLEngine (and hope to get it
> right)
> >>> > 2. Build their services around tested libraries (like Jetty, which
> handle
> >>> > the SSL offload but don't resurface it in SocketChannel/Selector
> paradigm,
> >>> > that also come with their huge set of dependencies, bringing in
> unavoidable
> >>> > version collisions)
> >>> > 3. Use proxies (nginx, ha) to deal with the high number of SSL
> connections
> >>> > and divide the load by scaling horizontally in the back end (making
> for a
> >>> > harder deployment model)
> >>> >
> >>> > We can make this a lot easier!
> >>> >
> >>> > Any feedback is greatly appreciated,
> >>> > Best,
> >>> >
> >>> > Andi Mullaraj
> >>> >
>
>
>
> --
> - DML
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190216/d4571833/attachment.html>

From yozons at gmail.com  Sun Feb 17 17:31:40 2019
From: yozons at gmail.com (Open eSignForms)
Date: Sun, 17 Feb 2019 09:31:40 -0800
Subject: XML Digital Signature throws NAMESPACE_ERR exception under
 OpenJDK 11 that works under Java SE 8, 9 and 10
In-Reply-To: <a36dc64c-b76a-6a3b-929a-03cc81beaa6d@gmail.com>
References: <CAFbjO8mZqry5HFx7ykz4=-mAyaM_nSkj5dBQAkhRqHm2oCzeTQ@mail.gmail.com>
 <ed7424ad-cf32-5a8f-4af0-3236dbaf0a78@oracle.com>
 <beb4e813-6e8a-5326-9341-64f9396b7b24@gmail.com>
 <a82659cb-efab-6e66-7c9b-ea55ae9507f4@oracle.com>
 <bd14b035-5f29-5350-7a04-06cefa609917@gmail.com>
 <8f5d59e0-89be-9146-7e57-5d2cf755043f@oracle.com>
 <66dd5bf7-b1b4-b3cf-b595-2c457b29a6af@gmail.com>
 <32d2fff5-1be5-1201-225e-15ac60982067@gmail.com>
 <648d666c-60a4-bc09-ecd9-f993255040e2@gmail.com>
 <ba795b7d-6100-208e-e463-1c3894612245@oracle.com>
 <cb4f5d6f-cfee-a9f6-0163-5f49147b2b55@gmail.com>
 <fb50c811-9404-9bc4-1aa3-6b06b5785763@oracle.com>
 <5360b44b-9f06-4107-fd9d-165f0b356952@gmail.com>
 <C726A215-FF1B-4827-ADF1-6B87C0EB2355@oracle.com>
 <166893ef-5c96-ba36-3a94-114dd2caeccf@gmail.com>
 <ea7a7809-665d-c8aa-9ebf-f2a54abbaf92@oracle.com>
 <8a01a47e-0984-b732-7cac-ec76e35b11ab@gmail.com>
 <c92d46fc-a60f-a0b2-e670-e4fb78efe332@oracle.com>
 <a36dc64c-b76a-6a3b-929a-03cc81beaa6d@gmail.com>
Message-ID: <26568382-4eeb-78bd-ff45-c39dca0830aa@gmail.com>

It seems that were are able to now make this work under Java 8, 10 and 
11 with the recommended changes.? Of course, I'm sure the bug report 
still is in place so that prior code not using namespaces will continue 
to work under 11.

For validation, we did note that we have to use special code to handle 
the prior version that didn't make use of distinct namespaces because of 
the need to set the "Id" attribute as the 'id' attribute for the Element 
and to even find the QualifyingProperties element as it's under the 
XaDES namespace now.? We decided to handle this by using a new default 
namespace for our XML documents that we sign (which makes sense since 
the underlying structure has changed), so on verification, we can query 
the namespace on the root/document element to process as before, or to 
use the new logic currently required under OpenJDK 11.

Thank you, Sean, so much for all your hard work in finding a resolution.

David


On 2/15/19 2:33 PM, Open eSignForms wrote:
>
> That seems to work, though I used this code instead:
>
> qualifyingPropertiesElement.setAttributeNS("http://www.w3.org/2000/xmlns/","xmlns:xades", 
> "http://uri.etsi.org/01903/v1.4.1#");
>
> That's because my xades elements all carry that prefix.? It does seem 
> to work.? It's a bit odd to have to code it since the signed XML 
> generates it in the expected way, as does the signature validation 
> code.? In the end, as long as it works, I'm happy again!
>
> Thanks for all your help.? After I try to push this back into our 
> actual code, I'll report back since I need to make sure that this 
> works not only on newly signed data using Java 11, but also continues 
> to work on previously signed content.? I think it will from prior testing.
>
> Thanks,
> David
>
> On 2/15/19 1:21 PM, Sean Mullan wrote:
>> I know what the problem is.
>>
>> You also need to add the actual namespace attribute to your element, 
>> for example:
>>
>> qualifyingPropertiesElement.setAttributeNS(
>> "http://www.w3.org/2000/xmlns/", "xmlns", 
>> "http://uri.etsi.org/01903/v1.1.1#");
>>
>> You only need to do that on the top-most parent element in that 
>> namespace.
>>
>> When I made that change to your code, everything generated and 
>> verified for me correctly (on JDK 10 anyway, JDK 11 may still have 
>> some issues).
>>
>> --Sean
>>
>> On 2/15/19 3:11 PM, Open eSignForms wrote:
>>>
>>> XML namespaces are pretty confusing.? From what little I gather, 
>>> unprefixed attributes don't belong to any namespace, not even the 
>>> default one.
>>>
>>> I think I can see the bug in the debugging output.
>>>
>>> On Java 8 and 10 and 11, I'd guess that the 
>>> marshaling/canonicalization has issues when combining differently 
>>> namespaced objects.
>>>
>>> In my working code (also works on Java 11), when my ETSI/XADES 
>>> QualifyingProperties element is created specifying my namespace (the 
>>> default namespace for the XML document that I'm signing), it works 
>>> fine.? If I change my document's default namespace to be the XADES 
>>> one, it also works.? But I cannot make them work when both are in 
>>> use. The reason seems to be as follows.
>>>
>>> 1) The signedXML generated looks great and sensible, with the xades 
>>> namespace as expected.
>>>
>>> ??? <ds:Object>
>>> ??????? <xades:QualifyingProperties Id="QualifyingProperties_ID" 
>>> Target="#OpenESignForms_Seal" 
>>> *xmlns:xades="http://uri.etsi.org/01903/v1.4.1#"*>
>>> ??????????? <xades:SignedProperties>
>>> ??????????????? <xades:SignedSignatureProperties>
>>> <xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime>
>>> ??????????????? </xades:SignedSignatureProperties>
>>> ??????????????? <xades:SignedDataObjectProperties>
>>> ??????????????????? <xades:DataObjectFormat 
>>> ObjectReference="#Payload_Reference_ID">
>>> <xades:Description>description</xades:Description>
>>> <xades:MimeType>text/html</xades:MimeType>
>>> ??????????????????? </xades:DataObjectFormat>
>>> ??????????????? </xades:SignedDataObjectProperties>
>>> ??????????? </xades:SignedProperties>
>>> ??????? </xades:QualifyingProperties>
>>> ??? </ds:Object>
>>>
>>> 2) But using the debugging options, it shows this element during 
>>> SIGNING (presuming canonicalization) that makes /*no sense*/.? It's 
>>> added both the default namespace, the 'dsig' namespace, but doesn't 
>>> include the xades namespace.? Wwhat does the 'xades' prefix even 
>>> refer to in this XML for the signing digest?
>>>
>>> ??? <xades:QualifyingProperties 
>>> *xmlns="http://open.esignforms.com/XMLSchema/2011" 
>>> xmlns:ds="http://www.w3.org/2000/09/xmldsig#"* 
>>> Id="QualifyingProperties_ID" Target="#OpenESignForms_Seal">
>>> ??????? <xades:SignedProperties>
>>> ??????????? <xades:SignedSignatureProperties>
>>> <xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime>
>>> ??????????? </xades:SignedSignatureProperties>
>>> ??????????? <xades:SignedDataObjectProperties>
>>> ??????????????? <xades:DataObjectFormat 
>>> ObjectReference="#Payload_Reference_ID">
>>> <xades:Description>description</xades:Description>
>>> <xades:MimeType>text/html</xades:MimeType>
>>> ??????????????? </xades:DataObjectFormat>
>>> ??????????? </xades:SignedDataObjectProperties>
>>> ??????? </xades:SignedProperties>
>>> ??? </xades:QualifyingProperties>
>>>
>>> 3) And again, the debugger shows this element during VERIFICATION 
>>> (presuming canonicalization) that is excessive, but at least makes 
>>> some sense (though there are no default elements nor 'dsig' 
>>> elements).? It's added all three namespaces: our default namespace, 
>>> the 'dsig' namespace AND the 'xades' namespace.
>>>
>>> ?? <xades:QualifyingProperties 
>>> *xmlns="http://open.esignforms.com/XMLSchema/2011" 
>>> xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 
>>> xmlns:xades="http://uri.etsi.org/01903/v1.4.1#"* 
>>> Id="QualifyingProperties_ID" Target="#OpenESignForms_Seal">
>>> ??????? <xades:SignedProperties>
>>> ??????????? <xades:SignedSignatureProperties>
>>> <xades:SigningTime>2019-02-15T11:30:44-08:00</xades:SigningTime>
>>> ??????????? </xades:SignedSignatureProperties>
>>> ??????????? <xades:SignedDataObjectProperties>
>>> ??????????????? <xades:DataObjectFormat 
>>> ObjectReference="#Payload_Reference_ID">
>>> <xades:Description>description</xades:Description>
>>> <xades:MimeType>text/html</xades:MimeType>
>>> ??????????????? </xades:DataObjectFormat>
>>> ??????????? </xades:SignedDataObjectProperties>
>>> ??????? </xades:SignedProperties>
>>> ??? </xades:QualifyingProperties
>>>
>>> So the libraries are oddly creating two distinct canonicalized XML 
>>> for digesting, with the signing phase seeming to miss the important 
>>> 'xades' namespace declaration entirely.? This is no doubt why this 
>>> is the only Reference that fails verification as the two.? I'm 
>>> guessing that the verification digest is correct when using multiple 
>>> namespaced objects/references, but the signing digest is not since 
>>> it doesn't include the 'xades' namespace declaration.
>>>
>>> This seems to hold true for Java 8, 10 and 11.? That is, by 
>>> specifying null namespaces on atrributes, the code fails the same 
>>> under under Java 11, and the debugging output shows the same odd 
>>> namespaces above.? If I use a single namespace, then it signs fine 
>>> under Java 8, 10 and 11.
>>>
>>> David
>>>
>>>
>>> On 2/15/19 11:12 AM, Sean Mullan wrote:
>>>> On 2/14/19 9:32 PM, Open eSignForms wrote:
>>>>>
>>>>> Yes, indeed that's the issue.? But I don't know why/how all those 
>>>>> xmlns attributes are added, since I don't directly add them.
>>>>>
>>>>> I found the only way I can make it work under Java 8, 10 and 11 is 
>>>>> to use my common namespace (XML_NAMESPACE_2011 = 
>>>>> "http://open.esignforms.com/XMLSchema/2011") for all the XADES 
>>>>> elements with the null namespace on all their attributes.? Even if 
>>>>> I put that same namespace on the attributes, it then fails.
>>>>>
>>>>> When I do that, the signed XML generates clean looking XML like this:
>>>>>
>>>>> ??? <ds:Object>
>>>>> ??????? <QualifyingProperties Id="QualifyingProperties_ID" 
>>>>> Target="#OpenESignForms_Seal">
>>>>> <SignedProperties><SignedSignatureProperties>
>>>>> <SigningTime>2019-02-14T17:37:39-08:00</SigningTime>
>>>>> ??????????? </SignedSignatureProperties>
>>>>> ??????????? <SignedDataObjectProperties>
>>>>> ??????????????? <DataObjectFormat 
>>>>> ObjectReference="#Payload_Reference_ID">
>>>>> <Description>description</Description>
>>>>> <MimeType>text/html</MimeType>
>>>>> ??????????????? </DataObjectFormat>
>>>>> ??????????? </SignedDataObjectProperties>
>>>>> ??????????? </SignedProperties>
>>>>> ??????? </QualifyingProperties>
>>>>> ??? </ds:Object>
>>>>> ??? <ds:Object>
>>>>> ??????? <ds:SignatureProperties>
>>>>> ??????????? <ds:SignatureProperty*Id="OpenESignForms_Seal_ID" 
>>>>> Target="#OpenESignForms_Seal"*>
>>>>> <OpenESignForms_XmlDigitalSignatureSeal 
>>>>> DeploymentHostAddress="192.1.1.1" 
>>>>> DeploymentHostName="open.esignforms.com" DeploymentId="1.1.1.1" 
>>>>> SignerAddress="192.1.1.1" SignerAgent="No-Browser-Test" 
>>>>> Timestamp="2019-02-14T17:37:39-08:00" Version="19.1.19"/>
>>>>> ??????????? </ds:SignatureProperty>
>>>>> ??????? </ds:SignatureProperties>
>>>>> ??? </ds:Object>
>>>>>
>>>>> But even above, as you can see, the second ds:Object shows 
>>>>> ds:SignatureProperty, yet the Id and Target attributes do not 
>>>>> include a 'ds:' prefix, which it's my understanding to mean that 
>>>>> they default to our XML payload's default namespace.
>>>>>
>>>> I don't think that's correct, I think attributes w/o a prefix by 
>>>> default belong to the namespace of the element in which they are 
>>>> defined, which in this case is SignatureProperties and the dsig 
>>>> namespace.
>>>>
>>>> Regarding below, I would forget about JDK 11 for the time being and 
>>>> focus on generating a signature with proper XMLNS definitions on 
>>>> JDK 10. If you have any problems verifying with that on JDK 10 or 
>>>> prior, let me know. The reason is that we will likely be restoring 
>>>> JDK 11 (and later) to the same state it was in for JDK 10. There 
>>>> were some changes to the marshalling code in JDK 11 which is 
>>>> causing these and other problems which will likely be backed out.
>>>>
>>>> --Sean
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190217/92363d03/attachment-0001.html>

From david.lloyd at redhat.com  Mon Feb 18 13:47:05 2019
From: david.lloyd at redhat.com (David Lloyd)
Date: Mon, 18 Feb 2019 07:47:05 -0600
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CADvBZ+3NCqhbywEm9W4Wm-Omf2CmX3DyRZKwLM0H=thTYzGNBg@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
 <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
 <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>
 <CADvBZ+3NCqhbywEm9W4Wm-Omf2CmX3DyRZKwLM0H=thTYzGNBg@mail.gmail.com>
Message-ID: <CANghgrSdRF+EAyt6hBRnExFuDqWsUDWEEFJjWADBCVDjXAav6Q@mail.gmail.com>

On Sat, Feb 16, 2019 at 4:19 PM Andi Mullaraj <andimullaraj at gmail.com> wrote:
> 2. What if someone decides to take the exact same approach to solve some other higher-OSI-layer protocol decoding? Now you have to choose which kind of protocol you want your selector to support.
>
> They create their own selector. I have hard time imagining one selector implementation being able to support various protocols at once.

That is the case today.  I can use one selector event loop today to
support TCP (including SSL) as well as UDP, even SCTP.  The point of
selectors is to combine many things into one event loop.

> 3. Note that with a plain selector and plain sockets, you *need* a thread to support the event loop anyway, I mean it has to run somewhere.
>
> I don't have enough knowledge here, but I am thinking it will depend on the OS ... if the OS provides similar hooks, then I'd say no other threads are needed -- the thread selecting would be entering a wait() until some notifier wakes it up ... not vital to the SSL part though.

It is definitely not OS-dependent; something in the end has to call
selector.select(), and that thing is indeed a thread.

I understand the urge to make SSL with Selectors easier, because right
now it is very painful.  But this approach is unlikely to succeed, at
least in the JDK.



--
- DML

From andimullaraj at gmail.com  Mon Feb 18 23:35:43 2019
From: andimullaraj at gmail.com (Andi Mullaraj)
Date: Mon, 18 Feb 2019 15:35:43 -0800
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CANghgrSdRF+EAyt6hBRnExFuDqWsUDWEEFJjWADBCVDjXAav6Q@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
 <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
 <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>
 <CADvBZ+3NCqhbywEm9W4Wm-Omf2CmX3DyRZKwLM0H=thTYzGNBg@mail.gmail.com>
 <CANghgrSdRF+EAyt6hBRnExFuDqWsUDWEEFJjWADBCVDjXAav6Q@mail.gmail.com>
Message-ID: <CADvBZ+3zPA13tuUH8+aPkNkSTr6jaLYK13KBX7=hFbdzhr=sUg@mail.gmail.com>

Thanks David,

> That is the case today.  I can use one selector event loop today to
> support TCP (including SSL) as well as UDP, even SCTP.  The point of
> selectors is to combine many things into one event loop.

Is this (to use one Selector class only for all protocols) a requirement in
JDK? I haven't seen it, but even if it were (such requirement):
1. I mentioned that the SSLSelector that I am proposing would be able to
select on whatever the default Selector is able to, plus the SSL socket
channels.
2. It would also be able to perform everything without the need for any
extra threads.
3. It would not be anymore an obstacle to additions (such as SCTP) than the
current one (plain sockets) is (if it were to make it to JDK, obviously)

> It is definitely not OS-dependent; something in the end has to call
> selector.select(), and that thing is indeed a thread.

I am beginning to think we might be on different pages here. Someone from
outside the selector calls selector.select(), and all selector's
functionality is handled within the context of the calling thread. So where
is the need for the extra thread here? More specifically, in the
SSLSelector case, a call to its select, ends up usually to a call to its
inner selector.select(), always in the context of the calling thread ... so
same thing again. Why do you think another thread is necessary here (within
the selector itself)?

> I understand the urge to make SSL with Selectors easier, because right
> now it is very painful.

Total agreement. I have one full year of development notes to show how
painful it is. I am talking about a fully functional, completely compatible
Selector, (down to the lock obtention order -- sometimes 6 to 8 locks to be
always kept in order) to vouch for that.

> But this approach is unlikely to succeed, at least in the JDK.

Would you mind clarifying which part doesn't fit the bill? Let's understand
well what is proposed first: A JDK enhancement of
Selector/SocketChannel/ServerSocketChannel able to provide the same exact
functionality across all existing channels (UDP/TCP) as well as SSL. It can
be implemented in pure Java, with no extra threads for selection, with
minimal cpu and memory impact (only for SSL channels) over the current
implementation.

If I were the JDK steward, I wouldn't know what to ask for more. Am not,
and thats the reason I am putting all this under
SSLSelector/SSLSocketChannel implementation, instances of which provide the
same proposed functionality.

Thanks,
--Andi



On Mon, Feb 18, 2019 at 5:47 AM David Lloyd <david.lloyd at redhat.com> wrote:

> On Sat, Feb 16, 2019 at 4:19 PM Andi Mullaraj <andimullaraj at gmail.com>
> wrote:
> > 2. What if someone decides to take the exact same approach to solve some
> other higher-OSI-layer protocol decoding? Now you have to choose which kind
> of protocol you want your selector to support.
> >
> > They create their own selector. I have hard time imagining one selector
> implementation being able to support various protocols at once.
>
> That is the case today.  I can use one selector event loop today to
> support TCP (including SSL) as well as UDP, even SCTP.  The point of
> selectors is to combine many things into one event loop.
>
> > 3. Note that with a plain selector and plain sockets, you *need* a
> thread to support the event loop anyway, I mean it has to run somewhere.
> >
> > I don't have enough knowledge here, but I am thinking it will depend on
> the OS ... if the OS provides similar hooks, then I'd say no other threads
> are needed -- the thread selecting would be entering a wait() until some
> notifier wakes it up ... not vital to the SSL part though.
>
> It is definitely not OS-dependent; something in the end has to call
> selector.select(), and that thing is indeed a thread.
>
> I understand the urge to make SSL with Selectors easier, because right
> now it is very painful.  But this approach is unlikely to succeed, at
> least in the JDK.
>
>
>
> --
> - DML
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190218/e67fdcd0/attachment.html>

From xuelei.fan at oracle.com  Wed Feb 20 05:38:40 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 19 Feb 2019 21:38:40 -0800
Subject: RFR [13] JDK-8219389: Delegated task created by SSLEngine throws
 BufferUnderflowException
Message-ID: <55104090-2235-8f79-47ba-b4ab3ce54ca3@oracle.com>

Hi Tony or Jamil,

Would you please review the following update:
    http://cr.openjdk.java.net/~xuelei/8219389/webrev.00/

BufferUnderflowException might be thrown if the record format does not 
confirm to the formal protocol syntax. The original bug was reported for 
the ClientHello handshake message, and was fixed in JDK-8215790.  I made 
an enhancement so that more handshake messages buffer operating 
RuntimeException could be handled properly.

Thanks,
Xuelei

From anthony.scarpino at oracle.com  Wed Feb 20 06:06:14 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Tue, 19 Feb 2019 22:06:14 -0800
Subject: RFR [13] JDK-8219389: Delegated task created by SSLEngine throws
 BufferUnderflowException
In-Reply-To: <55104090-2235-8f79-47ba-b4ab3ce54ca3@oracle.com>
References: <55104090-2235-8f79-47ba-b4ab3ce54ca3@oracle.com>
Message-ID: <a5991ec0-a4a8-f336-12b2-c2ece48d135f@oracle.com>

On 2/19/19 9:38 PM, Xuelei Fan wrote:
> Hi Tony or Jamil,
> 
> Would you please review the following update:
>  ?? http://cr.openjdk.java.net/~xuelei/8219389/webrev.00/
> 
> BufferUnderflowException might be thrown if the record format does not 
> confirm to the formal protocol syntax. The original bug was reported for 
> the ClientHello handshake message, and was fixed in JDK-8215790.? I made 
> an enhancement so that more handshake messages buffer operating 
> RuntimeException could be handled properly.
> 
> Thanks,
> Xuelei

I'm not saying your approach is incorrect, but I have to wonder if this 
is too generic.  Are you trying to catch situations other than 
RandomCookie throwing an exception?  RandomCookie is only in ClientHello 
and ServerHello, so PostHandshakeContext doesn't look necessary.

If we need a generic catch all consumed extensions, why not just have it 
catch "Exception" and run fatal.  This could eliminate many of the 
current fatal calls in the code and centralize the SSLException messages 
in these two files.  Assuming I understand the idea around this change 
correctly.

Tony

From Xuelei.Fan at Oracle.Com  Wed Feb 20 06:32:50 2019
From: Xuelei.Fan at Oracle.Com (Xuelei Fan)
Date: Tue, 19 Feb 2019 22:32:50 -0800
Subject: RFR [13] JDK-8219389: Delegated task created by SSLEngine throws
 BufferUnderflowException
In-Reply-To: <a5991ec0-a4a8-f336-12b2-c2ece48d135f@oracle.com>
References: <55104090-2235-8f79-47ba-b4ab3ce54ca3@oracle.com>
 <a5991ec0-a4a8-f336-12b2-c2ece48d135f@oracle.com>
Message-ID: <CBFD022C-B93C-4137-BEE6-8477F575A8AD@Oracle.Com>



> On Feb 19, 2019, at 10:06 PM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
> 
>> On 2/19/19 9:38 PM, Xuelei Fan wrote:
>> Hi Tony or Jamil,
>> Would you please review the following update:
>>    http://cr.openjdk.java.net/~xuelei/8219389/webrev.00/
>> BufferUnderflowException might be thrown if the record format does not confirm to the formal protocol syntax. The original bug was reported for the ClientHello handshake message, and was fixed in JDK-8215790.  I made an enhancement so that more handshake messages buffer operating RuntimeException could be handled properly.
>> Thanks,
>> Xuelei
> 
> I'm not saying your approach is incorrect, but I have to wonder if this is too generic.  Are you trying to catch situations other than RandomCookie throwing an exception?  
Yes, it is for cases other than RandomCookie.  Every call to ByteBuffer.get() could throw BUFE unless the length get checked.  The impl code did not always check the buffer length before calling the get() method.

The issues happens only when the record format does not comply to the protocol syntax.  For example, the record length is 5, but the content only have 1 byte.

We can fix these issues with two approaches: checking the buffer length before call get() and put(); or catch the exception in a general way.

> RandomCookie is only in ClientHello and ServerHello, so PostHandshakeContext doesn't look necessary.
> 
> If we need a generic catch all consumed extensions, why not just have it catch "Exception" and run fatal.  
I did not get the point.  It is not the purpose to catch all consumed exceptions, some of which could have been handled.

> This could eliminate many of the current fatal calls in the code and centralize the SSLException messages in these two files.  Assuming I understand the idea around this change correctly.
> 
We can go with checking the buffer length before each call to get(), which means we need to update a lot of code, and make no missing and mistakes.  Using a centralized way is more robust as if we missed somewhere in the handshake message operations like the ClientHello case.

I?m not sure I get the point about the elimination of fatal calls.  I think it is still needed to check the buffer length as soon as possible instead of depending on the two lazy centralized catch, which is used just in case the checking is missed somehow.

Thanks,
Xuelei

> Tony


From philipp.kunz at paratix.ch  Wed Feb 20 12:41:14 2019
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Wed, 20 Feb 2019 13:41:14 +0100
Subject: Jarsigner Fails To Verify Signed By Alias If Alias Given In Wrong Case
Message-ID: <1550666474.2433.13.camel@paratix.ch>

Hi,

When signing a jarfile the specified alias is converted by JavaKeyStore
(storetype JKS) to lower case.
When verifying the jarfile with the same alias, it is currently not
converted by JKS to lower case and jarsigner reports that the jar is
not signed by the alias even after having just signed it with that same
alias if not all characters are in lower case.

I found no statement in the documentation that an alias would support
only lower case or which characters could be used. It could, however,
be worth noting in the documentation of JavaKeyStore or the keytool
that the alias can be changed by the keystore in certain circumstances.
In my opinion, it feels like a bug that aliases are treated differently
when signing and verifying with respect to their upper and lower case.

Find a patch attached. Some explanations, just in case not too obvious
anyway:

- The jarsigner never changed the upper and lower cases of aliases
itself and neither does with the patch. That is now delegated to the
keystore implementation not only for signing but in addition also for
verifying. The fix is therefore not JSK-specific.
- I assume it is correct that the if (store != null) check and the try
catch KeyStoreException can both be moved outside the for loop over the
certificates because before as well as now with the patch the result
was alway 0 if store was null and KeyStoreException can happen only
when loading the keystore, which is certainly true for JKS.
- storeHash is used only by printCert and inKeyStoreForOneSigner and
contains the aliases as values enclosed in parentheses "(" and ")"
which is how it is printed by printCert. It would have probably been
easier to add the parentheses only later in printCert but then I tried
to change as little as possible.
- Two pairs of "result |= " statements were duplicate. Therefore there
are the two methods in the test which show that both actually failed
with "ckaliases.contains" being the offending piece of code. In the
patch I refactored to recombine them.
- I really wonder how "result |= SIGNED_BY_ALIAS;" should be set for
any certificate c and not only the one an alias in ckaliases points at
but I guess that is another story if one at all and might have come
from filling storeHash with all certificates and not only the ones in
ckaliases or so.
- At first glance it might look like a mistake that "alias" is not used
inside the loop over ckaliases but instead of comparing "alias" in
lower case to ckaliases with unspecified case, the certificate c is now
compared to the one gotten from the keystore handling the alias case in
its own way.

Would someone sponsor this fix or can/should it be improved?

Regards,
Philipp
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190220/eac5190c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JavaKeyStoreAliasCaseInsensitive.patch
Type: text/x-patch
Size: 8881 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190220/eac5190c/JavaKeyStoreAliasCaseInsensitive.patch>

From anthony.scarpino at oracle.com  Wed Feb 20 17:54:24 2019
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Wed, 20 Feb 2019 09:54:24 -0800
Subject: RFR [13] JDK-8219389: Delegated task created by SSLEngine throws
 BufferUnderflowException
In-Reply-To: <CBFD022C-B93C-4137-BEE6-8477F575A8AD@Oracle.Com>
References: <55104090-2235-8f79-47ba-b4ab3ce54ca3@oracle.com>
 <a5991ec0-a4a8-f336-12b2-c2ece48d135f@oracle.com>
 <CBFD022C-B93C-4137-BEE6-8477F575A8AD@Oracle.Com>
Message-ID: <d7d930c0-d138-c90a-348c-58cf54cf471a@oracle.com>

I understand. The change looks fine.

Tony

On 2/19/19 10:32 PM, Xuelei Fan wrote:
> 
> 
>> On Feb 19, 2019, at 10:06 PM, Anthony Scarpino <anthony.scarpino at oracle.com> wrote:
>>
>>> On 2/19/19 9:38 PM, Xuelei Fan wrote:
>>> Hi Tony or Jamil,
>>> Would you please review the following update:
>>>     http://cr.openjdk.java.net/~xuelei/8219389/webrev.00/
>>> BufferUnderflowException might be thrown if the record format does not confirm to the formal protocol syntax. The original bug was reported for the ClientHello handshake message, and was fixed in JDK-8215790.  I made an enhancement so that more handshake messages buffer operating RuntimeException could be handled properly.
>>> Thanks,
>>> Xuelei
>>
>> I'm not saying your approach is incorrect, but I have to wonder if this is too generic.  Are you trying to catch situations other than RandomCookie throwing an exception?
> Yes, it is for cases other than RandomCookie.  Every call to ByteBuffer.get() could throw BUFE unless the length get checked.  The impl code did not always check the buffer length before calling the get() method.
> 
> The issues happens only when the record format does not comply to the protocol syntax.  For example, the record length is 5, but the content only have 1 byte.
> 
> We can fix these issues with two approaches: checking the buffer length before call get() and put(); or catch the exception in a general way.
> 
>> RandomCookie is only in ClientHello and ServerHello, so PostHandshakeContext doesn't look necessary.
>>
>> If we need a generic catch all consumed extensions, why not just have it catch "Exception" and run fatal.
> I did not get the point.  It is not the purpose to catch all consumed exceptions, some of which could have been handled.
> 
>> This could eliminate many of the current fatal calls in the code and centralize the SSLException messages in these two files.  Assuming I understand the idea around this change correctly.
>>
> We can go with checking the buffer length before each call to get(), which means we need to update a lot of code, and make no missing and mistakes.  Using a centralized way is more robust as if we missed somewhere in the handshake message operations like the ClientHello case.
> 
> I?m not sure I get the point about the elimination of fatal calls.  I think it is still needed to check the buffer length as soon as possible instead of depending on the two lazy centralized catch, which is used just in case the checking is missed somehow.
> 
> Thanks,
> Xuelei
> 
>> Tony
> 


From xuelei.fan at oracle.com  Wed Feb 20 18:41:54 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 20 Feb 2019 10:41:54 -0800
Subject: RFR 8168069 : X509TrustManagerImpl causes ClassLoader leaks with
 unparseable extensions
In-Reply-To: <dce9b293-0d1f-b249-075e-b0f2776665c9@oracle.com>
References: <dce9b293-0d1f-b249-075e-b0f2776665c9@oracle.com>
Message-ID: <3ea044fd-d06b-a99e-3024-0dc1d7b92910@oracle.com>

ping ...

On 2/8/2019 12:26 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the following update reviewed?
>  ?? http://cr.openjdk.java.net/~xuelei/8168069/webrev.00/
> 
> In the lazy initialization holder in SSLContextImpl, an exception is 
> reserved as static in order to check if the holder is initialized 
> properly.? If the exception had a strong referent to some object, the 
> object will be out of the cycle of garbage collection.
> 
> With this update, the original exception is debug logged, and a new 
> exception with the same exception message as the original one.
> 
> Code cleanup, no new regression test.
> 
> Thanks & Regards,
> Xuelei

From sean.mullan at oracle.com  Wed Feb 20 18:52:21 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 20 Feb 2019 13:52:21 -0500
Subject: RFR 8168069 : X509TrustManagerImpl causes ClassLoader leaks with
 unparseable extensions
In-Reply-To: <3ea044fd-d06b-a99e-3024-0dc1d7b92910@oracle.com>
References: <dce9b293-0d1f-b249-075e-b0f2776665c9@oracle.com>
 <3ea044fd-d06b-a99e-3024-0dc1d7b92910@oracle.com>
Message-ID: <300b9a74-fbb6-364b-636c-1c8878934fa8@oracle.com>

On 2/20/19 1:41 PM, Xuelei Fan wrote:
> ping ...

I took a quick look, but not enough time to understand the full context. 
The exception in the UnparseableExtension can be useful to get a stack 
trace later of why it could not be parsed. Did you think of any other 
way you can fix this?

--Sean

> 
> On 2/8/2019 12:26 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the following update reviewed?
>> ??? http://cr.openjdk.java.net/~xuelei/8168069/webrev.00/
>>
>> In the lazy initialization holder in SSLContextImpl, an exception is 
>> reserved as static in order to check if the holder is initialized 
>> properly.? If the exception had a strong referent to some object, the 
>> object will be out of the cycle of garbage collection.
>>
>> With this update, the original exception is debug logged, and a new 
>> exception with the same exception message as the original one.
>>
>> Code cleanup, no new regression test.
>>
>> Thanks & Regards,
>> Xuelei

From xuelei.fan at oracle.com  Wed Feb 20 19:28:58 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 20 Feb 2019 11:28:58 -0800
Subject: RFR 8168069 : X509TrustManagerImpl causes ClassLoader leaks with
 unparseable extensions
In-Reply-To: <300b9a74-fbb6-364b-636c-1c8878934fa8@oracle.com>
References: <dce9b293-0d1f-b249-075e-b0f2776665c9@oracle.com>
 <3ea044fd-d06b-a99e-3024-0dc1d7b92910@oracle.com>
 <300b9a74-fbb6-364b-636c-1c8878934fa8@oracle.com>
Message-ID: <7da5b272-88a1-6aec-880c-af17b22e03ca@oracle.com>

On 2/20/2019 10:52 AM, Sean Mullan wrote:
> On 2/20/19 1:41 PM, Xuelei Fan wrote:
>> ping ...
> 
> I took a quick look, but not enough time to understand the full context. 
> The exception in the UnparseableExtension can be useful to get a stack 
> trace later of why it could not be parsed. Did you think of any other 
> way you can fix this?
> 
In the UnparseableExtension implementation, the private 'why' variable 
can be used to dump the stack trace later.  But as it is used to get it 
exception message only, I updated to store the exception message only. 
The update does not impact the fix.  It is a kind of DiD fix in case it 
is used in a static field in other places.  We can leave it unchanged if 
you like.

Thanks,
Xuelei

> --Sean
> 
>>
>> On 2/8/2019 12:26 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Could I get the following update reviewed?
>>> ??? http://cr.openjdk.java.net/~xuelei/8168069/webrev.00/
>>>
>>> In the lazy initialization holder in SSLContextImpl, an exception is 
>>> reserved as static in order to check if the holder is initialized 
>>> properly.? If the exception had a strong referent to some object, the 
>>> object will be out of the cycle of garbage collection.
>>>
>>> With this update, the original exception is debug logged, and a new 
>>> exception with the same exception message as the original one.
>>>
>>> Code cleanup, no new regression test.
>>>
>>> Thanks & Regards,
>>> Xuelei

From xuelei.fan at oracle.com  Wed Feb 20 19:38:00 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 20 Feb 2019 11:38:00 -0800
Subject: CSR Review Request, JDK-8160247 Mark deprecated javax.security.cert
 APIs with forRemoval=true
Message-ID: <e51c8926-1a95-2151-d3a0-68f47c15f6c1@oracle.com>

Hi,

Could I get the CSR reviewed:
     https://bugs.openjdk.java.net/browse/JDK-8219472

The javax.security.cert APIs were deprecated in 1.9 but have had the 
following warning (since 1.4.2) in the description of each class:

     Note: The classes in the package javax.security.cert exist for
     compatibility with earlier versions of the Java Secure Sockets
     Extension (JSSE). New applications should instead use the standard
     Java SE certificate classes located in java.security.cert.

Since these earlier versions of JSSE are no longer maintained or 
supported, they should be removed in a future release.

This proposal will add forRemoval=true to the deprecated 
javax.security.cert APIs.

Thanks,
Xuelei

From sean.mullan at oracle.com  Wed Feb 20 20:21:50 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 20 Feb 2019 15:21:50 -0500
Subject: CSR Review Request, JDK-8218932 Remove the internal package
 com.sun.net.ssl
In-Reply-To: <6071db41-91d6-6f55-ddeb-658c93a37280@oracle.com>
References: <6071db41-91d6-6f55-ddeb-658c93a37280@oracle.com>
Message-ID: <a26fe535-8364-c558-dda7-4e7aafbd966a@oracle.com>

In the Problem section:

"This internal package is not exported in the java.base module, and 
applications cannot use them directly any more."

That's not quite true. It is not exported but strong encapsulation is 
not yet enabled by default at runtime so by default the APIs are still 
accessible. At compile time, they are not, but you can still use the 
--add-exports option to override that. I would explain this a bit more.

Is the compatibility risk really minimal? I think there are some 
projects still using it, but they have had plenty of advance warning to 
switch. Maybe it should be low with some additional explanation.

Why are you adding "sun.security.ssl.SunJSSE" as a new provider name? I 
didn't understand why that was related to this issue or useful.


--Sean


On 2/13/19 4:51 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the CSR reviewed:
>  ?? https://bugs.openjdk.java.net/browse/JDK-8218932
> 
> The internal package com.sun.net.ssl had been deprecated since JDK 1.4, 
> and was not exported in the java.base module since JDK 9.? Application 
> cannot use them directly now.? It should be safe to remove them in JDK 13.
> 
> If you are using the internal package for some reason, please let me 
> know the compatibility impact by the end of Feb 20, 2019.
> 
> Thanks,
> Xuelei

From sean.mullan at oracle.com  Wed Feb 20 20:45:16 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 20 Feb 2019 15:45:16 -0500
Subject: RFR 8168069 : X509TrustManagerImpl causes ClassLoader leaks with
 unparseable extensions
In-Reply-To: <7da5b272-88a1-6aec-880c-af17b22e03ca@oracle.com>
References: <dce9b293-0d1f-b249-075e-b0f2776665c9@oracle.com>
 <3ea044fd-d06b-a99e-3024-0dc1d7b92910@oracle.com>
 <300b9a74-fbb6-364b-636c-1c8878934fa8@oracle.com>
 <7da5b272-88a1-6aec-880c-af17b22e03ca@oracle.com>
Message-ID: <26fa997c-4e15-8294-7cca-3b811d2fcdd4@oracle.com>

On 2/20/19 2:28 PM, Xuelei Fan wrote:
> On 2/20/2019 10:52 AM, Sean Mullan wrote:
>> On 2/20/19 1:41 PM, Xuelei Fan wrote:
>>> ping ...
>>
>> I took a quick look, but not enough time to understand the full 
>> context. The exception in the UnparseableExtension can be useful to 
>> get a stack trace later of why it could not be parsed. Did you think 
>> of any other way you can fix this?
>>
> In the UnparseableExtension implementation, the private 'why' variable 
> can be used to dump the stack trace later.? But as it is used to get it 
> exception message only, I updated to store the exception message only. 
> The update does not impact the fix.? It is a kind of DiD fix in case it 
> is used in a static field in other places.? We can leave it unchanged if 
> you like.

Actually I took another closer look at the code and I am ok with your 
change since you can always get the stack trace if you reparse the cert 
and enable debugging.

--Sean

> Thanks,
> Xuelei
> 
>> --Sean
>>
>>>
>>> On 2/8/2019 12:26 PM, Xuelei Fan wrote:
>>>> Hi,
>>>>
>>>> Could I get the following update reviewed?
>>>> ??? http://cr.openjdk.java.net/~xuelei/8168069/webrev.00/
>>>>
>>>> In the lazy initialization holder in SSLContextImpl, an exception is 
>>>> reserved as static in order to check if the holder is initialized 
>>>> properly.? If the exception had a strong referent to some object, 
>>>> the object will be out of the cycle of garbage collection.
>>>>
>>>> With this update, the original exception is debug logged, and a new 
>>>> exception with the same exception message as the original one.
>>>>
>>>> Code cleanup, no new regression test.
>>>>
>>>> Thanks & Regards,
>>>> Xuelei

From xuelei.fan at oracle.com  Thu Feb 21 03:07:48 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 20 Feb 2019 19:07:48 -0800
Subject: CSR Review Request, JDK-8218932 Remove the internal package
 com.sun.net.ssl
In-Reply-To: <a26fe535-8364-c558-dda7-4e7aafbd966a@oracle.com>
References: <6071db41-91d6-6f55-ddeb-658c93a37280@oracle.com>
 <a26fe535-8364-c558-dda7-4e7aafbd966a@oracle.com>
Message-ID: <c3643d1e-57b7-1257-1c9f-19a7c2b86a60@oracle.com>

On 2/20/2019 12:21 PM, Sean Mullan wrote:
> In the Problem section:
> 
> "This internal package is not exported in the java.base module, and 
> applications cannot use them directly any more."
> 
> That's not quite true. It is not exported but strong encapsulation is 
> not yet enabled by default at runtime so by default the APIs are still 
> accessible. At compile time, they are not, but you can still use the 
> --add-exports option to override that. I would explain this a bit more.
> 
Hm, I missed this point.  I will use the 1st part of the sentence only: 
"This internal package is not exported in the java.base module."

> Is the compatibility risk really minimal? I think there are some 
> projects still using it, but they have had plenty of advance warning to 
> switch. Maybe it should be low with some additional explanation.
> 
It's low if the package still can be used by applications since JDK 9.

> Why are you adding "sun.security.ssl.SunJSSE" as a new provider name? I 
> didn't understand why that was related to this issue or useful.
> 
I was hesitated to add a new provider name as well.  It should be fine 
to use "SunJSSE" without a namespace.

I updated the CSR accordingly.

Thanks,
Xuelei

> 
> --Sean
> 
> 
> On 2/13/19 4:51 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the CSR reviewed:
>> ??? https://bugs.openjdk.java.net/browse/JDK-8218932
>>
>> The internal package com.sun.net.ssl had been deprecated since JDK 
>> 1.4, and was not exported in the java.base module since JDK 9.  
>> Application cannot use them directly now.? It should be safe to remove 
>> them in JDK 13.
>>
>> If you are using the internal package for some reason, please let me 
>> know the compatibility impact by the end of Feb 20, 2019.
>>
>> Thanks,
>> Xuelei

From sean.mullan at oracle.com  Thu Feb 21 20:23:48 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 21 Feb 2019 15:23:48 -0500
Subject: CSR Review Request, JDK-8218932 Remove the internal package
 com.sun.net.ssl
In-Reply-To: <c3643d1e-57b7-1257-1c9f-19a7c2b86a60@oracle.com>
References: <6071db41-91d6-6f55-ddeb-658c93a37280@oracle.com>
 <a26fe535-8364-c558-dda7-4e7aafbd966a@oracle.com>
 <c3643d1e-57b7-1257-1c9f-19a7c2b86a60@oracle.com>
Message-ID: <8fbb03da-70bf-470d-8c17-7b1dbe9322b3@oracle.com>

On 2/20/19 10:07 PM, Xuelei Fan wrote:
> On 2/20/2019 12:21 PM, Sean Mullan wrote:
>> In the Problem section:
>>
>> "This internal package is not exported in the java.base module, and 
>> applications cannot use them directly any more."
>>
>> That's not quite true. It is not exported but strong encapsulation is 
>> not yet enabled by default at runtime so by default the APIs are still 
>> accessible. At compile time, they are not, but you can still use the 
>> --add-exports option to override that. I would explain this a bit more.
>>
> Hm, I missed this point.? I will use the 1st part of the sentence only: 
> "This internal package is not exported in the java.base module."
> 
>> Is the compatibility risk really minimal? I think there are some 
>> projects still using it, but they have had plenty of advance warning 
>> to switch. Maybe it should be low with some additional explanation.
>>
> It's low if the package still can be used by applications since JDK 9.
> 
>> Why are you adding "sun.security.ssl.SunJSSE" as a new provider name? 
>> I didn't understand why that was related to this issue or useful.
>>
> I was hesitated to add a new provider name as well.? It should be fine 
> to use "SunJSSE" without a namespace.
> 
> I updated the CSR accordingly.

Thanks, I added my name as Reviewer. I think the Compatibility Kind 
should be "Binary" since removing these APIs (even though they are 
internal) will cause existing applications using them to not link at 
runtime.

--Sean

> 
> Thanks,
> Xuelei
> 
>>
>> --Sean
>>
>>
>> On 2/13/19 4:51 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Could I get the CSR reviewed:
>>> ??? https://bugs.openjdk.java.net/browse/JDK-8218932
>>>
>>> The internal package com.sun.net.ssl had been deprecated since JDK 
>>> 1.4, and was not exported in the java.base module since JDK 9. 
>>> Application cannot use them directly now.? It should be safe to 
>>> remove them in JDK 13.
>>>
>>> If you are using the internal package for some reason, please let me 
>>> know the compatibility impact by the end of Feb 20, 2019.
>>>
>>> Thanks,
>>> Xuelei

From xuelei.fan at oracle.com  Thu Feb 21 21:45:43 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 21 Feb 2019 13:45:43 -0800
Subject: CSR Review Request, JDK-8163326, The default enabled cipher suites
 should prefer forward secrecy
Message-ID: <9d95ca80-e62a-e0b1-4a62-fba5d6f20f2b@oracle.com>

Hi,

Could I get the CSR reviewed?
     https://bugs.openjdk.java.net/browse/JDK-8219545

It is proposed to increase the priority of forward secrecy cipher 
suites, and decrease the priority of RSA key exchange based cipher 
suites for the default enabled cipher suites in the SunJSSE provider.

Thanks,
Xuelei

From xuelei.fan at oracle.com  Fri Feb 22 03:45:20 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 21 Feb 2019 19:45:20 -0800
Subject: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl
Message-ID: <898ee087-a589-de30-c842-770c606c49de@oracle.com>

Hi,

Could I get the following update reviewed:
    http://cr.openjdk.java.net/~xuelei/8215430/webrev.00/

The internal package com.sun.net.ssl had been deprecated since JDK 1.4, 
and was not exported in the java.base module since JDK 9. It should be 
safe to remove them in JDK 13.

For more details, please refer to CSR:
     https://bugs.openjdk.java.net/browse/JDK-8218932

Thanks,
Xuelei

From m.retzlaff at knuddels.de  Fri Feb 22 16:30:27 2019
From: m.retzlaff at knuddels.de (MRetz)
Date: Fri, 22 Feb 2019 09:30:27 -0700 (MST)
Subject: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid
 ECDH ServerKeyExchange with non-default security provider
In-Reply-To: <1c78066a-2415-ebb1-a9bc-f573a861988b@gmail.com>
References: <31ab966b-1f35-7cdd-3541-4b81e2d0bf01@gmail.com>
 <78b2ea15-82e1-57cd-49dc-d042323852b6@gmail.com>
 <75aa940a-33c9-1d13-ec84-1843631adb74@oracle.com>
 <a9b5c9f4-965f-a112-5934-cb204ac97cf1@gmail.com>
 <baaa68fb-97db-c5df-45b9-ecfa111610f4@oracle.com>
 <1c78066a-2415-ebb1-a9bc-f573a861988b@gmail.com>
Message-ID: <1550853027515-0.post@n7.nabble.com>

We are switching currently to openjdk and this is a problem, we now
experience and did not have before. This is our main blocker for doing the
switch. It prevents us to use the android playstore API.

Is there a fix available meanwhile? Can we do anything to help you
investigating this?





--
Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Security-Development-f69724.html

From xuelei.fan at oracle.com  Fri Feb 22 16:40:24 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 22 Feb 2019 08:40:24 -0800
Subject: Java 11 - SSL handshake for ECDH cipher suites trigger Invalid
 ECDH ServerKeyExchange with non-default security provider
In-Reply-To: <1550853027515-0.post@n7.nabble.com>
References: <31ab966b-1f35-7cdd-3541-4b81e2d0bf01@gmail.com>
 <78b2ea15-82e1-57cd-49dc-d042323852b6@gmail.com>
 <75aa940a-33c9-1d13-ec84-1843631adb74@oracle.com>
 <a9b5c9f4-965f-a112-5934-cb204ac97cf1@gmail.com>
 <baaa68fb-97db-c5df-45b9-ecfa111610f4@oracle.com>
 <1c78066a-2415-ebb1-a9bc-f573a861988b@gmail.com>
 <1550853027515-0.post@n7.nabble.com>
Message-ID: <a93321c6-255e-7f95-d937-e4ca4f7293fc@oracle.com>

Hi,

What's the underlying crypto provider?  Please read the discussion on 
about Sept 20, 2018 in this thread.

Would you please help to verify if the parameters used in the crypto 
provider is set after the init method?

Thanks,
Xuelei

On 2/22/2019 8:30 AM, MRetz wrote:
> We are switching currently to openjdk and this is a problem, we now
> experience and did not have before. This is our main blocker for doing the
> switch. It prevents us to use the android playstore API.
> 
> Is there a fix available meanwhile? Can we do anything to help you
> investigating this?
> 
> 
> 
> 
> 
> --
> Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Security-Development-f69724.html
> 

From valerie.peng at oracle.com  Fri Feb 22 21:14:16 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Fri, 22 Feb 2019 13:14:16 -0800
Subject: [13] RFR JDK-8183107: PKCS11 regression regarding checkKeySize
Message-ID: <0197236a-1efb-606d-b1d4-504a23362084@oracle.com>


Anyone can help reviewing this fix? According to the bug report, some 
vendors return 0 for both min/max key size range when queried which 
leads to unexpected errors when SunPKCS11 provider validates key sizes. 
So, I modified the code to work around this. No new regression test as 
this is vendor specific and not an issue for the current PKCS11 
libraries used in regression testing.

Bug: https://bugs.openjdk.java.net/browse/JDK-8183107

Webrev: http://cr.openjdk.java.net/~valeriep/8183107/webrev.00/

Mach5 run is clean.

Thanks,
Valerie

From j.p.cranendonk at gmail.com  Mon Feb 25 07:09:28 2019
From: j.p.cranendonk at gmail.com (Jeroen Cranendonk)
Date: Mon, 25 Feb 2019 08:09:28 +0100
Subject: Status of JDK-8207031
In-Reply-To: <CAJ2eHMbX4L_f69EYk10E6ju0WfdBhJ2+U45P6p58nNcV7RVk4w@mail.gmail.com>
References: <CAJ2eHMbX4L_f69EYk10E6ju0WfdBhJ2+U45P6p58nNcV7RVk4w@mail.gmail.com>
Message-ID: <79e8be80-7b23-26c4-ec50-d3663e0c6d15@gmail.com>

Sorry to bump my own mail, but is there anyone who could possibly have a 
look at this? :)

I've got a feeling everyone is hoping someone else will :)

Cheers!


On 11/02/2019 11:43, Jeroen Cranendonk wrote:
> Hi!
>
> I'm wondering what the status is on the issue: 
> https://bugs.openjdk.java.net/browse/JDK-8207031
>
> I saw a request for review:
> https://mail.openjdk.java.net/pipermail/security-dev/2018-July/017581.html 
>
> But I don't think that's been followed up on?
>
> We are looking to switch to Java 11, and this is becoming one of the 
> biggest blockers to us :)
>
> Cheers!
>
> --000000000000ea0d4005819bf889--) 

From sha.jiang at oracle.com  Mon Feb 25 12:01:28 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Mon, 25 Feb 2019 20:01:28 +0800
Subject: RFR[13] JDK-8215524: Finished message validation failure should be
 decrypt_error alert
Message-ID: <2d4d975d-0095-b15c-69fe-9f54f4bd39e2@oracle.com>

Hi,
When Finished message is validated failed, illegal_parameter is raised 
currently. But per RFC 8446 section 6.2, this error should alert 
decrypt_error.
And according to the same section, if the length of verify_data in 
Finished is incorrect, it should alert decode_error rather than 
illegal_parameter.

This fix is verified by fuzzing testing, but it's hard to add a new 
regression test.

Webrev: http://cr.openjdk.java.net/~jjiang/8215524/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8215524

Best regards,
John Jiang


From xuelei.fan at oracle.com  Mon Feb 25 15:01:55 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 25 Feb 2019 07:01:55 -0800
Subject: RFR[13] JDK-8215524: Finished message validation failure should
 be decrypt_error alert
In-Reply-To: <2d4d975d-0095-b15c-69fe-9f54f4bd39e2@oracle.com>
References: <2d4d975d-0095-b15c-69fe-9f54f4bd39e2@oracle.com>
Message-ID: <a945fae7-686c-32c7-7f28-ec63743e9caa@oracle.com>

Looks fine to me.

Thanks,
Xuelei

On 2/25/2019 4:01 AM, sha.jiang at oracle.com wrote:
> Hi,
> When Finished message is validated failed, illegal_parameter is raised 
> currently. But per RFC 8446 section 6.2, this error should alert 
> decrypt_error.
> And according to the same section, if the length of verify_data in 
> Finished is incorrect, it should alert decode_error rather than 
> illegal_parameter.
> 
> This fix is verified by fuzzing testing, but it's hard to add a new 
> regression test.
> 
> Webrev: http://cr.openjdk.java.net/~jjiang/8215524/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8215524
> 
> Best regards,
> John Jiang
> 

From xuelei.fan at oracle.com  Mon Feb 25 17:36:13 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 25 Feb 2019 09:36:13 -0800
Subject: CSR Review Request JDK-816826, Use server cipher suites preference by
 default
Message-ID: <2ba7b0d4-dff9-f5ef-683d-8fdae4f6cf9a@oracle.com>

Hi,

Could I have the following CSR reviewed?
    https://bugs.openjdk.java.net/browse/JDK-8219657

It is proposing to use server cipher suite preference by default for TLS 
connections in JDK. In the current implementation, the server honors the 
client cipher suite preference by default. It is easier to maintain if 
using the server cipher suite preference, and then the server can have 
more control over the security parameters of TLS connections.

I think the compatibility impact should be minimal.  If there is a known 
risk for you, please let me know by the end of March 4, 2019.

Thanks,
Xuelei

From xuelei.fan at oracle.com  Mon Feb 25 18:07:01 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 25 Feb 2019 10:07:01 -0800
Subject: RFR [13] JDK-8219658: Deadlock in sun.security.ssl.SSLSocketImpl
Message-ID: <c34de381-6d45-dde3-e3c9-f71d8aad9af3@oracle.com>

Hi,

Please review the following update:
    http://cr.openjdk.java.net/~xuelei/8219658/webrev.00/

There could be a deadlock if different threads are used for socket 
closing and reading.

The update is similar to the bug reported proposed fix, and has been 
verified.  No new regression test.

Thanks,
Xuelei

From sean.mullan at oracle.com  Mon Feb 25 20:46:18 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 25 Feb 2019 15:46:18 -0500
Subject: RFR [13] 8217878: ENVELOPING XML signature no longer works in JDK 11
Message-ID: <da254096-8a75-09b5-3436-21d4e1d53d33@oracle.com>

In JDK 11, we included an updated version of Apache Santuario (which the 
JDK XML Signature implementation is based on) [1]. This contained a 
newer XML marshalling implementation, which has caused a couple of 
serious regressions (this one and JDK-8218629 [2]).

After unsuccessfully trying to patch the current implementation, we 
decided to back it out and restore the previous code, which had been 
very stable for many years. The newer implementation is different in 
subtle ways and doesn't really offer any advantages other than a bit of 
reduction in lines of code. The Apache Santuario Project also has backed 
out the implementation.

webrev: http://cr.openjdk.java.net/~mullan/webrevs/8217878/webrev.00/
bug: https://bugs.openjdk.java.net/browse/JDK-8217878

New test cases have also been added for the regressions.

Note that this also fixes JDK-8218629 [2]. Since technically they are 
different issues, I will probably include both bug-ids in this changeset.

--Sean

[1] https://bugs.openjdk.java.net/browse/JDK-8177334
[2] https://bugs.openjdk.java.net/browse/JDK-8218629

From sean.coffey at oracle.com  Mon Feb 25 20:49:16 2019
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Mon, 25 Feb 2019 20:49:16 +0000
Subject: [13] RFR JDK-8218780 "Update MUSCLE PCSC-Lite header files"
In-Reply-To: <902a2671-051a-9d29-f49f-5b29b3fe173d@oracle.com>
References: <902a2671-051a-9d29-f49f-5b29b3fe173d@oracle.com>
Message-ID: <45537743-251c-0ec7-df04-4d2e8196a654@oracle.com>

Looks fine to me Valerie.

regards,
Sean.

On 15/02/2019 20:04, Valerie Peng wrote:
> Hi Sean (Coffey),
>
> Can you please help reviewing this fix? It's about updating the PC/SC 
> lite header files under the MUSCLE directory inside smartcardio 
> module. The header files are from https://pcsclite.apdu.fr/ and minor 
> adjustments are made to pcsc_md.h and pcsc.c to match the header 
> update and replace the old types, i.e. LPTSTR/LPCTSTR, with new ones 
> to avoid compilation fails on MacOs.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8218780
>
> Webrev: http://cr.openjdk.java.net/~valeriep/8218780/webrev.00/
>
> Mach5 run is clean.
>
> Thanks,
> Valerie

From sean.mullan at oracle.com  Mon Feb 25 21:23:19 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 25 Feb 2019 16:23:19 -0500
Subject: CSR Review Request, JDK-8160247 Mark deprecated
 javax.security.cert APIs with forRemoval=true
In-Reply-To: <e51c8926-1a95-2151-d3a0-68f47c15f6c1@oracle.com>
References: <e51c8926-1a95-2151-d3a0-68f47c15f6c1@oracle.com>
Message-ID: <f9bf0a21-8065-195a-a931-be37415e611f@oracle.com>

The diffs seem out of date. The @Deprecated annotations already have 
@since="9".

There are a few JSSE APIs that reference these deprecated APIs that 
should also be marked forRemoval and included in the CSR:

HandshakeCompletedEvent.getPeerCertificateChain()
SSLSession.getPeerCertificateChain()

(I think those are the only ones, but please double-check for others).

--Sean

On 2/20/19 2:38 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the CSR reviewed:
>  ??? https://bugs.openjdk.java.net/browse/JDK-8219472
> 
> The javax.security.cert APIs were deprecated in 1.9 but have had the 
> following warning (since 1.4.2) in the description of each class:
> 
>  ??? Note: The classes in the package javax.security.cert exist for
>  ??? compatibility with earlier versions of the Java Secure Sockets
>  ??? Extension (JSSE). New applications should instead use the standard
>  ??? Java SE certificate classes located in java.security.cert.
> 
> Since these earlier versions of JSSE are no longer maintained or 
> supported, they should be removed in a future release.
> 
> This proposal will add forRemoval=true to the deprecated 
> javax.security.cert APIs.
> 
> Thanks,
> Xuelei

From sean.mullan at oracle.com  Mon Feb 25 21:55:02 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 25 Feb 2019 16:55:02 -0500
Subject: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl
In-Reply-To: <898ee087-a589-de30-c842-770c606c49de@oracle.com>
References: <898ee087-a589-de30-c842-770c606c49de@oracle.com>
Message-ID: <a56327fc-174c-72c4-5c86-5fc2ef4b35ac@oracle.com>

(I'd suggest cross-posting to net-dev since some classes in the 
networking area are also changed).

- AbstractDelegateHttpsURLConnection

It might be less risky to leave the methods as public just in case some 
code out there is using them (even though they are not supposed to).

The rest of this looks ok, pretty straightforward.

--Sean

On 2/21/19 10:45 PM, Xuelei Fan wrote:
> Hi,
> 
> Could I get the following update reviewed:
>  ?? http://cr.openjdk.java.net/~xuelei/8215430/webrev.00/
> 
> The internal package com.sun.net.ssl had been deprecated since JDK 1.4, 
> and was not exported in the java.base module since JDK 9. It should be 
> safe to remove them in JDK 13.
> 
> For more details, please refer to CSR:
>  ??? https://bugs.openjdk.java.net/browse/JDK-8218932
> 
> Thanks,
> Xuelei

From dhiller at twitter.com  Tue Feb 19 16:17:49 2019
From: dhiller at twitter.com (Dean Hiller)
Date: Tue, 19 Feb 2019 09:17:49 -0700
Subject: Java SSLSocketChannel/SSLSelector?
In-Reply-To: <CADvBZ+3zPA13tuUH8+aPkNkSTr6jaLYK13KBX7=hFbdzhr=sUg@mail.gmail.com>
References: <CADvBZ+2745gjRm19x+-0ATxd7FGH=FZwXU+Qnui=a=92D+jzBA@mail.gmail.com>
 <e8f9dd37-4261-948c-782b-dd0d4161e235@oracle.com>
 <CAN1v_zrLuFDNQJZi74JB5rucqRGQ7B-+eec=KXLNgo4XrdfnvA@mail.gmail.com>
 <CADvBZ+1EWTFkSHXNUHGJf4twvKvT==1kz-B6NdPcFb3kYOkiLw@mail.gmail.com>
 <CANghgrRqurKyuiwk5ZhYS8JXscsdw582xUi8PShKna352WKffQ@mail.gmail.com>
 <CADvBZ+3NCqhbywEm9W4Wm-Omf2CmX3DyRZKwLM0H=thTYzGNBg@mail.gmail.com>
 <CANghgrSdRF+EAyt6hBRnExFuDqWsUDWEEFJjWADBCVDjXAav6Q@mail.gmail.com>
 <CADvBZ+3zPA13tuUH8+aPkNkSTr6jaLYK13KBX7=hFbdzhr=sUg@mail.gmail.com>
Message-ID: <CAN1v_zoCkZ4iM5r6Pg+HMshtDRx2RipC95bah71Df=hZgtUG9w@mail.gmail.com>

>
> I am beginning to think we might be on different pages here. Someone from
> outside the selector calls selector.select(), and all selector's
> functionality is handled within the context of the calling thread. So where
> is the need for the extra thread here? More specifically, in the
> SSLSelector case, a call to its select, ends up usually to a call to its
> inner selector.select(), always in the context of the calling thread ... so
> same thing again. Why do you think another thread is necessary here (within
> the selector itself)?
>

That implies multiple threads using 1 selector.  That can be very dangerous
and prone to bugs.  Even with SSL, I would shy away from making something
like that unless putting it behind some library/abstraction like netty,
webpieces channelmanager or something.

In fact, the performance of 1 thread that runs the selector who dishes the
work to a threadpool immediately (N sockets to X threads) has been
amazing!!!  *It was even better than multiple threads on a selector we
found.* This was because that caused lots of contention with locks(slowing
it down).  The contention depended on the application as some apps had more
contention than others.  I would highly advise just sticking 1 thread on
the selector dishing out to a thread pool which removed all contention to
streamline the whole process for speed.

THEN, if you do have a threadpool and an simple implementation that runs
the data serially per socket in the threadpool(this is quite easy to do),
you can do the decryption in the threadpool as well.  webpieces impl does
this as well.

just my 2 cents,
later,

Dean
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190219/75b4fe6c/attachment.html>

From xuelei.fan at oracle.com  Tue Feb 26 03:35:21 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 25 Feb 2019 19:35:21 -0800
Subject: CSR Review Request, JDK-8160247 Mark deprecated
 javax.security.cert APIs with forRemoval=true
In-Reply-To: <f9bf0a21-8065-195a-a931-be37415e611f@oracle.com>
References: <e51c8926-1a95-2151-d3a0-68f47c15f6c1@oracle.com>
 <f9bf0a21-8065-195a-a931-be37415e611f@oracle.com>
Message-ID: <5e8ec64d-b834-612d-7bbc-bf935e142d75@oracle.com>

All comments make sense to me.  I have updated the CSR accordingly.

Thanks,
Xuelei

On 2/25/2019 1:23 PM, Sean Mullan wrote:
> The diffs seem out of date. The @Deprecated annotations already have 
> @since="9".
> 
> There are a few JSSE APIs that reference these deprecated APIs that 
> should also be marked forRemoval and included in the CSR:
> 
> HandshakeCompletedEvent.getPeerCertificateChain()
> SSLSession.getPeerCertificateChain()
> 
> (I think those are the only ones, but please double-check for others).
> 
> --Sean
> 
> On 2/20/19 2:38 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the CSR reviewed:
>> ???? https://bugs.openjdk.java.net/browse/JDK-8219472
>>
>> The javax.security.cert APIs were deprecated in 1.9 but have had the 
>> following warning (since 1.4.2) in the description of each class:
>>
>> ???? Note: The classes in the package javax.security.cert exist for
>> ???? compatibility with earlier versions of the Java Secure Sockets
>> ???? Extension (JSSE). New applications should instead use the standard
>> ???? Java SE certificate classes located in java.security.cert.
>>
>> Since these earlier versions of JSSE are no longer maintained or 
>> supported, they should be removed in a future release.
>>
>> This proposal will add forRemoval=true to the deprecated 
>> javax.security.cert APIs.
>>
>> Thanks,
>> Xuelei

From xuelei.fan at oracle.com  Tue Feb 26 03:53:05 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Mon, 25 Feb 2019 19:53:05 -0800
Subject: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl
In-Reply-To: <a56327fc-174c-72c4-5c86-5fc2ef4b35ac@oracle.com>
References: <898ee087-a589-de30-c842-770c606c49de@oracle.com>
 <a56327fc-174c-72c4-5c86-5fc2ef4b35ac@oracle.com>
Message-ID: <80f63579-2d29-2600-9d92-da1410244fa4@oracle.com>

<Loop in net-dev>

It makes sense to me to leave the AbstractDelegateHttpsURLConnection 
methods as public.  We may need to re-org the code later, but it is out 
of the scope of this update.

Here is the new webrev (only AbstractDelegateHttpsURLConnection updated):
     http://cr.openjdk.java.net/~xuelei/8215430/webrev.01/

Thanks,
Xuelei


On 2/25/2019 1:55 PM, Sean Mullan wrote:
> (I'd suggest cross-posting to net-dev since some classes in the 
> networking area are also changed).
> 
> - AbstractDelegateHttpsURLConnection
> 
> It might be less risky to leave the methods as public just in case some 
> code out there is using them (even though they are not supposed to).
> 
> The rest of this looks ok, pretty straightforward.
> 
> --Sean
> 
> On 2/21/19 10:45 PM, Xuelei Fan wrote:
>> Hi,
>>
>> Could I get the following update reviewed:
>> ??? http://cr.openjdk.java.net/~xuelei/8215430/webrev.00/
>>
>> The internal package com.sun.net.ssl had been deprecated since JDK 
>> 1.4, and was not exported in the java.base module since JDK 9. It 
>> should be safe to remove them in JDK 13.
>>
>> For more details, please refer to CSR:
>> ???? https://bugs.openjdk.java.net/browse/JDK-8218932
>>
>> Thanks,
>> Xuelei

From sean.mullan at oracle.com  Tue Feb 26 15:33:22 2019
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 26 Feb 2019 10:33:22 -0500
Subject: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl
In-Reply-To: <80f63579-2d29-2600-9d92-da1410244fa4@oracle.com>
References: <898ee087-a589-de30-c842-770c606c49de@oracle.com>
 <a56327fc-174c-72c4-5c86-5fc2ef4b35ac@oracle.com>
 <80f63579-2d29-2600-9d92-da1410244fa4@oracle.com>
Message-ID: <c98a04af-23b2-5dd4-6a3e-bb05af459901@oracle.com>

Ok, looks good.

--Sean

On 2/25/19 10:53 PM, Xuelei Fan wrote:
> <Loop in net-dev>
> 
> It makes sense to me to leave the AbstractDelegateHttpsURLConnection 
> methods as public.? We may need to re-org the code later, but it is out 
> of the scope of this update.
> 
> Here is the new webrev (only AbstractDelegateHttpsURLConnection updated):
>  ??? http://cr.openjdk.java.net/~xuelei/8215430/webrev.01/
> 
> Thanks,
> Xuelei
> 
> 
> On 2/25/2019 1:55 PM, Sean Mullan wrote:
>> (I'd suggest cross-posting to net-dev since some classes in the 
>> networking area are also changed).
>>
>> - AbstractDelegateHttpsURLConnection
>>
>> It might be less risky to leave the methods as public just in case 
>> some code out there is using them (even though they are not supposed to).
>>
>> The rest of this looks ok, pretty straightforward.
>>
>> --Sean
>>
>> On 2/21/19 10:45 PM, Xuelei Fan wrote:
>>> Hi,
>>>
>>> Could I get the following update reviewed:
>>> ??? http://cr.openjdk.java.net/~xuelei/8215430/webrev.00/
>>>
>>> The internal package com.sun.net.ssl had been deprecated since JDK 
>>> 1.4, and was not exported in the java.base module since JDK 9. It 
>>> should be safe to remove them in JDK 13.
>>>
>>> For more details, please refer to CSR:
>>> ???? https://bugs.openjdk.java.net/browse/JDK-8218932
>>>
>>> Thanks,
>>> Xuelei

From chris.hegarty at oracle.com  Tue Feb 26 15:33:23 2019
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Tue, 26 Feb 2019 15:33:23 +0000
Subject: RFR [13] JDK-8215430: Remove the internal package com.sun.net.ssl
In-Reply-To: <80f63579-2d29-2600-9d92-da1410244fa4@oracle.com>
References: <898ee087-a589-de30-c842-770c606c49de@oracle.com>
 <a56327fc-174c-72c4-5c86-5fc2ef4b35ac@oracle.com>
 <80f63579-2d29-2600-9d92-da1410244fa4@oracle.com>
Message-ID: <C3A79D63-F1A7-4BFA-B8B6-1AA28199E21D@oracle.com>


> On 26 Feb 2019, at 03:53, Xuelei Fan <xuelei.fan at oracle.com> wrote:
> 
> <Loop in net-dev>
> 
> It makes sense to me to leave the AbstractDelegateHttpsURLConnection methods as public.  We may need to re-org the code later, but it is out of the scope of this update.
> 
> Here is the new webrev (only AbstractDelegateHttpsURLConnection updated):
>    http://cr.openjdk.java.net/~xuelei/8215430/webrev.01/

I think that this is probably ok ( since the package is not exported ),
but it seems a little distasteful to not have the API move through
the terminal deprecation route before being removed.

-Chris.

From jamil.j.nimeh at oracle.com  Tue Feb 26 16:57:50 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 26 Feb 2019 08:57:50 -0800
Subject: [13] RFR JDK-8183107: PKCS11 regression regarding checkKeySize
In-Reply-To: <0197236a-1efb-606d-b1d4-504a23362084@oracle.com>
References: <0197236a-1efb-606d-b1d4-504a23362084@oracle.com>
Message-ID: <e0381bd7-439b-ed83-3cf4-f97f0773b8f2@oracle.com>

Hi Valerie, looks good, I only had one comment and it's more of a nit 
than anything else.

  * P11KeyPairGenerator.java
      o 122-124: I think those lines could be safely moved under the
        algorithm.equals("RSA") clause up at line 113 and get rid of the
        extra check at line 121.

--Jamil

On 2/22/19 1:14 PM, Valerie Peng wrote:
>
> Anyone can help reviewing this fix? According to the bug report, some 
> vendors return 0 for both min/max key size range when queried which 
> leads to unexpected errors when SunPKCS11 provider validates key 
> sizes. So, I modified the code to work around this. No new regression 
> test as this is vendor specific and not an issue for the current 
> PKCS11 libraries used in regression testing.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8183107
>
> Webrev: http://cr.openjdk.java.net/~valeriep/8183107/webrev.00/
>
> Mach5 run is clean.
>
> Thanks,
> Valerie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190226/b8128cd6/attachment.html>

From valerie.peng at oracle.com  Tue Feb 26 22:19:13 2019
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 26 Feb 2019 14:19:13 -0800
Subject: Status of JDK-8207031
In-Reply-To: <79e8be80-7b23-26c4-ec50-d3663e0c6d15@gmail.com>
References: <CAJ2eHMbX4L_f69EYk10E6ju0WfdBhJ2+U45P6p58nNcV7RVk4w@mail.gmail.com>
 <79e8be80-7b23-26c4-ec50-d3663e0c6d15@gmail.com>
Message-ID: <6f3681ab-dd14-53a9-e53c-4a381ad1bff8@oracle.com>

I recall that there was some debate with the fix internally. So, maybe 
more polishing is needed. Just my guess.

If it's really critical to you, maybe you should add a comment to the 
bug record. Currently, it's just a P4 bug which may not get much cycles 
depending on the RE's cycles as well as the complexity of the fix.

Valerie

On 2/24/2019 11:09 PM, Jeroen Cranendonk wrote:
> Sorry to bump my own mail, but is there anyone who could possibly have 
> a look at this? :)
>
> I've got a feeling everyone is hoping someone else will :)
>
> Cheers!
>
>
> On 11/02/2019 11:43, Jeroen Cranendonk wrote:
>> Hi!
>>
>> I'm wondering what the status is on the issue: 
>> https://bugs.openjdk.java.net/browse/JDK-8207031
>>
>> I saw a request for review:
>> https://mail.openjdk.java.net/pipermail/security-dev/2018-July/017581.html 
>>
>> But I don't think that's been followed up on?
>>
>> We are looking to switch to Java 11, and this is becoming one of the 
>> biggest blockers to us :)
>>
>> Cheers!
>>
>> --000000000000ea0d4005819bf889--) 

From philipp.kunz at paratix.ch  Wed Feb 27 07:25:32 2019
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Wed, 27 Feb 2019 08:25:32 +0100
Subject: How about a ToolProvider for jarsigner (and maybe keytool)?
Message-ID: <1551252332.2433.32.camel@paratix.ch>

Hi,

Quite a few command line tools are available through
java.util.spi.ToolProvider. But not so jarsigner and keytool. If that
finds some common interest, I'd be glad to contribute a patch or two.

Advantages of having jarsigner and/or keytool available as a tool
(though that could certainly be achieved in another way as well) would
be
- Explicit Stdin, Stdout, and Stderr as parameters (possible already
now by forking a separate process?with the overhead of running the
tools in their own vm)
- Easy prevention of all possible calls to System.exit upon
unfavourable command line paramters (at least with jarsigner, and only
when working with?sun.security.tools.jarsigner.Main and not with
jdk.security.jarsigner.JarSigner)
- Easier to detect whether a jarsigner or keytool tool is available on
the class or module path or not.
- Those who are more familiar with the command line options can use
them also programmatically.

An example seems to be?JLinkSigningTest.java, [1]. Even though only a
test and in that context not actually severe but still not such a bad
example. I figure the following should not happen in real code:
- The tests catches an Exception which is never thrown (especially not
for the reason in the message, "jarsigner not found", I'd expect at
best a NoClassDefFoundError but which would not be caught there).
- Jarsigner (sun.security.tools.jarsigner.Main) will call System.exit
instead of throwing an exception (8 occurrences of System.exit in [2])
for certain command line args
- If command line arguments would be specified such that jarsigner
would prompt for input, it would be most probably stuck indefinitely.

I tried to search existing resources about the topic but found almost
nothing, potentially related [3], [4], and [5].

I'm not entirely sure, if java.util.spi.ToolProvider is preferred over
javax.tools.ToolProvider (or java.util.ServiceLoader). [7] might be a
hint that java.util.spi.ToolProvider is more current than
javax.tools.ToolProvider.

An additional point for keytool and jarsigner as opposed to jar, javac,
and other tools is that both jarsigner and keytool can use stdin when
prompting for passwords or maybe X.509 details which is not currently
possible through the api of java.util.spi.ToolProvider and would
require an additional parameter for Stdin such as in [6]. I would
propose that when jarsigner or keytool are invoked without a Stdin that
they throw an exception or return a non-zero exit code as their return
value immediately whenever they would have otherwise waited for input.

Some system properties also have influence on the operation of
jarsigner and possibly keytool (for example user.language and
java.security.properties among probably others) which could not
necessarily be set individually for each invocation of a tool gotten by
a ToolProvider but probably that would not be necessary in many cases
anyway.

Just like [3] sounds according to its subject,
jdk.security.jarsigner.JarSigner already has a useful API, so the need
for a ToolProvider is probably not that big. The current
jdk.security.jarsigner.JarSigner API, however, expects a key or
certificate or chain of certificates to be provided through the API and
therefore does not leverage the jarsigner and keytool command line
tools' keystore accessing features and aliases. I also don't see how it
would provide a possibility to verify a signed JAR but that could as
well be achieved in another way than with a ToolProvider.

It might be a bit of a challenge to catch all System.out and System.err
such as in sun.security.tools.KeyStoreUtil.getPassWithModifier or
sun.security.util.Debug or from whatever provider classes involved with
algorithms loaded with "-providerClass" or?"-altsigner" arguments. One
conceivable approach might be the one used in the compiler with a
context object holding references to Stdout and Stderr. What I don't
like for now in the attached patch is that wrapping System.out or
System.err PrintStreams into PrintWriters is repeated a few times and I
wonder if that could be refactored or recombined into another
PrintWriter constructor or PrintStream.toPrintWriter or something...

So far I haven't found an overview over all the tools available through
java.util.spi.ToolProvider other than the example in ToolProvider#name
or other documentation that might have to be updated with introducing
jarsigner as a tool.

Also I wonder if Stdin/System.in should be added to the ToolProvider
interface or a run method with only args that takes Stdin, Stdout, and
Stderr from System.in, System.out, and System.err but I guess that can
be discussed independently.

Attached is a patch with JarSignerToolProvider that provides jarsigner
as a tool. It's not yet meant as ready to merge but shows that it is
possible and more or less how big the change is.

I'm not really familiar at all with the processes involved with such a
proposal and would appreciate greatly any kind of guidance. Was
this?mailing list the right place to propose it?

Regards,
Philipp


[1] http://hg.openjdk.org/jdk/jdk/file/9c3fe09f69bc/test/jdk/tools/jlin
k/JLinkSigningTest.java#l79
[2] http://hg.openjdk.org/jdk/jdk/file/9c3fe09f69bc/src/jdk.jartool/sha
re/classes/sun/security/tools/jarsigner/Main.java
[3] https://bugs.openjdk.java.net/browse/JDK-8056174
[4] https://bugs.openjdk.java.net/browse/JDK-8058778
[5] http://mail.openjdk.java.net/pipermail/security-dev/2015-March/0118
31.html
[6] http://hg.openjdk.org/jdk/jdk/file/9c3fe09f69bc/src/jdk.compiler/sh
are/classes/com/sun/tools/javac/api/JavacTool.java#l203
[7] http://hg.openjdk.org/jdk/jdk/file/9c3fe09f69bc/src/java.compiler/s
hare/classes/javax/tools/ToolProvider.java#l90
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190227/7d6fdc2e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: JarSignerToolProvider.patch
Type: text/x-patch
Size: 51577 bytes
Desc: not available
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190227/7d6fdc2e/JarSignerToolProvider-0001.patch>

From weijun.wang at oracle.com  Wed Feb 27 08:48:05 2019
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 27 Feb 2019 16:48:05 +0800
Subject: How about a ToolProvider for jarsigner (and maybe keytool)?
In-Reply-To: <1551252332.2433.32.camel@paratix.ch>
References: <1551252332.2433.32.camel@paratix.ch>
Message-ID: <4AA6DE7E-584A-4F9E-9889-FE6ED81F3306@oracle.com>

Hi Philipp,

Thanks for looking into this. 

We have thought about this several years ago (when ToolProvider was created and javac became a tool) but had decided not to do it. 

There were several reasons:

1. These tools have too many functions, esp, keytool. 

2. There are user interactions that do not match the ToolProvider style, especially, the password input. 

3. A lot of functions are already available through public APIs, for example, verification of signed jars, reading certificates, managing entries in a keystore. 

So at last we decided to only extract some
functions (that can only be down with the tool) into individual APIs and let these tools call them. This includes:

1. Signing of jars. 

2. Generating certificates and certificate requests. 

The first is now a JDK API. The second one is stalled. We are not sure how useful it is and it?s a pain describing X.509 extensions.

Any more discussion is welcome. 

Thanks,
Max

> ? 2019?2?27??15:25?Philipp Kunz <philipp.kunz at paratix.ch> ???
> 
> Quite a few command line tools are available through java.util.spi.ToolProvider. But not so jarsigner and keytool.


From j.p.cranendonk at gmail.com  Wed Feb 27 17:09:39 2019
From: j.p.cranendonk at gmail.com (Jeroen Cranendonk)
Date: Wed, 27 Feb 2019 18:09:39 +0100
Subject: Status of JDK-8207031
In-Reply-To: <6f3681ab-dd14-53a9-e53c-4a381ad1bff8@oracle.com>
References: <CAJ2eHMbX4L_f69EYk10E6ju0WfdBhJ2+U45P6p58nNcV7RVk4w@mail.gmail.com>
 <79e8be80-7b23-26c4-ec50-d3663e0c6d15@gmail.com>
 <6f3681ab-dd14-53a9-e53c-4a381ad1bff8@oracle.com>
Message-ID: <ccfb5777-c39c-b5b9-c25d-407aa118df3b@gmail.com>

Hi!

Thanks for the reply :)

To add comments on the JIRA one needs to be at least an OpenJDK
Contributor I think, which I am not (and which would involve signing
the Oracle Contributor Agreement).
So the mailing list is my only way of communication on the issue I
think, feel free to correct me if I am wrong :)

I think/hope that over the next two weeks we can do an in depth
analysis of the problem, I will know better how high the prio is for
us then.
Right now I'm not sure yet if this is limited to certain
ciphers/protocols, if it's only client,server, or both, and there
might be a new pkcs11 dll which we can use which may or may not
support the CKM_SSL3_PRE_MASTER_KEY_GEN mechanism, which would be a
work around.

I take it you don't know the details of the internal debate? Was it
more whether to fix this, or on which approach to take?

Cheers!

Jeroen Cranendonk
     Java Developer

On 26/02/2019 23:19, Valerie Peng wrote:
> I recall that there was some debate with the fix internally. So, maybe 
> more polishing is needed. Just my guess.
>
> If it's really critical to you, maybe you should add a comment to the 
> bug record. Currently, it's just a P4 bug which may not get much 
> cycles depending on the RE's cycles as well as the complexity of the fix.
>
> Valerie
>
> On 2/24/2019 11:09 PM, Jeroen Cranendonk wrote:
>> Sorry to bump my own mail, but is there anyone who could possibly 
>> have a look at this? :)
>>
>> I've got a feeling everyone is hoping someone else will :)
>>
>> Cheers!
>>
>>
>> On 11/02/2019 11:43, Jeroen Cranendonk wrote:
>>> Hi!
>>>
>>> I'm wondering what the status is on the issue: 
>>> https://bugs.openjdk.java.net/browse/JDK-8207031
>>>
>>> I saw a request for review:
>>> https://mail.openjdk.java.net/pipermail/security-dev/2018-July/017581.html 
>>>
>>> But I don't think that's been followed up on?
>>>
>>> We are looking to switch to Java 11, and this is becoming one of the 
>>> biggest blockers to us :)
>>>
>>> Cheers!
>>>
>>> --000000000000ea0d4005819bf889--) 

From sha.jiang at oracle.com  Thu Feb 28 02:20:11 2019
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Thu, 28 Feb 2019 10:20:11 +0800
Subject: RFR[13] JDK-8219723: javax/net/ssl/compatibility/Compatibility.java
 failed on some SNI cases
Message-ID: <fb6e0626-346c-9490-323a-33079db65531@oracle.com>

Hi,
Test javax/net/ssl/compatibility/Compatibility.java failed due to the 
associated certificates are expired.
This fix just re-generates the certificates and set much longer validity 
period.

Issue: https://bugs.openjdk.java.net/browse/JDK-8219723
Webrev: http://cr.openjdk.java.net/~jjiang/8219723/webrev.00/

Best regards,
John Jiang


From xuelei.fan at oracle.com  Thu Feb 28 03:56:31 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 27 Feb 2019 19:56:31 -0800
Subject: RFR[13] JDK-8219723:
 javax/net/ssl/compatibility/Compatibility.java failed on some SNI cases
In-Reply-To: <fb6e0626-346c-9490-323a-33079db65531@oracle.com>
References: <fb6e0626-346c-9490-323a-33079db65531@oracle.com>
Message-ID: <a4f3030c-65ec-7a0b-43c3-f167d7e83e8c@oracle.com>

Looks good to me.

Thanks,
Xuelei

On 2/27/2019 6:20 PM, sha.jiang at oracle.com wrote:
> Hi,
> Test javax/net/ssl/compatibility/Compatibility.java failed due to the 
> associated certificates are expired.
> This fix just re-generates the certificates and set much longer validity 
> period.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8219723
> Webrev: http://cr.openjdk.java.net/~jjiang/8219723/webrev.00/
> 
> Best regards,
> John Jiang
> 

From norman.maurer at googlemail.com  Thu Feb 28 08:24:49 2019
From: norman.maurer at googlemail.com (Norman Maurer)
Date: Thu, 28 Feb 2019 09:24:49 +0100
Subject: SSLEngine.wrap(...) returns NOT_HANDSHAKING even when the alert was
 not consumed yet in latest JDK12 release (possible regression).
Message-ID: <F2454990-F28C-4295-93EB-149A1F392F06@googlemail.com>

Hi all,

I think I found a possible regression / bug in the latest JDK12 release when trying to upgrade the Netty CI server to test with the latest JDK12 release. The problem is that SSLEngine.wrap(?) returns NOT_HANDSHAKING even when there are bytes left that should be consumed (the alert itself). My understanding is that it should only return ?NOT_HANDSHAKING? once we also consumed the alert. Please correct me if I wrong tho.

I pushed a reproducer for this here:

https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug <https://github.com/normanmaurer/jdk12_ssl_engine_unwrap_bug>

When running this on the latest JDK12 release (and later JDK versions) it will fail with an AssertionError, while everything works as expected when using earlier Java versions.

Here is the Java version I used to reproduce:

# java -version
openjdk version "12" 2019-03-19
OpenJDK Runtime Environment (build 12+33)
OpenJDK 64-Bit Server VM (build 12+33, mixed mode, sharing)


It seems like this was not always the case for Java12 tho, as I can not reproduce it with this version:

#java -version
openjdk version "12-ea" 2019-03-19
OpenJDK Runtime Environment (build 12-ea+27)
OpenJDK 64-Bit Server VM (build 12-ea+27, mixed mode, sharing)

I don't have all the ?in between? releases on my machine atm so I can not tell exactly on which release this ?broke? :/

Thanks
Norman



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.java.net/pipermail/security-dev/attachments/20190228/4c8e4726/attachment.html>

From xuelei.fan at oracle.com  Thu Feb 28 17:52:29 2019
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 28 Feb 2019 09:52:29 -0800
Subject: RFR [13] JDK-8219658: Deadlock in sun.security.ssl.SSLSocketImpl
In-Reply-To: <c34de381-6d45-dde3-e3c9-f71d8aad9af3@oracle.com>
References: <c34de381-6d45-dde3-e3c9-f71d8aad9af3@oracle.com>
Message-ID: <40e7127a-bf94-3f22-d7ab-d23b6179fad7@oracle.com>

ping ...

On 2/25/2019 10:07 AM, Xuelei Fan wrote:
> Hi,
> 
> Please review the following update:
>  ?? http://cr.openjdk.java.net/~xuelei/8219658/webrev.00/
> 
> There could be a deadlock if different threads are used for socket 
> closing and reading.
> 
> The update is similar to the bug reported proposed fix, and has been 
> verified.? No new regression test.
> 
> Thanks,
> Xuelei

From jamil.j.nimeh at oracle.com  Thu Feb 28 17:54:06 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 28 Feb 2019 09:54:06 -0800
Subject: RFR[13] JDK-8219723:
 javax/net/ssl/compatibility/Compatibility.java failed on some SNI cases
In-Reply-To: <fb6e0626-346c-9490-323a-33079db65531@oracle.com>
References: <fb6e0626-346c-9490-323a-33079db65531@oracle.com>
Message-ID: <6364ede7-ab43-6f03-af3d-40d8414120f8@oracle.com>

This comment doesn't directly apply to this fix, but tests that depend 
on the certs from Cert.java and have configurable PKIXParameters might 
also just set setDate to something in the middle of this validity period 
so you never have to worry about regenerating the certs due to date 
issues.? That may not work for all your tests though, if? you're not 
customizing the trust managers with PKIXParameter objects.

Just something to consider as you're going forward, no changes to this 
webrev.

--Jamil

On 2/27/2019 6:20 PM, sha.jiang at oracle.com wrote:
> Hi,
> Test javax/net/ssl/compatibility/Compatibility.java failed due to the 
> associated certificates are expired.
> This fix just re-generates the certificates and set much longer 
> validity period.
>
> Issue: https://bugs.openjdk.java.net/browse/JDK-8219723
> Webrev: http://cr.openjdk.java.net/~jjiang/8219723/webrev.00/
>
> Best regards,
> John Jiang
>


From jamil.j.nimeh at oracle.com  Thu Feb 28 17:57:29 2019
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Thu, 28 Feb 2019 09:57:29 -0800
Subject: RFR [13] JDK-8219658: Deadlock in sun.security.ssl.SSLSocketImpl
In-Reply-To: <40e7127a-bf94-3f22-d7ab-d23b6179fad7@oracle.com>
References: <c34de381-6d45-dde3-e3c9-f71d8aad9af3@oracle.com>
 <40e7127a-bf94-3f22-d7ab-d23b6179fad7@oracle.com>
Message-ID: <49c45ea0-4e86-2d6b-9fb6-3df468c8bcd3@oracle.com>

Looks good.

On 2/28/2019 9:52 AM, Xuelei Fan wrote:
> ping ...
>
> On 2/25/2019 10:07 AM, Xuelei Fan wrote:
>> Hi,
>>
>> Please review the following update:
>> ??? http://cr.openjdk.java.net/~xuelei/8219658/webrev.00/
>>
>> There could be a deadlock if different threads are used for socket 
>> closing and reading.
>>
>> The update is similar to the bug reported proposed fix, and has been 
>> verified.? No new regression test.
>>
>> Thanks,
>> Xuelei