From bradford.wetmore at oracle.com Tue May 1 01:07:13 2018 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Mon, 30 Apr 2018 18:07:13 -0700 Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm as in PKCS#1 v2.2" In-Reply-To: <77185686-9640-ed7d-a30d-d8651fd6c280@oracle.com> References: <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com> <77185686-9640-ed7d-a30d-d8651fd6c280@oracle.com> Message-ID: I have not reviewed the tests, but the following is my deep-dive on the code. Mostly nits. I stopped making comments about javadoc style issues ("." at ends of fragments, indentation problems), except where you were making changes anyway. I realize the existing code has a bunch of problems that we shouldn't gratuitously break. >> PSSParameterSpec.java >> --------------------- >> Maybe add trailerFieldBC(1)? > Not sure what do u want me to add. A constants for TrailerFieldBC, or else? Yes that was my thought. A constant field for TrailerFieldBC. When I was trying to construct a PSSParameterSpec, the integer value to use is "1", but if you don't read ASN.1 well enough, one might be tempted to pass "0xbc" instead. If you weren't using DEFAULT, the call would be like this: PSSParameterSpec pssSpec = new PSSParameterSpec( "SHA-256", "MGF1", MGF1ParameterSpec.SHA256, 20, 1); -> PSSParameterSpec pssSpec = new PSSParameterSpec( "SHA-256", "MGF1", MGF1ParameterSpec.SHA256, 20, PSSParameterSpec.trailerBC); >> 157/202: We talked about this in person, but I wanted to mention here >> for a wider audience.? I had concerns about this typo, and any interop >> problems this might bring.? I looked over the Bouncy Castle impl, and >> it appears as though they also assumed it to be bytes, not bits.? Can >> you check with the other vendors who might have their own PSS >> implementations and verify this is not going to be a problem?? I >> talked with our CSR lead (Joe Darcy), he doesn't think it should be a >> problem if other impls are using bytes. > Thanks for checking on BouncyCastle, given the default is stated in the > class javadoc to be 20 and the norm is to use byte as the unit, I feel > the chance of other vendors using bits are very low. We can remind other > vendors about this typo, but we should fix this regardless. Ok. >> RSAPrivateCrtKeySpec.java >> ------------------------- >> 60/88:? Do you want to add v1.2? >> > I think you mean v2.2. Actually, I prefer to only mention the version > information in class javadoc. Easier to maintain this way. So, I > actually removed the version info from the method javadoc of other > classes for consistency. Good plan. Thanks, and Ok. java.base/.../java/security/interfaces/package-info.java -------------------------------------------------------- Suggest mentioning RFC 8017, as "November 2016" doesn't make it easy to find this particular version. The RSA version came out in October 27, 2012. Whether you want to add the hyperlinking is up to you, I notice you've added in other places (e.g. RSAPrivateCrtKeySpec.java) java.base/.../java/security/SignedObject.java --------------------------------------------- 59: In the javadoc, it looks like there is a missing opening brace that isn't closed with the one at line 64. However, the one at line 64 is not showing up in the generated output either. Weird. 152-209: The code in the other constructor is 99% the same, consider moving this setup code to a common method. 173: Exactly the same wording here as the previous constructor. Should we endeavor to make them different? 182/195/307/339-340: indention problems. 223: If you're going to fix this style problem, please fix the indention problem also. java.base/.../java/security/spec/package-info.java -------------------------------------------------- Suggest at least mentioning RFC 8017. java.base/.../java/security/spec/RSAKeyGenParameterSpec.java ------------------------------------------------------------ 60: public-exponent value with no key parameters -> public-exponent value, and no key parameters 71: public-exponent value and key parameters -> public-exponent value, and key parameters java.base/.../java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java -------------------------------------------------------------------- A general nit throughout your APIs, when you're doing multi-line things for your @params/@return/@exception, usually should be indented to help readability of the source. * @param otherPrimeInfo triplets of the rest of primes, null can be * specified if there are only two prime factors (p and q) -> * @param otherPrimeInfo triplets of the rest of primes, null can be * specified if there are only two prime factors (p * and q) java.base/.../javax/crypto/Cipher.java -------------------------------------- If we go with RSA-PSS or RSASSA-PSS, do you still need this change? java.base/.../javax/crypto/spec/OAEPParameterSpec.java ------------------------------------------------------ 77-80 should be 
.  It's rendering as a paragraph.


java.base/.../javax/crypto/spec/package-info.java
-------------------------------------------------
Suggest at least mentioning RFC 8017.


java.base/.../sun/security/rsa/PSSParameters.java
-------------------------------------------------
66/89/154/163/176/227/236: add @overrides?

115:  switch should not indent the arms:

     switch ... {
     case "...": ... ;
     default: ... ;
     }

130:  Shouldn't SHA-512/224 and /256 be here?


java.base/.../sun/security/rsa/RSAKeyFactory.java
-------------------------------------------------
202-208:  This code is repeated 5 times, maybe a single check method?

206 and other places:
Expect an
->
Expected a
or
Expected a/an


java.base/.../sun/security/rsa/RSAPrivateKeyImpl.java
-----------------------------------------------------
Add @Overrides like you did in the previous?


java.base/.../sun/security/rsa/RSAPSSSignature.java
---------------------------------------------------
53:
@since 10
->
@since 11

309-313:  Should this still be here?

75/190/231/406/443/479/497/and more...:  Line > 80 chars

358/and more:  Add @Overrides?

448-:  I appreciated the comments.  When people come up with their own 
optimizations of a relatively straightforward algorithm, it can be 
confusing to follow.  I'm guessing you're not going to be checking for 
input limitations?  (i.e. step 1)  A few more comments to help map the 
RFC to your code would be good, especially in the verify/decode. e.g. 
536-558.


java.base/.../sun/security/util/SignatureUtil.java
--------------------------------------------------
47/60-61/etc:  Parameter continuation should be indented 8 spaces here. 
Since this is a new file, can you please clean this up for readability? i.e.
     public static void specialSetParameter(Signature sig,
             AlgorithmParameters params)
             throws InvalidAlgorithmParameterException,
             ProviderException {

         ...deleted...


java.base/.../sun/security/x509/X509CertImpl.java
-------------------------------------------------
590-593:  Parameter continuation should be indented 8 spaces here.  This 
whole file is a mess!  :)


jdk.crypto.cryptoki/.../sun/security/pkcs11/P11Signature.java
-------------------------------------------------------------
@842:  @Overrides?


jdk.crypto.mscapi/.../sun/security/mscapi/RSASignature.java
-----------------------------------------------------------
474:  Extra *

491-492:  Extra lines.

Brad




>> SunRsaSignEntries.java
>> ----------------------
>> 145:? Where did you come up with this convention for your aliases?
>>
>> ??? SHA1withRSA-PSS
>>
>> I see Bouncy Castle[1] and Android[2] are both using:
>>
>> ??? SHA*withRSA/PSS
>> ??? RSASSA-PSS (name from PKCS#1)
>>
>> [1] 
>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java 
>>
>> [2] https://developer.android.com/reference/java/security/Signature.html
>>
> I removed the withRSA-PSS aliasses and am considering removing 
> the withRSAandMGF1 impls. The RSA-PSS (or RSASSA-PSS) scheme in 
> PKCS#1 v2.2 passes in the digest as part of signature parameters 
> (required) at runtime. Also, the oid corresponds to RSA-PSS unlike in 
> PKCS#1 v1.5 where oid is defined for each digest with RSA signature 
> scheme. So, I am having second thought on supporting the 
> withRSAandMGF1 names. The RSA-PSS signature impl code can use 
> less checks if we don't support these "friendly" names.
> As for the standard name, I didn't want to use RSA/PSS as the Cipher 
> transformation string uses "/" in its syntax. As for RSASSA-PSS, it is 
> also a little different from what we normally use. I don't have a strong 
> preference on names though. I can change it to whatever the groups' 
> preference is.
> 
> Thanks,
> Valerie
>>
>>
>> On 3/27/2018 6:40 PM, Valerie Peng wrote:
>>> Hi Brad,
>>>
>>> Can you please help review the changes for RSA-PSS support? I also 
>>> added some minor enhancement which add 2 more digest algorithms for 
>>> OAEP padding.
>>> There are quite some changes involved. The main changes are in the 
>>> SunRsaSign provider, i.e. sun.security.rsa packages. I reused 
>>> existing RSAKeyFactory, RSAKeyPairGenerator, and the RSA KeyImpl 
>>> classes as much as possible. However, given that RSA-PSS signatures 
>>> requires parameters, I put its implementation in a separate class, 
>>> i.e. RSAPSSSignature.java.
>>>
>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8146293
>>> Webrev: http://cr.openjdk.java.net/~valeriep/8146293/webrev.00/
>>>
>>> Existing and new regression tests have been run and result looks fine.
>>> Thanks,
>>> Valerie
> 


From ivan.gerasimov at oracle.com  Tue May  1 06:54:59 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Mon, 30 Apr 2018 23:54:59 -0700
Subject: RFR 8202086 : Improve performance characteristics of
 sun.security.util.MemoryCache
Message-ID: 

Hello!

This enhancement was generously contributed by Peter Levart [1]. The 
original webrev is found here [2].

The goal was to improve concurrent accessibility of the cache, while 
maintaining some additional limitations dictated by the spec.

Would you please help review this fix?

BUGURL: https://bugs.openjdk.java.net/browse/JDK-8202086
WEBREV: http://cr.openjdk.java.net/~igerasim/8202086/00/webrev/

Thanks in advance!

[1] 
http://mail.openjdk.java.net/pipermail/security-dev/2017-November/016512.html 

[2] 
http://cr.openjdk.java.net/~plevart/jdk10-dev/8186628_ssl_session_cache_scalability/webrev.01/

-- 
With kind regards,
Ivan Gerasimov



From sean.coffey at oracle.com  Tue May  1 10:16:38 2018
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 1 May 2018 11:16:38 +0100
Subject: [8u-dev] 8193171 : keytool -list displays "JKS" for a PKCS12
 keystore
In-Reply-To: <6952bad9-e230-8dce-be2d-2bb8f22c0b4c@oracle.com>
References: <6952bad9-e230-8dce-be2d-2bb8f22c0b4c@oracle.com>
Message-ID: 

Looks fine to me.

regards,
Sean.


On 30/04/2018 20:16, Ivan Gerasimov wrote:
> Hello!
>
> This is 8u-dev only bug fix.
>
> It was noticed that the keytool from the latest JDK 8 update release 
> displays type of PKCS12 keystore as JKS.
>
> Would you please help review the patch?
>
> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8193171
> WEBREV: http://cr.openjdk.java.net/~igerasim/8193171/00/webrev/
>
> Thanks in advance!
>



From adam.petcher at oracle.com  Tue May  1 15:21:00 2018
From: adam.petcher at oracle.com (Adam Petcher)
Date: Tue, 1 May 2018 11:21:00 -0400
Subject: JEP Proposal: EdDSA Signatures
Message-ID: 

The work for X25519/X448 is wrapping up[1], so I have started thinking 
about EdDSA. Please review the draft JEP[2] for EdDSA, and let me know 
what you think. I'm not really sure what priority to give the EdDSA 
work, and it is optional in TLS 1.3. So if you have a particular need or 
desire for EdDSA in the JDK, please let me know so I can figure what 
priority to give this task. Also let me know which variants of EdDSA you 
want---TLS only uses the "pure" variant, and I'm trying to decide 
whether it it is worthwhile to also implement the other variants.

Of course, I'm also interested in technical feedback on the JEP. A lot 
of the goals and design are similar to the X25519/X448 JEP.

[1] http://openjdk.java.net/jeps/324
[2] http://openjdk.java.net/jeps/8199231



From anders.rundgren.net at gmail.com  Tue May  1 16:24:00 2018
From: anders.rundgren.net at gmail.com (Anders Rundgren)
Date: Tue, 1 May 2018 18:24:00 +0200
Subject: JEP Proposal: EdDSA Signatures
In-Reply-To: 
References: 
Message-ID: <39c44a47-0004-8cac-2d20-07a6ce524c14@gmail.com>

On 2018-05-01 17:21, Adam Petcher wrote:
> The work for X25519/X448 is wrapping up[1], so I have started thinking
> about EdDSA. Please review the draft JEP[2] for EdDSA, and let me know
> what you think. I'm not really sure what priority to give the EdDSA
> work, and it is optional in TLS 1.3. So if you have a particular need or
> desire for EdDSA in the JDK, please let me know so I can figure what
> priority to give this task. Also let me know which variants of EdDSA you
> want---TLS only uses the "pure" variant, and I'm trying to decide
> whether it it is worthwhile to also implement the other variants.

https://ianix.com/pub/ed25519-deployment.html may be of some interest.

> 
> Of course, I'm also interested in technical feedback on the JEP. A lot
> of the goals and design are similar to the X25519/X448 JEP.
> 
> [1] http://openjdk.java.net/jeps/324
> [2] http://openjdk.java.net/jeps/8199231
> 



From sean.mullan at oracle.com  Tue May  1 17:20:40 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 1 May 2018 13:20:40 -0400
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
Message-ID: <9a046c64-8bfc-0a16-2540-534ebef472e7@oracle.com>

On 4/27/18 5:21 PM, Jamil Nimeh wrote:
> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff mostly:
> 
>   * Added words in the description of javax.crypto.Cipher recommending
>     callers reinitialize the Cipher to use different nonces after each
>     complete encryption or decryption (similar language to what exists
>     already for AES-GCM encryption).
>   * Added an additional test case for ChaCha20NoReuse
>   * Made accessor methods for ChaCha20ParameterSpec final and cleaned up
>     the code a bit based on comments from the field.
> 
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/

Some comments so far, will continue my review later ...

- Cipher.java

After the paragraph, I would add a reference for more info, ex: "Please 
see  RFC 7539  for 
more information on the ChaCha20 and ChaCha20-Poly1305 algorithms."

- SunJCE.java

81     "(implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, 
PBE, "

Should add the ChaCha20 algorithm to the provider information String above.

- ChaCha20ParameterSpec.java

Thinking more about this -- if you don't think there is any good reason 
that a provider would want to subclass this, I would just make the whole 
class final.

   60      * @throws IllegalArgumentException if {@code nonce} is not 12 
bytes
   61      *      in length.

Remove period since this is a fragment that is not followed by a sentence.

   87      * @return the counter value.

Same as above.

- ChaCha20Poly1305Parameters.java

52  * @since 11

We don't typically put @since lines in impl. classes.

111                     "ChaCha20-Poly1305 Parameter ASN.1 encoding error");

  102         if (val.tag == DerValue.tag_OctetString) {
  103             // Get the nonce value
  104             nonce = val.getOctetString();

I would probably just call val.getOctetString() directly and not 
proactively check the tag, since it will throw IOE if it is the wrong 
tag anyway. Then you don't need these lines:

  109         } else {
  110             throw new IOException(
  111                     "ChaCha20-Poly1305 Parameter ASN.1 encoding 
error");
  112         }

There are other reasons an IOException can be thrown, so it doesn't seem 
necessary to have a special-case for one type of error.

  134             throw new IllegalArgumentException(
  135                     "Unsupported parameter format: " + 
decodingMethod);

Although this seems like a reasonable exception to throw, 
AlgorithmParametersSpi.engineInit is not spec'ed to throw this, so I 
think you should throw an IOE instead.

  202             throw new IllegalArgumentException(
  203                     "Unsupported encoding format: " + encodingMethod);

Similar comment, AlgorithmParametersSpi.engineGetEncoded is not spec'ed 
to throw this, so I think you should throw an IOE instead.

--Sean


From sean.mullan at oracle.com  Tue May  1 20:53:41 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 1 May 2018 16:53:41 -0400
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <9a046c64-8bfc-0a16-2540-534ebef472e7@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 <9a046c64-8bfc-0a16-2540-534ebef472e7@oracle.com>
Message-ID: <9a56bc66-b93e-b244-9e47-1b795e8e2fb0@oracle.com>

On 5/1/18 1:20 PM, Sean Mullan wrote:
> On 4/27/18 5:21 PM, Jamil Nimeh wrote:
>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>> mostly:
>>
>> ? * Added words in the description of javax.crypto.Cipher recommending
>> ??? callers reinitialize the Cipher to use different nonces after each
>> ??? complete encryption or decryption (similar language to what exists
>> ??? already for AES-GCM encryption).
>> ? * Added an additional test case for ChaCha20NoReuse
>> ? * Made accessor methods for ChaCha20ParameterSpec final and cleaned up
>> ??? the code a bit based on comments from the field.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/

More comments:

- Poly1305.java

   44  * @since 10

Not necessary, but should be 11 if so.

   46 public final class Poly1305

Can this be package-private?

   84             keyBytes.length);
  122             BLOCK_LENGTH - blockOffset);

indent at least 4 more spaces

- ChaCha20Poly1305ParamTest.java

When you test for exceptions, you should throw an exception if the 
method does not throw an exception. For example:

  171         try {
  172             apsBad.init(NONCE_OCTET_STR_12, "OraclePrivate");
  173         } catch (IllegalArgumentException iae) {
  174             System.out.println("Caught expected exception: " + iae);
  175         }

should be something like:

     try {
         apsBad.init(NONCE_OCTET_STR_12, "OraclePrivate");
         throw new Exception("init passed unexpectedly");
     } catch (IllegalArgumentException iae) {
         System.out.println("Caught expected exception: " + iae);
     }

there are several other cases like this.

- ChaCha20KAT.java

looks good.

- ChaCha20NoReuse.java

looks good.

- ChaCha20Cipher.java

Exception messages say "bits" - should we use "bytes" to be consistent 
with the API?

  262         counter = 1;

Here you set the counter field to 1, but this method can still throw 
exceptions after that. Is there any risk of leaving the object in an 
inconsistent state by setting counter=1 if this method fails to complete 
successfully? Same comment on line 305.

  301                 if (newNonce.length != 12) {
  302                     throw new InvalidAlgorithmParameterException(
  303                         "ChaCha20 nonce must be 96 bits in length");
  304                 }

You don't need to check for this, since the ChaCha20ParamSpec class does 
already (especially if you make it final).

  375                         if (dv.tag == DerValue.tag_OctetString) {
  376                             // Get the nonce value
  377                             newNonce = dv.getOctetString();

Similar to a previous comment, I would just call 
DerValue.getOctetString() directly and let it throw an Exception if it 
is the wrong tag.

  395                 throw new UnsupportedOperationException("Invalid 
mode: " +

Seems inconsistent with 321 which throws RuntimeExc.

  401         if (newNonce == null) {
  402             newNonce = new byte[12];
  403             if (random != null) {
  404                 random.nextBytes(newNonce);
  405             }

It looks like there is a possibility of a non-random nonce being used if 
random is null at this point, which it could be if null is passed as the 
random and params parameters. I don't think that is what is intended. I 
think the right thing to do is throw an InvalidAlgParamException if you 
get to this point and random is null.

  508         this.keyBytes = newKeyBytes;
  509         nonce = newNonce;
  510
  511         aadDone = false;
  512         direction = opmode;

Here also you are setting various fields but the method may still throw 
an Exception - any issues about leaving the object in an inconsistent 
state? Preferably you should set these as the last thing you do before 
returning.

--Sean











From jamil.j.nimeh at oracle.com  Tue May  1 21:45:49 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 1 May 2018 14:45:49 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <9a046c64-8bfc-0a16-2540-534ebef472e7@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 <9a046c64-8bfc-0a16-2540-534ebef472e7@oracle.com>
Message-ID: 

Comments in-line:

On 5/1/2018 10:20 AM, Sean Mullan wrote:
> On 4/27/18 5:21 PM, Jamil Nimeh wrote:
>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>> mostly:
>>
>> ? * Added words in the description of javax.crypto.Cipher recommending
>> ??? callers reinitialize the Cipher to use different nonces after each
>> ??? complete encryption or decryption (similar language to what exists
>> ??? already for AES-GCM encryption).
>> ? * Added an additional test case for ChaCha20NoReuse
>> ? * Made accessor methods for ChaCha20ParameterSpec final and cleaned up
>> ??? the code a bit based on comments from the field.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>
> Some comments so far, will continue my review later ...
>
> - Cipher.java
>
> After the paragraph, I would add a reference for more info, ex: 
> "Please see  RFC 7539 
>  for more information on the ChaCha20 and ChaCha20-Poly1305 
> algorithms."
JN: Sounds good.? I'll do that.
>
> - SunJCE.java
>
> 81???? "(implements RSA, DES, Triple DES, AES, Blowfish, ARCFOUR, RC2, 
> PBE, "
>
> Should add the ChaCha20 algorithm to the provider information String 
> above.
JN: Yep, missed that.? Will fix.
>
> - ChaCha20ParameterSpec.java
>
> Thinking more about this -- if you don't think there is any good 
> reason that a provider would want to subclass this, I would just make 
> the whole class final.
JN: Given what ChaCha20 takes as variable inputs, I cannot see what 
anyone could gain from subclassing it.? I can set it to final and update 
the CSR.
>
> ? 60????? * @throws IllegalArgumentException if {@code nonce} is not 
> 12 bytes
> ? 61????? *????? in length.
>
> Remove period since this is a fragment that is not followed by a 
> sentence.
>
> ? 87????? * @return the counter value.
>
> Same as above.
JN: Will fix.
>
> - ChaCha20Poly1305Parameters.java
>
> 52? * @since 11
>
> We don't typically put @since lines in impl. classes.
JN: Consider it gone.
>
> 111???????????????????? "ChaCha20-Poly1305 Parameter ASN.1 encoding 
> error");
>
> ?102???????? if (val.tag == DerValue.tag_OctetString) {
> ?103???????????? // Get the nonce value
> ?104???????????? nonce = val.getOctetString();
>
> I would probably just call val.getOctetString() directly and not 
> proactively check the tag, since it will throw IOE if it is the wrong 
> tag anyway. Then you don't need these lines:
>
> ?109???????? } else {
> ?110???????????? throw new IOException(
> ?111???????????????????? "ChaCha20-Poly1305 Parameter ASN.1 encoding 
> error");
> ?112???????? }
>
> There are other reasons an IOException can be thrown, so it doesn't 
> seem necessary to have a special-case for one type of error.
JN: Sure, that seems reasonable.? Will fix.
>
> ?134???????????? throw new IllegalArgumentException(
> ?135???????????????????? "Unsupported parameter format: " + 
> decodingMethod);
>
> Although this seems like a reasonable exception to throw, 
> AlgorithmParametersSpi.engineInit is not spec'ed to throw this, so I 
> think you should throw an IOE instead.
>
> ?202???????????? throw new IllegalArgumentException(
> ?203???????????????????? "Unsupported encoding format: " + 
> encodingMethod);
>
> Similar comment, AlgorithmParametersSpi.engineGetEncoded is not 
> spec'ed to throw this, so I think you should throw an IOE instead.
JN: Fair enough.? I had figured IAE would be OK since it's an unchecked 
exception and seemed more appropriate to the situation. But IOE is fine 
too.? Will fix.

--Jamil


From jamil.j.nimeh at oracle.com  Tue May  1 22:55:21 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 1 May 2018 15:55:21 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <9a56bc66-b93e-b244-9e47-1b795e8e2fb0@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 <9a046c64-8bfc-0a16-2540-534ebef472e7@oracle.com>
 <9a56bc66-b93e-b244-9e47-1b795e8e2fb0@oracle.com>
Message-ID: <11d35b9a-611a-1cbc-36e5-c15312ae2744@oracle.com>

Hi Sean, many thanks for taking a detailed look at the code.? My 
comments are in-line

On 5/1/2018 1:53 PM, Sean Mullan wrote:
> On 5/1/18 1:20 PM, Sean Mullan wrote:
>> On 4/27/18 5:21 PM, Jamil Nimeh wrote:
>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>> mostly:
>>>
>>> ? * Added words in the description of javax.crypto.Cipher recommending
>>> ??? callers reinitialize the Cipher to use different nonces after each
>>> ??? complete encryption or decryption (similar language to what exists
>>> ??? already for AES-GCM encryption).
>>> ? * Added an additional test case for ChaCha20NoReuse
>>> ? * Made accessor methods for ChaCha20ParameterSpec final and 
>>> cleaned up
>>> ??? the code a bit based on comments from the field.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>
> More comments:
>
> - Poly1305.java
>
> ? 44? * @since 10
>
> Not necessary, but should be 11 if so.
JN: Will fix
>
> ? 46 public final class Poly1305
>
> Can this be package-private?
JN: Not sure.? I will make it so and run through the tests.? It will 
probably work.
>
> ? 84???????????? keyBytes.length);
> ?122???????????? BLOCK_LENGTH - blockOffset);
>
> indent at least 4 more spaces
JJN: Will fix.
>
> - ChaCha20Poly1305ParamTest.java
>
> When you test for exceptions, you should throw an exception if the 
> method does not throw an exception. For example:
>
> ?171???????? try {
> ?172???????????? apsBad.init(NONCE_OCTET_STR_12, "OraclePrivate");
> ?173???????? } catch (IllegalArgumentException iae) {
> ?174???????????? System.out.println("Caught expected exception: " + iae);
> ?175???????? }
>
> should be something like:
>
> ??? try {
> ??????? apsBad.init(NONCE_OCTET_STR_12, "OraclePrivate");
> ??????? throw new Exception("init passed unexpectedly");
> ??? } catch (IllegalArgumentException iae) {
> ??????? System.out.println("Caught expected exception: " + iae);
> ??? }
>
> there are several other cases like this.
JN: Yikes!? I normally do put an exception in the happy-path when I'm 
expecting a failure.? Major oversight here.? I will fix this.
>
> - ChaCha20KAT.java
>
> looks good.
>
> - ChaCha20NoReuse.java
>
> looks good.
>
> - ChaCha20Cipher.java
>
> Exception messages say "bits" - should we use "bytes" to be consistent 
> with the API?
JN: Sure, I can do that.
>
> ?262???????? counter = 1;
>
> Here you set the counter field to 1, but this method can still throw 
> exceptions after that. Is there any risk of leaving the object in an 
> inconsistent state by setting counter=1 if this method fails to 
> complete successfully? Same comment on line 305.
JN: I don't think so, since any Cipher.init call that would drop into 
these init routines expects the counter to be set to 1 (or to whatever 
value came in from the AlgorithmParameterSpec).? If an exception is 
thrown during the init codepath, the object will remain in an 
uninitialized state and cannot be used, so I don't see much danger 
there.? The only thing the user could do with an object in this 
situation would be to try to initialize it again (hopefully with 
parameters that don't cause it to fail).
>
> ?301???????????????? if (newNonce.length != 12) {
> ?302???????????????????? throw new InvalidAlgorithmParameterException(
> ?303???????????????????????? "ChaCha20 nonce must be 96 bits in length");
> ?304???????????????? }
>
> You don't need to check for this, since the ChaCha20ParamSpec class 
> does already (especially if you make it final).
JN: Yep, you're right.? A throwback to an earlier rev of the code before 
the ChaCha20ParameterSpec rigidly enforced this.? I can remove it.
>
>
> ?375???????????????????????? if (dv.tag == DerValue.tag_OctetString) {
> ?376???????????????????????????? // Get the nonce value
> ?377???????????????????????????? newNonce = dv.getOctetString();
>
> Similar to a previous comment, I would just call 
> DerValue.getOctetString() directly and let it throw an Exception if it 
> is the wrong tag.
JN: Except that I'll still have to catch the IOException and make that 
the cause of the InvalidAlgorithmParameterException.? I don't think 
CipherSpi.engineInit(int, Key, AlgorithmParameters, SecureRandom) can 
directly throw IOException.? If I have to wrap it inside IAPE, do you 
still prefer to do it that way or is the existing way OK?
>
> ?395???????????????? throw new UnsupportedOperationException("Invalid 
> mode: " +
>
> Seems inconsistent with 321 which throws RuntimeExc.
JN: So it is.? I'll change the UOE to RuntimeException.
>
> ?401???????? if (newNonce == null) {
> ?402???????????? newNonce = new byte[12];
> ?403???????????? if (random != null) {
> ?404???????????????? random.nextBytes(newNonce);
> ?405???????????? }
>
> It looks like there is a possibility of a non-random nonce being used 
> if random is null at this point, which it could be if null is passed 
> as the random and params parameters. I don't think that is what is 
> intended. I think the right thing to do is throw an 
> InvalidAlgParamException if you get to this point and random is null.
JN: Well, the method comment is old/outdated, another throwback to an 
older version that said it would use all zeroes in the null/null case 
and I don't want that to behave that way any longer.? I think if I do a 
similar approach to the init actions in 258-260 we should be in better 
shape.? Then when params is null there will always be a random 12-byte 
nonce generated, regardless of the null/non-null status of the "random" 
parameter.
>
> ?508???????? this.keyBytes = newKeyBytes;
> ?509???????? nonce = newNonce;
> ?510
> ?511???????? aadDone = false;
> ?512???????? direction = opmode;
>
> Here also you are setting various fields but the method may still 
> throw an Exception - any issues about leaving the object in an 
> inconsistent state? Preferably you should set these as the last thing 
> you do before returning.
JN: As before.? The object is in an inconsistent state, but unusable 
because the initialized flag is still false (and that's the absolute 
last thing that gets set to true during init).? If that flag is false, 
the update, updateAAD and doFinal methods will throw an execption.? The 
only way to make it usable is to init successfully. I think we're OK here.

Thank you for the detailed comments!
--Jamil


From jamil.j.nimeh at oracle.com  Tue May  1 23:19:38 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 1 May 2018 16:19:38 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <11d35b9a-611a-1cbc-36e5-c15312ae2744@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 <9a046c64-8bfc-0a16-2540-534ebef472e7@oracle.com>
 <9a56bc66-b93e-b244-9e47-1b795e8e2fb0@oracle.com>
 <11d35b9a-611a-1cbc-36e5-c15312ae2744@oracle.com>
Message-ID: <04dc7de4-0479-3d1e-b820-9fb5227c6d9d@oracle.com>

Update: forget my comment on this finding, Sean.? I'm already wrapping 
IOE in IAPE when IOE gets thrown so it's better to go the route you 
suggested.? I didn't read the method carefully enough.

>>
>>
>> ?375???????????????????????? if (dv.tag == DerValue.tag_OctetString) {
>> ?376???????????????????????????? // Get the nonce value
>> ?377???????????????????????????? newNonce = dv.getOctetString();
>>
>> Similar to a previous comment, I would just call 
>> DerValue.getOctetString() directly and let it throw an Exception if 
>> it is the wrong tag.
> JN: Except that I'll still have to catch the IOException and make that 
> the cause of the InvalidAlgorithmParameterException.? I don't think 
> CipherSpi.engineInit(int, Key, AlgorithmParameters, SecureRandom) can 
> directly throw IOException.? If I have to wrap it inside IAPE, do you 
> still prefer to do it that way or is the existing way OK?

--Jamil

From valerie.peng at oracle.com  Wed May  2 02:13:01 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 1 May 2018 19:13:01 -0700
Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm
 as in PKCS#1 v2.2"
In-Reply-To: 
References: 
 <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com>
 <77185686-9640-ed7d-a30d-d8651fd6c280@oracle.com>
 
Message-ID: <0260adcb-b2b0-61e0-d689-31e0db28a161@oracle.com>

Hi Brad,

Thanks for the review. Please find comments in line. I adopted most if 
not all of your comments.
I have incorporated your comments into the webrev but I am still not 
done with it yet due to name switch from RSA-PSS to RSASSA-PSS.
Will send out another email once webrev is updated.

On 4/30/2018 6:07 PM, Bradford Wetmore wrote:
>
> I have not reviewed the tests, but the following is my deep-dive on 
> the code.
>
> Mostly nits.? I stopped making comments about javadoc style issues 
> ("." at ends of fragments, indentation problems), except where you 
> were making changes anyway.? I realize the existing code has a bunch 
> of problems that we shouldn't gratuitously break.
>
>>> PSSParameterSpec.java
>>> ---------------------
>>> Maybe add trailerFieldBC(1)?
>> Not sure what do u want me to add. A constants for TrailerFieldBC, or 
>> else?
>
> Yes that was my thought.? A constant field for TrailerFieldBC. When I 
> was trying to construct a PSSParameterSpec, the integer value to use 
> is "1", but if you don't read ASN.1 well enough, one might be tempted 
> to pass "0xbc" instead.? If you weren't using DEFAULT, the call would 
> be like this:
>
> ??????? PSSParameterSpec pssSpec = new PSSParameterSpec(
> ??????????????? "SHA-256", "MGF1", MGF1ParameterSpec.SHA256, 20, 1);
> ->
> ??????? PSSParameterSpec pssSpec = new PSSParameterSpec(
> ??????????????? "SHA-256", "MGF1", MGF1ParameterSpec.SHA256, 20,
> ??????????????? PSSParameterSpec.trailerBC);
>
I added TRAILER_FIELD_BC constant for this as constant names are 
generally all upper case. Not too pretty and would welcome suggestions.

> java.base/.../java/security/interfaces/package-info.java
> --------------------------------------------------------
> Suggest mentioning RFC 8017, as "November 2016" doesn't make it easy 
> to find this particular version.? The RSA version came out in October 
> 27, 2012.? Whether you want to add the hyperlinking is up to you, I 
> notice you've added in other places (e.g. RSAPrivateCrtKeySpec.java)
>
Updated. I didn't include any link here as that seems to be the 
convention for package-info.java. Probably not that important comparing 
to the public classes like RSA*Key.

>
> java.base/.../java/security/SignedObject.java
> ---------------------------------------------
> 59:? In the javadoc, it looks like there is a missing opening brace 
> that isn't closed with the one at line 64.? However, the one at line 
> 64 is not showing up in the generated output either. Weird.
I think the {@ on line 59 pairs up with the } on line 64. Everything in 
between is shown as code.

> 152-209: The code in the other constructor is 99% the same, consider 
> moving this setup code to a common method.
Done.

> 173: Exactly the same wording here as the previous constructor.? 
> Should we endeavor to make them different?
The wordings look different to me. The former one explicitly states that 
no signature parameters is used.

> 182/195/307/339-340: indention problems.
>
> 223:? If you're going to fix this style problem, please fix the 
> indention problem also.
All Fixed.

> java.base/.../java/security/spec/package-info.java
> --------------------------------------------------
> Suggest at least mentioning RFC 8017.
Done.

> java.base/.../java/security/spec/RSAKeyGenParameterSpec.java
> ------------------------------------------------------------
> 60:
> public-exponent value with no key parameters
> ->
> public-exponent value, and no key parameters
>
> 71:
> public-exponent value and key parameters
> ->
> public-exponent value, and key parameters
Done.

> java.base/.../java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java
> --------------------------------------------------------------------
> A general nit throughout your APIs, when you're doing multi-line 
> things for your @params/@return/@exception, usually should be indented 
> to help readability of the source.
Alright, I will try to add indentation to improve readability to the 
part that I touched.

>
> * @param otherPrimeInfo triplets of the rest of primes, null can be
> * specified if there are only two prime factors (p and q)
> ->
> * @param otherPrimeInfo triplets of the rest of primes, null can be
> *?????????????????????? specified if there are only two prime factors (p
> *?????????????????????? and q)
>
>
> java.base/.../javax/crypto/Cipher.java
> --------------------------------------
> If we go with RSA-PSS or RSASSA-PSS, do you still need this change?
Yes, this change is for supporting OAEPwithandMGF1Paddong now 
that we added support for SHA512/224 and SHA512/256.

>
> java.base/.../javax/crypto/spec/OAEPParameterSpec.java
> ------------------------------------------------------
> 77-80 should be 
.? It's rendering as a paragraph.
Fixed.
> java.base/.../javax/crypto/spec/package-info.java
> -------------------------------------------------
> Suggest at least mentioning RFC 8017.
Done.
>
> java.base/.../sun/security/rsa/PSSParameters.java
> -------------------------------------------------
> 66/89/154/163/176/227/236: add @overrides?
> 115: switch should not indent the arms:
>
> ??? switch ... {
> ??? case "...": ... ;
> ??? default: ... ;
> ??? }
Fixed.
>
> 130:? Shouldn't SHA-512/224 and /256 be here?
Good catch. Added.

>
> java.base/.../sun/security/rsa/RSAKeyFactory.java
> -------------------------------------------------
> 202-208:? This code is repeated 5 times, maybe a single check method?
Sure, done.

> 206 and other places:
> Expect an
> ->
> Expected a
> or
> Expected a/an
Ok.

>
> java.base/.../sun/security/rsa/RSAPrivateKeyImpl.java
> -----------------------------------------------------
> Add @Overrides like you did in the previous?
Done.
>
> java.base/.../sun/security/rsa/RSAPSSSignature.java
> ---------------------------------------------------
> 53:
> @since 10
> ->
> @since 11
Fixed.

> 309-313: Should this still be here?
Removed.

>
> 75/190/231/406/443/479/497/and more...:? Line > 80 chars
Fixed.
> 358/and more:? Add @Overrides?
Done.
> 448-: I appreciated the comments.? When people come up with their own 
> optimizations of a relatively straightforward algorithm, it can be 
> confusing to follow.? I'm guessing you're not going to be checking for 
> input limitations?? (i.e. step 1)? A few more comments to help map the 
> RFC to your code would be good, especially in the verify/decode. e.g. 
> 536-558.
I will add some more comments on this.

>
> java.base/.../sun/security/util/SignatureUtil.java
> --------------------------------------------------
> 47/60-61/etc:? Parameter continuation should be indented 8 spaces 
> here. Since this is a new file, can you please clean this up for 
> readability? i.e.
> ??? public static void specialSetParameter(Signature sig,
> ??????????? AlgorithmParameters params)
> ??????????? throws InvalidAlgorithmParameterException,
> ??????????? ProviderException {
>
> ??????? ...deleted...
Done.

>
> java.base/.../sun/security/x509/X509CertImpl.java
> -------------------------------------------------
> 590-593:? Parameter continuation should be indented 8 spaces here.? 
> This whole file is a mess!? :)
Fixed. I only updated my changes. It'd make the webrev un-readable if I 
address all the indentation inconsistency.

>
>
> jdk.crypto.cryptoki/.../sun/security/pkcs11/P11Signature.java
> -------------------------------------------------------------
> @842:? @Overrides?
Added.
>
>
> jdk.crypto.mscapi/.../sun/security/mscapi/RSASignature.java
> -----------------------------------------------------------
> 474:? Extra *
>
> 491-492:? Extra lines.
Removed.
Valerie

>
> Brad
>
>
>
>
>>> SunRsaSignEntries.java
>>> ----------------------
>>> 145:? Where did you come up with this convention for your aliases?
>>>
>>> ??? SHA1withRSA-PSS
>>>
>>> I see Bouncy Castle[1] and Android[2] are both using:
>>>
>>> ??? SHA*withRSA/PSS
>>> ??? RSASSA-PSS (name from PKCS#1)
>>>
>>> [1] 
>>> https://github.com/bcgit/bc-java/blob/master/prov/src/main/java/org/bouncycastle/jcajce/provider/asymmetric/RSA.java 
>>>
>>> [2] 
>>> https://developer.android.com/reference/java/security/Signature.html
>>>
>> I removed the withRSA-PSS aliasses and am considering 
>> removing the withRSAandMGF1 impls. The RSA-PSS (or 
>> RSASSA-PSS) scheme in PKCS#1 v2.2 passes in the digest as part of 
>> signature parameters (required) at runtime. Also, the oid corresponds 
>> to RSA-PSS unlike in PKCS#1 v1.5 where oid is defined for each digest 
>> with RSA signature scheme. So, I am having second thought on 
>> supporting the withRSAandMGF1 names. The RSA-PSS signature 
>> impl code can use less checks if we don't support these "friendly" 
>> names.
>> As for the standard name, I didn't want to use RSA/PSS as the Cipher 
>> transformation string uses "/" in its syntax. As for RSASSA-PSS, it 
>> is also a little different from what we normally use. I don't have a 
>> strong preference on names though. I can change it to whatever the 
>> groups' preference is.
>>
>> Thanks,
>> Valerie
>>>
>>>
>>> On 3/27/2018 6:40 PM, Valerie Peng wrote:
>>>> Hi Brad,
>>>>
>>>> Can you please help review the changes for RSA-PSS support? I also 
>>>> added some minor enhancement which add 2 more digest algorithms for 
>>>> OAEP padding.
>>>> There are quite some changes involved. The main changes are in the 
>>>> SunRsaSign provider, i.e. sun.security.rsa packages. I reused 
>>>> existing RSAKeyFactory, RSAKeyPairGenerator, and the RSA KeyImpl 
>>>> classes as much as possible. However, given that RSA-PSS signatures 
>>>> requires parameters, I put its implementation in a separate class, 
>>>> i.e. RSAPSSSignature.java.
>>>>
>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8146293
>>>> Webrev: http://cr.openjdk.java.net/~valeriep/8146293/webrev.00/
>>>>
>>>> Existing and new regression tests have been run and result looks fine.
>>>> Thanks,
>>>> Valerie
>>



From philipp.kunz at paratix.ch  Wed May  2 05:21:37 2018
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Wed, 2 May 2018 07:21:37 +0200
Subject: RFR for 6443578 and 6202130: UTF-8 in Manifests
In-Reply-To: 
References: 
Message-ID: 

Hi,

Recently, I tried to fix only bug 6202130 with the intention to fix bug 
6443578 later with the intention to get some opportunity for feedback, 
but haven't got any, and propose now a fix for both together which in my 
opinion makes more sense.

See attached patch.

Some considerations, assumptions, and explanations

  * In my opinion, the code for writing manifests was distributed in the
    two classes Attributes and Manifest in an elegant way but somewhat
    difficult to explain the coherence. I chose to group the code that
    writes manifests into a new class ManifestWriter. The main incentive
    for that was to prevent or reduce duplicated code I would have had
    to change twice otherwise. This also results in a source file of a
    suitable size.
  * I could not support the assumption that the write and writeMain
    methods in Attributes couldn't be referenced anywhere so I
    deprecated them rather than having them removed.
  * I assumed the patch will not make it into JDK 10 and, hence, the
    deprecated annotations are attributed with since = 11.
  * I could not figure out any reason for the use of DataOutputStream
    and did not use it.
  * Performance-wise I assume that the code is approximately comparable
    to the previous version. The biggest improvement in this respect I
    hope comes from removing the String that contains the byte array
    constructed with deprecated String(byte[], int, int, int) and then
    copying it over again to a StringBuffer and from there to a String
    again and then Characters. On the other hand, keeping whole
    characters together when breaking lines might make it slightly
    slower. I hope my changes are an overall improvement, but I haven't
    measured it.
  * For telling first from continuation bytes of utf-8 characters apart
    I re-used a method isNotUtfContinuationByte from either StringCoding
    or UTF_8.Decoder. Unfortunately I found no way not to duplicate it.
  * Where it said before "XXX Need to handle UTF8 values and break up
    lines longer than 72 bytes" in Attributes#writeMain I did not dare
    to remove the comment completely because it still does not deal
    correctly with version headers longer than 72 bytes and the set of
    allowed values. I changed it accordingly. Two similar comments are
    removed in the patch.
  * I added two tests, WriteDeprecated and NullKeysAndValues, to
    demonstrate compatibility as good as I could. Might however not be
    desired to keep and having to maintain.
  * LineBrokenMultiByteCharacter for jarsigner should not be removed or
    not so immediately because someone might attempt to sign an older
    jarfile created without that patch with a newer jarsigner that
    already contains it.



suggested changes or additions to the bug database: (i have no 
permissions to edit it myself)

  * Re-combine copies of isNotUtfContinuationByte (three by now).
    Relates to 6184334. Worth to file another issue?
  * Manifest versions have specific specifications, cannot break across
    lines and can contain a subset of characters only. Bug 6910466
    relates but is not exactly the same. If someone else is convinced
    that writing a manifest should issue a warning or any other way to
    deal with a version that does not conform to the specification, I'd
    suggest to create a separate bug for that.


Now, I would be glad if someone sponsored a review. This is only my 
third attempt to submit a patch which is why I chose a lesser important 
subject to fix in order to get familiar and now I understand it's not 
the most attractive patch to review. Please don't hesitate to suggest 
what I could do better or differently.

As a bonus, with these changes, manifest files will always be displayed 
correctly with just any utf capable viewer even if they contain 
multi-byte utf characters that would have been broken across a line 
break with the current/previous implementation and all manifests will 
become also valid strings in Java.

Regards,
Philipp



On 20.04.2018 00:58, Philipp Kunz wrote:
> Hi,
>
> I tried to fix bug 6202130 about manifest utf support and come up now 
> with a test as suggested in the bug's comments that shows that utf 
> charset actually works before removing the comments from the code.
>
> When I wanted to remove the XXX comments about utf it occurred to me 
> that version attributes ("Signature-Version" and "Manifest-Version") 
> would never be broken across lines and should anyway not support the 
> whole utf character set which sounds more like related to bugs 6910466 
> or 4935610 but it's not a real fit. Therefore, I could not remove one 
> such comment of Attributes#writeMain but I changed it. The first 
> comment in bug 6202130 mentions only two comments but there are three 
> in Attributes. In the attached patch I removed only two of three and 
> changed the remaining third to not mention utf anymore.
>
> At the moment, at least until 6443578 is fixed, multi-byte utf 
> characters can be broken across lines. It might be worth a 
> consideration to test that explicitly as well but then I guess there 
> is not much of a point in testing the current behavior that will 
> change with 6443578, hopefully soon. There are in my opinion enough 
> characters broken across lines in the attached test that demonstrate 
> that this still works like it did before.
>
> I would have preferred also to remove the calls to deprecated 
> String(byte[], int, int, int) but then figured it relates more to bug 
> 6443578 than 6202130 and now prefer to do that in another separate patch.
>
> Bug 6202130 also states that lines are broken by String.length not by 
> byte length. While it looks so at first glance, I could not confirm. 
> The combination of getBytes("UTF8"), String(byte[], int, int, int), 
> and then DataOutputStream.writeBytes(String) in that combination does 
> not drop high-bytes because every byte (whether a whole character or 
> only a part of a multi-byte character) becomes a character in 
> String(...) containing that byte in its low-byte which will be read 
> again from writeBytes(...). Or put in a different way, every utf 
> encoded byte becomes a character and multi-byte utf characters are 
> converted into multiple string characters containing one byte each in 
> their lower bytes. The current solution is not nice, but at least 
> works. With that respect I'd like to suggest to deprecate 
> DataOutputStream.writeBytes(String) because it does something not 
> exactly expected when guessing from its name and that would suit a 
> byte[] parameter better very much like it has been done with 
> String(byte[], int, int, int). Any advice about the procedure to 
> deprecate something?
>
> I was surprised that it was not trivial to list all valid utf 
> characters. If someone has a better idea than isValidUtfCharacter in 
> the attached test, let me know.
>
> Altogether, I would not consider 6202130 resolved completely, unless 
> maybe all remaining points are copied to 6443578 and maybe another bug 
> about valid values for "Signature-Version" and "Manifest-Version" if 
> at all desired. But still I consider the attached patch an improvement 
> and most of the remainder can then be solved in 6443578 and so far I 
> am looking forward to any kind of feedback.
>
> Regards,
> Philipp
>




diff -r 2ace90aec488 
src/java.base/share/classes/java/util/jar/Attributes.java
--- a/src/java.base/share/classes/java/util/jar/Attributes.java Mon Apr 
30 21:56:54 2018 -0400
+++ b/src/java.base/share/classes/java/util/jar/Attributes.java Wed May 
02 07:20:46 2018 +0200
@@ -296,27 +296,13 @@

      /*
       * Writes the current attributes to the specified data output stream.
-     * XXX Need to handle UTF8 values and break up lines longer than 72 
bytes
+     *
+     * @deprecated moved to
+     * {@link ManifestWriter#writeSection(java.io.OutputStream)}
       */
-     @SuppressWarnings("deprecation")
-     void write(DataOutputStream os) throws IOException {
-         for (Entry e : entrySet()) {
-             StringBuffer buffer = new StringBuffer(
-                                         ((Name) e.getKey()).toString());
-             buffer.append(": ");
-
-             String value = (String) e.getValue();
-             if (value != null) {
-                 byte[] vb = value.getBytes("UTF8");
-                 value = new String(vb, 0, 0, vb.length);
-             }
-             buffer.append(value);
-
-             Manifest.make72Safe(buffer);
-             buffer.append("\r\n");
-             os.writeBytes(buffer.toString());
-         }
-        os.writeBytes("\r\n");
+    @Deprecated(since = "11")
+    void write(DataOutputStream os) throws IOException {
+        new ManifestWriter(os).writeSection(this);
      }

      /*
@@ -324,50 +310,16 @@
       * make sure to write out the MANIFEST_VERSION or SIGNATURE_VERSION
       * attributes first.
       *
-     * XXX Need to handle UTF8 values and break up lines longer than 72 
bytes
+     * @deprecated moved to
+     * {@link ManifestWriter#writeMain(java.io.OutputStream)}
       */
-    @SuppressWarnings("deprecation")
-    void writeMain(DataOutputStream out) throws IOException
-    {
-        // write out the *-Version header first, if it exists
-        String vername = Name.MANIFEST_VERSION.toString();
-        String version = getValue(vername);
-        if (version == null) {
-            vername = Name.SIGNATURE_VERSION.toString();
-            version = getValue(vername);
-        }
-
-        if (version != null) {
-            out.writeBytes(vername+": "+version+"\r\n");
-        }
-
-        // write out all attributes except for the version
-        // we wrote out earlier
-        for (Entry e : entrySet()) {
-            String name = ((Name) e.getKey()).toString();
-            if ((version != null) && !(name.equalsIgnoreCase(vername))) {
-
-                StringBuffer buffer = new StringBuffer(name);
-                buffer.append(": ");
-
-                String value = (String) e.getValue();
-                if (value != null) {
-                    byte[] vb = value.getBytes("UTF8");
-                    value = new String(vb, 0, 0, vb.length);
-                }
-                buffer.append(value);
-
-                Manifest.make72Safe(buffer);
-                buffer.append("\r\n");
-                out.writeBytes(buffer.toString());
-            }
-        }
-        out.writeBytes("\r\n");
+    @Deprecated(since = "11")
+    void writeMain(DataOutputStream os) throws IOException {
+        new ManifestWriter(os).writeMain(this);
      }

      /*
       * Reads attributes from the specified input stream.
-     * XXX Need to handle UTF8 values.
       */
      @SuppressWarnings("deprecation")
      void read(Manifest.FastInputStream is, byte[] lbuf) throws 
IOException {
diff -r 2ace90aec488 src/java.base/share/classes/java/util/jar/Manifest.java
--- a/src/java.base/share/classes/java/util/jar/Manifest.java    Mon Apr 
30 21:56:54 2018 -0400
+++ b/src/java.base/share/classes/java/util/jar/Manifest.java    Wed May 
02 07:20:46 2018 +0200
@@ -26,7 +26,6 @@
  package java.util.jar;

  import java.io.FilterInputStream;
-import java.io.DataOutputStream;
  import java.io.InputStream;
  import java.io.OutputStream;
  import java.io.IOException;
@@ -143,31 +142,19 @@
       * @exception IOException if an I/O error has occurred
       * @see #getMainAttributes
       */
-    @SuppressWarnings("deprecation")
      public void write(OutputStream out) throws IOException {
-        DataOutputStream dos = new DataOutputStream(out);
-        // Write out the main attributes for the manifest
-        attr.writeMain(dos);
-        // Now write out the per-entry attributes
-        for (Map.Entry e : entries.entrySet()) {
-            StringBuffer buffer = new StringBuffer("Name: ");
-            String value = e.getKey();
-            if (value != null) {
-                byte[] vb = value.getBytes("UTF8");
-                value = new String(vb, 0, 0, vb.length);
-            }
-            buffer.append(value);
-            make72Safe(buffer);
-            buffer.append("\r\n");
-            dos.writeBytes(buffer.toString());
-            e.getValue().write(dos);
-        }
-        dos.flush();
+        new ManifestWriter(out).write(this);
      }

      /**
       * Adds line breaks to enforce a maximum 72 bytes per line.
+     *
+     * @see ManifestWriter#write72broken(String)
+     * @deprecated replaced by
+     * {@link ManifestWriter#write72broken(String)}
+     * which keeps whole utf character together when breaking lines
       */
+    @Deprecated(since = "11")
      static void make72Safe(StringBuffer line) {
          int length = line.length();
          int index = 72;
diff -r 2ace90aec488 
src/java.base/share/classes/java/util/jar/ManifestWriter.java
--- /dev/null    Thu Jan 01 00:00:00 1970 +0000
+++ b/src/java.base/share/classes/java/util/jar/ManifestWriter.java Wed 
May 02 07:20:46 2018 +0200
@@ -0,0 +1,224 @@
+/*
+ * Copyright (c) 2018, 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.  Oracle designates this
+ * particular file as subject to the "Classpath" exception as provided
+ * by Oracle in the LICENSE file that accompanied this code.
+ *
+ * This code 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 General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License 
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+package java.util.jar;
+
+import java.io.IOException;
+import java.io.OutputStream;
+import java.nio.charset.Charset;
+import java.nio.charset.StandardCharsets;
+import java.util.Map;
+import java.util.Map.Entry;
+import java.util.jar.Attributes.Name;
+
+/**
+ * ManifestWriter writes manifests and takes care of their structure,
+ * correct encoding regarding character set, and maximum line width.
+ * 

+ * For information on the Manifest format, please see the
+ * 
+ * Manifest format specification.
+ *
+ * @see Manifest#write(OutputStream)
+ * @since 11
+ */
+class ManifestWriter {
+
+    /**
+     * The utf-8 character set used for {@link Manifest}s.
+     */
+    private static final java.nio.charset.Charset UTF_8 =
+            StandardCharsets.UTF_8;
+
+    private static final String
+            INDIVIDUAL_SECTION_NAME_HEADER_KEY = "Name",
+            KEY_VALUE_SEPARATOR = ": ",
+            LINE_BREAK = "\r\n",
+            CONTINUATION = " ";
+
+    /**
+    * The 
+    * "Notes on Manifest and Signature Files" in the "JAR File
+    * Specification" state that no line may be longer than
+    * 72 bytes (not characters), in its utf8-encoded 
form.
+    */
+    private static final int MANIFEST_LINE_WIDTH = 72;
+
+    /**
+     * The underlying output stream where to write a {@link Manifest} to by
+     * {@link #write(Manifest)}.
+     */
+    private final OutputStream out;
+
+    /**
+     * Only constructor.
+     *
+     * @param out output stream where to write a {@link Manifest} to by
+     * {@link #write(Manifest)}
+     */
+    ManifestWriter(OutputStream out) {
+        this.out = out;
+    }
+
+    private static byte[] encode(String value) {
+        return value.getBytes(UTF_8);
+    }
+
+    private void write(String value) throws IOException {
+        out.write(encode(value));
+    }
+
+    private void write(byte[] value, int off, int len) throws IOException {
+        out.write(value, off, len);
+    }
+
+    private static final byte[] LINE_BREAK_BUF = encode(LINE_BREAK);
+
+    private void writeLineBreak() throws IOException {
+        out.write(LINE_BREAK_BUF);
+    }
+
+    private static final byte[] LINE_BREAK_CONTINUATION_BUF =
+            encode(LINE_BREAK + CONTINUATION);
+
+    private void writeContinuationLineBreak() throws IOException {
+        out.write(LINE_BREAK_CONTINUATION_BUF);
+    }
+
+    /**
+     * Writes a header line with added line breaks to enforce a maximum 
of 72
+     * bytes per line with respect only to breaks whole characters and 
writes
+     * the result to the current {@link ManifestWriter}'s underlying output
+     * stream.
+     */
+    private void write72broken(String header) throws IOException {
+        byte[] buf = encode(header);
+        int l = buf.length;
+        int p = 0; // start position in buf of current line to write
+        int n = MANIFEST_LINE_WIDTH; // number of bytes going on 
current line
+        while (true) {
+            if (p + n >= l) {
+                n = l - p; // remainder fits on current (last) line
+            } else {
+                /*
+                 * break whole utf characters only:
+                 * put the current line end position on the next character
+                 * start position / utf non-continuation byte left of and
+                 * including n initial value / the maximum line width by
+                 * decreasing the current line end position n until not
+                 * followed by an utf continuation byte in order to not 
break
+                 * utf characters across line breaks
+                 */
+                while (!isNotUtfContinuationByte(buf[p + n])) n--;
+            }
+            write(buf, p, n);
+            p += n;
+            if (p == l) break;
+            n = MANIFEST_LINE_WIDTH - 1;
+            writeContinuationLineBreak();
+        }
+    }
+
+    /**
+     * @see StringCoding#isNotUtfContinuationByte(int)
+     * @see sun.nio.cs.UTF_8.Decoder#isNotUtfContinuationByte(int)
+     */
+    private static boolean isNotUtfContinuationByte(byte b) {
+        return (b & 0xc0) != 0x80;
+    }
+
+    private static String composeHeaderLine(String name, String value) {
+        return name + KEY_VALUE_SEPARATOR + value;
+    }
+
+    private void writeHeader(String name, String value) throws 
IOException {
+        write72broken(composeHeaderLine(name, value));
+        writeLineBreak();
+    }
+
+    /**
+     * Writes the specified attributes to the current output stream.
+     */
+    void writeSection(Attributes attributes) throws IOException {
+        for (Entry e : attributes.entrySet()) {
+            String name = ((Name) e.getKey()).toString();
+            writeHeader(name, (String) e.getValue());
+        }
+        writeLineBreak();
+    }
+
+    /**
+     * Writes the specified attributes to the current output stream,
+     * make sure to write out the MANIFEST_VERSION or SIGNATURE_VERSION
+     * attributes first.
+     */
+    /*
+     * XXX Need to handle version compliant to specification:
+     * - only digits and periods but no period at the beginning or end
+     * - not more than 72-16-1=55 characters in order not to exceed 
line width
+     * - no space after colon or rather change specs and only 54 
characters max
+     */
+    void writeMain(Attributes attributes) throws IOException {
+        // write out the *-Version header first, if it exists
+        String vername = Name.MANIFEST_VERSION.toString();
+        String version = attributes.getValue(vername);
+        if (version == null) {
+            vername = Name.SIGNATURE_VERSION.toString();
+            version = attributes.getValue(vername);
+        }
+
+        if (version != null) {
+            // version header cannot be continued on next line
+            write(composeHeaderLine(vername, version));
+            writeLineBreak();
+        }
+
+        // write out all attributes except for the version we wrote out 
earlier
+        for (Entry e : attributes.entrySet()) {
+            String name = ((Name) e.getKey()).toString();
+            if ((version != null) && !(name.equalsIgnoreCase(vername))) {
+                writeHeader(name, (String) e.getValue());
+            }
+        }
+        writeLineBreak();
+    }
+
+    /**
+     * Writes the given {@link Manifest} to the output stream of this
+     * {@link ManifestWriter} instance.
+     *
+     * @param mf the {@link Manifest} to write
+     */
+    void write(Manifest mf) throws IOException {
+        // Write out the main attributes for the manifest
+        writeMain(mf.getMainAttributes());
+        // Now write out the per-entry attributes
+        for (Entry e : mf.getEntries().entrySet()) {
+            writeHeader(INDIVIDUAL_SECTION_NAME_HEADER_KEY, e.getKey());
+            writeSection(e.getValue());
+        }
+    }
+
+}
diff -r 2ace90aec488 test/jdk/java/util/jar/Attributes/WriteDeprecated.java
--- /dev/null    Thu Jan 01 00:00:00 1970 +0000
+++ b/test/jdk/java/util/jar/Attributes/WriteDeprecated.java    Wed May 
02 07:20:46 2018 +0200
@@ -0,0 +1,123 @@
+/*
+ * Copyright (c) 2018, 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code 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 General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License 
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+import static java.nio.charset.StandardCharsets.UTF_8;
+
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.DataOutputStream;
+import java.io.IOException;
+import java.util.jar.Attributes;
+import java.util.jar.Attributes.Name;
+import java.util.jar.Manifest;
+import java.lang.reflect.Method;
+
+import org.testng.annotations.Test;
+import static org.testng.Assert.*;
+
+/**
+ * @test
+ * @run testng/othervm --illegal-access=warn WriteDeprecated
+ * @summary Tests that the Attribute's write methods still work despite not
+ *          being used any longer by Manifest.
+ */
+ at Deprecated
+/*
+ * Note to future maintainer:
+ * In order to actually being able to test Attributes' write methods work
+ * as before normal manifest and attributes manipulation through their 
public
+ * api is not sufficient but then these methods were there before and this
+ * way it's ensured that the behavior does not change with that respect.
+ * Once module isolation is enforced some test cases will not any longer be
+ * possible and those now tested situations will be guaranteed not to occur
+ * any longer at all at which point the corresponding tests can be removed
+ * safely without replacement unless of course another way is found to 
inject
+ * the tested null values.
+ * Another trick to access package private class members could be to use
+ * deserialization or adding a new class to the same package on the 
classpath.
+ * Here is not important how the methods are invoked because it shows that
+ * the behavior remains unchanged.
+ */
+public class WriteDeprecated {
+
+    static final Name KEY = new Name("some-key");
+    static final String VALUE = "value";
+
+    static class AccessibleAttributes extends Attributes {
+
+        void invoke(String name, DataOutputStream os) throws IOException {
+            try {
+                Method method = Attributes.class.getDeclaredMethod(
+                        name, DataOutputStream.class);
+                method.setAccessible(true);
+                method.invoke(this, os);
+            } catch (ReflectiveOperationException e) {
+                fail(e.getMessage(), e);
+            }
+        }
+
+        /**
+         * @see Attributes#write(DataOutputStream)
+         */
+        void write(DataOutputStream os) throws IOException {
+            invoke("write", os);
+        }
+
+        /**
+         * @see Attributes#writeMain(DataOutputStream)
+         */
+        void writeMain(DataOutputStream os) throws IOException {
+            invoke("writeMain", os);
+        }
+
+    }
+
+    @Test
+    public void testWriteMethods() throws Exception {
+        ByteArrayOutputStream out = new ByteArrayOutputStream();
+        AccessibleAttributes attributes = new AccessibleAttributes();
+        attributes.put(Name.MANIFEST_VERSION, "1.0");
+        attributes.put(KEY, VALUE);
+        DataOutputStream dos = new DataOutputStream(out);
+        attributes.writeMain(dos);
+        attributes.remove(Name.MANIFEST_VERSION);
+        dos.writeBytes("Name: " + VALUE + "\r\n");
+        attributes.write(dos);
+        dos.flush();
+
+        byte[] mfBytes = out.toByteArray();
+ System.out.println("-------------------------------------------"
+                + "-----------------------------");
+        System.out.print(new String(mfBytes, UTF_8));
+ System.out.println("-------------------------------------------"
+                + "-----------------------------");
+        Manifest mf = new Manifest(new ByteArrayInputStream(mfBytes));
+        assertEquals(mf.getMainAttributes().getValue(KEY), VALUE,
+                "main attributes header value");
+        Attributes attributes2 = mf.getAttributes(VALUE);
+        assertNotNull(attributes2, "named section not found");
+        assertEquals(attributes2.getValue(KEY), VALUE,
+                "named section attributes header value");
+    }
+
+}
diff -r 2ace90aec488 test/jdk/java/util/jar/Manifest/LineBreakCharacter.java
--- /dev/null    Thu Jan 01 00:00:00 1970 +0000
+++ b/test/jdk/java/util/jar/Manifest/LineBreakCharacter.java    Wed May 
02 07:20:46 2018 +0200
@@ -0,0 +1,405 @@
+/*
+ * Copyright (c) 2018, 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code 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 General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License 
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+import static java.nio.charset.StandardCharsets.UTF_8;
+
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.DataOutputStream;
+import java.io.IOException;
+import java.util.jar.Attributes;
+import java.util.jar.Manifest;
+import java.util.jar.Attributes.Name;
+import java.util.List;
+import java.util.LinkedList;
+
+import org.testng.annotations.Test;
+import org.testng.annotations.DataProvider;
+import static org.testng.Assert.*;
+
+/**
+ * @test
+ * @bug 6443578
+ * @run testng/othervm --illegal-access=warn LineBreakCharacter
+ * @summary Tests reading and writing of jar manifests with headers broken
+ *          across lines in conjunction with multi-byte utf characters.
+ * 

+ * Line breaks may or may not occur within utf encoded characters that are
+ * represented with more than one byte. Even though characters should 
not be
+ * broken across lines according to the specification the previous Manifest
+ * implementation did it and this test makes sure that no multi-byte 
characters
+ * are broken apart across a line break when writing manifests and 
manifests
+ * are read correctly no matter if multi-byte characters are continued 
after a
+ * line break.
+ * 

+ * Correct support of all utf characters is the concern of
+ * {@link ValueUtfEncoding}.
+ */
+public class LineBreakCharacter {
+
+    static final int MANIFEST_LINE_CONTENT_WIDTH_BYTES = 72;
+
+    static final String FILL = "x";
+
+    /**
+     * By using names of four characters the same values can be used for
+     * testing line breaks at exact positions for both header and section
+     * names, header names in main and named sections, because a named
+     * section name is represented with a header with key "Name" that 
occurs
+     * after a blank line and also has four characters.
+     */
+    static final String NAME = FILL + FILL + FILL + FILL;
+
+    /**
+     * Cover main attributes headers, section names, and headers in named
+     * sections because an implementation might make a difference.
+     */
+    enum PositionInManifest {
+        MAIN_ATTRIBUTES, SECTION_NAME, NAMED_SECTION;
+    }
+
+    /**
+     * @see LineBreakLineWidth#numByteUtfCharacter(int, int)
+     */
+    static String numByteUtfCharacter(int numBytes, int seed) {
+        seed = seed < 0 ? -seed : seed;
+        if (numBytes == 1) {
+            seed %= 0x5F;
+            seed += 0x20; // exclude control characters (0..0x19) here
+        } else if (numBytes == 2) {
+            seed %= 0x800 - 0x80;
+            seed += 0x80;
+        } else if (numBytes == 3) {
+            seed %= 0x10000 - 0x800 + 0xFDD0 - 0xFDEF + 0xFFFE - 0xFFFF;
+            seed += 0x800
+                    + (seed >= 0xFDD0 ? 0xFDEF - 0xFDD0 : 0) // 
non-characters
+                    + (seed % 0x10000) * (0xFFFF - 0xFFFE); // byte 
order marks
+        } else {
+            seed %= 0x110000 - (0x10000 - 0xFFFE);
+            seed += 0x10000
+                    + (seed % 0x10000) * (0xFFFF - 0xFFFE); // byte 
order marks
+        }
+
+        String string = new String(Character.toChars(seed));
+        assertEquals(string.getBytes(UTF_8).length, numBytes,
+                "self-test failed: unexpected utf encoded character 
length");
+        return string;
+    }
+
+    @DataProvider(name = "lineBreakParameters")
+    public static Object[][] lineBreakParameters() {
+        LinkedList params = new LinkedList<>();
+
+        // b: number of line breaks before character under test
+        for (int b = 0; b <= 3; b++) {
+
+           // c: character utf encoded length in bytes
+           for (int c = 1; c <= 4; c++) {
+
+                // p: potential break position offset in bytes
+                // p = 0 => before character
+                // p = c => after character and
+                // 0 < p < c => character potentially broken across 
line break
+                //              within the character
+                for (int p = c; p >= 0; p--) {
+
+                    // a: no or one character following the one under test
+                    // (a = 0 meaning the character under test is 
followed by
+                    // end of value which is also represented as a line 
break)
+                    for (int a = 0; a <= 1; a++) {
+
+                        // offset: so many characters (actually bytes here
+                        // filled with one byte characters) are needed 
to place
+                        // the next character into a position relative 
to the
+                        // maximum line width that it may or may not 
have to be
+                        // broken onto the next line
+                        int offset =
+                                // number of lines; - 1 is continuation 
space
+                                b * (MANIFEST_LINE_CONTENT_WIDTH_BYTES - 1)
+                                // line length minus "Name: ".length()
+                                + MANIFEST_LINE_CONTENT_WIDTH_BYTES - 6
+                                // position of maximum line width 
relative to
+                                // beginning of encoded character
+                                - p;
+                        int seed = ((a * 2 + p) * c + c) * 4 + b;
+                        String value = "";
+                        for (int i = 0; i < offset - 1; i++) {
+                            value += numByteUtfCharacter(1, seed++);
+                        }
+                        // character before the one to test the break
+                        value += FILL;
+                        String character = numByteUtfCharacter(c, seed);
+                        value += character;
+                        for (int i = 0; i < a; i++) {
+                            // character after the one to test the break
+                            value += FILL;
+                        }
+
+                        for (PositionInManifest i :
+                                PositionInManifest.values()) {
+
+                            params.add(new Object[] {
+                                    b, c, p, a, i, character, value});
+                        }
+                    }
+                }
+            }
+        }
+
+        return params.toArray(new Object[0][0]);
+    }
+
+    /**
+     * Checks that multi-byte utf characters work well with line breaks and
+     * continuation lines in jar manifests.
+     *
+     * Produces otherwise arbitrary manifests so that a specific character
+     * will not just fit on the same line and a line break and continuation
+     * line are required with:
    
+     * 
  • different encoded sizes of characters: one, two, three, and four
+     * bytes per character (including also utf bmp and surrogate 
pairs)
    • 
+     * 
  • different amount of space remaining on the same line or relative
+     * position of the latest possible line break position with respect 
to the
+     * character that can be continued on the same line or will have to be
+     * continued on the next line after a line break
    • 
+     * 
  • different number of preceding line breaks
    • 
+     * 

+     * For each of these cases the break position is verified in the binary
+     * manifest.
+     */
+    @Test(dataProvider = "lineBreakParameters")
+    public void testWriteLineBreaksKeepCharactersTogether(int b, int c, 
int p,
+            int a, PositionInManifest i, String character, String value)
+                    throws IOException {
+        byte[] mfBytes = writeManifest(i, NAME, value);
+
+        // expect the whole character on the next line unless it fits
+        // completely on the current line
+        boolean breakExpected = p < c;
+        String brokenPart = character;
+        if (breakExpected) {
+            brokenPart = "\r\n " + brokenPart;
+        }
+        // expect a line break before the next character if there is a next
+        // character and the previous not already broken on next line
+        if (a == 1) {
+            if (!breakExpected) {
+                brokenPart += "\r\n ";
+            }
+            brokenPart += FILL;
+        }
+        brokenPart = FILL + brokenPart + "\r\n";
+        assertOccurrence(mfBytes, brokenPart.getBytes(UTF_8));
+        readManifestAndAssertValue(mfBytes, i, NAME, value);
+    }
+
+    static byte[] writeManifest(PositionInManifest i, String name,
+            String value) throws IOException {
+        Manifest mf = new Manifest();
+        mf.getMainAttributes().put(Name.MANIFEST_VERSION, "1.0");
+        Attributes attributes = new Attributes();
+
+        switch (i) {
+        case MAIN_ATTRIBUTES:
+            mf.getMainAttributes().put(new Name(name), value);
+            break;
+        case SECTION_NAME:
+            mf.getEntries().put(value, attributes);
+            break;
+        case NAMED_SECTION:
+            mf.getEntries().put(NAME, attributes);
+            attributes.put(new Name(name), value);
+            break;
+        }
+
+        ByteArrayOutputStream out = new ByteArrayOutputStream();
+        mf.write(out);
+        byte[] mfBytes = out.toByteArray();
+ System.out.println("-------------------------------------------"
+                + "-----------------------------");
+        System.out.print(new String(mfBytes, UTF_8));
+ System.out.println("-------------------------------------------"
+                + "-----------------------------");
+        return mfBytes;
+    }
+
+    static void assertOccurrence(byte[] mf, byte[] part) {
+        List matchPos = new LinkedList<>();
+        for (int i = 0; i < mf.length; i++) {
+            for (int j = 0; j < part.length && i + j <= mf.length; j++) {
+                if (part[j] == 0) {
+                    if (i + j != mf.length) {
+                        break; // expected eof not found
+                    }
+                } else if (i + j == mf.length) {
+                    break;
+                } else if (mf[i + j] != part[j]) {
+                    break;
+                }
+                if (j == part.length - 1) {
+                    matchPos.add(i);
+                }
+            }
+        }
+        assertEquals(matchPos.size(), 1, "not "
+                + (matchPos.size() < 1 ? "found" : "unique") + ": '"
+                + new String(part, UTF_8) + "'");
+    }
+
+    static void readManifestAndAssertValue(
+            byte[] mfBytes, PositionInManifest i, String name, String 
value)
+                    throws IOException {
+        Manifest mf = new Manifest(new ByteArrayInputStream(mfBytes));
+
+        switch (i) {
+        case MAIN_ATTRIBUTES:
+            assertEquals(mf.getMainAttributes().getValue(name), value,
+                    "main attributes header value");
+            break;
+        case SECTION_NAME:
+            Attributes attributes = mf.getAttributes(value);
+            assertNotNull(attributes, "named section not found");
+            break;
+        case NAMED_SECTION:
+            attributes =
+                    mf.getAttributes(NAME);
+            assertEquals(attributes.getValue(name), value,
+                    "named section attributes header value");
+            break;
+        }
+    }
+
+    @Test(dataProvider = "lineBreakParameters")
+    public void readContinuationLines(int b, int c, int p, int a,
+            PositionInManifest i, String character, String value)
+                    throws IOException {
+        byte[] mfBytes = writeManifestWithBrokenCharacters(i, NAME, value);
+
+        ByteArrayOutputStream buf = new ByteArrayOutputStream();
+        buf.write(FILL.getBytes(UTF_8));
+        byte[] characterBytes = character.getBytes(UTF_8);
+        // the portion of the character that fits on the current line 
before
+        // a break at 72 bytes, ranges from nothing (p == 0) to the whole
+        // character (p == c)
+        for (int j = 0; j < p; j++) {
+            buf.write(characterBytes, j, 1);
+        }
+        // expect a line break at exactly 72 bytes from the beginning 
of the
+        // line unless the whole character fits on that line
+        boolean breakExpected = p < c;
+        if (breakExpected) {
+            buf.write("\r\n ".getBytes(UTF_8));
+        }
+        // the remaining portion of the character, if any
+        for (int j = p; j < c; j++) {
+            buf.write(characterBytes, j, 1);
+        }
+        // expect another linebreak if the whole character fitted on 
the same
+        // line and there is another character
+        if (a == 1) {
+            if (c == p) {
+                buf.write("\r\n ".getBytes(UTF_8));
+            }
+            buf.write(FILL.getBytes(UTF_8));
+        }
+        buf.write("\r\n".getBytes(UTF_8));
+        byte[] brokenPart = buf.toByteArray();
+        assertOccurrence(mfBytes, brokenPart);
+        readManifestAndAssertValue(mfBytes, i, NAME, value);
+    }
+
+    /*
+     * From previous Manifest implementation reduced to the minimum 
required to
+     * demonstrate compatibility
+     */
+    @SuppressWarnings("deprecation")
+    static byte[] writeManifestWithBrokenCharacters(
+            PositionInManifest i, String name, String value)
+                    throws IOException {
+        byte[] vb = value.getBytes("UTF8");
+        value = new String(vb, 0, 0, vb.length);
+        ByteArrayOutputStream out = new ByteArrayOutputStream();
+        DataOutputStream dos = new DataOutputStream(out);
+        String vername = Name.MANIFEST_VERSION.toString();
+        dos.writeBytes(vername + ": 0.1\r\n");
+
+        if (i == PositionInManifest.MAIN_ATTRIBUTES) {
+            StringBuffer buffer = new StringBuffer(name);
+            buffer.append(": ");
+            buffer.append(value);
+            make72Safe(buffer);
+            buffer.append("\r\n");
+            dos.writeBytes(buffer.toString());
+        }
+        dos.writeBytes("\r\n");
+
+        if (i == PositionInManifest.SECTION_NAME ||
+                i == PositionInManifest.NAMED_SECTION) {
+            StringBuffer buffer = new StringBuffer("Name: ");
+            if (i == PositionInManifest.SECTION_NAME) {
+                buffer.append(value);
+            } else {
+                buffer.append(NAME);
+            }
+            make72Safe(buffer);
+            buffer.append("\r\n");
+            dos.writeBytes(buffer.toString());
+
+            if (i == PositionInManifest.NAMED_SECTION) {
+                buffer = new StringBuffer(name);
+                buffer.append(": ");
+                buffer.append(value);
+                make72Safe(buffer);
+                buffer.append("\r\n");
+                dos.writeBytes(buffer.toString());
+            }
+
+            dos.writeBytes("\r\n");
+        }
+
+        dos.flush();
+        byte[] mfBytes = out.toByteArray();
+ System.out.println("-------------------------------------------"
+                + "-----------------------------");
+        System.out.print(new String(mfBytes, UTF_8));
+ System.out.println("-------------------------------------------"
+                + "-----------------------------");
+        return mfBytes;
+    }
+
+    /**
+     * Adds line breaks to enforce a maximum 72 bytes per line.
+     * From previous Manifest implementation.
+     */
+    static void make72Safe(StringBuffer line) {
+        try {
+            Method method = Manifest.class.getDeclaredMethod(
+                    "make72Safe", StringBuffer.class);
+            method.setAccessible(true);
+            method.invoke(null, line);
+        } catch (ReflectiveOperationException e) {
+            fail(e.getMessage(), e);
+        }
+    }
+
+}
diff -r 2ace90aec488 test/jdk/java/util/jar/Manifest/LineBreakLineWidth.java
--- a/test/jdk/java/util/jar/Manifest/LineBreakLineWidth.java    Mon Apr 
30 21:56:54 2018 -0400
+++ b/test/jdk/java/util/jar/Manifest/LineBreakLineWidth.java    Wed May 
02 07:20:46 2018 +0200
@@ -26,9 +26,13 @@
  import java.io.ByteArrayInputStream;
  import java.io.ByteArrayOutputStream;
  import java.io.IOException;
+import java.util.Set;
+import java.util.TreeSet;
  import java.util.jar.Manifest;
  import java.util.jar.Attributes;
  import java.util.jar.Attributes.Name;
+import java.util.stream.Collectors;
+import java.util.stream.IntStream;

  import org.testng.annotations.Test;
  import static org.testng.Assert.*;
@@ -37,8 +41,10 @@
   * @test
   * @bug 6372077
   * @run testng LineBreakLineWidth
- * @summary write valid manifests with respect to line breaks
- *          and read any line width
+ * @summary Write valid manifests with respect to line widths breaking 
longer
+ *          lines, especially for 6372077 that the lines are 
sufficiently wide
+ *          to contain all possible valid header names, and read any line
+ *          width.
   */
  public class LineBreakLineWidth {

@@ -49,6 +55,11 @@
      final static int MAX_HEADER_NAME_LENGTH = 70;

      /**
+     * maximum line width not including the line break
+     */
+    final static int MAX_LINE_CONTENT_LENGTH = 72;
+
+    /**
       * range of one..{@link #TEST_WIDTH_RANGE} covered in this test that
       * exceeds the range of allowed header name lengths or line widths
       * in order to also cover invalid cases beyond the valid boundaries
@@ -60,20 +71,27 @@
      final static int TEST_WIDTH_RANGE = 123;

      /**
-     * tests if only valid manifest files can written depending on the 
header
+     * Tests if only valid manifest files can written depending on the 
header
       * name length or that an exception occurs already on the attempt 
to write
       * an invalid one otherwise and that no invalid manifest can be 
written.
       * 

-     * due to bug JDK-6372077 it was possible to write a manifest that 
could
-     * not be read again. independent of the actual manifest line 
width, such
+     * Due to bug JDK-6372077 it was possible to write a manifest that 
could
+     * not be read again. Independent of the actual manifest line 
width, such
       * a situation should never happen, which is the subject of this test.
+     * 

+     * While this test covers header names which can contain only 
one-byte utf
+     * encoded characters and the resulting manifest line widths, 
multi-byte
+     * utf encoded characters can occur in header values, which is 
subject of
+     * {@link #testManifestLineWidthMaximumRange()}.
       */
      @Test
      public void testWriteValidManifestOrException() throws IOException {
+        assertTrue(TEST_WIDTH_RANGE > MAX_HEADER_NAME_LENGTH);
+
          /*
-         * multi-byte utf-8 characters cannot occur in header names,
+         * Multi-byte utf-8 characters cannot occur in header names,
           * only in values which are not subject of this test here.
-         * hence, each character in a header name uses exactly one byte and
+         * Hence, each character in a header name uses exactly one byte and
           * variable length utf-8 character encoding doesn't affect 
this test.
           */

@@ -111,18 +129,18 @@
      }

      /**
-     * tests that manifest files can be read even if the line breaks are
+     * Tests that manifest files can be read even if the line breaks are
       * placed in different positions than where the current JDK's
       * {@link Manifest#write(java.io.OutputStream)} would have put it 
provided
       * the manifest is valid otherwise.
       * 

-     * the 
-     * "Notes on Manifest and Signature Files" in the "JAR File
-     * Specification" state that "no line may be longer than 72 bytes
-     * (not characters), in its utf8-encoded form." but allows for 
earlier or
+     * The 
+     * "Notes on Manifest and Signature Files" in the "JAR File
+     * Specification" state that no line may be longer than 72 bytes 
(not
+     * characters), in its utf8-encoded form. but allows for earlier or
       * additional line breaks.
       * 

-     * the most important purpose of this test case is probably to make 
sure
+     * The most important purpose of this test case is probably to make 
sure
       * that manifest files broken at 70 bytes line width written with the
       * previous version of {@link Manifest} before this fix still work 
well.
       */
@@ -186,7 +204,8 @@
           * form.
           */
          String lineBrokenSectionName = breakLines(lineWidth, "Name: " 
+ name);
-        String lineBrokenNameAndValue = breakLines(lineWidth, name + ": 
" + value);
+        String lineBrokenNameAndValue = breakLines(lineWidth, name + ": "
+                    + value);

          ByteArrayOutputStream mfBuf = new ByteArrayOutputStream();
          mfBuf.write("Manifest-Version: 1.0".getBytes(UTF_8));
@@ -264,7 +283,7 @@
          return mfBytes;
      }

-    private static void printManifest(byte[] mfBytes) {
+    static void printManifest(byte[] mfBytes) {
          final String sepLine = 
"----------------------------------------------"
                  + "---------------------|-|-|"; // |-positions: 
---68-70-72
          System.out.println(sepLine);
@@ -272,13 +291,179 @@
          System.out.println(sepLine);
      }

-    private static void assertMainAndSectionValues(Manifest mf, String 
name,
+    static void assertMainAndSectionValues(Manifest mf, String name,
              String value) {
          String mainValue = mf.getMainAttributes().getValue(name);
-        String sectionValue = mf.getAttributes(name).getValue(name);
-
          assertEquals(value, mainValue, "value different in main section");
+        Attributes attributes = mf.getAttributes(name);
+        assertNotNull(attributes, "named section not found");
+        String sectionValue = attributes.getValue(name);
          assertEquals(value, sectionValue, "value different in named 
section");
      }

+    @Test
+    public void testWriteManifestOnOneLine() throws IOException {
+        testWriteVersionInfoLineWidth(Name.MANIFEST_VERSION);
+    }
+
+    @Test
+    public void testWriteSignatureVersionOnOneLine() throws IOException {
+        testWriteVersionInfoLineWidth(Name.SIGNATURE_VERSION);
+    }
+
+    /**
+     * Tests that manifest versions "Manifest-Version" and 
"Signature-Version"
+     * are not continued on a next line.
+     */
+    void testWriteVersionInfoLineWidth(Name version) throws IOException {
+        // e: number of characters of version header exceeding line width
+        for (int e = 0; e <= 1; e++) {
+            Manifest mf = new Manifest();
+            mf.getMainAttributes().put(version,
+ "01234567890123456789012345678901234567890123456789012345"
+                    .substring(0, MAX_HEADER_NAME_LENGTH
+                            - version.toString().length() + e));
+            ByteArrayOutputStream out = new ByteArrayOutputStream();
+            mf.write(out);
+            byte[] mfBytes = out.toByteArray();
+            printManifest(mfBytes);
+            // maximum line width can only be exceeded if header not broken
+            assertEquals(MAX_LINE_CONTENT_LENGTH + e,
+                    findMaximumLineWidth(mfBytes));
+        }
+    }
+
+    static int findMaximumLineWidth(byte[] mfBytes) {
+        int max = 0;
+        int b = 0; // start position of current line
+        for (int i = 0; i < mfBytes.length; i++) {
+            switch (mfBytes[i]) {
+            case 10:
+            case 13:
+                max = Math.max(max, i - b);
+                b = i + 1;
+            }
+        }
+        return max;
+    }
+
+    /**
+     * @see LineBreakCharacter#numByteUtfCharacter(int, int)
+     */
+    static String numByteUtfCharacter(int numBytes, int seed) {
+        seed = seed < 0 ? -seed : seed;
+        if (numBytes == 1) {
+            seed %= 0x5F;
+            seed += 0x20; // exclude control characters (0..0x19) here
+        } else if (numBytes == 2) {
+            seed %= 0x800 - 0x80;
+            seed += 0x80;
+        } else if (numBytes == 3) {
+            seed %= 0x10000 - 0x800 + 0xFDD0 - 0xFDEF + 0xFFFE - 0xFFFF;
+            seed += 0x800
+                    + (seed >= 0xFDD0 ? 0xFDEF - 0xFDD0 : 0) // 
non-characters
+                    + (seed % 0x10000) * (0xFFFF - 0xFFFE); // byte 
order marks
+        } else {
+            seed %= 0x110000 - (0x10000 - 0xFFFE);
+            seed += 0x10000
+                    + (seed % 0x10000) * (0xFFFF - 0xFFFE); // byte 
order marks
+        }
+
+        String string = new String(Character.toChars(seed));
+        assertEquals(string.getBytes(UTF_8).length, numBytes,
+                "self-test failed: unexpected utf encoded character 
length");
+        return string;
+    }
+
+    /**
+     * Tests that the manifest line content width is between 69 (1 +
+     * maximum line width (without line break) 72 - maximum utf encoded
+     * character length 4) and 72 before continued on the 
next
+     * line, aka continuation line, depending only on the last character
+     * before the line break and not on those before or after in order to
+     * ensure the minimum number of line breaks and continuation lines
+     * possible.
+     * 

+     * The 
+     * "Notes on Manifest and Signature Files" in the "JAR File
+     * Specification" state that no line may be longer than 72 bytes 
(not
+     * characters), in its utf8-encoded form. and allows for earlier or
+     * additional line breaks.
+     * 

+     * The number of characters a line may be less than the number of bytes
+     * but this is not explicitly verified because it can be assumed if 
some
+     * characters use more than one byte each and the number of bytes is as
+     * expected up to 72 that fewer than 72 characters were placed on 
the same
+     * line.
+     * 

+     * While {@link #testWriteValidManifestOrException()} tests header 
names
+     * lengths, this test covers the values.
+     */
+    @Test
+    public void testManifestLineWidthRange() throws Exception {
+        final int MAX_UTF_CHARACTER_ENCODED_LENGTH = 4;
+        final String TEST_NAME = "test";
+
+        // value will be filled with many possible sequences of utf
+        // characters of different encoded numbers of bytes in the form of
+        // "k times i-bytes size character" + "k times i-bytes size 
character"
+        // and by prepending up to 72 "x" characters at every possible 
position
+        // relative to a possible line break.
+        String value = "";
+        int seed = 0;
+        for (int i = 1; i <= MAX_UTF_CHARACTER_ENCODED_LENGTH; i++) {
+            for (int j = 1; j <= MAX_UTF_CHARACTER_ENCODED_LENGTH; j++) {
+                String valueI = "", valueJ = "";
+                for (int k = 1; k < MAX_LINE_CONTENT_LENGTH; k++) {
+                    valueI += numByteUtfCharacter(i, seed++);
+                    valueJ += numByteUtfCharacter(j, seed++);
+                    value += valueI + valueJ;
+                }
+            }
+        }
+
+        String offset = "";
+        for (int i = 0; i <= MAX_LINE_CONTENT_LENGTH; i++) {
+            offset += "x";
+            byte[] mfBytes = writeManifest(TEST_NAME, offset + value);
+            Manifest mf = new Manifest(new ByteArrayInputStream(mfBytes));
+            assertMainAndSectionValues(mf, TEST_NAME, offset + value);
+
+            Set allowedWidths = IntStream.rangeClosed(
+                    MAX_LINE_CONTENT_LENGTH - 
MAX_UTF_CHARACTER_ENCODED_LENGTH + 1,
+ MAX_LINE_CONTENT_LENGTH).boxed().collect(Collectors.toSet());
+            assertEquals(allowedWidths, findContinuedLineWidths(mfBytes));
+        }
+    }
+
+    /**
+     * Counts the length of lines (without the line breaks) which are
+     * continued, not the continuation lines but those before that did 
not fit
+     * on one line, whereby continuation lines may be continued again on
+     * another line, and returns their length in bytes, not characters.
+     */
+    static Set findContinuedLineWidths(byte[] mfBytes) {
+        Set widths = new TreeSet<>();
+        int previousLineWidth = -1;
+        int b = 0; // start position of current line
+        for (int i = 0; i < mfBytes.length; i++) {
+            switch (mfBytes[i]) {
+            case '\r':
+            case '\n':
+                previousLineWidth = i - b;
+                if (mfBytes[i] == '\r' &&
+                        i + 1 < mfBytes.length && mfBytes[i + 1] == '\n') {
+                    i++;
+                }
+                b = i + 1;
+                break;
+            case ' ':
+                if (i == b) {
+                    widths.add(previousLineWidth);
+                }
+            }
+        }
+        return widths;
+    }
+
  }
diff -r 2ace90aec488 test/jdk/java/util/jar/Manifest/NullKeysAndValues.java
--- /dev/null    Thu Jan 01 00:00:00 1970 +0000
+++ b/test/jdk/java/util/jar/Manifest/NullKeysAndValues.java    Wed May 
02 07:20:46 2018 +0200
@@ -0,0 +1,149 @@
+/*
+ * Copyright (c) 2018, 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code 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 General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License 
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+import static java.nio.charset.StandardCharsets.UTF_8;
+
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.util.jar.Attributes;
+import java.util.jar.Manifest;
+import java.util.jar.Attributes.Name;
+import java.lang.reflect.Field;
+
+import org.testng.annotations.Test;
+import static org.testng.Assert.*;
+
+/**
+ * @test
+ * @run testng/othervm --illegal-access=warn NullKeysAndValues
+ * @summary Tests manifests with {@code null} values as section name, 
header
+ *          name, or value in both main and named attributes sections.
+ */
+/*
+ * Note to future maintainer:
+ * In order to actually being able to test all the cases where key and 
values
+ * are null normal manifest and attributes manipulation through their 
public
+ * api is not sufficient but then there were these null checks there before
+ * which may or may not have had their reason and this way it's ensured 
that
+ * the behavior does not change with that respect.
+ * Once module isolation is enforced some test cases will not any longer be
+ * possible and those now tested situations will be guaranteed not to occur
+ * any longer at all at which point the corresponding tests can be removed
+ * safely without replacement unless of course another way is found 
inject the
+ * tested null values.
+ * Another trick to access package private class members could be to use
+ * deserialization or adding a new class to the same package on the 
classpath.
+ * Here is not important how the values are set to null because it 
shows that
+ * the behavior remains unchanged.
+ */
+public class NullKeysAndValues {
+
+    static final String SOME_KEY = "some-key";
+    static final String SOME_VALUE = "some value";
+    static final String STRNULL = "null";
+
+    @Test
+    public void testMainAttributesHeaderNameNull() throws Exception {
+        Manifest mf = new Manifest();
+        Field attr = mf.getClass().getDeclaredField("attr");
+        attr.setAccessible(true);
+        Attributes mainAtts = new Attributes() {{
+            super.put( /* in: */ null, SOME_VALUE);
+        }};
+        attr.set(mf, mainAtts);
+        mf.getMainAttributes().put(Name.MANIFEST_VERSION, "1.0");
+        try {
+            mf = writeAndRead(mf);
+            fail();
+        } catch ( /* out: */ NullPointerException e) {
+            return; // ok
+        }
+    }
+
+    @Test
+    public void testMainAttributesHeaderValueNull() throws Exception {
+        Manifest mf = new Manifest();
+        Field attr = mf.getClass().getDeclaredField("attr");
+        attr.setAccessible(true);
+        Attributes mainAtts = new Attributes() {{
+            map.put(new Name(SOME_KEY), /* in: */ null);
+        }};
+        attr.set(mf, mainAtts);
+        mf.getMainAttributes().put(Name.MANIFEST_VERSION, "1.0");
+        mf = writeAndRead(mf);
+        assertEquals(mf.getMainAttributes().getValue(SOME_KEY),
+                /* out: */ STRNULL);
+    }
+
+    @Test
+    public void testSectionNameNull() throws IOException {
+        Manifest mf = new Manifest();
+        mf.getMainAttributes().put(Name.MANIFEST_VERSION, "1.0");
+        mf.getEntries().put( /* in: */ null, new Attributes());
+        mf = writeAndRead(mf);
+        assertNotNull(mf.getEntries().get( /* out: */ STRNULL));
+    }
+
+    @Test
+    public void testNamedSectionHeaderNameNull() throws IOException {
+        Manifest mf = new Manifest();
+        mf.getMainAttributes().put(Name.MANIFEST_VERSION, "1.0");
+        mf.getEntries().put(SOME_KEY, new Attributes() {{
+            map.put( /* in: */ null, SOME_VALUE);
+        }});
+        try {
+            mf = writeAndRead(mf);
+            fail();
+        } catch ( /* out: */ NullPointerException e) {
+            return; // ok
+        }
+    }
+
+    @Test
+    public void testNamedSectionHeaderValueNull() throws IOException {
+        Manifest mf = new Manifest();
+        mf.getMainAttributes().put(Name.MANIFEST_VERSION, "1.0");
+        mf.getEntries().put(SOME_KEY, new Attributes() {{
+            map.put(new Name(SOME_KEY), /* in: */ null);
+        }});
+        mf = writeAndRead(mf);
+ assertEquals(mf.getEntries().get(SOME_KEY).getValue(SOME_KEY),
+                /* out: */ STRNULL);
+    }
+
+    static Manifest writeAndRead(Manifest mf) throws IOException {
+        ByteArrayOutputStream out = new ByteArrayOutputStream();
+        mf.write(out);
+        byte[] mfBytes = out.toByteArray();
+ System.out.println("-------------------------------------------"
+                + "-----------------------------");
+        System.out.print(new String(mfBytes, UTF_8));
+ System.out.println("-------------------------------------------"
+                + "-----------------------------");
+
+        ByteArrayInputStream in = new ByteArrayInputStream(mfBytes);
+        return new Manifest(in);
+    }
+
+}
diff -r 2ace90aec488 test/jdk/java/util/jar/Manifest/ValueUtfEncoding.java
--- /dev/null    Thu Jan 01 00:00:00 1970 +0000
+++ b/test/jdk/java/util/jar/Manifest/ValueUtfEncoding.java    Wed May 
02 07:20:46 2018 +0200
@@ -0,0 +1,226 @@
+/*
+ * Copyright (c) 2018, 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code 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 General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License 
version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+import static java.nio.charset.StandardCharsets.UTF_8;
+
+import java.io.ByteArrayInputStream;
+import java.io.ByteArrayOutputStream;
+import java.io.IOException;
+import java.util.jar.Attributes;
+import java.util.jar.Attributes.Name;
+import java.util.jar.Manifest;
+import java.util.List;
+import java.util.ArrayList;
+
+import org.testng.annotations.Test;
+import static org.testng.Assert.*;
+
+/**
+ * @test
+ * @bug 6202130
+ * @run testng ValueUtfEncoding
+ * @summary Tests complete manifest values utf encoding
+ * 

+ * This test writes and reads a manifest that contains every valid utf
+ * character (three times), grouped into manifest header values with about
+ * 65535 bytes each or slightly more, resulting in a single huge 
manifest with
+ * 3 * 67 + 1 values and 13703968 bytes in the manifest's encoded form in
+ * total. This way, all possible 1111995 utf characters are covered in one
+ * manifest.
+ * 

+ * Every character occurs three times, once in a main attribute value, 
once in
+ * a section name, and once in a named section attribute value, because
+ * implementation of writing the main section headers differs from the one
+ * writing named section headers in
+ * {@link Attributes#writeMain(java.io.DataOutputStream)} and
+ * {@link Attributes#write(java.io.DataOutputStream)} due to special 
order of
+ * {@link Name#MANIFEST_VERSION} and {@link Name#SIGNATURE_VERSION}.
+ * and also {@link Manifest#read(java.io.InputStream)} treating reading the
+ * main section differently from reading named sections names headers.
+ * 

+ * Only header values are tested. Characters for header names are much more
+ * limited and very simple ones are used just to get valid and 
different ones.
+ * 

+ * Correct support of all utf characters also has some relation to breaking
+ * characters across lines, see {@link LineBreakCharacter}.
+ */
+public class ValueUtfEncoding {
+
+    /**
+     * From the specifications:
+     * Implementations should support 65535-byte (not character) header
+     * values, and 65535 headers per file. They might run out of memory,
+     * but there should not be hard-coded limits below these values.
+     *
+     * @see Notes 
on Manifest and Signature Files
+     */
+    static final int MIN_VALUE_LENGTH_SUPPORTED = 2 << 16 - 1;
+
+    static final int MAX_UTF_CHARACTER_ENCODED_LENGTH = 4;
+
+    static boolean isValidUtfCharacter(int codePoint) {
+        if (0xFDD0 <= codePoint && codePoint <= 0xFDEF) {
+            return false; /* non-characters */
+        }
+        if ((codePoint & 0xFFFE) == 0xFFFE) {
+            return false; /* byte order marks */
+        }
+        return true;
+    }
+
+    /**
+     * returns {@code true} if {@code codePoint} is explicitly forbidden in
+     * manifest values based on a statement from the specs:
+     * 
otherchar: any UTF-8 character except NUL, CR and LF
+     *
+     * @see Jar File 
Specification
+     */
+    static boolean isInvalidManifestValueCharacter(int codePoint) {
+        return codePoint == 0 /* NUL */
+            || codePoint == '\r' /* CR */
+            || codePoint == '\n' /* LF */;
+    };
+
+    /**
+     * Produces a list of strings with all known utf characters except 
those
+     * invalid in manifest header values with at least
+     * {@link #MIN_VALUE_LENGTH_SUPPORTED} utf-8 encoded bytes each
+     * except the last string which contains just the remaining characters.
+     */
+    static List produceValidManifestUtfCharacterValues() {
+        int maxLengthBytes = MIN_VALUE_LENGTH_SUPPORTED +
+                // exceed the specified limit by at least one character
+                MAX_UTF_CHARACTER_ENCODED_LENGTH + 1;
+
+        int numberOfUsedCodePoints = 0;
+        ArrayList values = new ArrayList<>();
+        byte[] valueBuf = new byte[maxLengthBytes];
+        int pos = 0;
+        for (int codePoint = Character.MIN_CODE_POINT;
+                codePoint <= Character.MAX_CODE_POINT; codePoint++) {
+            if (!isValidUtfCharacter(codePoint)) {
+                continue;
+            }
+            if (isInvalidManifestValueCharacter(codePoint)) {
+                continue;
+            }
+            numberOfUsedCodePoints++;
+
+            byte[] charBuf =
+                    new 
String(Character.toChars(codePoint)).getBytes(UTF_8);
+            if (pos + charBuf.length > valueBuf.length) {
+                values.add(new String(valueBuf, 0, pos, UTF_8));
+                pos = 0;
+            }
+            System.arraycopy(charBuf, 0, valueBuf, pos, charBuf.length);
+            pos += charBuf.length;
+        }
+        if (pos > 0) {
+            values.add(new String(valueBuf, 0, pos, UTF_8));
+        }
+
+        if (numberOfUsedCodePoints !=
+                (17 << 16) /* utf space */
+                - 66 /* non-characters */
+                - 3 /* nul, cr, lf */) {
+            fail("self-test: utf character set not covered exactly");
+        }
+
+        return values;
+    }
+
+    /**
+     * returns simple, valid, short, and distinct manifest header names.
+     * The returned name cannot be "{@code Manifest-Version}" because the
+     * returned string does not contain "{@code -}".
+     *
+     * @param seed seed to produce distinct names
+     */
+    static String azName(int seed) {
+        StringBuffer name = new StringBuffer();
+        do {
+            name.insert(0, (char) (seed % 26 + (seed < 26 ? 'A' : 'a')));
+            seed = seed / 26 - 1;
+        } while (seed >= 0);
+        return name.toString();
+    }
+
+    /**
+     * covers writing and reading of manifests with all known utf 
characters.
+     *
+     * Because the implementation used different portions of code 
depending on
+     * where the value occurs to read or write in earlier versions, each
+     * character is tested in each of the three positions:
    
+     * 
  • main attribute header,
    • 
+     * 
  • named section name, which is in fact a header value after a 
blank
+     * line, and
    • 
+     * 
  • named sections header values
    • 
+     * 
      
+     */
+    @Test
+    public void testValueUtfEncoding() throws IOException {
+        Manifest mf = new Manifest();
+        mf.getMainAttributes().put(Name.MANIFEST_VERSION, "1.0");
+
+        List values = produceValidManifestUtfCharacterValues();
+        for (int i = 0; i < values.size(); i++) {
+            String name = azName(i);
+            String value = values.get(i);
+
+            mf.getMainAttributes().put(new Name(name), value);
+            Attributes attributes = new Attributes();
+            mf.getEntries().put(value, attributes);
+            attributes.put(new Name(name), value);
+        }
+
+        mf = writeAndRead(mf);
+
+        for (int i = 0; i < values.size(); i++) {
+            String value = values.get(i);
+            String name = azName(i);
+
+            assertEquals(mf.getMainAttributes().getValue(name), value,
+                    "main attributes header value");
+            Attributes attributes = mf.getAttributes(value);
+            assertNotNull(attributes, "named section not found");
+            assertEquals(attributes.getValue(name), value,
+                    "named section attributes value");
+        }
+    }
+
+    static Manifest writeAndRead(Manifest mf) throws IOException {
+        ByteArrayOutputStream out = new ByteArrayOutputStream();
+        mf.write(out);
+        byte[] mfBytes = out.toByteArray();
+
+ System.out.println("-------------------------------------------"
+                + "-----------------------------");
+        System.out.print(new String(mfBytes, UTF_8));
+ System.out.println("-------------------------------------------"
+                + "-----------------------------");
+
+        ByteArrayInputStream in = new ByteArrayInputStream(mfBytes);
+        return new Manifest(in);
+    }
+
+}
diff -r 2ace90aec488 
test/jdk/sun/security/tools/jarsigner/LineBrokenMultiByteCharacter.java
--- 
a/test/jdk/sun/security/tools/jarsigner/LineBrokenMultiByteCharacter.java 
Mon Apr 30 21:56:54 2018 -0400
+++ 
b/test/jdk/sun/security/tools/jarsigner/LineBrokenMultiByteCharacter.java 
Wed May 02 07:20:46 2018 +0200
@@ -21,35 +21,48 @@
   * questions.
   */

-/*
- * @test
- * @bug 6695402
- * @summary verify signatures of jars containing classes with names
- *          with multi-byte unicode characters broken across lines
- * @library /test/lib
- */
-
  import java.io.IOException;
  import java.io.InputStream;
  import java.nio.file.Files;
  import java.nio.file.Paths;
+import java.util.HashMap;
+import java.util.jar.Attributes.Name;
  import java.util.jar.JarFile;
-import java.util.jar.Attributes.Name;
  import java.util.jar.JarEntry;
+import java.util.zip.ZipEntry;
+import java.util.zip.ZipFile;

  import static java.nio.charset.StandardCharsets.UTF_8;

  import jdk.test.lib.SecurityTools;
  import jdk.test.lib.util.JarUtils;

+import org.testng.annotations.*;
+import static org.testng.Assert.*;
+
+/**
+ * @test
+ * @bug 6695402
+ * @library /test/lib
+ * @run testng LineBrokenMultiByteCharacter
+ * @summary verify signatures of jars containing classes with names
+ *          with multi-byte unicode characters broken across lines
+ *
+ * Before utf characters were kept in one piece by bug 6443578 and 
partially
+ * broken across a line break in manifests, bug 6695402 could occur 
resulting
+ * in a signature considered invalid. That can still happen after bug 
6443578
+ * fixed when signing manifests that already contain entries with 
characters
+ * broken across a line break, presumably when an older manifest is present
+ * created with a different jdk.
+ */
  public class LineBrokenMultiByteCharacter {

      /**
-     * this name will break across lines in MANIFEST.MF at the
+     * This name will break across lines in MANIFEST.MF at the
       * middle of a two-byte utf-8 encoded character due to its e acute 
letter
       * at its exact position.
-     *
-     * because no file with such a name exists {@link JarUtils} will 
add the
+     * 
      
+     * Because no file with such a name exists {@link JarUtils} will 
add the
       * name itself as contents to the jar entry which would have 
contained a
       * compiled class in the original bug. For this test, the contents 
of the
       * files contained in the jar file is not important as long as 
they get
@@ -58,55 +71,157 @@
       * @see #verifyClassNameLineBroken(JarFile, String)
       */
      static final String testClassName =
- 
"LineBrokenMultiByteCharacterA1234567890B1234567890C123456789D1234\u00E9xyz.class";
+ "LineBrokenMultiByteCharacterA1234567890B1234567890C123456789"
+            + "D1234\u00E9xyz.class";

+    /**
+     * Used for a test case where an entry / class file is added to an 
existing
+     * signed jar that already contains an entry with this name which 
of course
+     * has to be distinct from the one tested.
+     */
      static final String anotherName =
- 
"LineBrokenMultiByteCharacterA1234567890B1234567890C123456789D1234567890.class";
+ "LineBrokenMultiByteCharacterA1234567890B1234567890C123456789"
+            + "D1234567890.class";

      static final String alias = "a";
      static final String keystoreFileName = "test.jks";
-    static final String manifestFileName = "MANIFEST.MF";
+    static final String manifestFileName = JarFile.MANIFEST_NAME;

-    public static void main(String[] args) throws Exception {
-        prepare();
+    byte[] manifestNoDigest = "Manifest-Version: 
1.0\r\n\r\n".getBytes(UTF_8);
+    byte[] manifestWithDigest; // with character broken across line break

-        testSignJar("test.jar");
-        testSignJarNoManifest("test-no-manifest.jar");
-        testSignJarUpdate("test-update.jar", "test-updated.jar");
+    /**
+     * Simulate a jar manifest as it would have been created by an 
earlier jdk
+     * by re-arranging the line break at exactly 72 bytes content thereby
+     * breaking the multi-byte character under test.
+     */
+    static byte[] rebreak(byte[] mf0) {
+        byte[] mf1 = new byte[mf0.length];
+        int c0 = 0, c1 = 0; // bytes since last line start
+        for (int i0 = 0, i1 = 0; i0 < mf0.length; i0++, i1++) {
+            switch (mf0[i0]) {
+            case '\r':
+                if (i0 + 2 < mf0.length &&
+                        mf0[i0 + 1] == '\n' && mf0[i0 + 2] == ' ') {
+                    // skip line break
+                    i0 += 2;
+                    i1 -= 1;
+                } else {
+                    mf1[i1] = mf0[i0];
+                    c0 = c1 = 0;
+                }
+                break;
+            case '\n':
+                if (i0 + 1 < mf0.length && mf0[i0 + 1] == ' ') {
+                    // skip line break
+                    i0 += 1;
+                    i1 -= 1;
+                } else {
+                    mf1[i1] = mf0[i0];
+                    c0 = c1 = 0;
+                }
+                break;
+            case ' ':
+                if (c0 == 0) {
+                    continue;
+                }
+            default:
+                c0++;
+                if (c1 == 72) {
+                    mf1[i1++] = '\r';
+                    mf1[i1++] = '\n';
+                    mf1[i1++] = ' ';
+                    c1 = 1;
+                } else {
+                    c1++;
+                }
+                mf1[i1] = mf0[i0];
+            }
+        }
+        return mf1;
      }

-    static void prepare() throws Exception {
+    @BeforeClass
+    public void prepare() throws Exception {
          SecurityTools.keytool("-keystore", keystoreFileName, 
"-genkeypair",
                  "-storepass", "changeit", "-keypass", "changeit", 
"-storetype",
                  "JKS", "-alias", alias, "-dname", "CN=X", "-validity", 
"366")
              .shouldHaveExitValue(0);

-        Files.write(Paths.get(manifestFileName), (Name.
-                MANIFEST_VERSION.toString() + ": 
1.0\r\n").getBytes(UTF_8));
+        String jarFileName = "reference-manifest.jar";
+        createJarWithManifest(jarFileName, manifestNoDigest,
+                testClassName, anotherName);
+        SecurityTools.jarsigner("-keystore", keystoreFileName, 
"-storetype",
+                "JKS", "-storepass", "changeit", "-debug", jarFileName, 
alias)
+            .shouldHaveExitValue(0);
+        try (ZipFile refJar = new ZipFile(jarFileName);) {
+            ZipEntry mfEntry = refJar.getEntry(JarFile.MANIFEST_NAME);
+            manifestWithDigest = 
refJar.getInputStream(mfEntry).readAllBytes();
+        }
+        System.out.println("manifestWithDigest before re-break = " +
+                new String(manifestWithDigest, UTF_8));
+        manifestWithDigest = rebreak(manifestWithDigest);
+        System.out.println("manifestWithDigest after re-break = " +
+                new String(manifestWithDigest, UTF_8));
+        // now, manifestWithDigest is accepted as unmodified by
+        // jdk.security.jarsigner.JarSigner#updateDigests
+        // (ZipEntry,ZipFile,MessageDigest[],Manifest) on line 985:
+        // "if (!mfDigest.equalsIgnoreCase(base64Digests[i])) {"
+        // and therefore left unchanged when the jar is signed and
+        // signature verification will check it, which is the test case.
+
+        Files.createDirectory(Paths.get("META-INF/"));
      }

-    static void testSignJar(String jarFileName) throws Exception {
-        JarUtils.createJar(jarFileName, manifestFileName, testClassName);
-        verifyJarSignature(jarFileName);
+    @Test
+    public void testSignJarWithNoExistingClassEntry() throws Exception {
+        String jarFileName = "test-eacuteinonepiece.jar";
+        createJarWithManifest(jarFileName, manifestNoDigest, 
testClassName);
+        signAndVerifyJarSignature(jarFileName, false);
      }

-    static void testSignJarNoManifest(String jarFileName) throws 
Exception {
-        JarUtils.createJar(jarFileName, testClassName);
-        verifyJarSignature(jarFileName);
+    @Test
+    public void testSignJarWithBrokenEAcuteClassEntry() throws Exception {
+        String jarFileName = "test-brokeneacute.jar";
+        createJarWithManifest(jarFileName, manifestWithDigest, 
testClassName);
+        signAndVerifyJarSignature(jarFileName, true);
      }

-    static void testSignJarUpdate(
-            String initialFileName, String updatedFileName) throws 
Exception {
-        JarUtils.createJar(initialFileName, manifestFileName, anotherName);
+    @Test
+    public void testSignJarNoManifest() throws Exception {
+        String jarFileName = "test-no-manifest.jar";
+        JarUtils.createJar(jarFileName, testClassName);
+        signAndVerifyJarSignature(jarFileName, false);
+    }
+
+    @Test
+    public void testSignJarUpdateWithEAcuteClassEntryInOnePiece()
+            throws Exception {
+        String initialFileName = "test-eacuteinonepiece-update.jar";
+        String updatedFileName = "test-eacuteinonepiece-updated.jar";
+        createJarWithManifest(initialFileName, manifestNoDigest, 
anotherName);
          SecurityTools.jarsigner("-keystore", keystoreFileName, 
"-storetype",
                  "JKS", "-storepass", "changeit", "-debug", 
initialFileName,
                  alias).shouldHaveExitValue(0);
          JarUtils.updateJar(initialFileName, updatedFileName, 
testClassName);
-        verifyJarSignature(updatedFileName);
+        signAndVerifyJarSignature(updatedFileName, false);
      }

-    static void verifyJarSignature(String jarFileName) throws Exception {
-        // actually sign the jar
+    @Test
+    public void testSignJarUpdateWithBrokenEAcuteClassEntry()
+            throws Exception {
+        String initialFileName = "test-brokeneacute-update.jar";
+        String updatedFileName = "test-brokeneacute-updated.jar";
+        createJarWithManifest(initialFileName, manifestWithDigest, 
anotherName);
+        SecurityTools.jarsigner("-keystore", keystoreFileName, 
"-storetype",
+                "JKS", "-storepass", "changeit", "-debug", initialFileName,
+                alias).shouldHaveExitValue(0);
+        JarUtils.updateJar(initialFileName, updatedFileName, 
testClassName);
+        signAndVerifyJarSignature(updatedFileName, true);
+    }
+
+    void signAndVerifyJarSignature(String jarFileName,
+            boolean expectBrokenEAcute) throws Exception {
          SecurityTools.jarsigner("-keystore", keystoreFileName, 
"-storetype",
                  "JKS", "-storepass", "changeit", "-debug", 
jarFileName, alias)
              .shouldHaveExitValue(0);
@@ -114,34 +229,34 @@
          try (
              JarFile jar = new JarFile(jarFileName);
          ) {
-            verifyClassNameLineBroken(jar, testClassName);
+            verifyClassNameLineBroken(jar, testClassName, 
expectBrokenEAcute);
              verifyCodeSigners(jar, jar.getJarEntry(testClassName));
          }
      }

      /**
-     * it would be too easy to miss the actual test case by just 
renaming an
+     * It would be too easy to miss the actual test case by just 
renaming an
       * identifier so that the multi-byte encoded character would not 
any longer
       * be broken across a line break.
       *
-     * this check here verifies that the actual test case is tested 
based on
+     * This check here verifies that the actual test case is tested 
based on
       * the manifest and not based on the signature file because at the 
moment,
       * the signature file does not even contain the desired entry at all.
-     *
-     * this relies on {@link java.util.jar.Manifest} breaking lines unaware
-     * of bytes that belong to the same multi-byte utf characters.
       */
-    static void verifyClassNameLineBroken(JarFile jar, String className)
-            throws IOException {
+    static void verifyClassNameLineBroken(JarFile jar, String className,
+            boolean expectBrokenEAcute) throws IOException {
          byte[] eAcute = "\u00E9".getBytes(UTF_8);
          byte[] eAcuteBroken =
                  new byte[] {eAcute[0], '\r', '\n', ' ', eAcute[1]};

-        if (jar.getManifest().getAttributes(className) == null) {
-            throw new AssertionError(className + " not found in manifest");
-        }
+        assertNotNull(jar.getManifest().getAttributes(className),
+                className + " not found in manifest");

          JarEntry manifestEntry = jar.getJarEntry(JarFile.MANIFEST_NAME);
+        System.out.println("expectBrokenEAcute = " + expectBrokenEAcute);
+        System.out.println("Manifest = \n" + new String(
+                jar.getInputStream(manifestEntry).readAllBytes(), UTF_8));
+
          try (
              InputStream manifestIs = jar.getInputStream(manifestEntry);
          ) {
@@ -156,10 +271,12 @@
                      bytesMatched = 0;
                  }
              }
-            if (bytesMatched < eAcuteBroken.length) {
-                throw new AssertionError("self-test failed: multi-byte "
-                        + "utf-8 character not broken across lines");
-            }
+            assertEquals(expectBrokenEAcute,
+                    bytesMatched == eAcuteBroken.length,
+                    "self-test failed: multi-byte "
+                    + "utf-8 character "
+                    + (expectBrokenEAcute ? "not " : "")
+                    + "broken across lines");
          }
      }

@@ -175,11 +292,16 @@
          // a check for the presence of code signers is sufficient to check
          // bug JDK-6695402. no need to also verify the actual code signers
          // attributes here.
-        if (jarEntry.getCodeSigners() == null
-                || jarEntry.getCodeSigners().length == 0) {
-            throw new AssertionError(
-                    "no signing certificate found for " + 
jarEntry.getName());
-        }
+        assertTrue(jarEntry.getCodeSigners() != null
+                && jarEntry.getCodeSigners().length > 0,
+                "no signing certificate found for " + jarEntry.getName());
+    }
+
+    static void createJarWithManifest(String jarFileName, byte[] manifest,
+            String... files) throws IOException {
+        JarUtils.createJar("yetwithoutmanifest-" + jarFileName, files);
+        JarUtils.updateJar("yetwithoutmanifest-" + jarFileName, 
jarFileName,
+                new HashMap<>() {{ put(manifestFileName, manifest); }});
      }

  }

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 6372077and6443578.patch
Type: text/x-patch
Size: 79654 bytes
Desc: not available
URL: 

From sean.mullan at oracle.com  Wed May  2 14:22:03 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 2 May 2018 10:22:03 -0400
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 <9a046c64-8bfc-0a16-2540-534ebef472e7@oracle.com>
 
Message-ID: <18fa711c-8676-b27f-186a-56f16c5488da@oracle.com>

On 5/1/18 5:45 PM, Jamil Nimeh wrote:
>> 134???????????? throw new IllegalArgumentException(
>> ?135???????????????????? "Unsupported parameter format: " + 
>> decodingMethod);
>>
>> Although this seems like a reasonable exception to throw, 
>> AlgorithmParametersSpi.engineInit is not spec'ed to throw this, so I 
>> think you should throw an IOE instead.
>>
>> ?202???????????? throw new IllegalArgumentException(
>> ?203???????????????????? "Unsupported encoding format: " + 
>> encodingMethod);
>>
>> Similar comment, AlgorithmParametersSpi.engineGetEncoded is not 
>> spec'ed to throw this, so I think you should throw an IOE instead.
> JN: Fair enough.? I had figured IAE would be OK since it's an unchecked 
> exception and seemed more appropriate to the situation. But IOE is fine 
> too.? Will fix.

I checked all of the other JDK AlgorithmParametersSpi implementations, 
and they actually ignore the format parameter completely and always 
encode using ASN.1. But I don't think that is right. So, I think we 
should throw an Exception and maybe file a bug to add a clarification to 
the spec for engineGetEncoded.

One other issue. The spec for engineGetEncoded says that if the format 
is null, the primary encoding format for parameters is used, so the code 
for 199-200 should be:

199         if (encodingMethod == null || 
encodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
200             return engineGetEncoded();

--Sean


From sean.mullan at oracle.com  Wed May  2 14:35:59 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 2 May 2018 10:35:59 -0400
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <11d35b9a-611a-1cbc-36e5-c15312ae2744@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 <9a046c64-8bfc-0a16-2540-534ebef472e7@oracle.com>
 <9a56bc66-b93e-b244-9e47-1b795e8e2fb0@oracle.com>
 <11d35b9a-611a-1cbc-36e5-c15312ae2744@oracle.com>
Message-ID: <172b4231-74e5-1994-0739-24aa74b0a7c6@oracle.com>

On 5/1/18 6:55 PM, Jamil Nimeh wrote:
>> 262???????? counter = 1;
>>
>> Here you set the counter field to 1, but this method can still throw 
>> exceptions after that. Is there any risk of leaving the object in an 
>> inconsistent state by setting counter=1 if this method fails to 
>> complete successfully? Same comment on line 305.
> JN: I don't think so, since any Cipher.init call that would drop into 
> these init routines expects the counter to be set to 1 (or to whatever 
> value came in from the AlgorithmParameterSpec).? If an exception is 
> thrown during the init codepath, the object will remain in an 
> uninitialized state and cannot be used, so I don't see much danger 
> there.? The only thing the user could do with an object in this 
> situation would be to try to initialize it again (hopefully with 
> parameters that don't cause it to fail).

Ok.

>> ?401???????? if (newNonce == null) {
>> ?402???????????? newNonce = new byte[12];
>> ?403???????????? if (random != null) {
>> ?404???????????????? random.nextBytes(newNonce);
>> ?405???????????? }
>>
>> It looks like there is a possibility of a non-random nonce being used 
>> if random is null at this point, which it could be if null is passed 
>> as the random and params parameters. I don't think that is what is 
>> intended. I think the right thing to do is throw an 
>> InvalidAlgParamException if you get to this point and random is null.
> JN: Well, the method comment is old/outdated, another throwback to an 
> older version that said it would use all zeroes in the null/null case 
> and I don't want that to behave that way any longer.? I think if I do a 
> similar approach to the init actions in 258-260 we should be in better 
> shape.? Then when params is null there will always be a random 12-byte 
> nonce generated, regardless of the null/non-null status of the "random" 
> parameter.

Ok.

>> ?508???????? this.keyBytes = newKeyBytes;
>> ?509???????? nonce = newNonce;
>> ?510
>> ?511???????? aadDone = false;
>> ?512???????? direction = opmode;
>>
>> Here also you are setting various fields but the method may still 
>> throw an Exception - any issues about leaving the object in an 
>> inconsistent state? Preferably you should set these as the last thing 
>> you do before returning.
> JN: As before.? The object is in an inconsistent state, but unusable 
> because the initialized flag is still false (and that's the absolute 
> last thing that gets set to true during init).? If that flag is false, 
> the update, updateAAD and doFinal methods will throw an execption.? The 
> only way to make it usable is to init successfully. I think we're OK here.

Ok. I think as long as these fields are never dependent on previous 
values if you call engineInit again, then it is ok. In other words, they 
should be the same even if the previous call to engineInit throws an 
Exception. It might be safer as the first thing you do to re-initialize 
these each time engineInit is called.

--Sean



From jamil.j.nimeh at oracle.com  Wed May  2 15:23:02 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 2 May 2018 08:23:02 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <172b4231-74e5-1994-0739-24aa74b0a7c6@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 <9a046c64-8bfc-0a16-2540-534ebef472e7@oracle.com>
 <9a56bc66-b93e-b244-9e47-1b795e8e2fb0@oracle.com>
 <11d35b9a-611a-1cbc-36e5-c15312ae2744@oracle.com>
 <172b4231-74e5-1994-0739-24aa74b0a7c6@oracle.com>
Message-ID: <187b598a-5f3b-7a5e-2709-25febec08348@oracle.com>



On 05/02/2018 07:35 AM, Sean Mullan wrote:
> On 5/1/18 6:55 PM, Jamil Nimeh wrote:
>>> 262???????? counter = 1;
>>>
>>> Here you set the counter field to 1, but this method can still throw 
>>> exceptions after that. Is there any risk of leaving the object in an 
>>> inconsistent state by setting counter=1 if this method fails to 
>>> complete successfully? Same comment on line 305.
>> JN: I don't think so, since any Cipher.init call that would drop into 
>> these init routines expects the counter to be set to 1 (or to 
>> whatever value came in from the AlgorithmParameterSpec).? If an 
>> exception is thrown during the init codepath, the object will remain 
>> in an uninitialized state and cannot be used, so I don't see much 
>> danger there.? The only thing the user could do with an object in 
>> this situation would be to try to initialize it again (hopefully with 
>> parameters that don't cause it to fail).
>
> Ok.
>
>>> ?401???????? if (newNonce == null) {
>>> ?402???????????? newNonce = new byte[12];
>>> ?403???????????? if (random != null) {
>>> ?404???????????????? random.nextBytes(newNonce);
>>> ?405???????????? }
>>>
>>> It looks like there is a possibility of a non-random nonce being 
>>> used if random is null at this point, which it could be if null is 
>>> passed as the random and params parameters. I don't think that is 
>>> what is intended. I think the right thing to do is throw an 
>>> InvalidAlgParamException if you get to this point and random is null.
>> JN: Well, the method comment is old/outdated, another throwback to an 
>> older version that said it would use all zeroes in the null/null case 
>> and I don't want that to behave that way any longer.? I think if I do 
>> a similar approach to the init actions in 258-260 we should be in 
>> better shape.? Then when params is null there will always be a random 
>> 12-byte nonce generated, regardless of the null/non-null status of 
>> the "random" parameter.
>
> Ok.
>
>>> ?508???????? this.keyBytes = newKeyBytes;
>>> ?509???????? nonce = newNonce;
>>> ?510
>>> ?511???????? aadDone = false;
>>> ?512???????? direction = opmode;
>>>
>>> Here also you are setting various fields but the method may still 
>>> throw an Exception - any issues about leaving the object in an 
>>> inconsistent state? Preferably you should set these as the last 
>>> thing you do before returning.
>> JN: As before.? The object is in an inconsistent state, but unusable 
>> because the initialized flag is still false (and that's the absolute 
>> last thing that gets set to true during init).? If that flag is 
>> false, the update, updateAAD and doFinal methods will throw an 
>> execption.? The only way to make it usable is to init successfully. I 
>> think we're OK here.
>
> Ok. I think as long as these fields are never dependent on previous 
> values if you call engineInit again, then it is ok. In other words, 
> they should be the same even if the previous call to engineInit throws 
> an Exception. It might be safer as the first thing you do to 
> re-initialize these each time engineInit is called.
>
JN: Yeah, earlier this morning I found a sequence that the half-baked 
state of the object was a problem.? So I'm shuffling around the order 
that these parameters get set in the ChaCha20 object so it happens later 
in the method as you suggested earlier. Basically if you init the object 
with an unsupported mode like Cipher.UNWRAP_MODE, that gets pinned to 
the object and subsequent inits where the mode is corrected fail.? The 
stack trace on the second init never makes it into ChaCha20's code, so 
I'm not sure if something is set in Cipher itself that persists from 
init to init. But setting these fields at the end of the init process is 
a better way to do it regardless.

--Jamil


From sean.mullan at oracle.com  Wed May  2 15:30:49 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 2 May 2018 11:30:49 -0400
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <187b598a-5f3b-7a5e-2709-25febec08348@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 <9a046c64-8bfc-0a16-2540-534ebef472e7@oracle.com>
 <9a56bc66-b93e-b244-9e47-1b795e8e2fb0@oracle.com>
 <11d35b9a-611a-1cbc-36e5-c15312ae2744@oracle.com>
 <172b4231-74e5-1994-0739-24aa74b0a7c6@oracle.com>
 <187b598a-5f3b-7a5e-2709-25febec08348@oracle.com>
Message-ID: <16f6bb29-beac-67b5-2aee-d9856e0fdfab@oracle.com>

On 5/2/18 11:23 AM, Jamil Nimeh wrote:
>> Ok. I think as long as these fields are never dependent on previous 
>> values if you call engineInit again, then it is ok. In other words, 
>> they should be the same even if the previous call to engineInit throws 
>> an Exception. It might be safer as the first thing you do to 
>> re-initialize these each time engineInit is called.
>>
> JN: Yeah, earlier this morning I found a sequence that the half-baked 
> state of the object was a problem.? So I'm shuffling around the order 
> that these parameters get set in the ChaCha20 object so it happens later 
> in the method as you suggested earlier. Basically if you init the object 
> with an unsupported mode like Cipher.UNWRAP_MODE, that gets pinned to 
> the object and subsequent inits where the mode is corrected fail.? The 
> stack trace on the second init never makes it into ChaCha20's code, so 
> I'm not sure if something is set in Cipher itself that persists from 
> init to init. But setting these fields at the end of the init process is 
> a better way to do it regardless.

Another (I think simpler) option is to have a private method like 
initState() or initFields() which initializes all these fields to their 
default values and always call it as the first thing engineInit does.

--Sean


From mbalao at redhat.com  Wed May  2 23:50:02 2018
From: mbalao at redhat.com (Martin Balao)
Date: Wed, 2 May 2018 20:50:02 -0300
Subject: RFR 6913047: SunPKCS11 memory leak
In-Reply-To: 
References: 
 
Message-ID: 

Minor update (webrev 06):

 * Rebased to cece972575ac [1] (latest JDK revision today)
 * Compiler warnings fixed

 * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.06/
 * http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.06.zip

Kind regards,
Martin.-

--
[1] - http://hg.openjdk.java.net/jdk/jdk/rev/cece972575ac

On Thu, Oct 12, 2017 at 10:00 AM, Martin Balao  wrote:

> Webrev 04 uploaded to cr.openjdk.java.net:
>
>  * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/
> JDK-6913047/webrev.04/ (browse online)
>  * http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/
> JDK-6913047/webrev.04/6913047.webrev.04.zip (download)
>
> On Wed, Oct 11, 2017 at 10:31 AM, Martin Balao  wrote:
>
>> Hi,
>>
>> I'd like to propose a fix for bug JDK-6913047: "Long term memory leak
>> when using PKCS11 and JCE exceeds 32 bit process address space" [1]. This
>> fix does not contain changes in the GC and is SunPKCS11 internal only.
>>
>> PROBLEM
>> ........................................................
>>
>> When using the SunPKCS11 crypto provider (for cipher, signature, mac, key
>> generation or any other operation), multiple key objects may be created.
>> I.e.: every time a TLS session is established, a unique master key (derived
>> from the pre-master-key) has to be created and then used for encryption and
>> decryption operations. This is a legitimate use case in which key caching
>> does not make sense as each key is unique per session. These keys are of
>> P11Key type and have a corresponding native key object created. In the case
>> of NSS SunPKCS11 backend (PKCS11 software token), this native key object is
>> temporarily stored in the process native heap. The interface is simple: a
>> JNI call is done to create a native key object (C_CreateObject,
>> C_CopyObject, C_DeriveKey, C_GenerateKeys, etc., according to the PKCS11
>> interface) and an integer handler is kept in the Java side (P11Key). When
>> the P11Key object is destroyed, a finalizer code is executed to free the
>> native key object (through C_DestroyObject JNI call). The problem is that
>> finalizer code execution happens only if the JVM garbage-collector cleans
>> up the P11Key object. That may be delayed or not done at all, depending on
>> different GC algorithms, parameters and environment conditions. As a
>> result, the native heap may be exhausted with not freed native key objects,
>> and the JVM will then crash -this is particularly true for 32 bits VMs
>> where the virtual address space can be exhausted-.
>>
>>
>> SCOPE
>> ........................................................
>>
>> The fix is proposed for SunPKCS11 with NSS backend only. Other PKCS11
>> backends are not currently under scope. It's likely that hardware PKCS11
>> backends store native key objects in their own memory, preventing a native
>> heap exhaustion and a JVM crash. However, it might be possible to cause an
>> exhaustion on their own memory blocking key objects creation at some point.
>> In any case, this is speculative as no tests were done on our side with
>> real hardware.
>>
>>
>> SOLUTION
>> ........................................................
>>
>> Assuming that native keys are extractable, the idea is to hold native key
>> data in the Java heap while keys are not in use. When a P11Key is created,
>> every CK_ATTRIBUTE (PKCS11) value for the native key is queried, data
>> stored in an opaque Java byte[] (inside the P11Key object) and native key
>> destroyed. Every time the P11Key is about to be used, the native key is
>> created with the stored data. After usage, the native key is again
>> destroyed. Thus, it's not necessary to wait for a finalizer execution to
>> cleanup native resources: cleanup is done at deterministic and
>> previously-known points. This comes with a resposibility for key users
>> -which are all SunPKCS11 internal services like P11Signature, P11Cipher,
>> P11KeyGenerator, etc.-: create and destroy native keys through a reference
>> counting scheme exposed by P11Key class. There are two kind of usages:
>>
>>  1) stateless: the native key is "atomically" created, used and
>> destroyed. I.e.: MAC calculation, getEncodedInternal operation (on P11Key
>> objects), signature operations, TLS key derivation, etc.
>>
>>  2) statefull: the native key is created, one or multiple intermediate
>> actions are performed by the key user, a final action is performed and
>> finally the native key is destroyed. I.e.: cipher operations.
>>
>> For keys that are extractable but sensitive (CKA_SENSITIVE attribute is
>> true), as the case when operating in FIPS mode, wrapping/unwrapping is used
>> as a workaround to extract session keys. Wrapper key is global and lives
>> forever.
>>
>> There are no interface changes for SunPKCS11 external users.
>>
>> If keys are not extractable or the feature cannot be enabled for any
>> other reason, the previous finalizer scheme is used as a fallback.
>>
>>
>> ADDITIONAL IMPLEMENTATION NOTES
>> ........................................................
>>
>> When a P11Key is created, a constructor parameter exists to indicate if
>> the feature is enabled for that specific key. For this feature to be
>> enabled, 2 additional conditions apply: 1) SunPKCS11 backend has to be NSS,
>> and 2) key has to be extractable. If the feature is not enabled for a key,
>> behavior is as previous to this patch (native key destruction relies on
>> finalizer execution).
>>
>> The only P11Key user that explicitly does not use this feature is
>> P11KeyStore. This is because these keys (token keys) are managed by alias
>> names and makes no sense to remove them from the key store (they need to be
>> accessible by an alias at any time).
>>
>> Because P11Key objects can be used by multiple threads at a time, there
>> is a thread-safe reference counting scheme in order to decide when a native
>> key object has to be created or destroyed. The SunPKCS11 internal API to
>> use a P11Key is as follows: 1) increment the reference counter (which will
>> eventually create the native key object if it doesn't exist), 2) use the
>> key and 3) decrement the reference counter (which will eventually destroy
>> the native key if there it's not being used by anyone else).
>>
>> The reason why an opaque byte[] is used in P11Key objects to store native
>> keys data (instead of a CK_ATTRIBUTE[] Java objects, queried by Java's
>> C_GetAttributeValue function) is performance. My prototypes show a
>> difference of 4x in speed. 2 functions were added to libj2pkcs11 library:
>> getNativeKeyInfo (to extract the opaque byte[] from a native key object)
>> and createNativeKey (to create a native key object from an opaque byte[]).
>>
>>
>> CHANGESET
>> ........................................................
>>
>> This changeset is JDK-10 (at jdk c8796a577885 rev) based:
>>
>>  * http://people.redhat.com/mbalaoal/webrevs/jdk_6913047_sunpkc
>> s11_nss_memory_leak/2017_10_06/6913047.webrev.04/ (browse online)
>>  * http://people.redhat.com/mbalaoal/webrevs/jdk_6913047_sunpkc
>> s11_nss_memory_leak/2017_10_06/6913047.webrev.04.zip (download)
>>
>>
>> TESTING
>> ........................................................
>>
>> Test suite for 32 bits JVMs only: http://people.redhat.com/mbala
>> oal/webrevs/jdk_6913047_sunpkcs11_nss_memory_leak/2017_10_
>> 06/Bug6913047.java
>>
>>  * Suite (Bug6913047.java)
>>   * Tests JVM memory exhaustion while using keys for different services:
>> P11Cipher, P11Signature, P11KeyAgreement, P11Mac, P11Digest,
>> P11KeyGenerator, P11KeyFactory, etc.
>>   * Tests functional regression.
>>    * Including Key Stores (P11KeyStore)
>>
>> Parameters to run the reproducer (on JDK-10):
>>  * javac: --add-modules jdk.crypto.cryptoki --add-exports
>> java.base/sun.security.internal.spec=ALL-UNNAMED
>>  * java: -XX:+UseParallelGC -Xmx3500m --add-modules jdk.crypto.cryptoki
>> --add-opens java.base/javax.crypto=ALL-UNNAMED --add-opens
>> jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED
>>
>> You can also use jtreg.
>>
>>
>> PERFORMANCE
>> ........................................................
>>
>> For a quick reproducer previously developed (which looped 100000 times
>> creating P11Cipher and P11Key objects to encrypt a plaintext), these are
>> the figures I got:
>>
>>  * real 1m11.328s (without fix)
>>  * real 1m12.795s (with fix)
>>
>> Performance penalty seems to be low in current state.
>>
>> OTHER
>> .......................................................
>>
>> My employer has an OCA agreement with Oracle and this work has been done
>> in that context.
>>
>> Look forward to your comments.
>>
>> Kind regards,
>> Martin.-
>>
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-6913047
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From philipp.kunz at paratix.ch  Thu May  3 01:12:22 2018
From: philipp.kunz at paratix.ch (Philipp Kunz)
Date: Thu, 3 May 2018 03:12:22 +0200
Subject: RFR for 6443578 and 6202130: UTF-8 in Manifests
In-Reply-To: 
References: 
 
Message-ID: <56d63055-6c28-9029-354b-93be4cdca5e4@paratix.ch>

Hi,

Here is patch for 6443578 and 6202130 also in webrev form.

http://files.paratix.ch/jdk/6372077and6443578/webrev.01/
http://files.paratix.ch/jdk/6372077and6443578/webrev.01.zip

Hope it helps. With all the patience, can I do anything to make it 
easier to get feedback or find a sponsor?

Regards,
Philipp


On 02.05.2018 07:21, Philipp Kunz wrote:
> Hi,
>
> Recently, I tried to fix only bug 6202130 with the intention to fix 
> bug 6443578 later with the intention to get some opportunity for 
> feedback, but haven't got any, and propose now a fix for both together 
> which in my opinion makes more sense.
>
> See attached patch.
>
> Some considerations, assumptions, and explanations
>
>   * In my opinion, the code for writing manifests was distributed in
>     the two classes Attributes and Manifest in an elegant way but
>     somewhat difficult to explain the coherence. I chose to group the
>     code that writes manifests into a new class ManifestWriter. The
>     main incentive for that was to prevent or reduce duplicated code I
>     would have had to change twice otherwise. This also results in a
>     source file of a suitable size.
>   * I could not support the assumption that the write and writeMain
>     methods in Attributes couldn't be referenced anywhere so I
>     deprecated them rather than having them removed.
>   * I assumed the patch will not make it into JDK 10 and, hence, the
>     deprecated annotations are attributed with since = 11.
>   * I could not figure out any reason for the use of DataOutputStream
>     and did not use it.
>   * Performance-wise I assume that the code is approximately
>     comparable to the previous version. The biggest improvement in
>     this respect I hope comes from removing the String that contains
>     the byte array constructed with deprecated String(byte[], int,
>     int, int) and then copying it over again to a StringBuffer and
>     from there to a String again and then Characters. On the other
>     hand, keeping whole characters together when breaking lines might
>     make it slightly slower. I hope my changes are an overall
>     improvement, but I haven't measured it.
>   * For telling first from continuation bytes of utf-8 characters
>     apart I re-used a method isNotUtfContinuationByte from either
>     StringCoding or UTF_8.Decoder. Unfortunately I found no way not to
>     duplicate it.
>   * Where it said before "XXX Need to handle UTF8 values and break up
>     lines longer than 72 bytes" in Attributes#writeMain I did not dare
>     to remove the comment completely because it still does not deal
>     correctly with version headers longer than 72 bytes and the set of
>     allowed values. I changed it accordingly. Two similar comments are
>     removed in the patch.
>   * I added two tests, WriteDeprecated and NullKeysAndValues, to
>     demonstrate compatibility as good as I could. Might however not be
>     desired to keep and having to maintain.
>   * LineBrokenMultiByteCharacter for jarsigner should not be removed
>     or not so immediately because someone might attempt to sign an
>     older jarfile created without that patch with a newer jarsigner
>     that already contains it.
>
>
>
> suggested changes or additions to the bug database: (i have no 
> permissions to edit it myself)
>
>   * Re-combine copies of isNotUtfContinuationByte (three by now).
>     Relates to 6184334. Worth to file another issue?
>   * Manifest versions have specific specifications, cannot break
>     across lines and can contain a subset of characters only. Bug
>     6910466 relates but is not exactly the same. If someone else is
>     convinced that writing a manifest should issue a warning or any
>     other way to deal with a version that does not conform to the
>     specification, I'd suggest to create a separate bug for that.
>
>
> Now, I would be glad if someone sponsored a review. This is only my 
> third attempt to submit a patch which is why I chose a lesser 
> important subject to fix in order to get familiar and now I understand 
> it's not the most attractive patch to review. Please don't hesitate to 
> suggest what I could do better or differently.
>
> As a bonus, with these changes, manifest files will always be 
> displayed correctly with just any utf capable viewer even if they 
> contain multi-byte utf characters that would have been broken across a 
> line break with the current/previous implementation and all manifests 
> will become also valid strings in Java.
>
> Regards,
> Philipp
>
>
>
> On 20.04.2018 00:58, Philipp Kunz wrote:
>> Hi,
>>
>> I tried to fix bug 6202130 about manifest utf support and come up now 
>> with a test as suggested in the bug's comments that shows that utf 
>> charset actually works before removing the comments from the code.
>>
>> When I wanted to remove the XXX comments about utf it occurred to me 
>> that version attributes ("Signature-Version" and "Manifest-Version") 
>> would never be broken across lines and should anyway not support the 
>> whole utf character set which sounds more like related to bugs 
>> 6910466 or 4935610 but it's not a real fit. Therefore, I could not 
>> remove one such comment of Attributes#writeMain but I changed it. The 
>> first comment in bug 6202130 mentions only two comments but there are 
>> three in Attributes. In the attached patch I removed only two of 
>> three and changed the remaining third to not mention utf anymore.
>>
>> At the moment, at least until 6443578 is fixed, multi-byte utf 
>> characters can be broken across lines. It might be worth a 
>> consideration to test that explicitly as well but then I guess there 
>> is not much of a point in testing the current behavior that will 
>> change with 6443578, hopefully soon. There are in my opinion enough 
>> characters broken across lines in the attached test that demonstrate 
>> that this still works like it did before.
>>
>> I would have preferred also to remove the calls to deprecated 
>> String(byte[], int, int, int) but then figured it relates more to bug 
>> 6443578 than 6202130 and now prefer to do that in another separate 
>> patch.
>>
>> Bug 6202130 also states that lines are broken by String.length not by 
>> byte length. While it looks so at first glance, I could not confirm. 
>> The combination of getBytes("UTF8"), String(byte[], int, int, int), 
>> and then DataOutputStream.writeBytes(String) in that combination does 
>> not drop high-bytes because every byte (whether a whole character or 
>> only a part of a multi-byte character) becomes a character in 
>> String(...) containing that byte in its low-byte which will be read 
>> again from writeBytes(...). Or put in a different way, every utf 
>> encoded byte becomes a character and multi-byte utf characters are 
>> converted into multiple string characters containing one byte each in 
>> their lower bytes. The current solution is not nice, but at least 
>> works. With that respect I'd like to suggest to deprecate 
>> DataOutputStream.writeBytes(String) because it does something not 
>> exactly expected when guessing from its name and that would suit a 
>> byte[] parameter better very much like it has been done with 
>> String(byte[], int, int, int). Any advice about the procedure to 
>> deprecate something?
>>
>> I was surprised that it was not trivial to list all valid utf 
>> characters. If someone has a better idea than isValidUtfCharacter in 
>> the attached test, let me know.
>>
>> Altogether, I would not consider 6202130 resolved completely, unless 
>> maybe all remaining points are copied to 6443578 and maybe another 
>> bug about valid values for "Signature-Version" and "Manifest-Version" 
>> if at all desired. But still I consider the attached patch an 
>> improvement and most of the remainder can then be solved in 6443578 
>> and so far I am looking forward to any kind of feedback.
>>
>> Regards,
>> Philipp
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun.wang at oracle.com  Thu May  3 02:19:53 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 3 May 2018 10:19:53 +0800
Subject: RFR 8202299: Java Keystore fails to load PKCS12/PFX certificates
 created in WindowsServer2016
In-Reply-To: 
References: <0A68EB2D-D19D-4D7D-ADF8-971758D15303@oracle.com>
 
Message-ID: 

Yes, I meant \0.

Will fix it.

Thanks
Max

> On Apr 28, 2018, at 1:10 AM, Bernd Eckenfels  wrote:
> 
> Hello,
> 
> Is the following comment correct, it looks like it should read ?with NUL terminator? instead?
> 
> // without a NULL terminator
> 
> Greetings
> Bernd
> 
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> From: security-dev  on behalf of Weijun Wang 
> Sent: Friday, April 27, 2018 6:56:03 PM
> To: security-dev at openjdk.java.net
> Subject: RFR 8202299: Java Keystore fails to load PKCS12/PFX certificates created in WindowsServer2016
>  
> Please take a look at
> 
>    http://cr.openjdk.java.net/~weijun/8202299/webrev.00/
> 
> Turns out we have to retry [0] other than [] in all 3 locations: decrypting keys, decrypting certs, and verifying the mac.
> 
> Thanks
> Max
> 
> p.s. You might wonder why suddenly in Windows Server 2016, Microsoft starts using [0] to generate the Mac. In fact, they have been doing this all the time. However, before 2016, they also encrypted the certificates, and to decrypt them, Java has already changed password from [] to [0].
> 
> p.p.s. But is this correct? Should the certificate decryption code only temporarily retries [0] but not changing password itself? Well, maybe. But unless a weird software sometimes uses [] and sometimes [0], this will not be a problem, and changing password itself saves us some cycles from always trying twice.



From jai.forums2013 at gmail.com  Thu May  3 06:13:41 2018
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 3 May 2018 11:43:41 +0530
Subject: [PATCH] JDK-8190917 : SSL session resumption, through handshake, 
 in SSLEngine is broken for any protocols lesser than TLSv1.2
In-Reply-To: <1b7e0677-d92e-8f20-1abf-05134558fd3e@oracle.com>
References: <427ca55d-e619-21e5-d803-4e829007da43@gmail.com>
 <9f283fd1-f014-b1f6-5b03-d73f18048415@oracle.com>
 
 <11662f00-0c06-27fa-f4a0-350c846c9da6@gmail.com>
 
 <967d659e-1130-24f6-382c-cfdbf3dd63e1@gmail.com>
 <1b7e0677-d92e-8f20-1abf-05134558fd3e@oracle.com>
Message-ID: <8ecdcb3d-8ca0-58e8-b1c7-737db3fd01d1@gmail.com>

Hi Xuelei,

I just noticed the comment on JDK-8190917[1], stating that the issue has 
been fixed. So I just built the latest JDK upstream and ran my test and 
it went fine :) Glad that this now works. Would you be willing to 
include (just) the testcase to verify that this behaviour works and 
doesn't regress in future? If so, I've attached an updated patch to this 
mail which only contains the jtreg test case.

[1] https://bugs.openjdk.java.net/browse/JDK-8190917

-Jaikiran
On 28/02/18 10:09 PM, Xuelei Fan wrote:
> Hi Jaikiran,
>
> As you noticed, we updated to use the ClientHello.client_version and 
> session version for version negotiation during resumption.? It's not 
> the best option for performance, but it is a safer option for 
> compatibility before I'm able to make further evaluation.?? I need 
> more time to think about the impact if backporting t0 JDK 9.
>
> Thanks,
> Xuelei
>
> On 2/23/2018 9:17 PM, Jaikiran Pai wrote:
>> Sounds fine, thank you Xuelei. Would this later be backported to Java 
>> 9 too?
>>
>> -Jaikiran
>>
>>
>> On 24/02/18 12:21 AM, Xuelei Fan wrote:
>>> Hi Jaikiran,
>>>
>>> Thanks a lot for the update.? Your code looks fine to me.
>>>
>>> As we are working on the re-org of the implementation[1] now, I may 
>>> integrate your contribution shortly after the re-org changes.
>>>
>>> Thanks,
>>> Xuelei
>>>
>>> [1]: 
>>> http://mail.openjdk.java.net/pipermail/security-dev/2018-February/016815.html 
>>>
>>>
>>> On 2/22/2018 9:58 PM, Jaikiran Pai wrote:
>>>> Given some recent changes to the class involved in this patch, in 
>>>> the jdk repo (http://hg.openjdk.java.net/jdk/jdk), I noticed some 
>>>> merge conflicts to this patch today. So I've now attached an 
>>>> updated patch which resolves those merge issues. This has been 
>>>> tested with latest jtreg (tip).
>>>>
>>>> -Jaikiran
>>>>
>>>>
>>>> On 06/12/17 9:35 PM, Jaikiran Pai wrote:
>>>>> Thank you Xuelei. Please take your time.
>>>>>
>>>>> -Jaikiran
>>>>>
>>>>>
>>>>>
>>>>> On Wednesday, December 6, 2017, Xuelei Fan >>>> > wrote:
>>>>>
>>>>> ??? Hi Jaikiran,
>>>>>
>>>>> ??? I will sponsor this contribution.? I need more time for the 
>>>>> review
>>>>> ??? and testing.
>>>>>
>>>>> ??? Thanks,
>>>>> ??? Xuelei
>>>>>
>>>>> ??? On 11/23/2017 9:22 PM, Jaikiran Pai wrote:
>>>>>
>>>>> ??????? As noted in [1], there's a regression in Java 9, where SSL
>>>>> ??????? session resumption no longer works for SSL protocols other
>>>>> ??????? than TLSv1.2. The code which is responsible for session
>>>>> ??????? resumption resides in the ServerHandshaker[2], in the
>>>>> ??????? clientHello method. This method, in its logic to decide
>>>>> ??????? whether or not to resume a (previously) cached session, 
>>>>> checks
>>>>> ??????? if the client hello message has a session id associated. 
>>>>> If it
>>>>> ??????? does, it then fetches a session from the cache. If it does
>>>>> ??????? find a previously cached session for that id, it then goes
>>>>> ??????? ahead to check if the SSL protocol associated with the cached
>>>>> ??????? session matches with the protocol version that's
>>>>> ??????? "applicable/selected" of the incoming client hello message.
>>>>> ??????? However, a relatively recent change[3] has, IMO,
>>>>> ??????? unintentionally caused the protocol version check logic to
>>>>> ??????? fail for protocols other than TLSv1.2. The protocol version
>>>>> ??????? check looks like:
>>>>>
>>>>>
>>>>> ??????? // cannot resume session with different
>>>>>
>>>>> ??????? if (oldVersion != protocolVersion) {
>>>>> ??????? resumingSession = false;
>>>>> ??????? }
>>>>>
>>>>> ??????? The `protocolVersion` variable in this case happens to be a
>>>>> ??????? _default initialized value_ (TLSv1.2) instead of the one
>>>>> ??????? that's "selected" based on the incoming client hello message.
>>>>> ??????? As a result the `protocolVersion` value is always TLSv1.2 and
>>>>> ??????? thus for any other protocols, this comparison fails, even 
>>>>> when
>>>>> ??????? the client hello message uses the right session id and the
>>>>> ??????? right protocol that matches the previous session.
>>>>>
>>>>> ??????? The attached patch, includes a potential fix to this issue.
>>>>> ??????? The change makes sure that the protocol selection, based on
>>>>> ??????? the client hello message, is done before this session
>>>>> ??????? resumption check and also makes sure it uses that "selected"
>>>>> ??????? protocol in the version comparison check instead of the class
>>>>> ??????? member `protocolVersion` (which gets set when the server 
>>>>> hello
>>>>> ??????? message is finally being sent).
>>>>>
>>>>> ??????? The attached patch also contains a (jtreg) test case which
>>>>> ??????? reproduces this bug and verifies this fix. The test case 
>>>>> tests
>>>>> ??????? the session resumption against TLSv1, TLSv1.1 and TLSv1.2. 
>>>>> The
>>>>> ??????? test code itself is a minor modification of the SSL demo
>>>>> ??????? that's available here [4].
>>>>>
>>>>> ??????? This is my first OpenJDK patch and my OCA got approved a few
>>>>> ??????? days back. Could someone please help with the review of this
>>>>> ??????? patch?
>>>>>
>>>>> ??????? P.S: I noticed that the JIRA got assigned a few days back. I
>>>>> ??????? am not sure if that means the fix is already being worked 
>>>>> upon
>>>>> ??????? by someone else from the team. If that's the case, then 
>>>>> let me
>>>>> ??????? know and I'll let it be handled by them.
>>>>>
>>>>> ??????? [1] https://bugs.openjdk.java.net/browse/JDK-8190917
>>>>> 
>>>>>
>>>>> ??????? [2]
>>>>> http://hg.openjdk.java.net/jdk/jdk/file/b7ae1437111b/src/java.base/share/classes/sun/security/ssl/ServerHandshaker.java 
>>>>>
>>>>>  
>>>>>
>>>>>
>>>>>
>>>>> ??????? [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/42268eb6e04e
>>>>> 
>>>>>
>>>>> ??????? [4]
>>>>> https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sslengine/SSLEngineSimpleDemo.java 
>>>>>
>>>>>  
>>>>>
>>>>>
>>>>>
>>>>> ??????? -Jaikiran
>>>>>
>>>>>
>>>>>
>>>>
>>

-------------- next part --------------
# HG changeset patch
# User Jaikiran Pai 
# Date 1525327384 -19800
#      Thu May 03 11:33:04 2018 +0530
# Node ID 0fe788ad1edb045d9434920e55e66784350dc81a
# Parent  7379e6f906aeb6e69ed8eccda9de285e606ab1ff
JDK-8190917 Add a test case to verify SSL session resumption works as expected for various protocol versions

diff --git a/test/jdk/sun/security/ssl/SessionResumption/SSLSessionResumption.java b/test/jdk/sun/security/ssl/SessionResumption/SSLSessionResumption.java
new file mode 100644
--- /dev/null
+++ b/test/jdk/sun/security/ssl/SessionResumption/SSLSessionResumption.java
@@ -0,0 +1,374 @@
+/*
+ * Copyright (c) 2015, 2017, 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
+ * under the terms of the GNU General Public License version 2 only, as
+ * published by the Free Software Foundation.
+ *
+ * This code 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 General Public License
+ * version 2 for more details (a copy is included in the LICENSE file that
+ * accompanied this code).
+ *
+ * You should have received a copy of the GNU General Public License version
+ * 2 along with this work; if not, write to the Free Software Foundation,
+ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
+ *
+ * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
+ * or visit www.oracle.com if you need additional information or have any
+ * questions.
+ */
+
+import javax.net.ssl.KeyManagerFactory;
+import javax.net.ssl.SSLContext;
+import javax.net.ssl.SSLEngine;
+import javax.net.ssl.SSLEngineResult;
+import javax.net.ssl.SSLEngineResult.HandshakeStatus;
+import javax.net.ssl.SSLSession;
+import javax.net.ssl.TrustManagerFactory;
+import java.io.FileInputStream;
+import java.nio.ByteBuffer;
+import java.security.KeyStore;
+import java.util.Arrays;
+import java.util.HashSet;
+import java.util.Set;
+
+/*
+ * @test
+ * @bug 8190917
+ * @summary Verify that SSL session resumption works for all SSL protocols
+ * @run main SSLSessionResumption
+ */
+public class SSLSessionResumption {
+
+    private static final boolean debug = false;
+    private static String pathToStores = "../../../../javax/net/ssl/etc";
+    private static String keyStoreFile = "keystore";
+    private static String trustStoreFile = "truststore";
+    private static String passwd = "passphrase";
+
+    private static String keyFilename =
+            System.getProperty("test.src", "./") + "/" + pathToStores +
+                    "/" + keyStoreFile;
+    private static String trustFilename =
+            System.getProperty("test.src", "./") + "/" + pathToStores +
+                    "/" + trustStoreFile;
+
+
+    private final String sslProtocol;
+    private final SSLContext sslc;
+
+    private SSLEngine clientEngine;     // client Engine
+    private ByteBuffer clientOut;       // write side of clientEngine
+    private ByteBuffer clientIn;        // read side of clientEngine
+
+    private SSLEngine serverEngine;     // server Engine
+    private ByteBuffer serverOut;       // write side of serverEngine
+    private ByteBuffer serverIn;        // read side of serverEngine
+
+    private ByteBuffer cTOs;            // client->server
+    private ByteBuffer sTOc;            // server->client
+
+
+    private byte[] previousSessionId;    // session id of a previous established SSL session
+
+
+    private SSLSessionResumption(final String sslProtocol) throws Exception {
+        this.sslProtocol = sslProtocol;
+
+        final KeyStore ks = KeyStore.getInstance("JKS");
+        final KeyStore ts = KeyStore.getInstance("JKS");
+        final char[] passphrase = passwd.toCharArray();
+
+        ks.load(new FileInputStream(keyFilename), passphrase);
+        ts.load(new FileInputStream(trustFilename), passphrase);
+
+        final KeyManagerFactory kmf = KeyManagerFactory.getInstance("SunX509");
+        kmf.init(ks, passphrase);
+
+        final TrustManagerFactory tmf = TrustManagerFactory.getInstance("SunX509");
+        tmf.init(ts);
+
+        final SSLContext sslCtx = SSLContext.getInstance(this.sslProtocol);
+        sslCtx.init(kmf.getKeyManagers(), tmf.getTrustManagers(), null);
+
+        this.sslc = sslCtx;
+    }
+
+    // Note: the core of the SSL communication code has been borrowed from
+    // https://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sslengine/SSLEngineSimpleDemo.java
+    // and has been massaged into a test case
+    public static void main(final String[] args) throws Exception {
+        // for each of these protocols we run the session resumption test
+        // individually
+        final String[] protocols = new String[]{"TLSv1", "TLSv1.1", "TLSv1.2"};
+        final Set failedProtocols = new HashSet();
+        for (final String protocol : protocols) {
+            final SSLSessionResumption test = new SSLSessionResumption(protocol);
+            // verify that the session resumption works
+            if (!test.verifySessionResumption()) {
+                failedProtocols.add(protocol);
+            }
+        }
+        if (!failedProtocols.isEmpty()) {
+            throw new Exception("SSL session resumption failed for protocols " + failedProtocols);
+        }
+    }
+
+    /**
+     * Uses {@link SSLEngine} in the context of a {@link SSLContext} to do some SSL backed
+     * communication and verifies that the communication reuses a session
+     *
+     * @return Returns true if the SSL session was reused. False otherwise
+     * @throws Exception
+     */
+    private boolean verifySessionResumption() throws Exception {
+        try {
+            for (int i = 0; i < 2; i++) {
+                log("Starting SSL communication " + (i + 1) + " using protocol " + this.sslProtocol);
+                this.doSSLCommunication();
+            }
+        } catch (SessionIdMisMatchException e) {
+            return false;
+        }
+        return true;
+    }
+
+
+    private void doSSLCommunication() throws Exception {
+        boolean dataDone = false;
+
+        createSSLEngines();
+        createBuffers();
+
+        SSLEngineResult clientResult;   // results from client's last operation
+        SSLEngineResult serverResult;   // results from server's last operation
+
+        /*
+         * Examining the SSLEngineResults could be much more involved,
+         * and may alter the overall flow of the application.
+         *
+         * For example, if we received a BUFFER_OVERFLOW when trying
+         * to write to the output pipe, we could reallocate a larger
+         * pipe, but instead we wait for the peer to drain it.
+         */
+        while (!isEngineClosed(clientEngine) ||
+                !isEngineClosed(serverEngine)) {
+
+            log("================");
+
+            clientResult = clientEngine.wrap(clientOut, cTOs);
+            if (clientResult.getHandshakeStatus() == HandshakeStatus.FINISHED) {
+                assertSessionId(this.previousSessionId, clientEngine);
+                this.previousSessionId = clientEngine.getSession().getId();
+            }
+            log("client wrap: ", clientResult);
+            runDelegatedTasks(clientResult, clientEngine);
+
+            serverResult = serverEngine.wrap(serverOut, sTOc);
+            log("server wrap: ", serverResult);
+            runDelegatedTasks(serverResult, serverEngine);
+
+            cTOs.flip();
+            sTOc.flip();
+
+            log("----");
+
+            clientResult = clientEngine.unwrap(sTOc, clientIn);
+            if (clientResult.getHandshakeStatus() == HandshakeStatus.FINISHED) {
+                assertSessionId(this.previousSessionId, clientEngine);
+                this.previousSessionId = clientEngine.getSession().getId();
+            }
+            log("client unwrap: ", clientResult);
+            runDelegatedTasks(clientResult, clientEngine);
+
+            serverResult = serverEngine.unwrap(cTOs, serverIn);
+            log("server unwrap: ", serverResult);
+            runDelegatedTasks(serverResult, serverEngine);
+
+            cTOs.compact();
+            sTOc.compact();
+
+            /*
+             * After we've transfered all application data between the client
+             * and server, we close the clientEngine's outbound stream.
+             * This generates a close_notify handshake message, which the
+             * server engine receives and responds by closing itself.
+             *
+             * In normal operation, each SSLEngine should call
+             * closeOutbound().  To protect against truncation attacks,
+             * SSLEngine.closeInbound() should be called whenever it has
+             * determined that no more input data will ever be
+             * available (say a closed input stream).
+             */
+            if (!dataDone && (clientOut.limit() == serverIn.position()) &&
+                    (serverOut.limit() == clientIn.position())) {
+
+                /*
+                 * A sanity check to ensure we got what was sent.
+                 */
+                checkTransfer(serverOut, clientIn);
+                checkTransfer(clientOut, serverIn);
+
+                log("\tClosing clientEngine's *OUTBOUND*...");
+                clientEngine.closeOutbound();
+                // serverEngine.closeOutbound();
+                dataDone = true;
+            }
+        }
+    }
+
+    /*
+     * Using the SSLContext created during object creation,
+     * create/configure the SSLEngines we'll use for this demo.
+     */
+    private void createSSLEngines() throws Exception {
+        /*
+         * Configure the serverEngine to act as a server in the SSL/TLS
+         * handshake.
+         */
+        serverEngine = sslc.createSSLEngine();
+        serverEngine.setUseClientMode(false);
+        serverEngine.setNeedClientAuth(false);
+
+        /*
+         * Similar to above, but using client mode instead.
+         */
+        clientEngine = sslc.createSSLEngine("client", 80);
+        clientEngine.setUseClientMode(true);
+    }
+
+    /*
+     * Create and size the buffers appropriately.
+     */
+    private void createBuffers() {
+
+        /*
+         * We'll assume the buffer sizes are the same
+         * between client and server.
+         */
+        SSLSession session = clientEngine.getSession();
+        int appBufferMax = session.getApplicationBufferSize();
+        int netBufferMax = session.getPacketBufferSize();
+
+        /*
+         * We'll make the input buffers a bit bigger than the max needed
+         * size, so that unwrap()s following a successful data transfer
+         * won't generate BUFFER_OVERFLOWS.
+         *
+         * We'll use a mix of direct and indirect ByteBuffers for
+         * tutorial purposes only.  In reality, only use direct
+         * ByteBuffers when they give a clear performance enhancement.
+         */
+        clientIn = ByteBuffer.allocate(appBufferMax + 50);
+        serverIn = ByteBuffer.allocate(appBufferMax + 50);
+
+        cTOs = ByteBuffer.allocateDirect(netBufferMax);
+        sTOc = ByteBuffer.allocateDirect(netBufferMax);
+
+        clientOut = ByteBuffer.wrap("JDK-8190917 : Hi Server, I'm Client".getBytes());
+        serverOut = ByteBuffer.wrap("JDK-8190917 : Hello Client, I'm Server".getBytes());
+    }
+
+    /*
+     * If the result indicates that we have outstanding tasks to do,
+     * go ahead and run them in this thread.
+     */
+    private static void runDelegatedTasks(final SSLEngineResult result,
+                                          final SSLEngine engine) throws Exception {
+
+        if (result.getHandshakeStatus() == HandshakeStatus.NEED_TASK) {
+            Runnable runnable;
+            while ((runnable = engine.getDelegatedTask()) != null) {
+                log("\trunning delegated task...");
+                runnable.run();
+            }
+            final HandshakeStatus hsStatus = engine.getHandshakeStatus();
+            if (hsStatus == HandshakeStatus.NEED_TASK) {
+                throw new Exception(
+                        "handshake shouldn't need additional tasks");
+            }
+            log("\tnew HandshakeStatus: " + hsStatus);
+        }
+    }
+
+    private static boolean isEngineClosed(SSLEngine engine) {
+        return (engine.isOutboundDone() && engine.isInboundDone());
+    }
+
+    /*
+     * Simple check to make sure everything came across as expected.
+     */
+    private static void checkTransfer(ByteBuffer a, ByteBuffer b)
+            throws Exception {
+        a.flip();
+        b.flip();
+
+        if (!a.equals(b)) {
+            throw new Exception("Data didn't transfer cleanly");
+        } else {
+            log("\tData transferred cleanly");
+        }
+
+        a.position(a.limit());
+        b.position(b.limit());
+        a.limit(a.capacity());
+        b.limit(b.capacity());
+    }
+
+    private static void assertSessionId(final byte[] expected, final SSLEngine engine) throws SessionIdMisMatchException {
+        if (expected == null) {
+            // we haven't yet created a session previously, so there isn't any
+            // session to be expected to resume
+            return;
+        }
+        final byte[] sessionId = engine.getSession().getId();
+        // compare and verify if they are same
+        if (!java.util.Arrays.equals(expected, sessionId)) {
+            throw new SessionIdMisMatchException(expected, sessionId);
+        }
+    }
+
+    private static boolean resultOnce = true;
+
+    private static void log(final String str, final SSLEngineResult result) {
+        if (!debug) {
+            return;
+        }
+        if (resultOnce) {
+            resultOnce = false;
+            log("The format of the SSLEngineResult is: \n" +
+                    "\t\"getStatus() / getHandshakeStatus()\" +\n" +
+                    "\t\"bytesConsumed() / bytesProduced()\"\n");
+        }
+        final HandshakeStatus hsStatus = result.getHandshakeStatus();
+        log(str +
+                result.getStatus() + "/" + hsStatus + ", " +
+                result.bytesConsumed() + "/" + result.bytesProduced() +
+                " bytes");
+        if (hsStatus == HandshakeStatus.FINISHED) {
+            log("\t...ready for application data");
+        }
+    }
+
+    private static void log(final String message) {
+        if (debug) {
+            System.out.println(message);
+        }
+    }
+
+    private static final class SessionIdMisMatchException extends Exception {
+
+        private final byte[] expected;
+        private final byte[] actual;
+
+        private SessionIdMisMatchException(final byte[] expected, final byte[] actual) {
+            super("SSL session id mismatch - expected " + Arrays.toString(expected) + " actual " + Arrays.toString(actual));
+            this.expected = expected;
+            this.actual = actual;
+        }
+    }
+
+}
\ No newline at end of file

From bradford.wetmore at oracle.com  Thu May  3 22:55:21 2018
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Thu, 3 May 2018 15:55:21 -0700
Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm
 as in PKCS#1 v2.2"
In-Reply-To: <0260adcb-b2b0-61e0-d689-31e0db28a161@oracle.com>
References: 
 <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com>
 <77185686-9640-ed7d-a30d-d8651fd6c280@oracle.com>
 
 <0260adcb-b2b0-61e0-d689-31e0db28a161@oracle.com>
Message-ID: <135a4983-bc68-d30a-1f11-0faf13360ec6@oracle.com>


> I have incorporated your comments into the webrev but I am still not 
> done with it yet due to name switch from RSA-PSS to RSASSA-PSS.
> Will send out another email once webrev is updated.

Thanks, looking forward to it.

> On 4/30/2018 6:07 PM, Bradford Wetmore wrote:
>>>> PSSParameterSpec.java
>>>> ---------------------
>>>> Maybe add trailerFieldBC(1)?
>>> Not sure what do u want me to add. A constants for TrailerFieldBC, or 
>>> else?
>>
>> Yes that was my thought.? A constant field for TrailerFieldBC. When I 
>> was trying to construct a PSSParameterSpec, the integer value to use 
>> is "1", but if you don't read ASN.1 well enough, one might be tempted 
>> to pass "0xbc" instead.? If you weren't using DEFAULT, the call would 
>> be like this:
>>
>> ??????? PSSParameterSpec pssSpec = new PSSParameterSpec(
>> ??????????????? "SHA-256", "MGF1", MGF1ParameterSpec.SHA256, 20, 1);
>> ->
>> ??????? PSSParameterSpec pssSpec = new PSSParameterSpec(
>> ??????????????? "SHA-256", "MGF1", MGF1ParameterSpec.SHA256, 20,
>> ??????????????? PSSParameterSpec.trailerBC);
>>
> I added TRAILER_FIELD_BC constant for this as constant names are 
> generally all upper case. Not too pretty and would welcome suggestions.

Egads, that was a DWIMNWIS[1] move.  Yes, needs to be cap'd of course. 
:)

[1] https://www.urbandictionary.com/define.php?term=dwimnwis

Thanks for considering.

>> java.base/.../java/security/SignedObject.java
>> ---------------------------------------------
>> 59:? In the javadoc, it looks like there is a missing opening brace 
>> that isn't closed with the one at line 64.? However, the one at line 
>> 64 is not showing up in the generated output either. Weird.
> I think the {@ on line 59 pairs up with the } on line 64. Everything in 
> between is shown as code.

Oops, that is the closing brace for the @code on line 57.

One more minor nit?  Can you add braces around the so.verify "if" arm:

  if (so.verify(verificationKey, verificationParams, verificationEngine))
...deleted...
->
  if (so.verify(verificationKey, verificationParams, verificationEngine)) {
      try {
          Object myobj = so.getObject();
      } catch (java.lang.ClassNotFoundException e) {};
      try {
          Object myobj = so.getObject();
      } catch (java.lang.ClassNotFoundException e) {};
}

>> 173: Exactly the same wording here as the previous constructor. Should 
>> we endeavor to make them different?
> The wordings look different to me. The former one explicitly states that 
> no signature parameters is used.

In your other new constructors (e.g. 
RSAPrivateKeySpec.java/RSAPublicKeySpec.java), your new opening sentence 
called out the difference, but this one didn't.  Just wondering if you 
wanted to make it consistent.  I'm ok either way.

>> java.base/.../java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java
>> --------------------------------------------------------------------
>> A general nit throughout your APIs, when you're doing multi-line 
>> things for your @params/@return/@exception, usually should be indented 
>> to help readability of the source.
> Alright, I will try to add indentation to improve readability to the 
> part that I touched.

Thanks.  It bothers me just enough to notice it, but understand why we 
don't want to go through our javadocs just for this kind of change. 
Kinda wish it was on the technical debt list, but plenty of other things 
to do!  :)

>> java.base/.../javax/crypto/Cipher.java
>> --------------------------------------
>> If we go with RSA-PSS or RSASSA-PSS, do you still need this change?
> Yes, this change is for supporting OAEPwithandMGF1Paddong now 
> that we added support for SHA512/224 and SHA512/256.

Oh, of course.  Thanks.

>> 448-: I appreciated the comments.? When people come up with their own 
>> optimizations of a relatively straightforward algorithm, it can be 
>> confusing to follow.? I'm guessing you're not going to be checking for 
>> input limitations?? (i.e. step 1)? A few more comments to help map the 
>> RFC to your code would be good, especially in the verify/decode. e.g. 
>> 536-558.
> I will add some more comments on this.

Thanks.

Brad



From jamil.j.nimeh at oracle.com  Fri May  4 14:06:56 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Fri, 4 May 2018 07:06:56 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
Message-ID: 

Round 5.

This adds Sean's comments.? Sean, I was never able to execute a case on 
init where a half-baked object would fail.? In most cases it would fail 
in checks in javax.crypto.Cipher before it ever made it down to my 
code.? I'm pretty confident the init sequence is OK.? I did move the 
setting of a few data members toward the end of the init sequence but 
setting the key and nonce is necessary before creating the initial 
state, which is then used for generating an authentication key for AEAD 
mode and generating keystream.

http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05

Also the CSR has been finalized and can be found here:
https://bugs.openjdk.java.net/browse/JDK-8198925

--Jamil

On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>
> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff mostly:
>
>   * Added words in the description of javax.crypto.Cipher recommending
>     callers reinitialize the Cipher to use different nonces after each
>     complete encryption or decryption (similar language to what exists
>     already for AES-GCM encryption).
>   * Added an additional test case for ChaCha20NoReuse
>   * Made accessor methods for ChaCha20ParameterSpec final and cleaned
>     up the code a bit based on comments from the field.
>
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>
> Thanks!
>
> --Jamil
>
>
> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>
>> * Removed the key field in ChaCha20 and Poly1305 implementations and 
>> only retain the key bytes as an object field (thanks Thomas for 
>> catching this)
>>
>> * Added additional protections against key/nonce reuse.? This is a 
>> behavioral change to ChaCha20 and ChaCha20-Poly1305. Instances of 
>> these ciphers will no longer allow you to do subsequent 
>> doUpdate/doFinal calls after the first doFinal without 
>> re-initializing the cipher with either a new key or nonce. Attempting 
>> to reuse the cipher without a new initialization will throw an 
>> IllegalStateException.? This is similar to the behavior of AES-GCM in 
>> encrypt mode, but for ChaCha20 it needs to be done for both encrypt 
>> and decrypt.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>
>> Thanks,
>> --Jamil
>>
>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>> Hello everyone,
>>>
>>> This is a quick update to the previous webrev:
>>>
>>> * When using the form of engineInit that does only takes op, key and 
>>> random, the nonce will always be random even if the random parameter 
>>> is null.? A default instance of SecureRandom will be used to create 
>>> the nonce in this case, instead of all zeroes.
>>>
>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>
>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>> separator from a System property directly.? It calls 
>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>> classes in com.sun.crypto.provider do it.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>
>>> Thanks,
>>>
>>> --Jamil
>>>
>>>
>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>> Hello all,
>>>>
>>>> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 
>>>> cipher implementations.? Links to the webrev and the JEP which 
>>>> outlines the characteristics and behavior of the ciphers are listed 
>>>> below.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>> http://openjdk.java.net/jeps/329
>>>>
>>>> Thanks,
>>>> --Jamil
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From roger.riggs at oracle.com  Fri May  4 19:51:57 2018
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 4 May 2018 15:51:57 -0400
Subject: RFR for 6443578 and 6202130: UTF-8 in Manifests
In-Reply-To: <56d63055-6c28-9029-354b-93be4cdca5e4@paratix.ch>
References: 
 
 <56d63055-6c28-9029-354b-93be4cdca5e4@paratix.ch>
Message-ID: <82ce9e4a-9846-6df2-1902-43f0658f21f1@oracle.com>

Hi Phillip,

Just a reminder that OpenJDK can *only* accept patches via 
cr.openjdk.java.net
(as an author) or inline or attached in email.

Thanks, Roger


On 5/2/18 9:12 PM, Philipp Kunz wrote:
> Hi,
>
> Here is patch for 6443578 and 6202130 also in webrev form.
>
> http://files.paratix.ch/jdk/6372077and6443578/webrev.01/
> http://files.paratix.ch/jdk/6372077and6443578/webrev.01.zip
>
> Hope it helps. With all the patience, can I do anything to make it 
> easier to get feedback or find a sponsor?
>
> Regards,
> Philipp
>
>
> On 02.05.2018 07:21, Philipp Kunz wrote:
>> Hi,
>>
>> Recently, I tried to fix only bug 6202130 with the intention to fix 
>> bug 6443578 later with the intention to get some opportunity for 
>> feedback, but haven't got any, and propose now a fix for both 
>> together which in my opinion makes more sense.
>>
>> See attached patch.
>>
>> Some considerations, assumptions, and explanations
>>
>>   * In my opinion, the code for writing manifests was distributed in
>>     the two classes Attributes and Manifest in an elegant way but
>>     somewhat difficult to explain the coherence. I chose to group the
>>     code that writes manifests into a new class ManifestWriter. The
>>     main incentive for that was to prevent or reduce duplicated code
>>     I would have had to change twice otherwise. This also results in
>>     a source file of a suitable size.
>>   * I could not support the assumption that the write and writeMain
>>     methods in Attributes couldn't be referenced anywhere so I
>>     deprecated them rather than having them removed.
>>   * I assumed the patch will not make it into JDK 10 and, hence, the
>>     deprecated annotations are attributed with since = 11.
>>   * I could not figure out any reason for the use of DataOutputStream
>>     and did not use it.
>>   * Performance-wise I assume that the code is approximately
>>     comparable to the previous version. The biggest improvement in
>>     this respect I hope comes from removing the String that contains
>>     the byte array constructed with deprecated String(byte[], int,
>>     int, int) and then copying it over again to a StringBuffer and
>>     from there to a String again and then Characters. On the other
>>     hand, keeping whole characters together when breaking lines might
>>     make it slightly slower. I hope my changes are an overall
>>     improvement, but I haven't measured it.
>>   * For telling first from continuation bytes of utf-8 characters
>>     apart I re-used a method isNotUtfContinuationByte from either
>>     StringCoding or UTF_8.Decoder. Unfortunately I found no way not
>>     to duplicate it.
>>   * Where it said before "XXX Need to handle UTF8 values and break up
>>     lines longer than 72 bytes" in Attributes#writeMain I did not
>>     dare to remove the comment completely because it still does not
>>     deal correctly with version headers longer than 72 bytes and the
>>     set of allowed values. I changed it accordingly. Two similar
>>     comments are removed in the patch.
>>   * I added two tests, WriteDeprecated and NullKeysAndValues, to
>>     demonstrate compatibility as good as I could. Might however not
>>     be desired to keep and having to maintain.
>>   * LineBrokenMultiByteCharacter for jarsigner should not be removed
>>     or not so immediately because someone might attempt to sign an
>>     older jarfile created without that patch with a newer jarsigner
>>     that already contains it.
>>
>>
>>
>> suggested changes or additions to the bug database: (i have no 
>> permissions to edit it myself)
>>
>>   * Re-combine copies of isNotUtfContinuationByte (three by now).
>>     Relates to 6184334. Worth to file another issue?
>>   * Manifest versions have specific specifications, cannot break
>>     across lines and can contain a subset of characters only. Bug
>>     6910466 relates but is not exactly the same. If someone else is
>>     convinced that writing a manifest should issue a warning or any
>>     other way to deal with a version that does not conform to the
>>     specification, I'd suggest to create a separate bug for that.
>>
>>
>> Now, I would be glad if someone sponsored a review. This is only my 
>> third attempt to submit a patch which is why I chose a lesser 
>> important subject to fix in order to get familiar and now I 
>> understand it's not the most attractive patch to review. Please don't 
>> hesitate to suggest what I could do better or differently.
>>
>> As a bonus, with these changes, manifest files will always be 
>> displayed correctly with just any utf capable viewer even if they 
>> contain multi-byte utf characters that would have been broken across 
>> a line break with the current/previous implementation and all 
>> manifests will become also valid strings in Java.
>>
>> Regards,
>> Philipp
>>
>>
>>
>> On 20.04.2018 00:58, Philipp Kunz wrote:
>>> Hi,
>>>
>>> I tried to fix bug 6202130 about manifest utf support and come up 
>>> now with a test as suggested in the bug's comments that shows that 
>>> utf charset actually works before removing the comments from the code.
>>>
>>> When I wanted to remove the XXX comments about utf it occurred to me 
>>> that version attributes ("Signature-Version" and "Manifest-Version") 
>>> would never be broken across lines and should anyway not support the 
>>> whole utf character set which sounds more like related to bugs 
>>> 6910466 or 4935610 but it's not a real fit. Therefore, I could not 
>>> remove one such comment of Attributes#writeMain but I changed it. 
>>> The first comment in bug 6202130 mentions only two comments but 
>>> there are three in Attributes. In the attached patch I removed only 
>>> two of three and changed the remaining third to not mention utf 
>>> anymore.
>>>
>>> At the moment, at least until 6443578 is fixed, multi-byte utf 
>>> characters can be broken across lines. It might be worth a 
>>> consideration to test that explicitly as well but then I guess there 
>>> is not much of a point in testing the current behavior that will 
>>> change with 6443578, hopefully soon. There are in my opinion enough 
>>> characters broken across lines in the attached test that demonstrate 
>>> that this still works like it did before.
>>>
>>> I would have preferred also to remove the calls to deprecated 
>>> String(byte[], int, int, int) but then figured it relates more to 
>>> bug 6443578 than 6202130 and now prefer to do that in another 
>>> separate patch.
>>>
>>> Bug 6202130 also states that lines are broken by String.length not 
>>> by byte length. While it looks so at first glance, I could not 
>>> confirm. The combination of getBytes("UTF8"), String(byte[], int, 
>>> int, int), and then DataOutputStream.writeBytes(String) in that 
>>> combination does not drop high-bytes because every byte (whether a 
>>> whole character or only a part of a multi-byte character) becomes a 
>>> character in String(...) containing that byte in its low-byte which 
>>> will be read again from writeBytes(...). Or put in a different way, 
>>> every utf encoded byte becomes a character and multi-byte utf 
>>> characters are converted into multiple string characters containing 
>>> one byte each in their lower bytes. The current solution is not 
>>> nice, but at least works. With that respect I'd like to suggest to 
>>> deprecate DataOutputStream.writeBytes(String) because it does 
>>> something not exactly expected when guessing from its name and that 
>>> would suit a byte[] parameter better very much like it has been done 
>>> with String(byte[], int, int, int). Any advice about the procedure 
>>> to deprecate something?
>>>
>>> I was surprised that it was not trivial to list all valid utf 
>>> characters. If someone has a better idea than isValidUtfCharacter in 
>>> the attached test, let me know.
>>>
>>> Altogether, I would not consider 6202130 resolved completely, unless 
>>> maybe all remaining points are copied to 6443578 and maybe another 
>>> bug about valid values for "Signature-Version" and 
>>> "Manifest-Version" if at all desired. But still I consider the 
>>> attached patch an improvement and most of the remainder can then be 
>>> solved in 6443578 and so far I am looking forward to any kind of 
>>> feedback.
>>>
>>> Regards,
>>> Philipp
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From brian.burkhalter at oracle.com  Fri May  4 20:24:56 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Fri, 4 May 2018 13:24:56 -0700
Subject: RFR for 6443578 and 6202130: UTF-8 in Manifests
In-Reply-To: <82ce9e4a-9846-6df2-1902-43f0658f21f1@oracle.com>
References: 
 
 <56d63055-6c28-9029-354b-93be4cdca5e4@paratix.ch>
 <82ce9e4a-9846-6df2-1902-43f0658f21f1@oracle.com>
Message-ID: <2EB2CB42-AFE7-407B-9778-F4B244A79DB0@oracle.com>

For more specifics about allowed attachment types see [1].

Brian

[1] http://mail.openjdk.java.net/pipermail/code-tools-dev/2018-March/000378.html

On May 4, 2018, at 12:51 PM, Roger Riggs  wrote:

> Just a reminder that OpenJDK can *only* accept patches via cr.openjdk.java.net
> (as an author) or inline or attached in email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun.wang at oracle.com  Sat May  5 05:53:28 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 5 May 2018 13:53:28 +0800
Subject: RFR (+CSR) 8201627: Kerberos sequence number issues
In-Reply-To: 
References: 
 <7350da42-2c10-efc2-f1a2-e8b858ecce13@oracle.com>
 <082D896A-99EA-4E53-97A6-75FB2A6F8C26@oracle.com>
 <3AD821A8-8514-4D43-A9EE-360C9C03140D@oracle.com>
 <11172315-AA49-4B07-8846-674D8B644EB7@oracle.com>
 <1220F98D-A15B-499A-BE38-A5B544AD1DF7@oracle.com>
 
Message-ID: <10F790B3-6E30-486D-83F5-74963185A455@oracle.com>

Hi Valerie

Can you also review the release note at https://bugs.openjdk.java.net/browse/JDK-8202681?

Thanks
Max


> On Apr 27, 2018, at 5:58 AM, Valerie Peng  wrote:
> 
> Sure, should be fine...
> Valerie
> 
> On 4/25/2018 9:48 PM, Weijun Wang wrote:
>> I filed https://bugs.openjdk.java.net/browse/JDK-8202300 but might not have time to make it into JDK 11.
>> 
>> --Max
>> 
>>> On Apr 26, 2018, at 12:06 AM, Weijun Wang  wrote:
>>> 
>>> I'll keep using int32 (at least in this fix), both Java and MIT krb5 contain these words
>>> 
>>> * Workaround implementation incompatibilities by not generating
>>> * initial sequence numbers greater than 2^30
>>> 
>>> So bad thing could only happen after 2^30 messages.
>>> 
>>> --Max
>>> 
>>>> On Apr 25, 2018, at 10:38 PM, Weijun Wang  wrote:
>>>> 
>>>> It's complicated. Looks like MIT krb5 uses a uint32 for old etypes (DES, 3DES, RC4) and a uint64 for new ones (AES) [1][2].
>>>> 
>>>> I'll do more experiments.
>>>> 
>>>> Thanks
>>>> Max
>>>> 
>>>> [1] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/util_seqstate.c#L76
>>>> [2] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/krb5/init_sec_context.c#L825
>>>> 
>>>>> On Apr 24, 2018, at 8:55 PM, Wang Weijun  wrote:
>>>>> 
>>>>> RFC 4120 5.5.1 has
>>>>>> seq-number
>>>>>> This optional field includes the initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to detect replays. (It may also be used by application specific messages.) When included in the authenticator, this field specifies the initial sequence number for messages from the client to the server. When included in the AP-REP message, the initial sequence number is that for messages from the server to the client. When used in KRB_PRIV or KRB_SAFE messages, it is incremented by one after each message is sent. Sequence numbers fall in the range 0 through 2^32 - 1 and wrap to zero following the value 2^32 - 1.
>>>>> 
>>>>> If it wraps, then it?s 4 bytes.
>>>>> 
>>>>> I will read more on it.
>>>>> 
>>>>> Thanks
>>>>> Max
>>>>> 
>>>>>> ? 2018?4?24??18:08?Valerie Peng  ???
>>>>>> 
>>>>>> Hi Max,
>>>>>> 
>>>>>> Most changes look good. I have only some comments and questions (see below):
>>>>>> 
>>>>>> - InitSecContextToken.java, line 62: bad -> unrecognized?
>>>>>> - According to the class javadoc of various Token classes and Kerberos spec, the sequence number is 8-byte integer from header byte 8-15, but java int have only 4 bytes. The current code seems to assume the first 4 bytes of the sequence number are always 0. For the sake of compliance and max inter-operability, maybe we should use long to store the sequence number?
>>>>>> 
>>>>>> CSR looks good to me.
>>>>>> Thanks,
>>>>>> Valerie
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On 4/18/2018 10:40 AM, Weijun Wang wrote:
>>>>>>> Please take a review of this fix:
>>>>>>> 
>>>>>>> webrev: http://cr.openjdk.java.net/~weijun/8201627/webrev.00/
>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201814
>>>>>>> 
>>>>>>> Basically we fix some bugs and introduce a system property so we can interop with everyone.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Max
>>>>>>> 
> 



From weijun.wang at oracle.com  Sat May  5 07:38:47 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 5 May 2018 15:38:47 +0800
Subject: RFR CSR 8202590: Customizing the generation of a PKCS12 keystore
Message-ID: <253F0053-D087-4B8B-BAAA-07C4FD8B61FF@oracle.com>

Please take a review of

   https://bugs.openjdk.java.net/browse/JDK-8202590

This enhancement has two major purposes:

1. Provide a way to change encryption and Mac algorithms used in PKCS 12.

2. The ability to create a password-less PKCS 12 keystore containing unencrypted certificates and no Mac.

Especially, the long paragraph in the spec on behavior of an existing keystore makes sure that once a password-less keystore is generated (with -Dkeystore.pkcs12.certProtectionAlgorithm=NONE and -Dkeystore.pkcs12.macAlgorithm=NONE), one can add new certificates to it without any special setting and keep it password-less.

Thanks
Max



From mstjohns at comcast.net  Sat May  5 14:50:21 2018
From: mstjohns at comcast.net (Michael StJohns)
Date: Sat, 5 May 2018 10:50:21 -0400
Subject: RFR CSR 8202590: Customizing the generation of a PKCS12 keystore
In-Reply-To: <253F0053-D087-4B8B-BAAA-07C4FD8B61FF@oracle.com>
References: <253F0053-D087-4B8B-BAAA-07C4FD8B61FF@oracle.com>
Message-ID: <2060f656-9a05-90d1-3426-fe4719cfff71@comcast.net>

On 5/5/2018 3:38 AM, Weijun Wang wrote:
> Please take a review of
>
>     https://bugs.openjdk.java.net/browse/JDK-8202590
>
> This enhancement has two major purposes:
>
> 1. Provide a way to change encryption and Mac algorithms used in PKCS 12.
>
> 2. The ability to create a password-less PKCS 12 keystore containing unencrypted certificates and no Mac.
>
> Especially, the long paragraph in the spec on behavior of an existing keystore makes sure that once a password-less keystore is generated (with -Dkeystore.pkcs12.certProtectionAlgorithm=NONE and -Dkeystore.pkcs12.macAlgorithm=NONE), one can add new certificates to it without any special setting and keep it password-less.
>
> Thanks
> Max
>

|I think you want to break this into two parts - the first part 
specifies the algorithm used to convert a password into key material. 
The second defines the algorithms used for protection for the various parts.
# password to key material scheme
.pbkdf=PBKDF2withHMAC-SHA256? (Form is base function with the PRF)
# PKCS12 macData
.macAlgorithm=HMAC-SHA256? # this is the algorithm for the PKCS12 
macData component, if NONE, this component is not present
# protection scheme for PKCS8ShroudedKeyBagn if NONE, then a PKCS8KeyBag 
is produced instead.
.keyProtectionAlgorithm=AES-KWA
#protection scheme for certificates - produces an encryptedData object 
encrypted under the scheme, or a certBag object if "NONE" is specified
.certProtectionAlgorithm=NONE


Second, you probably want to do this as multi-choice entries in the 
java.security file ala providers:

.pbkdf.0=PBKDF2withSHA256
.pbkdf.9=PBKDF1withSHA1 # the current default aka pbe

So that you can specify a somewhat secure default, but still allow for 
providers that don't implement the stronger versions.

This requires a bit more work in figuring out what the embedded OIDs 
should be, and there is always the chance of mismatch, but it turns out 
there is the chance of mismatch even in the proposed version if you have 
protection algorithms coming from two different PBE schemes.

Specifying it this way is closer to the PKCS5 2.0 model rather than 
PKCS12 and matches the recommendations in the IETF's version of PKCS12.? 
You also *really* don't want to use two different KDFs with the same 
password.

Mike




|
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sean.mullan at oracle.com  Mon May  7 19:58:28 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Mon, 7 May 2018 15:58:28 -0400
Subject: RFR JDK-8199388: Test development for ChaCha20 and Poly1305
 algorithms
In-Reply-To: <6e713b9f-b9bb-7172-4fee-5b750bed33f8@oracle.com>
References: <6e713b9f-b9bb-7172-4fee-5b750bed33f8@oracle.com>
Message-ID: <26f1eceb-1b38-7192-9f13-d91ef5ca149a@oracle.com>

- test/lib/jdk/test/lib/Utils.java

402       * @param bytes Byte array to process

Nit, but you should keep the previous version where "byte" was not 
capitalized. Typically, sentence fragments in javadoc like this are not 
capitalized, and "Byte" can be confused with java.lang.Byte which this 
is not.

403       * @return Space separated hexadecimal string representation of 
bytes

Based on previous comment, this should be "space".

Looks fine otherwise.

--Sean

On 4/23/18 9:16 PM, sha.jiang at oracle.com wrote:
> Hi,
> This patch only adds a test for ChaCha20 key generator.
> 
> Issue: https://bugs.openjdk.java.net/browse/JDK-8199388
> Webrev: http://cr.openjdk.java.net/~jjiang/8199388/webrev.00/
> 
> Best regards,
> John Jiang
> 


From sha.jiang at oracle.com  Tue May  8 03:18:00 2018
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Tue, 8 May 2018 11:18:00 +0800
Subject: RFR JDK-8199388: Test development for ChaCha20 and Poly1305
 algorithms
In-Reply-To: <26f1eceb-1b38-7192-9f13-d91ef5ca149a@oracle.com>
References: <6e713b9f-b9bb-7172-4fee-5b750bed33f8@oracle.com>
 <26f1eceb-1b38-7192-9f13-d91ef5ca149a@oracle.com>
Message-ID: 

Hi Sean,
Thanks for your comments.
Please review at this updated webrev: 
http://cr.openjdk.java.net/~jjiang/8199388/webrev.01/

Best regards,
John Jiang

On 08/05/2018 03:58, Sean Mullan wrote:
> - test/lib/jdk/test/lib/Utils.java
>
> 402?????? * @param bytes Byte array to process
>
> Nit, but you should keep the previous version where "byte" was not 
> capitalized. Typically, sentence fragments in javadoc like this are 
> not capitalized, and "Byte" can be confused with java.lang.Byte which 
> this is not.
>
> 403?????? * @return Space separated hexadecimal string representation 
> of bytes
>
> Based on previous comment, this should be "space".
>
> Looks fine otherwise.
>
> --Sean
>
> On 4/23/18 9:16 PM, sha.jiang at oracle.com wrote:
>> Hi,
>> This patch only adds a test for ChaCha20 key generator.
>>
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199388
>> Webrev: http://cr.openjdk.java.net/~jjiang/8199388/webrev.00/
>>
>> Best regards,
>> John Jiang
>>
>



From weijun.wang at oracle.com  Tue May  8 06:47:43 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 8 May 2018 14:47:43 +0800
Subject: RFR 8201867: Kerberos keytabs with holes in certain places are
 parsed incorrectly
In-Reply-To: <75DD716E-82A1-4160-A057-90735DC38147@oracle.com>
References: <75DD716E-82A1-4160-A057-90735DC38147@oracle.com>
Message-ID: 

Ping again. Thanks.

> On Apr 24, 2018, at 10:42 PM, Weijun Wang  wrote:
> 
> Please take a review at
> 
>  http://cr.openjdk.java.net/~weijun/8201867/webrev.00/
> 
> When the hole in keytab is right on the 8192 buffer boundary, skip(n) does not return n.
> 
> I are not sure if I can do something like "while (i < n) i += skip(n)" because skip(n) can return zero and it does not understand EOF. Therefore I readNBytes(n) and discard the result. If you have a better solution, I'll be happy to know.
> 
> Thanks
> Max
> 



From sean.mullan at oracle.com  Tue May  8 16:51:07 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 8 May 2018 12:51:07 -0400
Subject: RFR JDK-8199388: Test development for ChaCha20 and Poly1305
 algorithms
In-Reply-To: 
References: <6e713b9f-b9bb-7172-4fee-5b750bed33f8@oracle.com>
 <26f1eceb-1b38-7192-9f13-d91ef5ca149a@oracle.com>
 
Message-ID: 

Looks good.

--Sean

On 5/7/18 11:18 PM, sha.jiang at oracle.com wrote:
> Hi Sean,
> Thanks for your comments.
> Please review at this updated webrev: 
> http://cr.openjdk.java.net/~jjiang/8199388/webrev.01/
> 
> Best regards,
> John Jiang
> 
> On 08/05/2018 03:58, Sean Mullan wrote:
>> - test/lib/jdk/test/lib/Utils.java
>>
>> 402?????? * @param bytes Byte array to process
>>
>> Nit, but you should keep the previous version where "byte" was not 
>> capitalized. Typically, sentence fragments in javadoc like this are 
>> not capitalized, and "Byte" can be confused with java.lang.Byte which 
>> this is not.
>>
>> 403?????? * @return Space separated hexadecimal string representation 
>> of bytes
>>
>> Based on previous comment, this should be "space".
>>
>> Looks fine otherwise.
>>
>> --Sean
>>
>> On 4/23/18 9:16 PM, sha.jiang at oracle.com wrote:
>>> Hi,
>>> This patch only adds a test for ChaCha20 key generator.
>>>
>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8199388
>>> Webrev: http://cr.openjdk.java.net/~jjiang/8199388/webrev.00/
>>>
>>> Best regards,
>>> John Jiang
>>>
>>
> 


From sean.mullan at oracle.com  Tue May  8 17:49:48 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 8 May 2018 13:49:48 -0400
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
Message-ID: <327f8f3d-d56a-d447-3dbc-70b5da2c013a@oracle.com>

- ChaCha20ParameterSpec.java

The methods don't need to be final now that the class is final.

- ChaCha20Poly1305Parameters.java

  122         if (decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
  123             engineInit(encoded);

The spec for engineInit() says if decodingMethod is null, the default 
encoding should be used, so the code above should be:

  122         if (decodingMethod == null || 
decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
  123             engineInit(encoded);

Looks good otherwise.

--Sean

On 5/4/18 10:06 AM, Jamil Nimeh wrote:
> Round 5.
> 
> This adds Sean's comments.? Sean, I was never able to execute a case on 
> init where a half-baked object would fail.? In most cases it would fail 
> in checks in javax.crypto.Cipher before it ever made it down to my 
> code.? I'm pretty confident the init sequence is OK.? I did move the 
> setting of a few data members toward the end of the init sequence but 
> setting the key and nonce is necessary before creating the initial 
> state, which is then used for generating an authentication key for AEAD 
> mode and generating keystream.
> 
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
> 
> Also the CSR has been finalized and can be found here:
> https://bugs.openjdk.java.net/browse/JDK-8198925
> 
> --Jamil
> 
> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>
>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff mostly:
>>
>>   * Added words in the description of javax.crypto.Cipher recommending
>>     callers reinitialize the Cipher to use different nonces after each
>>     complete encryption or decryption (similar language to what exists
>>     already for AES-GCM encryption).
>>   * Added an additional test case for ChaCha20NoReuse
>>   * Made accessor methods for ChaCha20ParameterSpec final and cleaned
>>     up the code a bit based on comments from the field.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>
>> Thanks!
>>
>> --Jamil
>>
>>
>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>
>>> * Removed the key field in ChaCha20 and Poly1305 implementations and 
>>> only retain the key bytes as an object field (thanks Thomas for 
>>> catching this)
>>>
>>> * Added additional protections against key/nonce reuse.? This is a 
>>> behavioral change to ChaCha20 and ChaCha20-Poly1305. Instances of 
>>> these ciphers will no longer allow you to do subsequent 
>>> doUpdate/doFinal calls after the first doFinal without 
>>> re-initializing the cipher with either a new key or nonce. Attempting 
>>> to reuse the cipher without a new initialization will throw an 
>>> IllegalStateException.? This is similar to the behavior of AES-GCM in 
>>> encrypt mode, but for ChaCha20 it needs to be done for both encrypt 
>>> and decrypt.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>
>>> Thanks,
>>> --Jamil
>>>
>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>> Hello everyone,
>>>>
>>>> This is a quick update to the previous webrev:
>>>>
>>>> * When using the form of engineInit that does only takes op, key and 
>>>> random, the nonce will always be random even if the random parameter 
>>>> is null.? A default instance of SecureRandom will be used to create 
>>>> the nonce in this case, instead of all zeroes.
>>>>
>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>
>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>> separator from a System property directly.? It calls 
>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>> classes in com.sun.crypto.provider do it.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>
>>>> Thanks,
>>>>
>>>> --Jamil
>>>>
>>>>
>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>> Hello all,
>>>>>
>>>>> This is a request for review for the ChaCha20 and ChaCha20-Poly1305 
>>>>> cipher implementations.? Links to the webrev and the JEP which 
>>>>> outlines the characteristics and behavior of the ciphers are listed 
>>>>> below.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>> http://openjdk.java.net/jeps/329
>>>>>
>>>>> Thanks,
>>>>> --Jamil
>>>>
>>>
>>
> 


From jamil.j.nimeh at oracle.com  Tue May  8 17:52:16 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 8 May 2018 10:52:16 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <327f8f3d-d56a-d447-3dbc-70b5da2c013a@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <327f8f3d-d56a-d447-3dbc-70b5da2c013a@oracle.com>
Message-ID: <99d4f29a-2dd1-0e7e-a521-d0ae22a250e3@oracle.com>

I'll make those fixes.? One question with respect to the final methods: 
the CSR had those methods in the description and they were marked as 
final.? That CSR is now complete.? Will removing the final qualifier in 
the methods be an issue?? In terms of effect on the code it doesn't 
matter.? It's more of a dot-i/cross-t kind of question.

--Jamil

On 5/8/2018 10:49 AM, Sean Mullan wrote:
> - ChaCha20ParameterSpec.java
>
> The methods don't need to be final now that the class is final.
>
> - ChaCha20Poly1305Parameters.java
>
> ?122???????? if (decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
> ?123???????????? engineInit(encoded);
>
> The spec for engineInit() says if decodingMethod is null, the default 
> encoding should be used, so the code above should be:
>
> ?122???????? if (decodingMethod == null || 
> decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
> ?123???????????? engineInit(encoded);
>
> Looks good otherwise.
>
> --Sean
>
> On 5/4/18 10:06 AM, Jamil Nimeh wrote:
>> Round 5.
>>
>> This adds Sean's comments.? Sean, I was never able to execute a case 
>> on init where a half-baked object would fail.? In most cases it would 
>> fail in checks in javax.crypto.Cipher before it ever made it down to 
>> my code.? I'm pretty confident the init sequence is OK.? I did move 
>> the setting of a few data members toward the end of the init sequence 
>> but setting the key and nonce is necessary before creating the 
>> initial state, which is then used for generating an authentication 
>> key for AEAD mode and generating keystream.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>
>> Also the CSR has been finalized and can be found here:
>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>
>> --Jamil
>>
>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>
>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>> mostly:
>>>
>>> ? * Added words in the description of javax.crypto.Cipher recommending
>>> ??? callers reinitialize the Cipher to use different nonces after each
>>> ??? complete encryption or decryption (similar language to what exists
>>> ??? already for AES-GCM encryption).
>>> ? * Added an additional test case for ChaCha20NoReuse
>>> ? * Made accessor methods for ChaCha20ParameterSpec final and cleaned
>>> ??? up the code a bit based on comments from the field.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>
>>> Thanks!
>>>
>>> --Jamil
>>>
>>>
>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>
>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>> and only retain the key bytes as an object field (thanks Thomas for 
>>>> catching this)
>>>>
>>>> * Added additional protections against key/nonce reuse. This is a 
>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305. Instances of 
>>>> these ciphers will no longer allow you to do subsequent 
>>>> doUpdate/doFinal calls after the first doFinal without 
>>>> re-initializing the cipher with either a new key or nonce. 
>>>> Attempting to reuse the cipher without a new initialization will 
>>>> throw an IllegalStateException. This is similar to the behavior of 
>>>> AES-GCM in encrypt mode, but for ChaCha20 it needs to be done for 
>>>> both encrypt and decrypt.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>
>>>> Thanks,
>>>> --Jamil
>>>>
>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>> Hello everyone,
>>>>>
>>>>> This is a quick update to the previous webrev:
>>>>>
>>>>> * When using the form of engineInit that does only takes op, key 
>>>>> and random, the nonce will always be random even if the random 
>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>
>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>
>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>> separator from a System property directly.? It calls 
>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>> classes in com.sun.crypto.provider do it.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Jamil
>>>>>
>>>>>
>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> This is a request for review for the ChaCha20 and 
>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>> the ciphers are listed below.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>> http://openjdk.java.net/jeps/329
>>>>>>
>>>>>> Thanks,
>>>>>> --Jamil
>>>>>
>>>>
>>>
>>



From sean.mullan at oracle.com  Tue May  8 17:58:26 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 8 May 2018 13:58:26 -0400
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <99d4f29a-2dd1-0e7e-a521-d0ae22a250e3@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <327f8f3d-d56a-d447-3dbc-70b5da2c013a@oracle.com>
 <99d4f29a-2dd1-0e7e-a521-d0ae22a250e3@oracle.com>
Message-ID: <7ca08ad2-92d0-983d-116a-3580fda623e2@oracle.com>

On 5/8/18 1:52 PM, Jamil Nimeh wrote:
> I'll make those fixes.? One question with respect to the final methods: 
> the CSR had those methods in the description and they were marked as 
> final.? That CSR is now complete.? Will removing the final qualifier in 
> the methods be an issue?? In terms of effect on the code it doesn't 
> matter.? It's more of a dot-i/cross-t kind of question.

I don't think so as the behavior is the same either way.

--Sean

> 
> --Jamil
> 
> On 5/8/2018 10:49 AM, Sean Mullan wrote:
>> - ChaCha20ParameterSpec.java
>>
>> The methods don't need to be final now that the class is final.
>>
>> - ChaCha20Poly1305Parameters.java
>>
>> ?122???????? if (decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
>> ?123???????????? engineInit(encoded);
>>
>> The spec for engineInit() says if decodingMethod is null, the default 
>> encoding should be used, so the code above should be:
>>
>> ?122???????? if (decodingMethod == null || 
>> decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
>> ?123???????????? engineInit(encoded);
>>
>> Looks good otherwise.
>>
>> --Sean
>>
>> On 5/4/18 10:06 AM, Jamil Nimeh wrote:
>>> Round 5.
>>>
>>> This adds Sean's comments.? Sean, I was never able to execute a case 
>>> on init where a half-baked object would fail.? In most cases it would 
>>> fail in checks in javax.crypto.Cipher before it ever made it down to 
>>> my code.? I'm pretty confident the init sequence is OK.? I did move 
>>> the setting of a few data members toward the end of the init sequence 
>>> but setting the key and nonce is necessary before creating the 
>>> initial state, which is then used for generating an authentication 
>>> key for AEAD mode and generating keystream.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>
>>> Also the CSR has been finalized and can be found here:
>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>
>>> --Jamil
>>>
>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>
>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>> mostly:
>>>>
>>>> ? * Added words in the description of javax.crypto.Cipher recommending
>>>> ??? callers reinitialize the Cipher to use different nonces after each
>>>> ??? complete encryption or decryption (similar language to what exists
>>>> ??? already for AES-GCM encryption).
>>>> ? * Added an additional test case for ChaCha20NoReuse
>>>> ? * Made accessor methods for ChaCha20ParameterSpec final and cleaned
>>>> ??? up the code a bit based on comments from the field.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>
>>>> Thanks!
>>>>
>>>> --Jamil
>>>>
>>>>
>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>
>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>> and only retain the key bytes as an object field (thanks Thomas for 
>>>>> catching this)
>>>>>
>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305. Instances of 
>>>>> these ciphers will no longer allow you to do subsequent 
>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>> throw an IllegalStateException. This is similar to the behavior of 
>>>>> AES-GCM in encrypt mode, but for ChaCha20 it needs to be done for 
>>>>> both encrypt and decrypt.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>
>>>>> Thanks,
>>>>> --Jamil
>>>>>
>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>> Hello everyone,
>>>>>>
>>>>>> This is a quick update to the previous webrev:
>>>>>>
>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>> and random, the nonce will always be random even if the random 
>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>
>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>
>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>> separator from a System property directly.? It calls 
>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --Jamil
>>>>>>
>>>>>>
>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>> the ciphers are listed below.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --Jamil
>>>>>>
>>>>>
>>>>
>>>
> 


From Roger.Riggs at Oracle.com  Tue May  8 18:03:45 2018
From: Roger.Riggs at Oracle.com (Roger Riggs)
Date: Tue, 8 May 2018 14:03:45 -0400
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <7ca08ad2-92d0-983d-116a-3580fda623e2@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <327f8f3d-d56a-d447-3dbc-70b5da2c013a@oracle.com>
 <99d4f29a-2dd1-0e7e-a521-d0ae22a250e3@oracle.com>
 <7ca08ad2-92d0-983d-116a-3580fda623e2@oracle.com>
Message-ID: 

Hi,

"final" is a important modifier of the method signature and if the CSR 
and the implementation are
different it might raise a question about which is the correct signature 
when the JCK folks write tests.

It is pretty lightweight process to return the CSR to draft and update 
it and finalize it again.
It should be readily approved.? (or leave the implementation as final).

$.02, Roger

On 5/8/2018 1:58 PM, Sean Mullan wrote:
> On 5/8/18 1:52 PM, Jamil Nimeh wrote:
>> I'll make those fixes.? One question with respect to the final 
>> methods: the CSR had those methods in the description and they were 
>> marked as final.? That CSR is now complete.? Will removing the final 
>> qualifier in the methods be an issue?? In terms of effect on the code 
>> it doesn't matter. It's more of a dot-i/cross-t kind of question.
>
> I don't think so as the behavior is the same either way.
>
> --Sean
>
>>
>> --Jamil
>>
>> On 5/8/2018 10:49 AM, Sean Mullan wrote:
>>> - ChaCha20ParameterSpec.java
>>>
>>> The methods don't need to be final now that the class is final.
>>>
>>> - ChaCha20Poly1305Parameters.java
>>>
>>> ?122???????? if (decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
>>> ?123???????????? engineInit(encoded);
>>>
>>> The spec for engineInit() says if decodingMethod is null, the 
>>> default encoding should be used, so the code above should be:
>>>
>>> ?122???????? if (decodingMethod == null || 
>>> decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
>>> ?123???????????? engineInit(encoded);
>>>
>>> Looks good otherwise.
>>>
>>> --Sean
>>>
>>> On 5/4/18 10:06 AM, Jamil Nimeh wrote:
>>>> Round 5.
>>>>
>>>> This adds Sean's comments.? Sean, I was never able to execute a 
>>>> case on init where a half-baked object would fail.? In most cases 
>>>> it would fail in checks in javax.crypto.Cipher before it ever made 
>>>> it down to my code. I'm pretty confident the init sequence is OK.? 
>>>> I did move the setting of a few data members toward the end of the 
>>>> init sequence but setting the key and nonce is necessary before 
>>>> creating the initial state, which is then used for generating an 
>>>> authentication key for AEAD mode and generating keystream.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>>
>>>> Also the CSR has been finalized and can be found here:
>>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>>
>>>> --Jamil
>>>>
>>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>>
>>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>>> mostly:
>>>>>
>>>>> ? * Added words in the description of javax.crypto.Cipher 
>>>>> recommending
>>>>> ??? callers reinitialize the Cipher to use different nonces after 
>>>>> each
>>>>> ??? complete encryption or decryption (similar language to what 
>>>>> exists
>>>>> ??? already for AES-GCM encryption).
>>>>> ? * Added an additional test case for ChaCha20NoReuse
>>>>> ? * Made accessor methods for ChaCha20ParameterSpec final and cleaned
>>>>> ??? up the code a bit based on comments from the field.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --Jamil
>>>>>
>>>>>
>>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>>
>>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>>> for catching this)
>>>>>>
>>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305. Instances of 
>>>>>> these ciphers will no longer allow you to do subsequent 
>>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>>> throw an IllegalStateException. This is similar to the behavior 
>>>>>> of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done 
>>>>>> for both encrypt and decrypt.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>>
>>>>>> Thanks,
>>>>>> --Jamil
>>>>>>
>>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>> This is a quick update to the previous webrev:
>>>>>>>
>>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>>> and random, the nonce will always be random even if the random 
>>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>>
>>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>>
>>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>>> separator from a System property directly. It calls 
>>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --Jamil
>>>>>>>
>>>>>>>
>>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>>> the ciphers are listed below.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> --Jamil
>>>>>>>
>>>>>>
>>>>>
>>>>
>>



From sean.mullan at oracle.com  Tue May  8 18:11:10 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 8 May 2018 14:11:10 -0400
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <327f8f3d-d56a-d447-3dbc-70b5da2c013a@oracle.com>
 <99d4f29a-2dd1-0e7e-a521-d0ae22a250e3@oracle.com>
 <7ca08ad2-92d0-983d-116a-3580fda623e2@oracle.com>
 
Message-ID: <559ec280-b248-572c-6438-25f0eb9a3e1f@oracle.com>

To clarify, both the impl and the CSR mark the ChaCha20ParameterSpec 
class as final, but the CSR also (accidentally) marked the methods of 
the class as final. If that qualifies as an API change, then we should 
fix the CSR, but I don't know for sure. It's an odd case.

--Sean

On 5/8/18 2:03 PM, Roger Riggs wrote:
> Hi,
> 
> "final" is a important modifier of the method signature and if the CSR 
> and the implementation are
> different it might raise a question about which is the correct signature 
> when the JCK folks write tests.
> 
> It is pretty lightweight process to return the CSR to draft and update 
> it and finalize it again.
> It should be readily approved.? (or leave the implementation as final).
> 
> $.02, Roger
> 
> On 5/8/2018 1:58 PM, Sean Mullan wrote:
>> On 5/8/18 1:52 PM, Jamil Nimeh wrote:
>>> I'll make those fixes.? One question with respect to the final 
>>> methods: the CSR had those methods in the description and they were 
>>> marked as final.? That CSR is now complete.? Will removing the final 
>>> qualifier in the methods be an issue?? In terms of effect on the code 
>>> it doesn't matter. It's more of a dot-i/cross-t kind of question.
>>
>> I don't think so as the behavior is the same either way.
>>
>> --Sean
>>
>>>
>>> --Jamil
>>>
>>> On 5/8/2018 10:49 AM, Sean Mullan wrote:
>>>> - ChaCha20ParameterSpec.java
>>>>
>>>> The methods don't need to be final now that the class is final.
>>>>
>>>> - ChaCha20Poly1305Parameters.java
>>>>
>>>> ?122???????? if (decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
>>>> ?123???????????? engineInit(encoded);
>>>>
>>>> The spec for engineInit() says if decodingMethod is null, the 
>>>> default encoding should be used, so the code above should be:
>>>>
>>>> ?122???????? if (decodingMethod == null || 
>>>> decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
>>>> ?123???????????? engineInit(encoded);
>>>>
>>>> Looks good otherwise.
>>>>
>>>> --Sean
>>>>
>>>> On 5/4/18 10:06 AM, Jamil Nimeh wrote:
>>>>> Round 5.
>>>>>
>>>>> This adds Sean's comments.? Sean, I was never able to execute a 
>>>>> case on init where a half-baked object would fail.? In most cases 
>>>>> it would fail in checks in javax.crypto.Cipher before it ever made 
>>>>> it down to my code. I'm pretty confident the init sequence is OK. I 
>>>>> did move the setting of a few data members toward the end of the 
>>>>> init sequence but setting the key and nonce is necessary before 
>>>>> creating the initial state, which is then used for generating an 
>>>>> authentication key for AEAD mode and generating keystream.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>>>
>>>>> Also the CSR has been finalized and can be found here:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>>>
>>>>> --Jamil
>>>>>
>>>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>>>
>>>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>>>> mostly:
>>>>>>
>>>>>> ? * Added words in the description of javax.crypto.Cipher 
>>>>>> recommending
>>>>>> ??? callers reinitialize the Cipher to use different nonces after 
>>>>>> each
>>>>>> ??? complete encryption or decryption (similar language to what 
>>>>>> exists
>>>>>> ??? already for AES-GCM encryption).
>>>>>> ? * Added an additional test case for ChaCha20NoReuse
>>>>>> ? * Made accessor methods for ChaCha20ParameterSpec final and cleaned
>>>>>> ??? up the code a bit based on comments from the field.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> --Jamil
>>>>>>
>>>>>>
>>>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>>>
>>>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>>>> for catching this)
>>>>>>>
>>>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305. Instances of 
>>>>>>> these ciphers will no longer allow you to do subsequent 
>>>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>>>> throw an IllegalStateException. This is similar to the behavior 
>>>>>>> of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done 
>>>>>>> for both encrypt and decrypt.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --Jamil
>>>>>>>
>>>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>>>> Hello everyone,
>>>>>>>>
>>>>>>>> This is a quick update to the previous webrev:
>>>>>>>>
>>>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>>>> and random, the nonce will always be random even if the random 
>>>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>>>
>>>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>>>
>>>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>>>> separator from a System property directly. It calls 
>>>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> --Jamil
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>>>> the ciphers are listed below.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> --Jamil
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
> 


From jamil.j.nimeh at oracle.com  Tue May  8 18:13:01 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 8 May 2018 11:13:01 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <327f8f3d-d56a-d447-3dbc-70b5da2c013a@oracle.com>
 <99d4f29a-2dd1-0e7e-a521-d0ae22a250e3@oracle.com>
 <7ca08ad2-92d0-983d-116a-3580fda623e2@oracle.com>
 
Message-ID: <287323e6-356c-4fc6-d474-3daf94029fff@oracle.com>

Okay, let me fix the code and the CSR and make them match.? I'll put the 
CSR back in draft and make a note in the comments about what is 
changing.? This is an innocuous change, but if Sean feels that code-wise 
the final class should not have final methods, then making the CSR match 
the fixed code sounds like the right way to go.

--Jamil

On 5/8/2018 11:03 AM, Roger Riggs wrote:
> Hi,
>
> "final" is a important modifier of the method signature and if the CSR 
> and the implementation are
> different it might raise a question about which is the correct 
> signature when the JCK folks write tests.
>
> It is pretty lightweight process to return the CSR to draft and update 
> it and finalize it again.
> It should be readily approved.? (or leave the implementation as final).
>
> $.02, Roger
>
> On 5/8/2018 1:58 PM, Sean Mullan wrote:
>> On 5/8/18 1:52 PM, Jamil Nimeh wrote:
>>> I'll make those fixes.? One question with respect to the final 
>>> methods: the CSR had those methods in the description and they were 
>>> marked as final.? That CSR is now complete.? Will removing the final 
>>> qualifier in the methods be an issue?? In terms of effect on the 
>>> code it doesn't matter. It's more of a dot-i/cross-t kind of question.
>>
>> I don't think so as the behavior is the same either way.
>>
>> --Sean
>>
>>>
>>> --Jamil
>>>
>>> On 5/8/2018 10:49 AM, Sean Mullan wrote:
>>>> - ChaCha20ParameterSpec.java
>>>>
>>>> The methods don't need to be final now that the class is final.
>>>>
>>>> - ChaCha20Poly1305Parameters.java
>>>>
>>>> ?122???????? if (decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
>>>> ?123???????????? engineInit(encoded);
>>>>
>>>> The spec for engineInit() says if decodingMethod is null, the 
>>>> default encoding should be used, so the code above should be:
>>>>
>>>> ?122???????? if (decodingMethod == null || 
>>>> decodingMethod.equalsIgnoreCase(DEFAULT_FMT)) {
>>>> ?123???????????? engineInit(encoded);
>>>>
>>>> Looks good otherwise.
>>>>
>>>> --Sean
>>>>
>>>> On 5/4/18 10:06 AM, Jamil Nimeh wrote:
>>>>> Round 5.
>>>>>
>>>>> This adds Sean's comments.? Sean, I was never able to execute a 
>>>>> case on init where a half-baked object would fail.? In most cases 
>>>>> it would fail in checks in javax.crypto.Cipher before it ever made 
>>>>> it down to my code. I'm pretty confident the init sequence is OK.? 
>>>>> I did move the setting of a few data members toward the end of the 
>>>>> init sequence but setting the key and nonce is necessary before 
>>>>> creating the initial state, which is then used for generating an 
>>>>> authentication key for AEAD mode and generating keystream.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>>>
>>>>> Also the CSR has been finalized and can be found here:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>>>
>>>>> --Jamil
>>>>>
>>>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>>>
>>>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor 
>>>>>> stuff mostly:
>>>>>>
>>>>>> ? * Added words in the description of javax.crypto.Cipher 
>>>>>> recommending
>>>>>> ??? callers reinitialize the Cipher to use different nonces after 
>>>>>> each
>>>>>> ??? complete encryption or decryption (similar language to what 
>>>>>> exists
>>>>>> ??? already for AES-GCM encryption).
>>>>>> ? * Added an additional test case for ChaCha20NoReuse
>>>>>> ? * Made accessor methods for ChaCha20ParameterSpec final and 
>>>>>> cleaned
>>>>>> ??? up the code a bit based on comments from the field.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> --Jamil
>>>>>>
>>>>>>
>>>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>>>
>>>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>>>> for catching this)
>>>>>>>
>>>>>>> * Added additional protections against key/nonce reuse. This is 
>>>>>>> a behavioral change to ChaCha20 and ChaCha20-Poly1305. Instances 
>>>>>>> of these ciphers will no longer allow you to do subsequent 
>>>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>>>> throw an IllegalStateException. This is similar to the behavior 
>>>>>>> of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done 
>>>>>>> for both encrypt and decrypt.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --Jamil
>>>>>>>
>>>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>>>> Hello everyone,
>>>>>>>>
>>>>>>>> This is a quick update to the previous webrev:
>>>>>>>>
>>>>>>>> * When using the form of engineInit that does only takes op, 
>>>>>>>> key and random, the nonce will always be random even if the 
>>>>>>>> random parameter is null.? A default instance of SecureRandom 
>>>>>>>> will be used to create the nonce in this case, instead of all 
>>>>>>>> zeroes.
>>>>>>>>
>>>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>>>
>>>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>>>> separator from a System property directly. It calls 
>>>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> --Jamil
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>>>> the ciphers are listed below.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> --Jamil
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>



From weijun.wang at oracle.com  Wed May  9 00:29:03 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 9 May 2018 08:29:03 +0800
Subject: RFR Update JarSigning.keystore
Message-ID: <2BA39EC3-DD65-4CBD-A745-3C485F315E2C@oracle.com>

test/jdk/sun/security/tools/jarsigner/JarSigning.keystore is still using 512-bit DSA and it's disabled in jar signing now.

I just updated it and added a README.

diff --git a/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README b/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README
new file mode 100644
--- /dev/null
+++ b/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README
@@ -0,0 +1,5 @@
+#JarSigning.keystore is generated with
+
+rm JarSigning.keystore
+keytool -genkeypair -keystore JarSigning.keystore -storepass bbbbbb -keypass bbbbbb -alias b -dname CN=b -keyalg DSA
+keytool -genkeypair -keystore JarSigning.keystore -storepass bbbbbb -keypass bbbbbb -alias c -dname CN=c -keyalg RSA

bugs.openjdk.java.net is down for maintenance and I will file a bug later.

Running tier1+tier2 now...

Thanks
Max



From xuelei.fan at oracle.com  Wed May  9 00:36:01 2018
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 8 May 2018 17:36:01 -0700
Subject: RFR Update JarSigning.keystore
In-Reply-To: <2BA39EC3-DD65-4CBD-A745-3C485F315E2C@oracle.com>
References: <2BA39EC3-DD65-4CBD-A745-3C485F315E2C@oracle.com>
Message-ID: <31a8ff7f-3a56-6211-7d14-697897480fdc@oracle.com>

Looks fine to me.

BTW, does it make sense to support more signature algorithms other than 
DSA and RSA?

Thanks,
Xuelei

On 5/8/2018 5:29 PM, Weijun Wang wrote:
> test/jdk/sun/security/tools/jarsigner/JarSigning.keystore is still using 512-bit DSA and it's disabled in jar signing now.
> 
> I just updated it and added a README.
> 
> diff --git a/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README b/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README
> new file mode 100644
> --- /dev/null
> +++ b/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README
> @@ -0,0 +1,5 @@
> +#JarSigning.keystore is generated with
> +
> +rm JarSigning.keystore
> +keytool -genkeypair -keystore JarSigning.keystore -storepass bbbbbb -keypass bbbbbb -alias b -dname CN=b -keyalg DSA
> +keytool -genkeypair -keystore JarSigning.keystore -storepass bbbbbb -keypass bbbbbb -alias c -dname CN=c -keyalg RSA
> 
> bugs.openjdk.java.net is down for maintenance and I will file a bug later.
> 
> Running tier1+tier2 now...
> 
> Thanks
> Max
> 


From weijun.wang at oracle.com  Wed May  9 00:39:31 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 9 May 2018 08:39:31 +0800
Subject: RFR Update JarSigning.keystore
In-Reply-To: <31a8ff7f-3a56-6211-7d14-697897480fdc@oracle.com>
References: <2BA39EC3-DD65-4CBD-A745-3C485F315E2C@oracle.com>
 <31a8ff7f-3a56-6211-7d14-697897480fdc@oracle.com>
Message-ID: 



> On May 9, 2018, at 8:36 AM, Xuelei Fan  wrote:
> 
> Looks fine to me.
> 
> BTW, does it make sense to support more signature algorithms other than DSA and RSA?

Most modern tests generate key/cert pairs inside the test (because we don't like binary files). This file is used by old tests and some tests outside java security.

That said, I'm happy to add a new entry "d" for EC. Whoever likes EC can use it.

Thanks
Max

> 
> Thanks,
> Xuelei
> 
> On 5/8/2018 5:29 PM, Weijun Wang wrote:
>> test/jdk/sun/security/tools/jarsigner/JarSigning.keystore is still using 512-bit DSA and it's disabled in jar signing now.
>> I just updated it and added a README.
>> diff --git a/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README b/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README
>> new file mode 100644
>> --- /dev/null
>> +++ b/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README
>> @@ -0,0 +1,5 @@
>> +#JarSigning.keystore is generated with
>> +
>> +rm JarSigning.keystore
>> +keytool -genkeypair -keystore JarSigning.keystore -storepass bbbbbb -keypass bbbbbb -alias b -dname CN=b -keyalg DSA
>> +keytool -genkeypair -keystore JarSigning.keystore -storepass bbbbbb -keypass bbbbbb -alias c -dname CN=c -keyalg RSA
>> bugs.openjdk.java.net is down for maintenance and I will file a bug later.
>> Running tier1+tier2 now...
>> Thanks
>> Max



From xuelei.fan at oracle.com  Wed May  9 01:09:40 2018
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Tue, 8 May 2018 18:09:40 -0700
Subject: RFR Update JarSigning.keystore
In-Reply-To: 
References: <2BA39EC3-DD65-4CBD-A745-3C485F315E2C@oracle.com>
 <31a8ff7f-3a56-6211-7d14-697897480fdc@oracle.com>
 
Message-ID: <4464fdd6-127a-cf6a-7dd7-a22f85cd488e@oracle.com>

On 5/8/2018 5:39 PM, Weijun Wang wrote:
> 
> 
>> On May 9, 2018, at 8:36 AM, Xuelei Fan  wrote:
>>
>> Looks fine to me.
>>
>> BTW, does it make sense to support more signature algorithms other than DSA and RSA?
> 
> Most modern tests generate key/cert pairs inside the test (because we don't like binary files). This file is used by old tests and some tests outside java security.
> 
OK. Then it is sufficient.

Thanks,
Xuelei

> That said, I'm happy to add a new entry "d" for EC. Whoever likes EC can use it.
> 
> Thanks
> Max
> 
>>
>> Thanks,
>> Xuelei
>>
>> On 5/8/2018 5:29 PM, Weijun Wang wrote:
>>> test/jdk/sun/security/tools/jarsigner/JarSigning.keystore is still using 512-bit DSA and it's disabled in jar signing now.
>>> I just updated it and added a README.
>>> diff --git a/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README b/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README
>>> new file mode 100644
>>> --- /dev/null
>>> +++ b/test/jdk/sun/security/tools/jarsigner/JarSigning.keystore.README
>>> @@ -0,0 +1,5 @@
>>> +#JarSigning.keystore is generated with
>>> +
>>> +rm JarSigning.keystore
>>> +keytool -genkeypair -keystore JarSigning.keystore -storepass bbbbbb -keypass bbbbbb -alias b -dname CN=b -keyalg DSA
>>> +keytool -genkeypair -keystore JarSigning.keystore -storepass bbbbbb -keypass bbbbbb -alias c -dname CN=c -keyalg RSA
>>> bugs.openjdk.java.net is down for maintenance and I will file a bug later.
>>> Running tier1+tier2 now...
>>> Thanks
>>> Max
> 


From weijun.wang at oracle.com  Wed May  9 10:06:16 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 9 May 2018 18:06:16 +0800
Subject: RFR CSR 8202590: Customizing the generation of a PKCS12 keystore
In-Reply-To: <2060f656-9a05-90d1-3426-fe4719cfff71@comcast.net>
References: <253F0053-D087-4B8B-BAAA-07C4FD8B61FF@oracle.com>
 <2060f656-9a05-90d1-3426-fe4719cfff71@comcast.net>
Message-ID: <1B882230-5EC7-4E57-9CEA-98CD06230C64@oracle.com>

Hi Mike

Your comments make sense. However,

1. I don't think it's easy in JDK to break a PBE algorithm into PBKDF + Cipher. For example, I cannot create a SecretKey from SecretKeyFactory.getInstance("PBEWithSHA1AndDESede") and use it to init a Cipher.getInstance("DESede"). I still have to use Cipher.getInstance("PBEWithSHA1AndDESede").

2. If I read correctly, MacData in pkcs12 (https://tools.ietf.org/html/rfc7292#page-11) always uses the old style KDF (https://tools.ietf.org/html/rfc7292#appendix-B). If we have a "pbkdf" setting, it might mislead a user to believe it's also used by MacData generation.

I looked at openssl and it also has independent -certpbe and -keypbe.

Also, setting multiple algorithms with a preference order might not be what we wish for. The choice of algorithms is first about security and second about interoperability. By assigning *only* one algorithm for each usage, we are clear what the default algorithms are. For example, Oracle's JDK release will set them to match our crypto roadmap. Or, an application vendor or system administrator can choose their algorithms if it can be guaranteed that all parties using the application or inside a certain enterprise support the algorithms.

Thanks
Max

> On May 5, 2018, at 10:50 PM, Michael StJohns  wrote:
> 
> On 5/5/2018 3:38 AM, Weijun Wang wrote:
>> Please take a review of
>> 
>>    
>> https://bugs.openjdk.java.net/browse/JDK-8202590
>> 
>> 
>> This enhancement has two major purposes:
>> 
>> 1. Provide a way to change encryption and Mac algorithms used in PKCS 12.
>> 
>> 2. The ability to create a password-less PKCS 12 keystore containing unencrypted certificates and no Mac.
>> 
>> Especially, the long paragraph in the spec on behavior of an existing keystore makes sure that once a password-less keystore is generated (with -Dkeystore.pkcs12.certProtectionAlgorithm=NONE and -Dkeystore.pkcs12.macAlgorithm=NONE), one can add new certificates to it without any special setting and keep it password-less.
>> 
>> Thanks
>> Max
>> 
>> 
> 
> I think you want to break this into two parts - the first part specifies the algorithm used to convert a password into key material. The second defines the algorithms used for protection for the various parts.
> # password to key material scheme
> .pbkdf=PBKDF2withHMAC-SHA256  (Form is base function with the PRF)
> # PKCS12 macData
> .macAlgorithm=HMAC-SHA256  # this is the algorithm for the PKCS12 macData component, if NONE, this component is not present
> # protection scheme for PKCS8ShroudedKeyBagn if NONE, then a PKCS8KeyBag is produced instead.
> .keyProtectionAlgorithm=AES-KWA 
> #protection scheme for certificates - produces an encryptedData object encrypted under the scheme, or a certBag object if "NONE" is specified
> .certProtectionAlgorithm=NONE
> 
> 
> Second, you probably want to do this as multi-choice entries in the java.security file ala providers:
> 
> .pbkdf.0=PBKDF2withSHA256
> .pbkdf.9=PBKDF1withSHA1 # the current default aka pbe
> 
> So that you can specify a somewhat secure default, but still allow for providers that don't implement the stronger versions.
> 
> This requires a bit more work in figuring out what the embedded OIDs should be, and there is always the chance of mismatch, but it turns out there is the chance of mismatch even in the proposed version if you have protection algorithms coming from two different PBE schemes.
> 
> Specifying it this way is closer to the PKCS5 2.0 model rather than PKCS12 and matches the recommendations in the IETF's version of PKCS12.  You also *really* don't want to use two different KDFs with the same password.
> 
> Mike
> 
> 
> 
> 



From valerie.peng at oracle.com  Wed May  9 23:45:51 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 9 May 2018 16:45:51 -0700
Subject: RFR 6913047: SunPKCS11 memory leak
In-Reply-To: 
References: 
 
 
Message-ID: 


Thanks for the update, there are still some build problems due to 
compiler warnings/errors.

Perhaps https://wiki.openjdk.java.net/display/Build/Submit+Repo and 
https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms 
would help?

Regards,
Valerie

On 5/2/2018 4:50 PM, Martin Balao wrote:
> Minor update (webrev 06):
>
> ?* Rebased to cece972575ac [1] (latest JDK revision today)
> ?* Compiler warnings fixed
>
> ?* 
> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.06/ 
> 
> ?* 
> http://cr.openjdk.java.net/~mbalao/webrevs/6913047/6913047.webrev.06.zip 
> 
>
> Kind regards,
> Martin.-
>
> --
> [1] - http://hg.openjdk.java.net/jdk/jdk/rev/cece972575ac 
> 
>
> On Thu, Oct 12, 2017 at 10:00 AM, Martin Balao  > wrote:
>
>     Webrev 04 uploaded to cr.openjdk.java.net
>     :
>
>     ?*
>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6913047/webrev.04/
>     ?(browse
>     online)
>     ?*
>     http://cr.openjdk.java.net/~sgehwolf/webrevs/mbalaoal/JDK-6913047/webrev.04/6913047.webrev.04.zip
>     ?(download)
>
>     On Wed, Oct 11, 2017 at 10:31 AM, Martin Balao      > wrote:
>
>         Hi,
>
>         I'd like to propose a fix for bug JDK-6913047: "Long term
>         memory leak when using PKCS11 and JCE exceeds 32 bit process
>         address space" [1]. This fix does not contain changes in the
>         GC and is SunPKCS11 internal only.
>
>         PROBLEM
>         ........................................................
>
>         When using the SunPKCS11 crypto provider (for cipher,
>         signature, mac, key generation or any other operation),
>         multiple key objects may be created. I.e.: every time a TLS
>         session is established, a unique master key (derived from the
>         pre-master-key) has to be created and then used for encryption
>         and decryption operations. This is a legitimate use case in
>         which key caching does not make sense as each key is unique
>         per session. These keys are of P11Key type and have a
>         corresponding native key object created. In the case of NSS
>         SunPKCS11 backend (PKCS11 software token), this native key
>         object is temporarily stored in the process native heap. The
>         interface is simple: a JNI call is done to create a native key
>         object (C_CreateObject, C_CopyObject, C_DeriveKey,
>         C_GenerateKeys, etc., according to the PKCS11 interface) and
>         an integer handler is kept in the Java side (P11Key). When the
>         P11Key object is destroyed, a finalizer code is executed to
>         free the native key object (through C_DestroyObject JNI call).
>         The problem is that finalizer code execution happens only if
>         the JVM garbage-collector cleans up the P11Key object. That
>         may be delayed or not done at all, depending on different GC
>         algorithms, parameters and environment conditions. As a
>         result, the native heap may be exhausted with not freed native
>         key objects, and the JVM will then crash -this is particularly
>         true for 32 bits VMs where the virtual address space can be
>         exhausted-.
>
>
>         SCOPE
>         ........................................................
>
>         The fix is proposed for SunPKCS11 with NSS backend only. Other
>         PKCS11 backends are not currently under scope. It's likely
>         that hardware PKCS11 backends store native key objects in
>         their own memory, preventing a native heap exhaustion and a
>         JVM crash. However, it might be possible to cause an
>         exhaustion on their own memory blocking key objects creation
>         at some point. In any case, this is speculative as no tests
>         were done on our side with real hardware.
>
>
>         SOLUTION
>         ........................................................
>
>         Assuming that native keys are extractable, the idea is to hold
>         native key data in the Java heap while keys are not in use.
>         When a P11Key is created, every CK_ATTRIBUTE (PKCS11) value
>         for the native key is queried, data stored in an opaque Java
>         byte[] (inside the P11Key object) and native key destroyed.
>         Every time the P11Key is about to be used, the native key is
>         created with the stored data. After usage, the native key is
>         again destroyed. Thus, it's not necessary to wait for a
>         finalizer execution to cleanup native resources: cleanup is
>         done at deterministic and previously-known points. This comes
>         with a resposibility for key users -which are all SunPKCS11
>         internal services like P11Signature, P11Cipher,
>         P11KeyGenerator, etc.-: create and destroy native keys through
>         a reference counting scheme exposed by P11Key class. There are
>         two kind of usages:
>
>         ?1) stateless: the native key is "atomically" created, used
>         and destroyed. I.e.: MAC calculation, getEncodedInternal
>         operation (on P11Key objects), signature operations, TLS key
>         derivation, etc.
>
>         ?2) statefull: the native key is created, one or multiple
>         intermediate actions are performed by the key user, a final
>         action is performed and finally the native key is destroyed.
>         I.e.: cipher operations.
>
>         For keys that are extractable but sensitive (CKA_SENSITIVE
>         attribute is true), as the case when operating in FIPS mode,
>         wrapping/unwrapping is used as a workaround to extract session
>         keys. Wrapper key is global and lives forever.
>
>         There are no interface changes for SunPKCS11 external users.
>
>         If keys are not extractable or the feature cannot be enabled
>         for any other reason, the previous finalizer scheme is used as
>         a fallback.
>
>
>         ADDITIONAL IMPLEMENTATION NOTES
>         ........................................................
>
>         When a P11Key is created, a constructor parameter exists to
>         indicate if the feature is enabled for that specific key. For
>         this feature to be enabled, 2 additional conditions apply: 1)
>         SunPKCS11 backend has to be NSS, and 2) key has to be
>         extractable. If the feature is not enabled for a key, behavior
>         is as previous to this patch (native key destruction relies on
>         finalizer execution).
>
>         The only P11Key user that explicitly does not use this feature
>         is P11KeyStore. This is because these keys (token keys) are
>         managed by alias names and makes no sense to remove them from
>         the key store (they need to be accessible by an alias at any
>         time).
>
>         Because P11Key objects can be used by multiple threads at a
>         time, there is a thread-safe reference counting scheme in
>         order to decide when a native key object has to be created or
>         destroyed. The SunPKCS11 internal API to use a P11Key is as
>         follows: 1) increment the reference counter (which will
>         eventually create the native key object if it doesn't exist),
>         2) use the key and 3) decrement the reference counter (which
>         will eventually destroy the native key if there it's not being
>         used by anyone else).
>
>         The reason why an opaque byte[] is used in P11Key objects to
>         store native keys data (instead of a CK_ATTRIBUTE[] Java
>         objects, queried by Java's C_GetAttributeValue function) is
>         performance. My prototypes show a difference of 4x in speed. 2
>         functions were added to libj2pkcs11 library: getNativeKeyInfo
>         (to extract the opaque byte[] from a native key object) and
>         createNativeKey (to create a native key object from an opaque
>         byte[]).
>
>
>         CHANGESET
>         ........................................................
>
>         This changeset is JDK-10 (at jdk c8796a577885 rev) based:
>
>         ?*
>         http://people.redhat.com/mbalaoal/webrevs/jdk_6913047_sunpkcs11_nss_memory_leak/2017_10_06/6913047.webrev.04/
>         
>         (browse online)
>         ?*
>         http://people.redhat.com/mbalaoal/webrevs/jdk_6913047_sunpkcs11_nss_memory_leak/2017_10_06/6913047.webrev.04.zip
>         
>         (download)
>
>
>         TESTING
>         ........................................................
>
>         Test suite for 32 bits JVMs only:
>         http://people.redhat.com/mbalaoal/webrevs/jdk_6913047_sunpkcs11_nss_memory_leak/2017_10_06/Bug6913047.java
>         
>
>         ?* Suite (Bug6913047.java)
>         ? * Tests JVM memory exhaustion while using keys for different
>         services: P11Cipher, P11Signature, P11KeyAgreement, P11Mac,
>         P11Digest, P11KeyGenerator, P11KeyFactory, etc.
>         ? * Tests functional regression.
>         ? ?* Including Key Stores (P11KeyStore)
>
>         Parameters to run the reproducer (on JDK-10):
>         ?* javac: --add-modules jdk.crypto.cryptoki --add-exports
>         java.base/sun.security.internal.spec=ALL-UNNAMED
>         ?* java: -XX:+UseParallelGC -Xmx3500m --add-modules
>         jdk.crypto.cryptoki --add-opens
>         java.base/javax.crypto=ALL-UNNAMED --add-opens
>         jdk.crypto.cryptoki/sun.security.pkcs11=ALL-UNNAMED
>
>         You can also use jtreg.
>
>
>         PERFORMANCE
>         ........................................................
>
>         For a quick reproducer previously developed (which looped
>         100000 times creating P11Cipher and P11Key objects to encrypt
>         a plaintext), these are the figures I got:
>
>         ?* real 1m11.328s (without fix)
>         ?* real 1m12.795s (with fix)
>
>         Performance penalty seems to be low in current state.
>
>         OTHER
>         .......................................................
>
>         My employer has an OCA agreement with Oracle and this work has
>         been done in that context.
>
>         Look forward to your comments.
>
>         Kind regards,
>         Martin.-
>
>         --
>         [1] - https://bugs.openjdk.java.net/browse/JDK-6913047
>         
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From valerie.peng at oracle.com  Thu May 10 21:40:36 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 10 May 2018 14:40:36 -0700
Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm
 as in PKCS#1 v2.2"
In-Reply-To: <135a4983-bc68-d30a-1f11-0faf13360ec6@oracle.com>
References: 
 <52626728-e4cd-c8d9-d2d1-3951737d992a@oracle.com>
 <77185686-9640-ed7d-a30d-d8651fd6c280@oracle.com>
 
 <0260adcb-b2b0-61e0-d689-31e0db28a161@oracle.com>
 <135a4983-bc68-d30a-1f11-0faf13360ec6@oracle.com>
Message-ID: 


Webrev has been updated with review comments from Sean and Brad:
http://cr.openjdk.java.net/~valeriep/8146293/webrev.03/

Ran through Mach5, things look good.
Thanks,
Valerie

On 5/3/2018 3:55 PM, Bradford Wetmore wrote:
>
>> I have incorporated your comments into the webrev but I am still not 
>> done with it yet due to name switch from RSA-PSS to RSASSA-PSS.
>> Will send out another email once webrev is updated.
>
> Thanks, looking forward to it.
>
>> On 4/30/2018 6:07 PM, Bradford Wetmore wrote:
>>>>> PSSParameterSpec.java
>>>>> ---------------------
>>>>> Maybe add trailerFieldBC(1)?
>>>> Not sure what do u want me to add. A constants for TrailerFieldBC, 
>>>> or else?
>>>
>>> Yes that was my thought.? A constant field for TrailerFieldBC. When 
>>> I was trying to construct a PSSParameterSpec, the integer value to 
>>> use is "1", but if you don't read ASN.1 well enough, one might be 
>>> tempted to pass "0xbc" instead.? If you weren't using DEFAULT, the 
>>> call would be like this:
>>>
>>> ??????? PSSParameterSpec pssSpec = new PSSParameterSpec(
>>> ??????????????? "SHA-256", "MGF1", MGF1ParameterSpec.SHA256, 20, 1);
>>> ->
>>> ??????? PSSParameterSpec pssSpec = new PSSParameterSpec(
>>> ??????????????? "SHA-256", "MGF1", MGF1ParameterSpec.SHA256, 20,
>>> ??????????????? PSSParameterSpec.trailerBC);
>>>
>> I added TRAILER_FIELD_BC constant for this as constant names are 
>> generally all upper case. Not too pretty and would welcome suggestions.
>
> Egads, that was a DWIMNWIS[1] move.? Yes, needs to be cap'd of course. :)
>
> [1] https://www.urbandictionary.com/define.php?term=dwimnwis
>
> Thanks for considering.
>
>>> java.base/.../java/security/SignedObject.java
>>> ---------------------------------------------
>>> 59:? In the javadoc, it looks like there is a missing opening brace 
>>> that isn't closed with the one at line 64.? However, the one at line 
>>> 64 is not showing up in the generated output either. Weird.
>> I think the {@ on line 59 pairs up with the } on line 64. Everything 
>> in between is shown as code.
>
> Oops, that is the closing brace for the @code on line 57.
>
> One more minor nit?? Can you add braces around the so.verify "if" arm:
>
> ?if (so.verify(verificationKey, verificationParams, verificationEngine))
> ...deleted...
> ->
> ?if (so.verify(verificationKey, verificationParams, 
> verificationEngine)) {
> ???? try {
> ???????? Object myobj = so.getObject();
> ???? } catch (java.lang.ClassNotFoundException e) {};
> ???? try {
> ???????? Object myobj = so.getObject();
> ???? } catch (java.lang.ClassNotFoundException e) {};
> }
>
>>> 173: Exactly the same wording here as the previous constructor. 
>>> Should we endeavor to make them different?
>> The wordings look different to me. The former one explicitly states 
>> that no signature parameters is used.
>
> In your other new constructors (e.g. 
> RSAPrivateKeySpec.java/RSAPublicKeySpec.java), your new opening 
> sentence called out the difference, but this one didn't.? Just 
> wondering if you wanted to make it consistent.? I'm ok either way.
>
>>> java.base/.../java/security/spec/RSAMultiPrimePrivateCrtKeySpec.java
>>> --------------------------------------------------------------------
>>> A general nit throughout your APIs, when you're doing multi-line 
>>> things for your @params/@return/@exception, usually should be 
>>> indented to help readability of the source.
>> Alright, I will try to add indentation to improve readability to the 
>> part that I touched.
>
> Thanks.? It bothers me just enough to notice it, but understand why we 
> don't want to go through our javadocs just for this kind of change. 
> Kinda wish it was on the technical debt list, but plenty of other 
> things to do!? :)
>
>>> java.base/.../javax/crypto/Cipher.java
>>> --------------------------------------
>>> If we go with RSA-PSS or RSASSA-PSS, do you still need this change?
>> Yes, this change is for supporting OAEPwithandMGF1Paddong now 
>> that we added support for SHA512/224 and SHA512/256.
>
> Oh, of course.? Thanks.
>
>>> 448-: I appreciated the comments.? When people come up with their 
>>> own optimizations of a relatively straightforward algorithm, it can 
>>> be confusing to follow.? I'm guessing you're not going to be 
>>> checking for input limitations?? (i.e. step 1)? A few more comments 
>>> to help map the RFC to your code would be good, especially in the 
>>> verify/decode. e.g. 536-558.
>> I will add some more comments on this.
>
> Thanks.
>
> Brad
>



From mstjohns at comcast.net  Fri May 11 15:47:19 2018
From: mstjohns at comcast.net (Michael StJohns)
Date: Fri, 11 May 2018 11:47:19 -0400
Subject: RFR CSR 8202590: Customizing the generation of a PKCS12 keystore
In-Reply-To: <1B882230-5EC7-4E57-9CEA-98CD06230C64@oracle.com>
References: <253F0053-D087-4B8B-BAAA-07C4FD8B61FF@oracle.com>
 <2060f656-9a05-90d1-3426-fe4719cfff71@comcast.net>
 <1B882230-5EC7-4E57-9CEA-98CD06230C64@oracle.com>
Message-ID: <58d56848-6c02-918f-a69d-0f4812c4c697@comcast.net>

On 5/9/2018 6:06 AM, Weijun Wang wrote:
> Hi Mike
>
> Your comments make sense. However,
>
> 1. I don't think it's easy in JDK to break a PBE algorithm into PBKDF + Cipher. For example, I cannot create a SecretKey from SecretKeyFactory.getInstance("PBEWithSHA1AndDESede") and use it to init a Cipher.getInstance("DESede"). I still have to use Cipher.getInstance("PBEWithSHA1AndDESede").

No - you'd instantiate a KDF using PBE, derive the secret key from the 
password, and use it with DESede.?? Right now, you're hiding a KDF under 
the cover of turning a secret key spec into a secret key.

And right now, all of this is actually hidden under the KeyStore 
covers.??? If you're going to use compound algorithm names, what I'd 
rather do is

    KeyStore ks = KeyStore.getInstance("PKCS12/PBKDF2/HMAC-SHA256/AES-KW");

Or? ///

And have the generic KeyStore.getInstance("PKCS12")? return what you 
specify in the preferences, or a general parser for things you're 
reading in.


>
> 2. If I read correctly, MacData in pkcs12 (https://tools.ietf.org/html/rfc7292#page-11) always uses the old style KDF (https://tools.ietf.org/html/rfc7292#appendix-B). If we have a "pbkdf" setting, it might mislead a user to believe it's also used by MacData generation.

You are - unfortunately - correct that Appendix B is still used for the 
KDF for macdata keys.? That appears to be a bug as you shouldn't be 
using the same key (password) for different algorithms and also appears 
to be a backwards compatibility item from the previous versions of 
PKCS12.? I'll ask the CFRG? what they think about it.

But I disagree with the "mislead a user".? As you note, Appendix B is 
specific that it's the only source for macdata KDFs, and you could 
include a note in the spec that this only applies to deriving data 
encryption keys rather than the macdata key.

>
> I looked at openssl and it also has independent -certpbe and -keypbe.
>
> Also, setting multiple algorithms with a preference order might not be what we wish for. The choice of algorithms is first about security and second about interoperability. By assigning *only* one algorithm for each usage, we are clear what the default algorithms are. For example, Oracle's JDK release will set them to match our crypto roadmap. Or, an application vendor or system administrator can choose their algorithms if it can be guaranteed that all parties using the application or inside a certain enterprise support the algorithms.

You've got a fair point - but I'd disagree that assigning default 
algorithms is about security, it really is about interoperability - 
making sure that the most number of people can handle the PKCS12 object 
without installing additional providers.?? But seriously,

|keystore.pkcs12.certProtectionAlgorithm = PBEWithSHA1AndRC2_40|

is not a security choice!

But, after thinking about it a bit more, the preference list isn't 
useful without additional providers - and at that point you're probably 
generating stuff by specifying algorithms and such so I agree with no 
preference list.? Could you please, please, please not use weak 
algorithms as the default here though?

>
> Thanks
> Max
>
>> On May 5, 2018, at 10:50 PM, Michael StJohns  wrote:
>>
>> On 5/5/2018 3:38 AM, Weijun Wang wrote:
>>> Please take a review of
>>>
>>>     
>>> https://bugs.openjdk.java.net/browse/JDK-8202590
>>>
>>>
>>> This enhancement has two major purposes:
>>>
>>> 1. Provide a way to change encryption and Mac algorithms used in PKCS 12.
>>>
>>> 2. The ability to create a password-less PKCS 12 keystore containing unencrypted certificates and no Mac.
>>>
>>> Especially, the long paragraph in the spec on behavior of an existing keystore makes sure that once a password-less keystore is generated (with -Dkeystore.pkcs12.certProtectionAlgorithm=NONE and -Dkeystore.pkcs12.macAlgorithm=NONE), one can add new certificates to it without any special setting and keep it password-less.
>>>
>>> Thanks
>>> Max
>>>
>>>
>> I think you want to break this into two parts - the first part specifies the algorithm used to convert a password into key material. The second defines the algorithms used for protection for the various parts.
>> # password to key material scheme
>> .pbkdf=PBKDF2withHMAC-SHA256  (Form is base function with the PRF)
>> # PKCS12 macData
>> .macAlgorithm=HMAC-SHA256  # this is the algorithm for the PKCS12 macData component, if NONE, this component is not present
>> # protection scheme for PKCS8ShroudedKeyBagn if NONE, then a PKCS8KeyBag is produced instead.
>> .keyProtectionAlgorithm=AES-KWA
>> #protection scheme for certificates - produces an encryptedData object encrypted under the scheme, or a certBag object if "NONE" is specified
>> .certProtectionAlgorithm=NONE
>>
>>
>> Second, you probably want to do this as multi-choice entries in the java.security file ala providers:
>>
>> .pbkdf.0=PBKDF2withSHA256
>> .pbkdf.9=PBKDF1withSHA1 # the current default aka pbe
>>
>> So that you can specify a somewhat secure default, but still allow for providers that don't implement the stronger versions.
>>
>> This requires a bit more work in figuring out what the embedded OIDs should be, and there is always the chance of mismatch, but it turns out there is the chance of mismatch even in the proposed version if you have protection algorithms coming from two different PBE schemes.
>>
>> Specifying it this way is closer to the PKCS5 2.0 model rather than PKCS12 and matches the recommendations in the IETF's version of PKCS12.  You also *really* don't want to use two different KDFs with the same password.
>>
>> Mike
>>
>>
>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bradford.wetmore at oracle.com  Fri May 11 23:53:11 2018
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Fri, 11 May 2018 16:53:11 -0700
Subject: Initial TLSv1.3 implementation Released to the Open Sandbox.
Message-ID: <9619e0d6-7017-4c9e-3f66-6262db5c10d7@oracle.com>


Development of the TLSv1.3 protocol has been underway within the IETF 
TLS Working Group for several years.  After 28 revisions, the resulting 
Internet-Draft [1] has finally reached the RFC Editor's Desk, and is 
close to release as an RFC.

We've also been actively working on a TLSv1.3 implementation for the 
JDK.  We've placed our work so far into the OpenJDK "open sandbox" [2] 
so that you see what's happening.  (See the Mercurial branch 
"JDK-8145252-TLS13-branch".)

If you're not familiar with OpenJDK sandbox/branches, please see Chris 
Hegarty's "JDK Sandbox Development Repository" [3].  His page provides 
details of the OpenJDK sandbox/branches, but here's a quick primer if 
you just want to get to the source quickly:

     % hg clone http://hg.openjdk.java.net/jdk/sandbox/ sandbox
     % cd sandbox
     % hg update -r JDK-8145252-TLS13-branch

The current branch includes the TLSv1.3 implementation, plus a snapshot 
of the RSASSA-PSS code [4] from PKCS#1 v2.2, which is being done under 
JDK-8190180 [5].

I've also placed a webrev on CR [6].

Please note well: this branch is under very active development and is 
not final by any means.  Also note: by releasing this code, we are not 
committing a specific release or timeframe.  We will continue 
development and fixing bugs until the code is ready for inclusion in the 
JDK.

Have a look around, and of course, we welcome your feedback.

Thanks,
Brad

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/
[2] http://hg.openjdk.java.net/jdk/sandbox/
[3] http://cr.openjdk.java.net/~chegar/docs/sandbox.html
[4] http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017137.html
[5] https://bugs.openjdk.java.net/browse/JDK-8190180
[6] http://cr.openjdk.java.net/~wetmore/8145252/



From valerie.peng at oracle.com  Mon May 14 20:20:56 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 14 May 2018 13:20:56 -0700
Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm
 as in PKCS#1 v2.2"
In-Reply-To: 
References: 
Message-ID: <4d09005b-df60-00a8-0bdb-c65dbc8f40bf@oracle.com>

Hi Brad,

The latest webrev is at 
http://cr.openjdk.java.net/~valeriep/8146293/webrev.04/
The only difference between webrev.03 and webrev.04 is the review 
comments from the CSR.
Thanks,
Valerie

On 3/27/2018 6:40 PM, Valerie Peng wrote:
> Hi Brad,
>
> Can you please help review the changes for RSA-PSS support? I also 
> added some minor enhancement which add 2 more digest algorithms for 
> OAEP padding.
> There are quite some changes involved. The main changes are in the 
> SunRsaSign provider, i.e. sun.security.rsa packages. I reused existing 
> RSAKeyFactory, RSAKeyPairGenerator, and the RSA KeyImpl classes as 
> much as possible. However, given that RSA-PSS signatures requires 
> parameters, I put its implementation in a separate class, i.e. 
> RSAPSSSignature.java.
>
> RFE: https://bugs.openjdk.java.net/browse/JDK-8146293
> Webrev: http://cr.openjdk.java.net/~valeriep/8146293/webrev.00/
>
> Existing and new regression tests have been run and result looks fine.
> Thanks,
> Valerie



From mbalao at redhat.com  Mon May 14 22:25:13 2018
From: mbalao at redhat.com (Martin Balao)
Date: Mon, 14 May 2018 19:25:13 -0300
Subject: [RFR]: JDK-8203182 - Release session if initialization of SunPKCS11
 Signature fails
Message-ID: 

Hi,

Can I have a review for "JDK-8203182 - Release session if initialization of
SunPKCS11 Signature fails" [1]?

 * http://cr.openjdk.java.net/~mbalao/webrevs/8203182/8203182.webrev.00/
 * http://cr.openjdk.java.net/~mbalao/webrevs/8203182/8203182.webrev.00.zip

Thanks in advanced!

Martin.-

--
[1] - https://bugs.openjdk.java.net/browse/JDK-8203182
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From valerie.peng at oracle.com  Mon May 14 23:58:17 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 14 May 2018 16:58:17 -0700
Subject: RFR 8201867: Kerberos keytabs with holes in certain places are
 parsed incorrectly
In-Reply-To: <75DD716E-82A1-4160-A057-90735DC38147@oracle.com>
References: <75DD716E-82A1-4160-A057-90735DC38147@oracle.com>
Message-ID: <9427145a-7642-a6a1-d8af-fa5643b39a88@oracle.com>


I will take a look in a day or two if no one else get to it.

Valerie


On 4/24/2018 7:42 AM, Weijun Wang wrote:
> Please take a review at
>
>    http://cr.openjdk.java.net/~weijun/8201867/webrev.00/
>
> When the hole in keytab is right on the 8192 buffer boundary, skip(n) does not return n.
>
> I are not sure if I can do something like "while (i < n) i += skip(n)" because skip(n) can return zero and it does not understand EOF. Therefore I readNBytes(n) and discard the result. If you have a better solution, I'll be happy to know.
>
> Thanks
> Max
>



From valerie.peng at oracle.com  Tue May 15 00:32:15 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 14 May 2018 17:32:15 -0700
Subject: RFR (+CSR) 8201627: Kerberos sequence number issues
In-Reply-To: <10F790B3-6E30-486D-83F5-74963185A455@oracle.com>
References: 
 <7350da42-2c10-efc2-f1a2-e8b858ecce13@oracle.com>
 <082D896A-99EA-4E53-97A6-75FB2A6F8C26@oracle.com>
 <3AD821A8-8514-4D43-A9EE-360C9C03140D@oracle.com>
 <11172315-AA49-4B07-8846-674D8B644EB7@oracle.com>
 <1220F98D-A15B-499A-BE38-A5B544AD1DF7@oracle.com>
 
 <10F790B3-6E30-486D-83F5-74963185A455@oracle.com>
Message-ID: <2390192f-a076-ece2-6f37-72f81f80acde@oracle.com>

Hi Max,

I think it'd be clearer to mention default behavior first and then 
mention the system property for overriding it if necessary. Something 
like following:

When mutual auth is not requested by the Kerberos 5 initiator, there is 
no way to negotiate acceptor's initial sequence number. With this fix, 
the SunJGSS provider will use initiator's initial sequence number as the 
initial sequence number. To override this default behavior and to use 0 
instead, please set the system property 
"sun.security.krb5.acceptor.sequence.number.nonmutual" to "zero" or "0". 
Values other than "initiator", "zero", and "0" are illegal".

Maybe it'd also be nice to mention how the illegal values are handled, 
i.e. ignored, exception thrown, etc.

Valerie


On 5/4/2018 10:53 PM, Weijun Wang wrote:
> Hi Valerie
>
> Can you also review the release note at https://bugs.openjdk.java.net/browse/JDK-8202681?
>
> Thanks
> Max
>
>
>> On Apr 27, 2018, at 5:58 AM, Valerie Peng  wrote:
>>
>> Sure, should be fine...
>> Valerie
>>
>> On 4/25/2018 9:48 PM, Weijun Wang wrote:
>>> I filed https://bugs.openjdk.java.net/browse/JDK-8202300 but might not have time to make it into JDK 11.
>>>
>>> --Max
>>>
>>>> On Apr 26, 2018, at 12:06 AM, Weijun Wang  wrote:
>>>>
>>>> I'll keep using int32 (at least in this fix), both Java and MIT krb5 contain these words
>>>>
>>>> * Workaround implementation incompatibilities by not generating
>>>> * initial sequence numbers greater than 2^30
>>>>
>>>> So bad thing could only happen after 2^30 messages.
>>>>
>>>> --Max
>>>>
>>>>> On Apr 25, 2018, at 10:38 PM, Weijun Wang  wrote:
>>>>>
>>>>> It's complicated. Looks like MIT krb5 uses a uint32 for old etypes (DES, 3DES, RC4) and a uint64 for new ones (AES) [1][2].
>>>>>
>>>>> I'll do more experiments.
>>>>>
>>>>> Thanks
>>>>> Max
>>>>>
>>>>> [1] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/util_seqstate.c#L76
>>>>> [2] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/krb5/init_sec_context.c#L825
>>>>>
>>>>>> On Apr 24, 2018, at 8:55 PM, Wang Weijun  wrote:
>>>>>>
>>>>>> RFC 4120 5.5.1 has
>>>>>>> seq-number
>>>>>>> This optional field includes the initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to detect replays. (It may also be used by application specific messages.) When included in the authenticator, this field specifies the initial sequence number for messages from the client to the server. When included in the AP-REP message, the initial sequence number is that for messages from the server to the client. When used in KRB_PRIV or KRB_SAFE messages, it is incremented by one after each message is sent. Sequence numbers fall in the range 0 through 2^32 - 1 and wrap to zero following the value 2^32 - 1.
>>>>>> If it wraps, then it?s 4 bytes.
>>>>>>
>>>>>> I will read more on it.
>>>>>>
>>>>>> Thanks
>>>>>> Max
>>>>>>
>>>>>>> ? 2018?4?24??18:08?Valerie Peng  ???
>>>>>>>
>>>>>>> Hi Max,
>>>>>>>
>>>>>>> Most changes look good. I have only some comments and questions (see below):
>>>>>>>
>>>>>>> - InitSecContextToken.java, line 62: bad -> unrecognized?
>>>>>>> - According to the class javadoc of various Token classes and Kerberos spec, the sequence number is 8-byte integer from header byte 8-15, but java int have only 4 bytes. The current code seems to assume the first 4 bytes of the sequence number are always 0. For the sake of compliance and max inter-operability, maybe we should use long to store the sequence number?
>>>>>>>
>>>>>>> CSR looks good to me.
>>>>>>> Thanks,
>>>>>>> Valerie
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On 4/18/2018 10:40 AM, Weijun Wang wrote:
>>>>>>>> Please take a review of this fix:
>>>>>>>>
>>>>>>>> webrev: http://cr.openjdk.java.net/~weijun/8201627/webrev.00/
>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201814
>>>>>>>>
>>>>>>>> Basically we fix some bugs and introduce a system property so we can interop with everyone.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> Max
>>>>>>>>



From weijun.wang at oracle.com  Tue May 15 02:12:34 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 15 May 2018 10:12:34 +0800
Subject: RFR (+CSR) 8201627: Kerberos sequence number issues
In-Reply-To: <2390192f-a076-ece2-6f37-72f81f80acde@oracle.com>
References: 
 <7350da42-2c10-efc2-f1a2-e8b858ecce13@oracle.com>
 <082D896A-99EA-4E53-97A6-75FB2A6F8C26@oracle.com>
 <3AD821A8-8514-4D43-A9EE-360C9C03140D@oracle.com>
 <11172315-AA49-4B07-8846-674D8B644EB7@oracle.com>
 <1220F98D-A15B-499A-BE38-A5B544AD1DF7@oracle.com>
 
 <10F790B3-6E30-486D-83F5-74963185A455@oracle.com>
 <2390192f-a076-ece2-6f37-72f81f80acde@oracle.com>
Message-ID: <05075018-9996-4219-AA6C-05F090EF8BDC@oracle.com>



> On May 15, 2018, at 8:32 AM, Valerie Peng  wrote:
> 
> Hi Max,
> 
> I think it'd be clearer to mention default behavior first and then mention the system property for overriding it if necessary. Something like following:
> 
> When mutual auth is not requested by the Kerberos 5 initiator, there is no way to negotiate acceptor's initial sequence number. With this fix, the SunJGSS provider will use initiator's initial sequence number as the initial sequence number. To override this default behavior and to use 0 instead, please set the system property "sun.security.krb5.acceptor.sequence.number.nonmutual" to "zero" or "0". Values other than "initiator", "zero", and "0" are illegal".

Great.

> 
> Maybe it'd also be nice to mention how the illegal values are handled, i.e. ignored, exception thrown, etc.

An error will be thrown.

Thanks
Max

> 
> Valerie
> 
> 
> On 5/4/2018 10:53 PM, Weijun Wang wrote:
>> Hi Valerie
>> 
>> Can you also review the release note at https://bugs.openjdk.java.net/browse/JDK-8202681?
>> 
>> Thanks
>> Max
>> 
>> 
>>> On Apr 27, 2018, at 5:58 AM, Valerie Peng  wrote:
>>> 
>>> Sure, should be fine...
>>> Valerie
>>> 
>>> On 4/25/2018 9:48 PM, Weijun Wang wrote:
>>>> I filed https://bugs.openjdk.java.net/browse/JDK-8202300 but might not have time to make it into JDK 11.
>>>> 
>>>> --Max
>>>> 
>>>>> On Apr 26, 2018, at 12:06 AM, Weijun Wang  wrote:
>>>>> 
>>>>> I'll keep using int32 (at least in this fix), both Java and MIT krb5 contain these words
>>>>> 
>>>>> * Workaround implementation incompatibilities by not generating
>>>>> * initial sequence numbers greater than 2^30
>>>>> 
>>>>> So bad thing could only happen after 2^30 messages.
>>>>> 
>>>>> --Max
>>>>> 
>>>>>> On Apr 25, 2018, at 10:38 PM, Weijun Wang  wrote:
>>>>>> 
>>>>>> It's complicated. Looks like MIT krb5 uses a uint32 for old etypes (DES, 3DES, RC4) and a uint64 for new ones (AES) [1][2].
>>>>>> 
>>>>>> I'll do more experiments.
>>>>>> 
>>>>>> Thanks
>>>>>> Max
>>>>>> 
>>>>>> [1] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/generic/util_seqstate.c#L76
>>>>>> [2] https://github.com/krb5/krb5/blob/master/src/lib/gssapi/krb5/init_sec_context.c#L825
>>>>>> 
>>>>>>> On Apr 24, 2018, at 8:55 PM, Wang Weijun  wrote:
>>>>>>> 
>>>>>>> RFC 4120 5.5.1 has
>>>>>>>> seq-number
>>>>>>>> This optional field includes the initial sequence number to be used by the KRB_PRIV or KRB_SAFE messages when sequence numbers are used to detect replays. (It may also be used by application specific messages.) When included in the authenticator, this field specifies the initial sequence number for messages from the client to the server. When included in the AP-REP message, the initial sequence number is that for messages from the server to the client. When used in KRB_PRIV or KRB_SAFE messages, it is incremented by one after each message is sent. Sequence numbers fall in the range 0 through 2^32 - 1 and wrap to zero following the value 2^32 - 1.
>>>>>>> If it wraps, then it?s 4 bytes.
>>>>>>> 
>>>>>>> I will read more on it.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Max
>>>>>>> 
>>>>>>>> ? 2018?4?24??18:08?Valerie Peng  ???
>>>>>>>> 
>>>>>>>> Hi Max,
>>>>>>>> 
>>>>>>>> Most changes look good. I have only some comments and questions (see below):
>>>>>>>> 
>>>>>>>> - InitSecContextToken.java, line 62: bad -> unrecognized?
>>>>>>>> - According to the class javadoc of various Token classes and Kerberos spec, the sequence number is 8-byte integer from header byte 8-15, but java int have only 4 bytes. The current code seems to assume the first 4 bytes of the sequence number are always 0. For the sake of compliance and max inter-operability, maybe we should use long to store the sequence number?
>>>>>>>> 
>>>>>>>> CSR looks good to me.
>>>>>>>> Thanks,
>>>>>>>> Valerie
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On 4/18/2018 10:40 AM, Weijun Wang wrote:
>>>>>>>>> Please take a review of this fix:
>>>>>>>>> 
>>>>>>>>> webrev: http://cr.openjdk.java.net/~weijun/8201627/webrev.00/
>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8201814
>>>>>>>>> 
>>>>>>>>> Basically we fix some bugs and introduce a system property so we can interop with everyone.
>>>>>>>>> 
>>>>>>>>> Thanks
>>>>>>>>> Max
>>>>>>>>> 
> 



From weijun.wang at oracle.com  Tue May 15 11:26:42 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 15 May 2018 19:26:42 +0800
Subject: RFR CSR 8202590: Customizing the generation of a PKCS12 keystore
In-Reply-To: <58d56848-6c02-918f-a69d-0f4812c4c697@comcast.net>
References: <253F0053-D087-4B8B-BAAA-07C4FD8B61FF@oracle.com>
 <2060f656-9a05-90d1-3426-fe4719cfff71@comcast.net>
 <1B882230-5EC7-4E57-9CEA-98CD06230C64@oracle.com>
 <58d56848-6c02-918f-a69d-0f4812c4c697@comcast.net>
Message-ID: <8DEB0FB8-B1BC-416A-8543-40420AD82CEF@oracle.com>

Sorry, busy on something else.

> On May 11, 2018, at 11:47 PM, Michael StJohns  wrote:
> 
> On 5/9/2018 6:06 AM, Weijun Wang wrote:
>> Hi Mike
>> 
>> Your comments make sense. However,
>> 
>> 1. I don't think it's easy in JDK to break a PBE algorithm into PBKDF + Cipher. For example, I cannot create a SecretKey from SecretKeyFactory.getInstance("PBEWithSHA1AndDESede") and use it to init a Cipher.getInstance("DESede"). I still have to use Cipher.getInstance("PBEWithSHA1AndDESede").
>> 
> 
> No - you'd instantiate a KDF using PBE, derive the secret key from the password, and use it with DESede.   Right now, you're hiding a KDF under the cover of turning a secret key spec into a secret key.   

Last time I tried, SecretKeyFactory.getInstance("PBEWithSHA1AndDESede") can only generate a PBEKey (which has not been derived) and Cipher.getInstance("DESede") does not accept it. I'll take another look.

I know it's a good practice using the same PBKDF for certs and keys. Must we enforce it and not allow people to use different ones?

> 
> And right now, all of this is actually hidden under the KeyStore covers.    If you're going to use compound algorithm names, what I'd rather do is 
> 
> KeyStore ks = KeyStore.getInstance("PKCS12/PBKDF2/HMAC-SHA256/AES-KW");    
> 
> Or  ///

Big change, not this time.

> 
> And have the generic KeyStore.getInstance("PKCS12")  return what you specify in the preferences, or a general parser for things you're reading in.
> 
> 
>> ....
> 
> 
> But, after thinking about it a bit more, the preference list isn't useful without additional providers - and at that point you're probably generating stuff by specifying algorithms and such so I agree with no preference list.  Could you please, please, please not use weak algorithms as the default here though?

PBEWithHmacSHA256AndAES_128?

I'll see how other tools support it.

Thanks
Max

> 
>> 
>> Thanks
>> Max
>> 
>> 
>>> On May 5, 2018, at 10:50 PM, Michael StJohns 
>>>  wrote:
>>> 
>>> On 5/5/2018 3:38 AM, Weijun Wang wrote:
>>> 
>>>> Please take a review of
>>>> 
>>>>    
>>>> 
>>>> https://bugs.openjdk.java.net/browse/JDK-8202590
>>>> 
>>>> 
>>>> 
>>>> This enhancement has two major purposes:
>>>> 
>>>> 1. Provide a way to change encryption and Mac algorithms used in PKCS 12.
>>>> 
>>>> 2. The ability to create a password-less PKCS 12 keystore containing unencrypted certificates and no Mac.
>>>> 
>>>> Especially, the long paragraph in the spec on behavior of an existing keystore makes sure that once a password-less keystore is generated (with -Dkeystore.pkcs12.certProtectionAlgorithm=NONE and -Dkeystore.pkcs12.macAlgorithm=NONE), one can add new certificates to it without any special setting and keep it password-less.
>>>> 
>>>> Thanks
>>>> Max
>>>> 
>>>> 
>>>> 
>>> I think you want to break this into two parts - the first part specifies the algorithm used to convert a password into key material. The second defines the algorithms used for protection for the various parts.
>>> # password to key material scheme
>>> .pbkdf=PBKDF2withHMAC-SHA256  (Form is base function with the PRF)
>>> # PKCS12 macData
>>> .macAlgorithm=HMAC-SHA256  # this is the algorithm for the PKCS12 macData component, if NONE, this component is not present
>>> # protection scheme for PKCS8ShroudedKeyBagn if NONE, then a PKCS8KeyBag is produced instead.
>>> .keyProtectionAlgorithm=AES-KWA 
>>> #protection scheme for certificates - produces an encryptedData object encrypted under the scheme, or a certBag object if "NONE" is specified
>>> .certProtectionAlgorithm=NONE
>>> 
>>> 
>>> Second, you probably want to do this as multi-choice entries in the java.security file ala providers:
>>> 
>>> .pbkdf.0=PBKDF2withSHA256
>>> .pbkdf.9=PBKDF1withSHA1 # the current default aka pbe
>>> 
>>> So that you can specify a somewhat secure default, but still allow for providers that don't implement the stronger versions.
>>> 
>>> This requires a bit more work in figuring out what the embedded OIDs should be, and there is always the chance of mismatch, but it turns out there is the chance of mismatch even in the proposed version if you have protection algorithms coming from two different PBE schemes.
>>> 
>>> Specifying it this way is closer to the PKCS5 2.0 model rather than PKCS12 and matches the recommendations in the IETF's version of PKCS12.  You also *really* don't want to use two different KDFs with the same password.
>>> 
>>> Mike
>>> 
>>> 
>>> 
>>> 
>>> 
> 



From adam.petcher at oracle.com  Tue May 15 18:42:39 2018
From: adam.petcher at oracle.com (Adam Petcher)
Date: Tue, 15 May 2018 14:42:39 -0400
Subject: RFR 8203228: Branch-free output conversion for X25519 and X448
Message-ID: 

Webrev: http://cr.openjdk.java.net/~apetcher/8203228/webrev.00/

Please review the change for this leftover task from the X25519/X448 
JEP. The current code uses BigInteger to convert the final result from a 
field element to a byte array that can be used to derive a key. Using 
branch-free operations instead of BigInteger will protect this secret 
from certain side-channel attacks.

The output conversion is done entirely by the asByteArray method of 
IntegerPolynomial, which is implemented by limbsToByteArray. For this 
change, I took the branch-free output conversion routine from the 
Poly1305 field and pushed it into the parent class. I had to generalize 
it a bit in order to deal with the peculiarities of the X25519/X448 
fields and their representations. I also made addModPowerTwo branch 
free, because this was a relatively simple change once the rest was 
done. But this method is not used by X25519/X448.

In addition to running the full regression test suite, I also ran some 
benchmarks on X25519 and X448 to confirm that performance wasn't 
impacted. Not surprising, since this method is only called once per key 
generation/agreement operation.



From valerie.peng at oracle.com  Tue May 15 22:30:54 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Tue, 15 May 2018 15:30:54 -0700
Subject: [RFR]: JDK-8203182 - Release session if initialization of
 SunPKCS11 Signature fails
In-Reply-To: 
References: 
Message-ID: 

Hi Martin,

Your fix only addresses the initialization case. Have you considered 
fixing the same problem under difference calls?

Regards,
Valerie

On 5/14/2018 3:25 PM, Martin Balao wrote:
> Hi,
>
> Can I have a review for "JDK-8203182 - Release session if 
> initialization of SunPKCS11 Signature fails" [1]?
>
> ?* 
> http://cr.openjdk.java.net/~mbalao/webrevs/8203182/8203182.webrev.00/ 
> 
> ?* 
> http://cr.openjdk.java.net/~mbalao/webrevs/8203182/8203182.webrev.00.zip 
> 
>
> Thanks in advanced!
>
> Martin.-
>
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8203182



From sean.mullan at oracle.com  Wed May 16 18:42:06 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 16 May 2018 14:42:06 -0400
Subject: RFR 8202299: Java Keystore fails to load PKCS12/PFX certificates
 created in WindowsServer2016
In-Reply-To: <0A68EB2D-D19D-4D7D-ADF8-971758D15303@oracle.com>
References: <0A68EB2D-D19D-4D7D-ADF8-971758D15303@oracle.com>
Message-ID: <575f6ca0-e115-c998-f0ea-30df7527f3bc@oracle.com>

The while(true) in PKCS12KeyStore.java seems like it isn't really 
necessary, since you are calling the code inside it at most twice. I 
think a better approach would be to move lines 2134-2146 into a utility 
method and call it again if you get an Exception and the password is empty.

Looks fine otherwise.

--Sean

On 4/27/18 12:56 PM, Weijun Wang wrote:
> Please take a look at
> 
>     http://cr.openjdk.java.net/~weijun/8202299/webrev.00/
> 
> Turns out we have to retry [0] other than [] in all 3 locations: decrypting keys, decrypting certs, and verifying the mac.
> 
> Thanks
> Max
> 
> p.s. You might wonder why suddenly in Windows Server 2016, Microsoft starts using [0] to generate the Mac. In fact, they have been doing this all the time. However, before 2016, they also encrypted the certificates, and to decrypt them, Java has already changed password from [] to [0].
> 
> p.p.s. But is this correct? Should the certificate decryption code only temporarily retries [0] but not changing password itself? Well, maybe. But unless a weird software sometimes uses [] and sometimes [0], this will not be a problem, and changing password itself saves us some cycles from always trying twice.
> 


From jamil.j.nimeh at oracle.com  Wed May 16 19:05:48 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 16 May 2018 12:05:48 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
Message-ID: 

Round 6.

This brings ChaCha20/ChaCha20-Poly1305 into conformance with Cipher's 
specification when forms of init that take AlgorithmParameters or 
AlgorithmParameterSpec are used. Previously, a non-null AP or APS object 
was required.? In order to better conform to the specification, if a 
null AP or APS is provided for these ciphers, a random nonce will be 
generated and the counter will be set to 1, just as is currently done 
with valid forms of init that don't take an AP or APS object (e.g. 
Cipher.init(int, Key, SecureRandom) ).? Per the spec in Cipher, this is 
only true for ENCRYPT_MODE and will throw InvalidKeyException when done 
in DECRYPT_MODE.

I also added a few test cases that exercise these code paths in the 
ChaCha20Poly1305Parameters.java test case.

http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/

Thanks,

--Jamil


On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>
> Round 5.
>
> This adds Sean's comments.? Sean, I was never able to execute a case 
> on init where a half-baked object would fail.? In most cases it would 
> fail in checks in javax.crypto.Cipher before it ever made it down to 
> my code.? I'm pretty confident the init sequence is OK.? I did move 
> the setting of a few data members toward the end of the init sequence 
> but setting the key and nonce is necessary before creating the initial 
> state, which is then used for generating an authentication key for 
> AEAD mode and generating keystream.
>
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>
> Also the CSR has been finalized and can be found here:
> https://bugs.openjdk.java.net/browse/JDK-8198925
>
> --Jamil
>
> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>
>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>> mostly:
>>
>>   * Added words in the description of javax.crypto.Cipher
>>     recommending callers reinitialize the Cipher to use different
>>     nonces after each complete encryption or decryption (similar
>>     language to what exists already for AES-GCM encryption).
>>   * Added an additional test case for ChaCha20NoReuse
>>   * Made accessor methods for ChaCha20ParameterSpec final and cleaned
>>     up the code a bit based on comments from the field.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>
>> Thanks!
>>
>> --Jamil
>>
>>
>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>
>>> * Removed the key field in ChaCha20 and Poly1305 implementations and 
>>> only retain the key bytes as an object field (thanks Thomas for 
>>> catching this)
>>>
>>> * Added additional protections against key/nonce reuse.? This is a 
>>> behavioral change to ChaCha20 and ChaCha20-Poly1305. Instances of 
>>> these ciphers will no longer allow you to do subsequent 
>>> doUpdate/doFinal calls after the first doFinal without 
>>> re-initializing the cipher with either a new key or nonce. 
>>> Attempting to reuse the cipher without a new initialization will 
>>> throw an IllegalStateException.? This is similar to the behavior of 
>>> AES-GCM in encrypt mode, but for ChaCha20 it needs to be done for 
>>> both encrypt and decrypt.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>
>>> Thanks,
>>> --Jamil
>>>
>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>> Hello everyone,
>>>>
>>>> This is a quick update to the previous webrev:
>>>>
>>>> * When using the form of engineInit that does only takes op, key 
>>>> and random, the nonce will always be random even if the random 
>>>> parameter is null.? A default instance of SecureRandom will be used 
>>>> to create the nonce in this case, instead of all zeroes.
>>>>
>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>
>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>> separator from a System property directly.? It calls 
>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>> classes in com.sun.crypto.provider do it.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>
>>>> Thanks,
>>>>
>>>> --Jamil
>>>>
>>>>
>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>> Hello all,
>>>>>
>>>>> This is a request for review for the ChaCha20 and 
>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev and 
>>>>> the JEP which outlines the characteristics and behavior of the 
>>>>> ciphers are listed below.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>> http://openjdk.java.net/jeps/329
>>>>>
>>>>> Thanks,
>>>>> --Jamil
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jamil.j.nimeh at oracle.com  Wed May 16 19:05:58 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 16 May 2018 12:05:58 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
Message-ID: <3dda646c-2854-cdf2-cc1b-4d2c3133d787@oracle.com>

Round 6.

This brings ChaCha20/ChaCha20-Poly1305 into conformance with Cipher's 
specification when forms of init that take AlgorithmParameters or 
AlgorithmParameterSpec are used. Previously, a non-null AP or APS object 
was required.? In order to better conform to the specification, if a 
null AP or APS is provided for these ciphers, a random nonce will be 
generated and the counter will be set to 1, just as is currently done 
with valid forms of init that don't take an AP or APS object (e.g. 
Cipher.init(int, Key, SecureRandom) ).? Per the spec in Cipher, this is 
only true for ENCRYPT_MODE and will throw InvalidKeyException when done 
in DECRYPT_MODE.

I also added a few test cases that exercise these code paths in the 
ChaCha20Poly1305Parameters.java test case.

http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/

Thanks,

--Jamil


On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>
> Round 5.
>
> This adds Sean's comments.? Sean, I was never able to execute a case 
> on init where a half-baked object would fail.? In most cases it would 
> fail in checks in javax.crypto.Cipher before it ever made it down to 
> my code.? I'm pretty confident the init sequence is OK.? I did move 
> the setting of a few data members toward the end of the init sequence 
> but setting the key and nonce is necessary before creating the initial 
> state, which is then used for generating an authentication key for 
> AEAD mode and generating keystream.
>
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>
> Also the CSR has been finalized and can be found here:
> https://bugs.openjdk.java.net/browse/JDK-8198925
>
> --Jamil
>
> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>
>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>> mostly:
>>
>>   * Added words in the description of javax.crypto.Cipher
>>     recommending callers reinitialize the Cipher to use different
>>     nonces after each complete encryption or decryption (similar
>>     language to what exists already for AES-GCM encryption).
>>   * Added an additional test case for ChaCha20NoReuse
>>   * Made accessor methods for ChaCha20ParameterSpec final and cleaned
>>     up the code a bit based on comments from the field.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>
>> Thanks!
>>
>> --Jamil
>>
>>
>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>
>>> * Removed the key field in ChaCha20 and Poly1305 implementations and 
>>> only retain the key bytes as an object field (thanks Thomas for 
>>> catching this)
>>>
>>> * Added additional protections against key/nonce reuse.? This is a 
>>> behavioral change to ChaCha20 and ChaCha20-Poly1305. Instances of 
>>> these ciphers will no longer allow you to do subsequent 
>>> doUpdate/doFinal calls after the first doFinal without 
>>> re-initializing the cipher with either a new key or nonce. 
>>> Attempting to reuse the cipher without a new initialization will 
>>> throw an IllegalStateException.? This is similar to the behavior of 
>>> AES-GCM in encrypt mode, but for ChaCha20 it needs to be done for 
>>> both encrypt and decrypt.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>
>>> Thanks,
>>> --Jamil
>>>
>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>> Hello everyone,
>>>>
>>>> This is a quick update to the previous webrev:
>>>>
>>>> * When using the form of engineInit that does only takes op, key 
>>>> and random, the nonce will always be random even if the random 
>>>> parameter is null.? A default instance of SecureRandom will be used 
>>>> to create the nonce in this case, instead of all zeroes.
>>>>
>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>
>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>> separator from a System property directly.? It calls 
>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>> classes in com.sun.crypto.provider do it.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>
>>>> Thanks,
>>>>
>>>> --Jamil
>>>>
>>>>
>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>> Hello all,
>>>>>
>>>>> This is a request for review for the ChaCha20 and 
>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev and 
>>>>> the JEP which outlines the characteristics and behavior of the 
>>>>> ciphers are listed below.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>> http://openjdk.java.net/jeps/329
>>>>>
>>>>> Thanks,
>>>>> --Jamil
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From valerie.peng at oracle.com  Wed May 16 22:43:10 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Wed, 16 May 2018 15:43:10 -0700
Subject: RFR 8201867: Kerberos keytabs with holes in certain places are
 parsed incorrectly
In-Reply-To: <75DD716E-82A1-4160-A057-90735DC38147@oracle.com>
References: <75DD716E-82A1-4160-A057-90735DC38147@oracle.com>
Message-ID: <0a342404-abe2-51f9-e416-1300b7b79c63@oracle.com>


Looking at the BufferedInputStream impl, it looks like its skip(...) 
method should trigger the internal array to be refilled when the 
internal bytes are used up. Maybe something like below would also work?

 ??? while (n > 0) {
	int n2 = skip(n);
	if (n2 == 0) {throw new IOException("Premature EOF reached"); } else { n -= n2; } }

Valerie



On 4/24/2018 7:42 AM, Weijun Wang wrote:
> Please take a review at
>
>    http://cr.openjdk.java.net/~weijun/8201867/webrev.00/
>
> When the hole in keytab is right on the 8192 buffer boundary, skip(n) does not return n.
>
> I are not sure if I can do something like "while (i < n) i += skip(n)" because skip(n) can return zero and it does not understand EOF. Therefore I readNBytes(n) and discard the result. If you have a better solution, I'll be happy to know.
>
> Thanks
> Max
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun.wang at oracle.com  Thu May 17 02:02:26 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 17 May 2018 10:02:26 +0800
Subject: RFR 8202299: Java Keystore fails to load PKCS12/PFX certificates
 created in WindowsServer2016
In-Reply-To: <575f6ca0-e115-c998-f0ea-30df7527f3bc@oracle.com>
References: <0A68EB2D-D19D-4D7D-ADF8-971758D15303@oracle.com>
 <575f6ca0-e115-c998-f0ea-30df7527f3bc@oracle.com>
Message-ID: 



> On May 17, 2018, at 2:42 AM, Sean Mullan  wrote:
> 
> The while(true) in PKCS12KeyStore.java seems like it isn't really necessary, since you are calling the code inside it at most twice. I think a better approach would be to move lines 2134-2146 into a utility method and call it again if you get an Exception and the password is empty.

The while block looks a little strange, but there are too many local variables here and extracting the lines into a method means we need to pass all of them as arguments. This is also just a single step in a long process and taking it out as a separate method breaks the code reading. Finally, such while blocks appear 3 times and we will have to create multiple methods like tryDecryptKey/tryDecryptCert/tryVerifyMac.

It will be nice if Java allows a method defined inside a method. What do you think if I extract the lines into a lambda?

interface RetryWithZero {

    T tryOnce(char[] password) throws Exception;

    static  S run(RetryWithZero f, char[] password) throws Exception {
        try {
            return f.tryOnce(password);
        } catch (Exception e) {
            if (password.length == 0) {
                return f.tryOnce(new char[1]);
            }
            throw e;
        }
    }
}

byte[] keyInfo = RetryWithZero.run(pass -> {
    SecretKey skey = getPBEKey(pass);
    Cipher cipher = Cipher.getInstance(
            mapPBEParamsToAlgorithm(algOid, algParams));
    cipher.init(Cipher.DECRYPT_MODE, skey, algParams);
    return cipher.doFinal(encryptedKey);
}, password);

byte[] rawData = safeContentsData;
try {
    safeContentsData = RetryWithZero.run(pass -> {
        SecretKey skey = getPBEKey(pass);
        Cipher cipher = Cipher.getInstance(algOid.toString());
        cipher.init(Cipher.DECRYPT_MODE, skey, algParams);
        return cipher.doFinal(rawData);
    }, password);
} catch (Exception e) {
    throw new IOException("keystore password was incorrect",
            new UnrecoverableKeyException(
                    "failed to decrypt safe contents entry: " + e));
}

RetryWithZero.run(pass -> {
    SecretKey key = getPBEKey(pass);
    m.init(key, params);
    m.update(authSafeData);
    byte[] macResult = m.doFinal();

    if (debug != null) {
        debug.println("Checking keystore integrity " +
                "(" + m.getAlgorithm() + " iterations: " + ic + ")");
    }

    if (!MessageDigest.isEqual(macData.getDigest(), macResult)) {
        throw new UnrecoverableKeyException("Failed PKCS12" +
                " integrity checking");
    }
    return (Void)null;
}, password);

If we code this way, password will NOT be updated permanently (see p.p.s of my previous mail).

Thanks
Max

> 
> Looks fine otherwise.
> 
> --Sean
> 
> On 4/27/18 12:56 PM, Weijun Wang wrote:
>> Please take a look at
>>    http://cr.openjdk.java.net/~weijun/8202299/webrev.00/
>> Turns out we have to retry [0] other than [] in all 3 locations: decrypting keys, decrypting certs, and verifying the mac.
>> Thanks
>> Max
>> p.s. You might wonder why suddenly in Windows Server 2016, Microsoft starts using [0] to generate the Mac. In fact, they have been doing this all the time. However, before 2016, they also encrypted the certificates, and to decrypt them, Java has already changed password from [] to [0].
>> p.p.s. But is this correct? Should the certificate decryption code only temporarily retries [0] but not changing password itself? Well, maybe. But unless a weird software sometimes uses [] and sometimes [0], this will not be a problem, and changing password itself saves us some cycles from always trying twice.



From weijun.wang at oracle.com  Thu May 17 03:00:34 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 17 May 2018 11:00:34 +0800
Subject: RFR 8201867: Kerberos keytabs with holes in certain places are
 parsed incorrectly
In-Reply-To: <0a342404-abe2-51f9-e416-1300b7b79c63@oracle.com>
References: <75DD716E-82A1-4160-A057-90735DC38147@oracle.com>
 <0a342404-abe2-51f9-e416-1300b7b79c63@oracle.com>
Message-ID: 



> On May 17, 2018, at 6:43 AM, Valerie Peng  wrote:
> 
> 
> Looking at the BufferedInputStream impl, it looks like its skip(...) method should trigger the internal array to be refilled when the internal bytes are used up. Maybe something like below would also work?

Looks so. I'll use your code.

Thanks
Max

>     while (n > 0) {
> 	int n2 = skip(n);
> 	if (n2 == 0) {
> 
> 	    throw new IOException("Premature EOF reached");
> 	} else {
> 	    n -= n2;
> 	}
>     }
> 
> Valerie
> 
> 
> On 4/24/2018 7:42 AM, Weijun Wang wrote:
>> Please take a review at
>> 
>>   
>> http://cr.openjdk.java.net/~weijun/8201867/webrev.00/
>> 
>> 
>> When the hole in keytab is right on the 8192 buffer boundary, skip(n) does not return n.
>> 
>> I are not sure if I can do something like "while (i < n) i += skip(n)" because skip(n) can return zero and it does not understand EOF. Therefore I readNBytes(n) and discard the result. If you have a better solution, I'll be happy to know.
>> 
>> Thanks
>> Max
>> 
>> 
> 



From sean.mullan at oracle.com  Thu May 17 17:49:51 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 17 May 2018 13:49:51 -0400
Subject: RFR 8202299: Java Keystore fails to load PKCS12/PFX certificates
 created in WindowsServer2016
In-Reply-To: 
References: <0A68EB2D-D19D-4D7D-ADF8-971758D15303@oracle.com>
 <575f6ca0-e115-c998-f0ea-30df7527f3bc@oracle.com>
 
Message-ID: 

On 5/16/18 10:02 PM, Weijun Wang wrote:
> 
> 
>> On May 17, 2018, at 2:42 AM, Sean Mullan  wrote:
>>
>> The while(true) in PKCS12KeyStore.java seems like it isn't really necessary, since you are calling the code inside it at most twice. I think a better approach would be to move lines 2134-2146 into a utility method and call it again if you get an Exception and the password is empty.
> 
> The while block looks a little strange, but there are too many local variables here and extracting the lines into a method means we need to pass all of them as arguments. This is also just a single step in a long process and taking it out as a separate method breaks the code reading. Finally, such while blocks appear 3 times and we will have to create multiple methods like tryDecryptKey/tryDecryptCert/tryVerifyMac.

Ok, I didn't realize this pattern was used before.

> 
> It will be nice if Java allows a method defined inside a method. What do you think if I extract the lines into a lambda?
> 
> interface RetryWithZero {
> 
>      T tryOnce(char[] password) throws Exception;
> 
>      static  S run(RetryWithZero f, char[] password) throws Exception {
>          try {
>              return f.tryOnce(password);
>          } catch (Exception e) {
>              if (password.length == 0) {
>                  return f.tryOnce(new char[1]);
>              }
>              throw e;
>          }
>      }
> }
> 
> byte[] keyInfo = RetryWithZero.run(pass -> {
>      SecretKey skey = getPBEKey(pass);
>      Cipher cipher = Cipher.getInstance(
>              mapPBEParamsToAlgorithm(algOid, algParams));
>      cipher.init(Cipher.DECRYPT_MODE, skey, algParams);
>      return cipher.doFinal(encryptedKey);
> }, password);
> 
> byte[] rawData = safeContentsData;
> try {
>      safeContentsData = RetryWithZero.run(pass -> {
>          SecretKey skey = getPBEKey(pass);
>          Cipher cipher = Cipher.getInstance(algOid.toString());
>          cipher.init(Cipher.DECRYPT_MODE, skey, algParams);
>          return cipher.doFinal(rawData);
>      }, password);
> } catch (Exception e) {
>      throw new IOException("keystore password was incorrect",
>              new UnrecoverableKeyException(
>                      "failed to decrypt safe contents entry: " + e));
> }
> 
> RetryWithZero.run(pass -> {
>      SecretKey key = getPBEKey(pass);
>      m.init(key, params);
>      m.update(authSafeData);
>      byte[] macResult = m.doFinal();
> 
>      if (debug != null) {
>          debug.println("Checking keystore integrity " +
>                  "(" + m.getAlgorithm() + " iterations: " + ic + ")");
>      }
> 
>      if (!MessageDigest.isEqual(macData.getDigest(), macResult)) {
>          throw new UnrecoverableKeyException("Failed PKCS12" +
>                  " integrity checking");
>      }
>      return (Void)null;
> }, password);
> 
> If we code this way, password will NOT be updated permanently (see p.p.s of my previous mail).

Seems more complicated and harder to understand that code. So I'm ok 
with the current changes.

--Sean

> 
> Thanks
> Max
> 
>>
>> Looks fine otherwise.
>>
>> --Sean
>>
>> On 4/27/18 12:56 PM, Weijun Wang wrote:
>>> Please take a look at
>>>     http://cr.openjdk.java.net/~weijun/8202299/webrev.00/
>>> Turns out we have to retry [0] other than [] in all 3 locations: decrypting keys, decrypting certs, and verifying the mac.
>>> Thanks
>>> Max
>>> p.s. You might wonder why suddenly in Windows Server 2016, Microsoft starts using [0] to generate the Mac. In fact, they have been doing this all the time. However, before 2016, they also encrypted the certificates, and to decrypt them, Java has already changed password from [] to [0].
>>> p.p.s. But is this correct? Should the certificate decryption code only temporarily retries [0] but not changing password itself? Well, maybe. But unless a weird software sometimes uses [] and sometimes [0], this will not be a problem, and changing password itself saves us some cycles from always trying twice.
> 


From shubhamnba2009 at gmail.com  Thu May 17 05:54:14 2018
From: shubhamnba2009 at gmail.com (Shubham Rajput)
Date: Thu, 17 May 2018 11:24:14 +0530
Subject: Signature from User-specified URIDereferencers NodeSetData objects is
 wrong
Message-ID: 

Hi all,
I am using the following URIreference to form the
signature: #xpointer(//*[@authenticate='true'])

The XML that I am targetting is having 3 element with attribute
'authenticate' set to 'true'. For those 3 element the signature is required
to be formed.

To achieve the above functionality I am using my own URIDereference class
and forming a nodelist comprising all the node elements containing the
elements with attribute 'authenticate' set to'true'.
I am returning back a iterator method after forming the arraylist from
nodelist.

But it seems the signature is forming only for the nodes name and not the
whole node.

 Here's my URIDreferencer method:

------------------------------------source-start---------------------------------------------------------

public MyURIDereferencer(Document doc1) {
this.doc = doc1;
}

public Data dereference(URIReference uriReference, XMLCryptoContext context)
throws URIReferenceException {
XPathFactory factory = XPathFactory.newInstance();
XPath xpath = factory.newXPath();
NodeList nodes = null;
try {
String x = uriReference.getURI();
x = x.replace("#xpointer(", "");
x = x.replace("%5B", "[");
x = x.replace("%5D", "]");
x = x.substring(0, x.length() - 1);
nodes = (NodeList) xpath.evaluate(x, this.doc,
XPathConstants.NODESET);
String nwe = nodeToString(nodes.item(0));
final List l = new ArrayList();

                 for (int i = 0; i < nodes.getLength(); i++)
             l.add(nodes.item(i));

                    return new NodeSetData() {

             public Iterator iterator() {

                 return l.listIterator();
             };
         };
} catch (XPathExpressionException e) {
System.err
.println("XPathExpression Exception when defrencing a URI."
+ e.getMessage());
return null;
}

---------------------------------------------source-end-----------------------------------------------------


Any lead why the signature is forming for the node element name only and
not for the whole node?

Thanks in advance

Regards,

Shubham Rajput
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun.wang at oracle.com  Fri May 18 04:00:25 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 18 May 2018 12:00:25 +0800
Subject: RFR 8202299: Java Keystore fails to load PKCS12/PFX certificates
 created in WindowsServer2016
In-Reply-To: 
References: <0A68EB2D-D19D-4D7D-ADF8-971758D15303@oracle.com>
 <575f6ca0-e115-c998-f0ea-30df7527f3bc@oracle.com>
 
 
Message-ID: <90C07E52-F88F-4FA1-9272-D90A009E3C55@oracle.com>

> 
> Seems more complicated and harder to understand that code.

Not really.

The former

 373             byte[] keyInfo;
 374             while (true) {
 375                 try {
 376                     // Use JCE
 377                     SecretKey skey = getPBEKey(password);
 378                     Cipher cipher = Cipher.getInstance(
 379                         mapPBEParamsToAlgorithm(algOid, algParams));
 380                     cipher.init(Cipher.DECRYPT_MODE, skey, algParams);
 381                     keyInfo = cipher.doFinal(encryptedKey);
 382                     break;
 383                 } catch (Exception e) {
 384                     if (password.length == 0) {
 385                         // Retry using an empty password
 386                         // without a NULL terminator.
 387                         password = new char[1];
 388                         continue;
 389                     }
 390                     throw e;
 391                 }
 392             }

becomes

 394             byte[] keyInfo = RetryWithZero.run(pass -> {
 395                 // Use JCE
 396                 SecretKey skey = getPBEKey(pass);
 397                 Cipher cipher = Cipher.getInstance(
 398                         mapPBEParamsToAlgorithm(algOid, algParams));
 399                 cipher.init(Cipher.DECRYPT_MODE, skey, algParams);
 400                 return cipher.doFinal(encryptedKey);
 401             }, password);

I would say it's clearer and pretty standard functional programming.

Thanks
Max



From sean.mullan at oracle.com  Fri May 18 14:28:15 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Fri, 18 May 2018 10:28:15 -0400
Subject: Signature from User-specified URIDereferencers NodeSetData
 objects is wrong
In-Reply-To: 
References: 
Message-ID: 

On 5/17/18 1:54 AM, Shubham Rajput wrote:
> 
> Any lead why the signature is forming for the node element name only and 
> not for the whole node?

I can't remember for sure now, but it probably has something to do with 
the way you are returning the nodes from your URIDereferencer.

You are probably better off defining an XPathFilter2Transform with an 
XPathFilter2ParameterSpec [1] for your signature and letting that do the 
filtering for you automatically.

HTH,
Sean

[1] 
https://docs.oracle.com/javase/10/docs/api/javax/xml/crypto/dsig/spec/XPathFilter2ParameterSpec.html


From sha.jiang at oracle.com  Fri May 18 23:06:04 2018
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Sat, 19 May 2018 07:06:04 +0800
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 
Message-ID: <6cd74c4b-649d-d7b8-4f1d-2d1ddb07a5c4@oracle.com>

Hi Jamil,

-- ChaCha20Cipher.java
 ?430???????? } else if (aadDone) {
 ?431???????????? // No AAD updates allowed after the PT/CT update 
method? is called
 ?432???????????? throw new IllegalStateException("Attempted to update 
AAD on " +
 ?433???????????????????? "Cipher after plaintext/ciphertext update");

Please consider the below case,
cipher.updateAAD();
cipher.update();
cipher.updateAAD();
Should the second call on updateAAD() throw IllegalStateException?

Minor: Two spaces between "method" and "is" on line 431.

Best regards,
John Jiang

On 17/05/2018 03:05, Jamil Nimeh wrote:
>
> Round 6.
>
> This brings ChaCha20/ChaCha20-Poly1305 into conformance with Cipher's 
> specification when forms of init that take AlgorithmParameters or 
> AlgorithmParameterSpec are used. Previously, a non-null AP or APS 
> object was required.? In order to better conform to the specification, 
> if a null AP or APS is provided for these ciphers, a random nonce will 
> be generated and the counter will be set to 1, just as is currently 
> done with valid forms of init that don't take an AP or APS object 
> (e.g. Cipher.init(int, Key, SecureRandom) ).? Per the spec in Cipher, 
> this is only true for ENCRYPT_MODE and will throw InvalidKeyException 
> when done in DECRYPT_MODE.
>
> I also added a few test cases that exercise these code paths in the 
> ChaCha20Poly1305Parameters.java test case.
>
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>
> Thanks,
>
> --Jamil
>
>
> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>
>> Round 5.
>>
>> This adds Sean's comments.? Sean, I was never able to execute a case 
>> on init where a half-baked object would fail.? In most cases it would 
>> fail in checks in javax.crypto.Cipher before it ever made it down to 
>> my code.? I'm pretty confident the init sequence is OK.? I did move 
>> the setting of a few data members toward the end of the init sequence 
>> but setting the key and nonce is necessary before creating the 
>> initial state, which is then used for generating an authentication 
>> key for AEAD mode and generating keystream.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>
>> Also the CSR has been finalized and can be found here:
>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>
>> --Jamil
>>
>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>
>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>> mostly:
>>>
>>>   * Added words in the description of javax.crypto.Cipher
>>>     recommending callers reinitialize the Cipher to use different
>>>     nonces after each complete encryption or decryption (similar
>>>     language to what exists already for AES-GCM encryption).
>>>   * Added an additional test case for ChaCha20NoReuse
>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>     cleaned up the code a bit based on comments from the field.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>
>>> Thanks!
>>>
>>> --Jamil
>>>
>>>
>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>
>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>> and only retain the key bytes as an object field (thanks Thomas for 
>>>> catching this)
>>>>
>>>> * Added additional protections against key/nonce reuse. This is a 
>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances of 
>>>> these ciphers will no longer allow you to do subsequent 
>>>> doUpdate/doFinal calls after the first doFinal without 
>>>> re-initializing the cipher with either a new key or nonce. 
>>>> Attempting to reuse the cipher without a new initialization will 
>>>> throw an IllegalStateException.? This is similar to the behavior of 
>>>> AES-GCM in encrypt mode, but for ChaCha20 it needs to be done for 
>>>> both encrypt and decrypt.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>
>>>> Thanks,
>>>> --Jamil
>>>>
>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>> Hello everyone,
>>>>>
>>>>> This is a quick update to the previous webrev:
>>>>>
>>>>> * When using the form of engineInit that does only takes op, key 
>>>>> and random, the nonce will always be random even if the random 
>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>
>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>
>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>> separator from a System property directly.? It calls 
>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>> classes in com.sun.crypto.provider do it.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Jamil
>>>>>
>>>>>
>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> This is a request for review for the ChaCha20 and 
>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>> the ciphers are listed below.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>> http://openjdk.java.net/jeps/329
>>>>>>
>>>>>> Thanks,
>>>>>> --Jamil
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jamil.j.nimeh at oracle.com  Fri May 18 23:27:48 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Fri, 18 May 2018 16:27:48 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <6cd74c4b-649d-d7b8-4f1d-2d1ddb07a5c4@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 
 <6cd74c4b-649d-d7b8-4f1d-2d1ddb07a5c4@oracle.com>
Message-ID: 

Hi John,

Yes, the second call must throw IllegalStateException.? See the class 
description in javax.crypto.Cipher where it talks about AEAD modes and 
AAD processing.? It states that all AAD has to be supplied before update 
and/or doFinal methods are invoked.? This constraint is also talked 
about in Cipher.updateAAD's javadoc.

Thanks for the catch on the double-space.

--Jamil

On 05/18/2018 04:06 PM, sha.jiang at oracle.com wrote:
>
> Hi Jamil,
>
> -- ChaCha20Cipher.java
> ?430???????? } else if (aadDone) {
> ?431???????????? // No AAD updates allowed after the PT/CT update 
> method? is called
> ?432???????????? throw new IllegalStateException("Attempted to update 
> AAD on " +
> ?433???????????????????? "Cipher after plaintext/ciphertext update");
>
> Please consider the below case,
> cipher.updateAAD();
> cipher.update();
> cipher.updateAAD();
> Should the second call on updateAAD() throw IllegalStateException?
>
> Minor: Two spaces between "method" and "is" on line 431.
>
> Best regards,
> John Jiang
>
> On 17/05/2018 03:05, Jamil Nimeh wrote:
>>
>> Round 6.
>>
>> This brings ChaCha20/ChaCha20-Poly1305 into conformance with Cipher's 
>> specification when forms of init that take AlgorithmParameters or 
>> AlgorithmParameterSpec are used. Previously, a non-null AP or APS 
>> object was required.? In order to better conform to the 
>> specification, if a null AP or APS is provided for these ciphers, a 
>> random nonce will be generated and the counter will be set to 1, just 
>> as is currently done with valid forms of init that don't take an AP 
>> or APS object (e.g. Cipher.init(int, Key, SecureRandom) ). Per the 
>> spec in Cipher, this is only true for ENCRYPT_MODE and will throw 
>> InvalidKeyException when done in DECRYPT_MODE.
>>
>> I also added a few test cases that exercise these code paths in the 
>> ChaCha20Poly1305Parameters.java test case.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>>
>> Thanks,
>>
>> --Jamil
>>
>>
>> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>>
>>> Round 5.
>>>
>>> This adds Sean's comments.? Sean, I was never able to execute a case 
>>> on init where a half-baked object would fail.? In most cases it 
>>> would fail in checks in javax.crypto.Cipher before it ever made it 
>>> down to my code. I'm pretty confident the init sequence is OK.? I 
>>> did move the setting of a few data members toward the end of the 
>>> init sequence but setting the key and nonce is necessary before 
>>> creating the initial state, which is then used for generating an 
>>> authentication key for AEAD mode and generating keystream.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>
>>> Also the CSR has been finalized and can be found here:
>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>
>>> --Jamil
>>>
>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>
>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>> mostly:
>>>>
>>>>   * Added words in the description of javax.crypto.Cipher
>>>>     recommending callers reinitialize the Cipher to use different
>>>>     nonces after each complete encryption or decryption (similar
>>>>     language to what exists already for AES-GCM encryption).
>>>>   * Added an additional test case for ChaCha20NoReuse
>>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>>     cleaned up the code a bit based on comments from the field.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>
>>>> Thanks!
>>>>
>>>> --Jamil
>>>>
>>>>
>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>
>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>> for catching this)
>>>>>
>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances of 
>>>>> these ciphers will no longer allow you to do subsequent 
>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>> throw an IllegalStateException.? This is similar to the behavior 
>>>>> of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done 
>>>>> for both encrypt and decrypt.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>
>>>>> Thanks,
>>>>> --Jamil
>>>>>
>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>> Hello everyone,
>>>>>>
>>>>>> This is a quick update to the previous webrev:
>>>>>>
>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>> and random, the nonce will always be random even if the random 
>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>
>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>
>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>> separator from a System property directly.? It calls 
>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --Jamil
>>>>>>
>>>>>>
>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>> the ciphers are listed below.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --Jamil
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bradford.wetmore at oracle.com  Fri May 18 23:29:54 2018
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Fri, 18 May 2018 16:29:54 -0700
Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm
 as in PKCS#1 v2.2"
In-Reply-To: <4d09005b-df60-00a8-0bdb-c65dbc8f40bf@oracle.com>
References: 
 <4d09005b-df60-00a8-0bdb-c65dbc8f40bf@oracle.com>
Message-ID: <690752a9-e5f3-6052-0bc2-815d56717a60@oracle.com>

Mostly minor, but a couple substantive comments.

I skimmed the tests this time, but didn't hit them as hard.

On 5/14/2018 1:20 PM, Valerie Peng wrote:
> Hi Brad,
> 
> The latest webrev is at 
> http://cr.openjdk.java.net/~valeriep/8146293/webrev.04/
> The only difference between webrev.03 and webrev.04 is the review 
> comments from the CSR.

SignedObject.java
-----------------
Now that SignedObject is no longer in the scope of the CSR, we talked 
about updating the class javadoc with an example about setting the 
parameters before passing the Signature object in.  I didn't see that, 
so did you want to at least give an example of it here?  I don't expect 
that would require a separate CSR.


Signature.java
--------------
Copyright year update.


PSSParameterSpec.java
---------------------
Nit:  add vertical space between description and params.  98/99, 104/105.

125:  Here you do need a period, since it's the end of a sentence and 
you need to separate the two sentence.  Periods after both sentences.

162/164:  If you're going to fix some of the other spots in this file, 
you might also add spaces here.


RSAPrivateCrtKeySpec.java
-------------------------
Out of curiosity, here and in a couple of other places, what prompted 
you to completely reword these constructor sentences?  It's always 
bothered me, and I noticed it was done between webrev.01 and .02.  It 
was approved in the CSR, so yay!


RSAPublicKeySpec.java
RSAPrivateKeySpec.java
----------------------
95:  Shouldn't you  move the null statement to the @return line instead 
of the method summary? e.g.

* Returns the parameters associated with this key.
*
* @return the parameters associated with this key, or null if not present?


javax/crypto/spec/package-info.java
-----------------------------------
Copyright year update.


SignerInfo.java
PKCS10.java
---------------
This is what we talked about earlier.  In X509CRL.java, 
X509CRLImpl.java, X509Certificate.java, X509CertImpl.java, you are 
setting the parameters after the init calls, but here you are doing them 
before.  Probably should be consistent.


RSAUtil.java
------------
44:  Extra ","


RSAPadding.java
---------------
106/109:  Make final?


RSASignature.java
-----------------
281.  Indent 4 more spaces.


MGF1.java
---------
31.  If you wouldn't mind adding RFC here?


RSAPSSSignature.java
--------------------
191:  Would you mind inserting a comment that you "skip the JCA overhead"?

264:  -> PSSParameterSpec.TRAILER_FIELD_BC instead of hardcoding 1?

418:  Thanks for adding all of the "stepX" comments.  That really helps 
readability!  I'm assuming no material changes were made here?  I looked 
at the impl code heavily on the last review, but not as much this time.


TestOAEPWithParams.java
-----------------------
50:  Should we also add SHA-384, SHA-512 here?


Offsets.java
------------
43:  Should we also add all of the missing RSA variants as well? 
SHA{1,224,256...}withRSA


Thanks,

Brad


From valerie.peng at oracle.com  Sat May 19 00:35:28 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Fri, 18 May 2018 17:35:28 -0700
Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm
 as in PKCS#1 v2.2"
In-Reply-To: <690752a9-e5f3-6052-0bc2-815d56717a60@oracle.com>
References: 
 <4d09005b-df60-00a8-0bdb-c65dbc8f40bf@oracle.com>
 <690752a9-e5f3-6052-0bc2-815d56717a60@oracle.com>
Message-ID: <9ce116b4-c3fd-adff-a9e0-c4c2c1c72ad1@oracle.com>

Please find comments in line.

On 5/18/2018 4:29 PM, Bradford Wetmore wrote:
> Mostly minor, but a couple substantive comments.
>
> I skimmed the tests this time, but didn't hit them as hard.
>
> On 5/14/2018 1:20 PM, Valerie Peng wrote:
>> Hi Brad,
>>
>> The latest webrev is at 
>> http://cr.openjdk.java.net/~valeriep/8146293/webrev.04/
>> The only difference between webrev.03 and webrev.04 is the review 
>> comments from the CSR.
>
> SignedObject.java
> -----------------
> Now that SignedObject is no longer in the scope of the CSR, we talked 
> about updating the class javadoc with an example about setting the 
> parameters before passing the Signature object in.? I didn't see that, 
> so did you want to at least give an example of it here?? I don't 
> expect that would require a separate CSR.

Well, I debated about this and feel that it's probably better to leave 
this for later once we are set about the recommended usage for 
SignedObject.

> Signature.java
> --------------
> Copyright year update.
Fixed.
>
> PSSParameterSpec.java
> ---------------------
> Nit:? add vertical space between description and params.? 98/99, 104/105.
>
> 125:? Here you do need a period, since it's the end of a sentence and 
> you need to separate the two sentence.? Periods after both sentences.
>
> 162/164:? If you're going to fix some of the other spots in this file, 
> you might also add spaces here.
Ok.

> RSAPrivateCrtKeySpec.java
> -------------------------
> Out of curiosity, here and in a couple of other places, what prompted 
> you to completely reword these constructor sentences? It's always 
> bothered me, and I noticed it was done between webrev.01 and .02.? It 
> was approved in the CSR, so yay!
You commented about it. So I made the changes.

> RSAPublicKeySpec.java
> RSAPrivateKeySpec.java
> ----------------------
> 95:? Shouldn't you? move the null statement to the @return line 
> instead of the method summary? e.g.
>
> * Returns the parameters associated with this key.
> *
> * @return the parameters associated with this key, or null if not 
> present?
Existing javadoc seems to be using either. I prefer to keep it as is.

>
> javax/crypto/spec/package-info.java
> -----------------------------------
> Copyright year update.
Fixed.
>
>
> SignerInfo.java
> PKCS10.java
> ---------------
> This is what we talked about earlier.? In X509CRL.java, 
> X509CRLImpl.java, X509Certificate.java, X509CertImpl.java, you are 
> setting the parameters after the init calls, but here you are doing 
> them before.? Probably should be consistent.
Correct. Good catch.

> RSAUtil.java
> ------------
> 44:? Extra ","
Fixed.
>
> RSAPadding.java
> ---------------
> 106/109:? Make final?
Ok.
>
> RSASignature.java
> -----------------
> 281.? Indent 4 more spaces.
Fixed.

>
> MGF1.java
> ---------
> 31.? If you wouldn't mind adding RFC here?
Ok.
>
> RSAPSSSignature.java
> --------------------
> 191:? Would you mind inserting a comment that you "skip the JCA 
> overhead"?
Ok.
>
> 264:? -> PSSParameterSpec.TRAILER_FIELD_BC instead of hardcoding 1?
>
> 418:? Thanks for adding all of the "stepX" comments.? That really 
> helps readability!? I'm assuming no material changes were made here?? 
> I looked at the impl code heavily on the last review, but not as much 
> this time.
No, only comments are added.

>
> TestOAEPWithParams.java
> -----------------------
> 50:? Should we also add SHA-384, SHA-512 here?
I am not so sure as the key size is only 768. We can bump the size up 
and add SHA-384, SHA512, but since other tests in the same directory 
covers SHA-382 and SHA-512, I only added SHA-512/224 and SHA-512/256 to 
this test.

>
>
> Offsets.java
> ------------
> 43:? Should we also add all of the missing RSA variants as well? 
> SHA{1,224,256...}withRSA
Ok, I added more but left SHA1 out as it's sunsetting and existing coverage.

Will re-run mach5 again. Webrev updated at: 
http://cr.openjdk.java.net/~valeriep/8146293/webrev.05/
Thanks,
Valerie

>
> Thanks,
>
> Brad



From sha.jiang at oracle.com  Sat May 19 08:31:41 2018
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Sat, 19 May 2018 16:31:41 +0800
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 
 <6cd74c4b-649d-d7b8-4f1d-2d1ddb07a5c4@oracle.com>
 
Message-ID: <3890b763-aa91-5829-b594-4d8ac00741d1@oracle.com>

Hi Jamil,

On 19/05/2018 07:27, Jamil Nimeh wrote:
>
> Hi John,
>
> Yes, the second call must throw IllegalStateException.? See the class 
> description in javax.crypto.Cipher where it talks about AEAD modes and 
> AAD processing.? It states that all AAD has to be supplied before 
> update and/or doFinal methods are invoked.? This constraint is also 
> talked about in Cipher.updateAAD's javadoc.
>
I see.

I was confused by a corner case that passing an empty byte[] (or a 
ByteBuffer that has no remaining byte) to the second call on 
Cipher.updateAAD().
In fact, in this case, the second call doesn't invoke the underlying 
engineUpdateAAD(), so IllegalStateException won't be thrown.

Best regards,
John Jiang

> Thanks for the catch on the double-space.
>
> --Jamil
>
> On 05/18/2018 04:06 PM, sha.jiang at oracle.com wrote:
>>
>> Hi Jamil,
>>
>> -- ChaCha20Cipher.java
>> ?430???????? } else if (aadDone) {
>> ?431???????????? // No AAD updates allowed after the PT/CT update 
>> method? is called
>> ?432???????????? throw new IllegalStateException("Attempted to update 
>> AAD on " +
>> ?433???????????????????? "Cipher after plaintext/ciphertext update");
>>
>> Please consider the below case,
>> cipher.updateAAD();
>> cipher.update();
>> cipher.updateAAD();
>> Should the second call on updateAAD() throw IllegalStateException?
>>
>> Minor: Two spaces between "method" and "is" on line 431.
>>
>> Best regards,
>> John Jiang
>>
>> On 17/05/2018 03:05, Jamil Nimeh wrote:
>>>
>>> Round 6.
>>>
>>> This brings ChaCha20/ChaCha20-Poly1305 into conformance with 
>>> Cipher's specification when forms of init that take 
>>> AlgorithmParameters or AlgorithmParameterSpec are used. Previously, 
>>> a non-null AP or APS object was required.? In order to better 
>>> conform to the specification, if a null AP or APS is provided for 
>>> these ciphers, a random nonce will be generated and the counter will 
>>> be set to 1, just as is currently done with valid forms of init that 
>>> don't take an AP or APS object (e.g. Cipher.init(int, Key, 
>>> SecureRandom) ).? Per the spec in Cipher, this is only true for 
>>> ENCRYPT_MODE and will throw InvalidKeyException when done in 
>>> DECRYPT_MODE.
>>>
>>> I also added a few test cases that exercise these code paths in the 
>>> ChaCha20Poly1305Parameters.java test case.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>>>
>>> Thanks,
>>>
>>> --Jamil
>>>
>>>
>>> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>>>
>>>> Round 5.
>>>>
>>>> This adds Sean's comments.? Sean, I was never able to execute a 
>>>> case on init where a half-baked object would fail.? In most cases 
>>>> it would fail in checks in javax.crypto.Cipher before it ever made 
>>>> it down to my code.? I'm pretty confident the init sequence is OK.? 
>>>> I did move the setting of a few data members toward the end of the 
>>>> init sequence but setting the key and nonce is necessary before 
>>>> creating the initial state, which is then used for generating an 
>>>> authentication key for AEAD mode and generating keystream.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>>
>>>> Also the CSR has been finalized and can be found here:
>>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>>
>>>> --Jamil
>>>>
>>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>>
>>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>>> mostly:
>>>>>
>>>>>   * Added words in the description of javax.crypto.Cipher
>>>>>     recommending callers reinitialize the Cipher to use different
>>>>>     nonces after each complete encryption or decryption (similar
>>>>>     language to what exists already for AES-GCM encryption).
>>>>>   * Added an additional test case for ChaCha20NoReuse
>>>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>>>     cleaned up the code a bit based on comments from the field.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --Jamil
>>>>>
>>>>>
>>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>>
>>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>>> for catching this)
>>>>>>
>>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances 
>>>>>> of these ciphers will no longer allow you to do subsequent 
>>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>>> throw an IllegalStateException.? This is similar to the behavior 
>>>>>> of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done 
>>>>>> for both encrypt and decrypt.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>>
>>>>>> Thanks,
>>>>>> --Jamil
>>>>>>
>>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>> This is a quick update to the previous webrev:
>>>>>>>
>>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>>> and random, the nonce will always be random even if the random 
>>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>>
>>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>>
>>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>>> separator from a System property directly. It calls 
>>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --Jamil
>>>>>>>
>>>>>>>
>>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>>> the ciphers are listed below.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> --Jamil
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jamil.j.nimeh at oracle.com  Sat May 19 14:40:16 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Sat, 19 May 2018 07:40:16 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <3890b763-aa91-5829-b594-4d8ac00741d1@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 
 <6cd74c4b-649d-d7b8-4f1d-2d1ddb07a5c4@oracle.com>
 
 <3890b763-aa91-5829-b594-4d8ac00741d1@oracle.com>
Message-ID: <5bd12247-c693-603b-86df-7239a3bab5f3@oracle.com>

Hi John, comments below:

On 5/19/2018 1:31 AM, sha.jiang at oracle.com wrote:
>
> Hi Jamil,
>
> On 19/05/2018 07:27, Jamil Nimeh wrote:
>>
>> Hi John,
>>
>> Yes, the second call must throw IllegalStateException.? See the class 
>> description in javax.crypto.Cipher where it talks about AEAD modes 
>> and AAD processing.? It states that all AAD has to be supplied before 
>> update and/or doFinal methods are invoked.? This constraint is also 
>> talked about in Cipher.updateAAD's javadoc.
>>
> I see.
>
> I was confused by a corner case that passing an empty byte[] (or a 
> ByteBuffer that has no remaining byte) to the second call on 
> Cipher.updateAAD().
> In fact, in this case, the second call doesn't invoke the underlying 
> engineUpdateAAD(), so IllegalStateException won't be thrown.
I see what you're talking about, but I can't protect against that (if it 
even needs protecting).? That zero-length check is in Cipher so my code 
is never invoked (as you stated).? The upside is the behavior of 
ChaCha20 in this case would be consistent with any other AEAD cipher.? 
Changing that behavior (and I'm not convinced we should change it) is 
something that goes beyond the scope of this JEP.

I think it is safe in this case to not throw ISE since you're not adding 
any AAD data, so for ChaCha20 you would not affect the AAD length or 
padding, and any buffer that would affect it will most definitely cause 
ISE to be thrown.? I think we're OK here (as with any other AEAD cipher).

Thanks,
--Jamil
>
> Best regards,
> John Jiang
>
>> Thanks for the catch on the double-space.
>>
>> --Jamil
>>
>> On 05/18/2018 04:06 PM, sha.jiang at oracle.com wrote:
>>>
>>> Hi Jamil,
>>>
>>> -- ChaCha20Cipher.java
>>> ?430???????? } else if (aadDone) {
>>> ?431???????????? // No AAD updates allowed after the PT/CT update 
>>> method? is called
>>> ?432???????????? throw new IllegalStateException("Attempted to 
>>> update AAD on " +
>>> ?433???????????????????? "Cipher after plaintext/ciphertext update");
>>>
>>> Please consider the below case,
>>> cipher.updateAAD();
>>> cipher.update();
>>> cipher.updateAAD();
>>> Should the second call on updateAAD() throw IllegalStateException?
>>>
>>> Minor: Two spaces between "method" and "is" on line 431.
>>>
>>> Best regards,
>>> John Jiang
>>>
>>> On 17/05/2018 03:05, Jamil Nimeh wrote:
>>>>
>>>> Round 6.
>>>>
>>>> This brings ChaCha20/ChaCha20-Poly1305 into conformance with 
>>>> Cipher's specification when forms of init that take 
>>>> AlgorithmParameters or AlgorithmParameterSpec are used. Previously, 
>>>> a non-null AP or APS object was required.? In order to better 
>>>> conform to the specification, if a null AP or APS is provided for 
>>>> these ciphers, a random nonce will be generated and the counter 
>>>> will be set to 1, just as is currently done with valid forms of 
>>>> init that don't take an AP or APS object (e.g. Cipher.init(int, 
>>>> Key, SecureRandom) ).? Per the spec in Cipher, this is only true 
>>>> for ENCRYPT_MODE and will throw InvalidKeyException when done in 
>>>> DECRYPT_MODE.
>>>>
>>>> I also added a few test cases that exercise these code paths in the 
>>>> ChaCha20Poly1305Parameters.java test case.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>>>>
>>>> Thanks,
>>>>
>>>> --Jamil
>>>>
>>>>
>>>> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>>>>
>>>>> Round 5.
>>>>>
>>>>> This adds Sean's comments.? Sean, I was never able to execute a 
>>>>> case on init where a half-baked object would fail.? In most cases 
>>>>> it would fail in checks in javax.crypto.Cipher before it ever made 
>>>>> it down to my code.? I'm pretty confident the init sequence is 
>>>>> OK.? I did move the setting of a few data members toward the end 
>>>>> of the init sequence but setting the key and nonce is necessary 
>>>>> before creating the initial state, which is then used for 
>>>>> generating an authentication key for AEAD mode and generating 
>>>>> keystream.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>>>
>>>>> Also the CSR has been finalized and can be found here:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>>>
>>>>> --Jamil
>>>>>
>>>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>>>
>>>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor 
>>>>>> stuff mostly:
>>>>>>
>>>>>>   * Added words in the description of javax.crypto.Cipher
>>>>>>     recommending callers reinitialize the Cipher to use different
>>>>>>     nonces after each complete encryption or decryption (similar
>>>>>>     language to what exists already for AES-GCM encryption).
>>>>>>   * Added an additional test case for ChaCha20NoReuse
>>>>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>>>>     cleaned up the code a bit based on comments from the field.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> --Jamil
>>>>>>
>>>>>>
>>>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>>>
>>>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>>>> for catching this)
>>>>>>>
>>>>>>> * Added additional protections against key/nonce reuse.? This is 
>>>>>>> a behavioral change to ChaCha20 and ChaCha20-Poly1305.? 
>>>>>>> Instances of these ciphers will no longer allow you to do 
>>>>>>> subsequent doUpdate/doFinal calls after the first doFinal 
>>>>>>> without re-initializing the cipher with either a new key or 
>>>>>>> nonce. Attempting to reuse the cipher without a new 
>>>>>>> initialization will throw an IllegalStateException.? This is 
>>>>>>> similar to the behavior of AES-GCM in encrypt mode, but for 
>>>>>>> ChaCha20 it needs to be done for both encrypt and decrypt.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --Jamil
>>>>>>>
>>>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>>>> Hello everyone,
>>>>>>>>
>>>>>>>> This is a quick update to the previous webrev:
>>>>>>>>
>>>>>>>> * When using the form of engineInit that does only takes op, 
>>>>>>>> key and random, the nonce will always be random even if the 
>>>>>>>> random parameter is null.? A default instance of SecureRandom 
>>>>>>>> will be used to create the nonce in this case, instead of all 
>>>>>>>> zeroes.
>>>>>>>>
>>>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>>>
>>>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>>>> separator from a System property directly.? It calls 
>>>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> --Jamil
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>>>> the ciphers are listed below.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> --Jamil
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sha.jiang at oracle.com  Sat May 19 23:13:54 2018
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Sun, 20 May 2018 07:13:54 +0800
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <5bd12247-c693-603b-86df-7239a3bab5f3@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 
 <6cd74c4b-649d-d7b8-4f1d-2d1ddb07a5c4@oracle.com>
 
 <3890b763-aa91-5829-b594-4d8ac00741d1@oracle.com>
 <5bd12247-c693-603b-86df-7239a3bab5f3@oracle.com>
Message-ID: 

Hi Jamil,

On 19/05/2018 22:40, Jamil Nimeh wrote:
> Hi John, comments below:
>
> On 5/19/2018 1:31 AM, sha.jiang at oracle.com wrote:
>>
>> Hi Jamil,
>>
>> On 19/05/2018 07:27, Jamil Nimeh wrote:
>>>
>>> Hi John,
>>>
>>> Yes, the second call must throw IllegalStateException.? See the 
>>> class description in javax.crypto.Cipher where it talks about AEAD 
>>> modes and AAD processing.? It states that all AAD has to be supplied 
>>> before update and/or doFinal methods are invoked.? This constraint 
>>> is also talked about in Cipher.updateAAD's javadoc.
>>>
>> I see.
>>
>> I was confused by a corner case that passing an empty byte[] (or a 
>> ByteBuffer that has no remaining byte) to the second call on 
>> Cipher.updateAAD().
>> In fact, in this case, the second call doesn't invoke the underlying 
>> engineUpdateAAD(), so IllegalStateException won't be thrown.
> I see what you're talking about, but I can't protect against that (if 
> it even needs protecting).? That zero-length check is in Cipher so my 
> code is never invoked (as you stated).? The upside is the behavior of 
> ChaCha20 in this case would be consistent with any other AEAD cipher.? 
> Changing that behavior (and I'm not convinced we should change it) is 
> something that goes beyond the scope of this JEP.
>
> I think it is safe in this case to not throw ISE since you're not 
> adding any AAD data, so for ChaCha20 you would not affect the AAD 
> length or padding, and any buffer that would affect it will most 
> definitely cause ISE to be thrown.? I think we're OK here (as with any 
> other AEAD cipher).
Never mind, I have no concern on this point.

Best regards,
John Jiang
>
> Thanks,
> --Jamil
>>
>> Best regards,
>> John Jiang
>>
>>> Thanks for the catch on the double-space.
>>>
>>> --Jamil
>>>
>>> On 05/18/2018 04:06 PM, sha.jiang at oracle.com wrote:
>>>>
>>>> Hi Jamil,
>>>>
>>>> -- ChaCha20Cipher.java
>>>> ?430???????? } else if (aadDone) {
>>>> ?431???????????? // No AAD updates allowed after the PT/CT update 
>>>> method? is called
>>>> ?432???????????? throw new IllegalStateException("Attempted to 
>>>> update AAD on " +
>>>> ?433???????????????????? "Cipher after plaintext/ciphertext update");
>>>>
>>>> Please consider the below case,
>>>> cipher.updateAAD();
>>>> cipher.update();
>>>> cipher.updateAAD();
>>>> Should the second call on updateAAD() throw IllegalStateException?
>>>>
>>>> Minor: Two spaces between "method" and "is" on line 431.
>>>>
>>>> Best regards,
>>>> John Jiang
>>>>
>>>> On 17/05/2018 03:05, Jamil Nimeh wrote:
>>>>>
>>>>> Round 6.
>>>>>
>>>>> This brings ChaCha20/ChaCha20-Poly1305 into conformance with 
>>>>> Cipher's specification when forms of init that take 
>>>>> AlgorithmParameters or AlgorithmParameterSpec are used. 
>>>>> Previously, a non-null AP or APS object was required. In order to 
>>>>> better conform to the specification, if a null AP or APS is 
>>>>> provided for these ciphers, a random nonce will be generated and 
>>>>> the counter will be set to 1, just as is currently done with valid 
>>>>> forms of init that don't take an AP or APS object (e.g. 
>>>>> Cipher.init(int, Key, SecureRandom) ).? Per the spec in Cipher, 
>>>>> this is only true for ENCRYPT_MODE and will throw 
>>>>> InvalidKeyException when done in DECRYPT_MODE.
>>>>>
>>>>> I also added a few test cases that exercise these code paths in 
>>>>> the ChaCha20Poly1305Parameters.java test case.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Jamil
>>>>>
>>>>>
>>>>> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>>>>>
>>>>>> Round 5.
>>>>>>
>>>>>> This adds Sean's comments.? Sean, I was never able to execute a 
>>>>>> case on init where a half-baked object would fail.? In most cases 
>>>>>> it would fail in checks in javax.crypto.Cipher before it ever 
>>>>>> made it down to my code.? I'm pretty confident the init sequence 
>>>>>> is OK. I did move the setting of a few data members toward the 
>>>>>> end of the init sequence but setting the key and nonce is 
>>>>>> necessary before creating the initial state, which is then used 
>>>>>> for generating an authentication key for AEAD mode and generating 
>>>>>> keystream.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>>>>
>>>>>> Also the CSR has been finalized and can be found here:
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>>>>
>>>>>> --Jamil
>>>>>>
>>>>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>>>>
>>>>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor 
>>>>>>> stuff mostly:
>>>>>>>
>>>>>>>   * Added words in the description of javax.crypto.Cipher
>>>>>>>     recommending callers reinitialize the Cipher to use
>>>>>>>     different nonces after each complete encryption or
>>>>>>>     decryption (similar language to what exists already for
>>>>>>>     AES-GCM encryption).
>>>>>>>   * Added an additional test case for ChaCha20NoReuse
>>>>>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>>>>>     cleaned up the code a bit based on comments from the field.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>>>>
>>>>>>> Thanks!
>>>>>>>
>>>>>>> --Jamil
>>>>>>>
>>>>>>>
>>>>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>>>>
>>>>>>>> * Removed the key field in ChaCha20 and Poly1305 
>>>>>>>> implementations and only retain the key bytes as an object 
>>>>>>>> field (thanks Thomas for catching this)
>>>>>>>>
>>>>>>>> * Added additional protections against key/nonce reuse.? This 
>>>>>>>> is a behavioral change to ChaCha20 and ChaCha20-Poly1305.? 
>>>>>>>> Instances of these ciphers will no longer allow you to do 
>>>>>>>> subsequent doUpdate/doFinal calls after the first doFinal 
>>>>>>>> without re-initializing the cipher with either a new key or 
>>>>>>>> nonce. Attempting to reuse the cipher without a new 
>>>>>>>> initialization will throw an IllegalStateException.? This is 
>>>>>>>> similar to the behavior of AES-GCM in encrypt mode, but for 
>>>>>>>> ChaCha20 it needs to be done for both encrypt and decrypt.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> --Jamil
>>>>>>>>
>>>>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>>>>> Hello everyone,
>>>>>>>>>
>>>>>>>>> This is a quick update to the previous webrev:
>>>>>>>>>
>>>>>>>>> * When using the form of engineInit that does only takes op, 
>>>>>>>>> key and random, the nonce will always be random even if the 
>>>>>>>>> random parameter is null.? A default instance of SecureRandom 
>>>>>>>>> will be used to create the nonce in this case, instead of all 
>>>>>>>>> zeroes.
>>>>>>>>>
>>>>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>>>>
>>>>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>>>>> separator from a System property directly.? It calls 
>>>>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>>
>>>>>>>>> --Jamil
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>>>>> Hello all,
>>>>>>>>>>
>>>>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>>>>> ChaCha20-Poly1305 cipher implementations. Links to the webrev 
>>>>>>>>>> and the JEP which outlines the characteristics and behavior 
>>>>>>>>>> of the ciphers are listed below.
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>>>>
>>>>>>>>>> Thanks,
>>>>>>>>>> --Jamil
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From bradford.wetmore at oracle.com  Mon May 21 16:56:37 2018
From: bradford.wetmore at oracle.com (Bradford Wetmore)
Date: Mon, 21 May 2018 09:56:37 -0700
Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm
 as in PKCS#1 v2.2"
In-Reply-To: <9ce116b4-c3fd-adff-a9e0-c4c2c1c72ad1@oracle.com>
References: 
 <4d09005b-df60-00a8-0bdb-c65dbc8f40bf@oracle.com>
 <690752a9-e5f3-6052-0bc2-815d56717a60@oracle.com>
 <9ce116b4-c3fd-adff-a9e0-c4c2c1c72ad1@oracle.com>
Message-ID: 


>> SignedObject.java
>> -----------------
>> Now that SignedObject is no longer in the scope of the CSR, we talked 
>> about updating the class javadoc with an example about setting the 
>> parameters before passing the Signature object in.? I didn't see that, 
>> so did you want to at least give an example of it here?? I don't 
>> expect that would require a separate CSR.
> 
> Well, I debated about this and feel that it's probably better to leave 
> this for later once we are set about the recommended usage for 
> SignedObject.

Ok.  File a CR to track if you think it's something you want to come 
back to.

>> RSAPSSSignature.java
>> --------------------
>> 191:? Would you mind inserting a comment that you "skip the JCA 
>> overhead"?
> Ok.
>>
>> 264:? -> PSSParameterSpec.TRAILER_FIELD_BC instead of hardcoding 1?

I think you might have missed this one.

>> TestOAEPWithParams.java
>> -----------------------
>> 50:? Should we also add SHA-384, SHA-512 here?
> I am not so sure as the key size is only 768. We can bump the size up 
> and add SHA-384, SHA512, but since other tests in the same directory 
> covers SHA-382 and SHA-512, I only added SHA-512/224 and SHA-512/256 to 
> this test.

Ok.

>> Offsets.java
>> ------------
>> 43:? Should we also add all of the missing RSA variants as well? 
>> SHA{1,224,256...}withRSA
> Ok, I added more but left SHA1 out as it's sunsetting and existing 
> coverage.

Sounds good.

Brad




From valerie.peng at oracle.com  Mon May 21 17:06:40 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 21 May 2018 10:06:40 -0700
Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm
 as in PKCS#1 v2.2"
In-Reply-To: 
References: 
 <4d09005b-df60-00a8-0bdb-c65dbc8f40bf@oracle.com>
 <690752a9-e5f3-6052-0bc2-815d56717a60@oracle.com>
 <9ce116b4-c3fd-adff-a9e0-c4c2c1c72ad1@oracle.com>
 
Message-ID: 

Right, I will update line 264 of RSAPSSSignature.java.
Thanks,
Valerie

On 5/21/2018 9:56 AM, Bradford Wetmore wrote:
>
>>> SignedObject.java
>>> -----------------
>>> Now that SignedObject is no longer in the scope of the CSR, we 
>>> talked about updating the class javadoc with an example about 
>>> setting the parameters before passing the Signature object in.? I 
>>> didn't see that, so did you want to at least give an example of it 
>>> here?? I don't expect that would require a separate CSR.
>>
>> Well, I debated about this and feel that it's probably better to 
>> leave this for later once we are set about the recommended usage for 
>> SignedObject.
>
> Ok.? File a CR to track if you think it's something you want to come 
> back to.
>
>>> RSAPSSSignature.java
>>> --------------------
>>> 191:? Would you mind inserting a comment that you "skip the JCA 
>>> overhead"?
>> Ok.
>>>
>>> 264:? -> PSSParameterSpec.TRAILER_FIELD_BC instead of hardcoding 1?
>
> I think you might have missed this one.
>
>>> TestOAEPWithParams.java
>>> -----------------------
>>> 50:? Should we also add SHA-384, SHA-512 here?
>> I am not so sure as the key size is only 768. We can bump the size up 
>> and add SHA-384, SHA512, but since other tests in the same directory 
>> covers SHA-382 and SHA-512, I only added SHA-512/224 and SHA-512/256 
>> to this test.
>
> Ok.
>
>>> Offsets.java
>>> ------------
>>> 43:? Should we also add all of the missing RSA variants as well? 
>>> SHA{1,224,256...}withRSA
>> Ok, I added more but left SHA1 out as it's sunsetting and existing 
>> coverage.
>
> Sounds good.
>
> Brad
>
>



From valerie.peng at oracle.com  Mon May 21 17:22:56 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Mon, 21 May 2018 10:22:56 -0700
Subject: RFR[11] JDK-8146293 "Add Support for RSA-PSS Signature Algorithm
 as in PKCS#1 v2.2"
In-Reply-To: 
References: 
 <4d09005b-df60-00a8-0bdb-c65dbc8f40bf@oracle.com>
 <690752a9-e5f3-6052-0bc2-815d56717a60@oracle.com>
 <9ce116b4-c3fd-adff-a9e0-c4c2c1c72ad1@oracle.com>
 
 
Message-ID: <7d3f96de-9e64-d5a2-c195-31a3aca43b46@oracle.com>

BTW, SignedObject javadoc update is tracked under 
https://bugs.openjdk.java.net/browse/JDK-8203489

Valerie

On 5/21/2018 10:06 AM, Valerie Peng wrote:
> Right, I will update line 264 of RSAPSSSignature.java.
> Thanks,
> Valerie
>
> On 5/21/2018 9:56 AM, Bradford Wetmore wrote:
>>
>>>> SignedObject.java
>>>> -----------------
>>>> Now that SignedObject is no longer in the scope of the CSR, we 
>>>> talked about updating the class javadoc with an example about 
>>>> setting the parameters before passing the Signature object in.? I 
>>>> didn't see that, so did you want to at least give an example of it 
>>>> here?? I don't expect that would require a separate CSR.
>>>
>>> Well, I debated about this and feel that it's probably better to 
>>> leave this for later once we are set about the recommended usage for 
>>> SignedObject.
>>
>> Ok.? File a CR to track if you think it's something you want to come 
>> back to.
>>
>>>> RSAPSSSignature.java
>>>> --------------------
>>>> 191:? Would you mind inserting a comment that you "skip the JCA 
>>>> overhead"?
>>> Ok.
>>>>
>>>> 264:? -> PSSParameterSpec.TRAILER_FIELD_BC instead of hardcoding 1?
>>
>> I think you might have missed this one.
>>
>>>> TestOAEPWithParams.java
>>>> -----------------------
>>>> 50:? Should we also add SHA-384, SHA-512 here?
>>> I am not so sure as the key size is only 768. We can bump the size 
>>> up and add SHA-384, SHA512, but since other tests in the same 
>>> directory covers SHA-382 and SHA-512, I only added SHA-512/224 and 
>>> SHA-512/256 to this test.
>>
>> Ok.
>>
>>>> Offsets.java
>>>> ------------
>>>> 43:? Should we also add all of the missing RSA variants as well? 
>>>> SHA{1,224,256...}withRSA
>>> Ok, I added more but left SHA1 out as it's sunsetting and existing 
>>> coverage.
>>
>> Sounds good.
>>
>> Brad
>>
>>
>



From jamil.j.nimeh at oracle.com  Mon May 21 18:36:51 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 21 May 2018 11:36:51 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <3dda646c-2854-cdf2-cc1b-4d2c3133d787@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <3dda646c-2854-cdf2-cc1b-4d2c3133d787@oracle.com>
Message-ID: 

And the fun just keeps going!? Round 7.

This revision removes wrap/unwrap support for ChaCha20 and 
ChaCha20-Poly1305 until there is a standardized key wrapping approach 
for these ciphers (similar to how AES has its own key wrapping scheme in 
RFC 3394).

Initializing the cipher with WRAP/UNWRAP mode will throw 
UnsupportedOperationException and likewise the wrap/unwrap methods will 
throw IllegalStateException.

http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.07/

Thanks,

--Jamil


On 05/16/2018 12:05 PM, Jamil Nimeh wrote:
>
> Round 6.
>
> This brings ChaCha20/ChaCha20-Poly1305 into conformance with Cipher's 
> specification when forms of init that take AlgorithmParameters or 
> AlgorithmParameterSpec are used. Previously, a non-null AP or APS 
> object was required.? In order to better conform to the specification, 
> if a null AP or APS is provided for these ciphers, a random nonce will 
> be generated and the counter will be set to 1, just as is currently 
> done with valid forms of init that don't take an AP or APS object 
> (e.g. Cipher.init(int, Key, SecureRandom) ).? Per the spec in Cipher, 
> this is only true for ENCRYPT_MODE and will throw InvalidKeyException 
> when done in DECRYPT_MODE.
>
> I also added a few test cases that exercise these code paths in the 
> ChaCha20Poly1305Parameters.java test case.
>
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>
> Thanks,
>
> --Jamil
>
>
> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>
>> Round 5.
>>
>> This adds Sean's comments.? Sean, I was never able to execute a case 
>> on init where a half-baked object would fail.? In most cases it would 
>> fail in checks in javax.crypto.Cipher before it ever made it down to 
>> my code.? I'm pretty confident the init sequence is OK.? I did move 
>> the setting of a few data members toward the end of the init sequence 
>> but setting the key and nonce is necessary before creating the 
>> initial state, which is then used for generating an authentication 
>> key for AEAD mode and generating keystream.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>
>> Also the CSR has been finalized and can be found here:
>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>
>> --Jamil
>>
>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>
>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>> mostly:
>>>
>>>   * Added words in the description of javax.crypto.Cipher
>>>     recommending callers reinitialize the Cipher to use different
>>>     nonces after each complete encryption or decryption (similar
>>>     language to what exists already for AES-GCM encryption).
>>>   * Added an additional test case for ChaCha20NoReuse
>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>     cleaned up the code a bit based on comments from the field.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>
>>> Thanks!
>>>
>>> --Jamil
>>>
>>>
>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>
>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>> and only retain the key bytes as an object field (thanks Thomas for 
>>>> catching this)
>>>>
>>>> * Added additional protections against key/nonce reuse. This is a 
>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances of 
>>>> these ciphers will no longer allow you to do subsequent 
>>>> doUpdate/doFinal calls after the first doFinal without 
>>>> re-initializing the cipher with either a new key or nonce. 
>>>> Attempting to reuse the cipher without a new initialization will 
>>>> throw an IllegalStateException.? This is similar to the behavior of 
>>>> AES-GCM in encrypt mode, but for ChaCha20 it needs to be done for 
>>>> both encrypt and decrypt.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>
>>>> Thanks,
>>>> --Jamil
>>>>
>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>> Hello everyone,
>>>>>
>>>>> This is a quick update to the previous webrev:
>>>>>
>>>>> * When using the form of engineInit that does only takes op, key 
>>>>> and random, the nonce will always be random even if the random 
>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>
>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>
>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>> separator from a System property directly.? It calls 
>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>> classes in com.sun.crypto.provider do it.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>
>>>>> Thanks,
>>>>>
>>>>> --Jamil
>>>>>
>>>>>
>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>> Hello all,
>>>>>>
>>>>>> This is a request for review for the ChaCha20 and 
>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>> the ciphers are listed below.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>> http://openjdk.java.net/jeps/329
>>>>>>
>>>>>> Thanks,
>>>>>> --Jamil
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tom.w.hood at gmail.com  Tue May 22 02:48:27 2018
From: tom.w.hood at gmail.com (Tom Hood)
Date: Mon, 21 May 2018 19:48:27 -0700
Subject: JNLP launched legacy app needs to override jdk.tls.disabledAlgorithms
Message-ID: 

Hi,

Our legacy app will no longer launch with JNLP as of Java 8u171 and 8u172
due to the addition of "3DES_EDE_CBC" to the global java.security file's
"jdk.tls.disabledAlgorithms" property.

Schedule constraints do not allow us to upgrade our application to a
stronger cipher suite at this time and our customer is okay with continuing
to run with a compromised cipher suite in the near term for our legacy app.

Problem is we cannot (and probably should not) simply edit the global
/lib/security/java.security file.  Also, we would prefer not to
edit "Runtime Parameters" in the java control panel on each user's PC to
specify an override property file.  We would like a way to override in a
JNLP launch.  Is this possible?

Other info about the app:
- JNLP has security element:  
- SSL connection that uses the compromised cipher suite is coming from
inside the guts of an antiquated, unsupported ORB implementation
(Visibroker 5.2.1).  Its source code is not available.  It does not support
a stronger cipher suite.

Things I've tried:

(1) add an overrides file with System property "java.security.properties"

It doesn't appear there is a way to do this for a JNLP launch.  I tried
each of the following individually and none had the desired effect:





None of them have any effect except the last one which sets the system
property before main() starts, but that doesn't help, because it has the
"jnlp." prefix which isn't what the Security class expects.

Since "-D" is not listed as a secure arg for "java-vm-args", it looks like
this is not possible by design, despite the jnlp file having
.  Reference doc:
https://docs.oracle.com/javase/8/docs/technotes/guides/javaws/developersguide/syntax.html#resources

(2) At start of app's main(), call
Security.setProperty("jdk.tls.disabledAlgorithms",
newvalue)

JNLP launch: no change; fails same way
Eclipse run as regular Java app: now works

This leads me to believe the old value for the property is used and/or
cached in places other than the Security class *before* main starts for a
JNLP launch compared to when run as a regular Java app.

(3) At start of app's main, use reflection as follows:

(a) with reflection: force loading of
sun.security.ssl.SSLAlgorithmConstraints class via Class.forName
(b) call Security.setProperty("jdk.tls.disabledAlgorithms", newvalue)
(c) with reflection: SSLAlgorithmConstraints.tlsDisabledAlgorithms = new
sun.security.util.DisabledAlgorithmConstraints(PROPERTY_TLS_DISABLED_ARGS)
(d) call Security.setProperty("jdk.tls.disabledAlgorithms", oldvalue)

JNLP launch: no change; fails same way
Eclipse run as regular Java app: now works; without substep (c) it fails
same way

The old value must have been used and/or cached elsewhere besides
SSLAgorithmConstraints for a JNLP launch compared to running as a regular
java app.

Unfortunately, I'm not sure I have the source code for sun.* that matches
up with 8u172, otherwise I would try to find where else that property is
read.  Even if I could get the reflection to work, it seems all too fragile
and likely to break in future Java updates.  I'd prefer a different
approach.

Any suggestions?

Thank you,
-- Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun.wang at oracle.com  Tue May 22 02:57:51 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 22 May 2018 10:57:51 +0800
Subject: RFR CSR 8203460: Update xmldsig implementation to latest version of
 Apache Santuario
Message-ID: <54D9DAEE-F409-47CC-8F0B-AC606FCA565A@oracle.com>

Please take a review at

   https://bugs.openjdk.java.net/browse/JDK-8203460

The current XMLDSig provider implementation is based on Apache Santuario 1.5.4. We'll update it to be 2.1.1. New algorithms are added.

Thanks
Max



From sha.jiang at oracle.com  Tue May 22 03:30:18 2018
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Tue, 22 May 2018 11:30:18 +0800
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <3dda646c-2854-cdf2-cc1b-4d2c3133d787@oracle.com>
 
Message-ID: <441c12c7-3620-f1bd-86af-6a24d47470b9@oracle.com>

Hi Jamil,

-- ChaCha20Cipher.java
 ?497???? /**
 ?498????? * Perform additional initialization actions based on the key 
and operation
 ?499????? * type.
 ?500????? *
 ?501????? * @param opmode the type of operation to do.? This value must 
be either
 ?502????? *????? {@code Cipher.ENCRYPT_MODE} or {@code Cipher.DECRYPT_MODE}
 ?503????? * @param key a 256-bit key suitable for ChaCha20
 ?504????? * @param newNonce the new nonce value for this initialization.
 ?505????? *
 ?506????? * @throws UnsupportedOperationException if the {@code opmode} 
parameter
 ?507????? *????? is {@code Cipher.WRAP_MODE} or {@code Cipher.UNWRAP_MODE}
 ?508????? *????? (currently unsupported).
 ?509????? * @throws InvalidKeyException if the {@code opmode} parameter 
is not
 ?510????? *????? {@code Cipher.ENCRYPT_MODE} or {@code 
Cipher.DECRYPT_MODE}, or
 ?511????? *????? if the key format is not {@code RAW}.
 ?512????? */
 ?513???? private void init(int opmode, Key key, byte[] newNonce)
 ?514???????????? throws InvalidKeyException {
 ?515???????? if ((opmode == Cipher.WRAP_MODE) || (opmode == 
Cipher.UNWRAP_MODE)) {
 ?516???????????? throw new UnsupportedOperationException(
 ?517???????????????????? "WRAP_MODE and UNWRAP_MODE are not currently 
supported");
 ?518???????? } else if ((opmode != Cipher.ENCRYPT_MODE) &&
 ?519???????????????? (opmode != Cipher.DECRYPT_MODE)) {
 ?520???????????? throw new InvalidKeyException("Unknown opmode: " + 
opmode);
 ?521???????? }
With my understanding, WRAP_MODE and UNWRAP_MODE can be allowed, though 
they are not supported yet. But the doc on param opmode stats the 
allowed modes are only ENCRYPT_MODE and DECRYPT_MODE.
In fact, the doc on param opmode in method engineInit(int opmode, Key 
key, SecureRandom random) implies that WRAP_MODE can be accepted.
 ?242????? * @param opmode the type of operation to do.? This value may 
not be
 ?243????? *????? {@code Cipher.DECRYPT_MODE} or {@code Cipher.UNWRAP} 
mode because
 ?244????? *????? it must generate random parameters like the nonce.
BTW, Cipher.UNWRAP or Cipher.UNWRAP_MODE?

Best regards,
John Jiang

On 22/05/2018 02:36, Jamil Nimeh wrote:
>
> And the fun just keeps going!? Round 7.
>
> This revision removes wrap/unwrap support for ChaCha20 and 
> ChaCha20-Poly1305 until there is a standardized key wrapping approach 
> for these ciphers (similar to how AES has its own key wrapping scheme 
> in RFC 3394).
>
> Initializing the cipher with WRAP/UNWRAP mode will throw 
> UnsupportedOperationException and likewise the wrap/unwrap methods 
> will throw IllegalStateException.
>
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.07/
>
> Thanks,
>
> --Jamil
>
>
> On 05/16/2018 12:05 PM, Jamil Nimeh wrote:
>>
>> Round 6.
>>
>> This brings ChaCha20/ChaCha20-Poly1305 into conformance with Cipher's 
>> specification when forms of init that take AlgorithmParameters or 
>> AlgorithmParameterSpec are used. Previously, a non-null AP or APS 
>> object was required.? In order to better conform to the 
>> specification, if a null AP or APS is provided for these ciphers, a 
>> random nonce will be generated and the counter will be set to 1, just 
>> as is currently done with valid forms of init that don't take an AP 
>> or APS object (e.g. Cipher.init(int, Key, SecureRandom) ). Per the 
>> spec in Cipher, this is only true for ENCRYPT_MODE and will throw 
>> InvalidKeyException when done in DECRYPT_MODE.
>>
>> I also added a few test cases that exercise these code paths in the 
>> ChaCha20Poly1305Parameters.java test case.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>>
>> Thanks,
>>
>> --Jamil
>>
>>
>> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>>
>>> Round 5.
>>>
>>> This adds Sean's comments.? Sean, I was never able to execute a case 
>>> on init where a half-baked object would fail.? In most cases it 
>>> would fail in checks in javax.crypto.Cipher before it ever made it 
>>> down to my code. I'm pretty confident the init sequence is OK.? I 
>>> did move the setting of a few data members toward the end of the 
>>> init sequence but setting the key and nonce is necessary before 
>>> creating the initial state, which is then used for generating an 
>>> authentication key for AEAD mode and generating keystream.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>
>>> Also the CSR has been finalized and can be found here:
>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>
>>> --Jamil
>>>
>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>
>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>> mostly:
>>>>
>>>>   * Added words in the description of javax.crypto.Cipher
>>>>     recommending callers reinitialize the Cipher to use different
>>>>     nonces after each complete encryption or decryption (similar
>>>>     language to what exists already for AES-GCM encryption).
>>>>   * Added an additional test case for ChaCha20NoReuse
>>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>>     cleaned up the code a bit based on comments from the field.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>
>>>> Thanks!
>>>>
>>>> --Jamil
>>>>
>>>>
>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>
>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>> for catching this)
>>>>>
>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances of 
>>>>> these ciphers will no longer allow you to do subsequent 
>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>> throw an IllegalStateException.? This is similar to the behavior 
>>>>> of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done 
>>>>> for both encrypt and decrypt.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>
>>>>> Thanks,
>>>>> --Jamil
>>>>>
>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>> Hello everyone,
>>>>>>
>>>>>> This is a quick update to the previous webrev:
>>>>>>
>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>> and random, the nonce will always be random even if the random 
>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>
>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>
>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>> separator from a System property directly.? It calls 
>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --Jamil
>>>>>>
>>>>>>
>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>> the ciphers are listed below.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --Jamil
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From anthony.scarpino at oracle.com  Tue May 22 03:56:36 2018
From: anthony.scarpino at oracle.com (Anthony Scarpino)
Date: Mon, 21 May 2018 20:56:36 -0700
Subject: JNLP launched legacy app needs to override
 jdk.tls.disabledAlgorithms
In-Reply-To: 
References: 
Message-ID: <528DB0B9-9A13-4B49-B957-0028BE23A9A9@oracle.com>

The property can get loaded very early and it can be hard to get ahead of it. 

The only suggestion I can think of is your option 1 isn't doing what you expect. To append to the existing java.security properties, you use one equals, ?=?. To override you use 2, ?==?.  So you may want something like:
> java-vm-args="-Djava.security.properties==override_file" 

Tony

> On May 21, 2018, at 7:48 PM, Tom Hood  wrote:
> 
> Hi,
> 
> Our legacy app will no longer launch with JNLP as of Java 8u171 and 8u172 due to the addition of "3DES_EDE_CBC" to the global java.security file's "jdk.tls.disabledAlgorithms" property.
> 
> Schedule constraints do not allow us to upgrade our application to a stronger cipher suite at this time and our customer is okay with continuing to run with a compromised cipher suite in the near term for our legacy app.
> 
> Problem is we cannot (and probably should not) simply edit the global /lib/security/java.security file.  Also, we would prefer not to edit "Runtime Parameters" in the java control panel on each user's PC to specify an override property file.  We would like a way to override in a JNLP launch.  Is this possible?
> 
> Other info about the app:
> - JNLP has security element:  
> - SSL connection that uses the compromised cipher suite is coming from inside the guts of an antiquated, unsupported ORB implementation (Visibroker 5.2.1).  Its source code is not available.  It does not support a stronger cipher suite.
> 
> Things I've tried:
> 
> (1) add an overrides file with System property "java.security.properties"
> 
> It doesn't appear there is a way to do this for a JNLP launch.  I tried each of the following individually and none had the desired effect:
> 
> 
> 
> 
> 
> None of them have any effect except the last one which sets the system property before main() starts, but that doesn't help, because it has the "jnlp." prefix which isn't what the Security class expects.
> 
> Since "-D" is not listed as a secure arg for "java-vm-args", it looks like this is not possible by design, despite the jnlp file having .  Reference doc:  https://docs.oracle.com/javase/8/docs/technotes/guides/javaws/developersguide/syntax.html#resources
> 
> (2) At start of app's main(), call Security.setProperty("jdk.tls.disabledAlgorithms", newvalue)
> 
> JNLP launch: no change; fails same way
> Eclipse run as regular Java app: now works
> 
> This leads me to believe the old value for the property is used and/or cached in places other than the Security class *before* main starts for a JNLP launch compared to when run as a regular Java app.
> 
> (3) At start of app's main, use reflection as follows:
> 
> (a) with reflection: force loading of sun.security.ssl.SSLAlgorithmConstraints class via Class.forName
> (b) call Security.setProperty("jdk.tls.disabledAlgorithms", newvalue)
> (c) with reflection: SSLAlgorithmConstraints.tlsDisabledAlgorithms = new sun.security.util.DisabledAlgorithmConstraints(PROPERTY_TLS_DISABLED_ARGS)
> (d) call Security.setProperty("jdk.tls.disabledAlgorithms", oldvalue)
> 
> JNLP launch: no change; fails same way
> Eclipse run as regular Java app: now works; without substep (c) it fails same way
> 
> The old value must have been used and/or cached elsewhere besides SSLAgorithmConstraints for a JNLP launch compared to running as a regular java app.
> 
> Unfortunately, I'm not sure I have the source code for sun.* that matches up with 8u172, otherwise I would try to find where else that property is read.  Even if I could get the reflection to work, it seems all too fragile and likely to break in future Java updates.  I'd prefer a different approach.
> 
> Any suggestions?
> 
> Thank you,
> -- Tom
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jamil.j.nimeh at oracle.com  Tue May 22 04:07:32 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Mon, 21 May 2018 21:07:32 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <441c12c7-3620-f1bd-86af-6a24d47470b9@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <3dda646c-2854-cdf2-cc1b-4d2c3133d787@oracle.com>
 
 <441c12c7-3620-f1bd-86af-6a24d47470b9@oracle.com>
Message-ID: 

Hi John, comments in-line

On 5/21/2018 8:30 PM, sha.jiang at oracle.com wrote:
>
> Hi Jamil,
>
> -- ChaCha20Cipher.java
> ?497???? /**
> ?498????? * Perform additional initialization actions based on the key 
> and operation
> ?499????? * type.
> ?500????? *
> ?501????? * @param opmode the type of operation to do.? This value 
> must be either
> ?502????? *????? {@code Cipher.ENCRYPT_MODE} or {@code 
> Cipher.DECRYPT_MODE}
> ?503????? * @param key a 256-bit key suitable for ChaCha20
> ?504????? * @param newNonce the new nonce value for this initialization.
> ?505????? *
> ?506????? * @throws UnsupportedOperationException if the {@code 
> opmode} parameter
> ?507????? *????? is {@code Cipher.WRAP_MODE} or {@code Cipher.UNWRAP_MODE}
> ?508????? *????? (currently unsupported).
> ?509????? * @throws InvalidKeyException if the {@code opmode} 
> parameter is not
> ?510????? *????? {@code Cipher.ENCRYPT_MODE} or {@code 
> Cipher.DECRYPT_MODE}, or
> ?511????? *????? if the key format is not {@code RAW}.
> ?512????? */
> ?513???? private void init(int opmode, Key key, byte[] newNonce)
> ?514???????????? throws InvalidKeyException {
> ?515???????? if ((opmode == Cipher.WRAP_MODE) || (opmode == 
> Cipher.UNWRAP_MODE)) {
> ?516???????????? throw new UnsupportedOperationException(
> ?517???????????????????? "WRAP_MODE and UNWRAP_MODE are not currently 
> supported");
> ?518???????? } else if ((opmode != Cipher.ENCRYPT_MODE) &&
> ?519???????????????? (opmode != Cipher.DECRYPT_MODE)) {
> ?520???????????? throw new InvalidKeyException("Unknown opmode: " + 
> opmode);
> ?521???????? }
> With my understanding, WRAP_MODE and UNWRAP_MODE can be allowed, 
> though they are not supported yet. But the doc on param opmode stats 
> the allowed modes are only ENCRYPT_MODE and DECRYPT_MODE.
> In fact, the doc on param opmode in method engineInit(int opmode, Key 
> key, SecureRandom random) implies that WRAP_MODE can be accepted.
>
JN: Given that Cipher.init and CipherSpi.init both state that UOE should 
be thrown if WRAP/UNWRAP_MODE is provided and the underlying CipherSpi 
does not support those modes, you should NOT accept those values for the 
opmode parameter.? If and when we do support those modes of operation, 
then I will loosen the check and allow it.? But you shouldn't allow a 
Cipher object to be initialized with a mode that you know isn't 
supported.? I would much rather see things behave in a fail-fast manner 
where it is plausible, and this is one of those cases.

I will clean up the method header comments for engineInit to reflect the 
change I made down in the private init common method.
>
> ?242????? * @param opmode the type of operation to do.? This value may 
> not be
> ?243????? *????? {@code Cipher.DECRYPT_MODE} or {@code Cipher.UNWRAP} 
> mode because
> ?244????? *????? it must generate random parameters like the nonce.
> BTW, Cipher.UNWRAP or Cipher.UNWRAP_MODE?
>
It should be UNWRAP_MODE, good catch.
>
>
> Best regards,
> John Jiang
>
> On 22/05/2018 02:36, Jamil Nimeh wrote:
>>
>> And the fun just keeps going!? Round 7.
>>
>> This revision removes wrap/unwrap support for ChaCha20 and 
>> ChaCha20-Poly1305 until there is a standardized key wrapping approach 
>> for these ciphers (similar to how AES has its own key wrapping scheme 
>> in RFC 3394).
>>
>> Initializing the cipher with WRAP/UNWRAP mode will throw 
>> UnsupportedOperationException and likewise the wrap/unwrap methods 
>> will throw IllegalStateException.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.07/
>>
>> Thanks,
>>
>> --Jamil
>>
>>
>> On 05/16/2018 12:05 PM, Jamil Nimeh wrote:
>>>
>>> Round 6.
>>>
>>> This brings ChaCha20/ChaCha20-Poly1305 into conformance with 
>>> Cipher's specification when forms of init that take 
>>> AlgorithmParameters or AlgorithmParameterSpec are used. Previously, 
>>> a non-null AP or APS object was required.? In order to better 
>>> conform to the specification, if a null AP or APS is provided for 
>>> these ciphers, a random nonce will be generated and the counter will 
>>> be set to 1, just as is currently done with valid forms of init that 
>>> don't take an AP or APS object (e.g. Cipher.init(int, Key, 
>>> SecureRandom) ).? Per the spec in Cipher, this is only true for 
>>> ENCRYPT_MODE and will throw InvalidKeyException when done in 
>>> DECRYPT_MODE.
>>>
>>> I also added a few test cases that exercise these code paths in the 
>>> ChaCha20Poly1305Parameters.java test case.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>>>
>>> Thanks,
>>>
>>> --Jamil
>>>
>>>
>>> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>>>
>>>> Round 5.
>>>>
>>>> This adds Sean's comments.? Sean, I was never able to execute a 
>>>> case on init where a half-baked object would fail.? In most cases 
>>>> it would fail in checks in javax.crypto.Cipher before it ever made 
>>>> it down to my code.? I'm pretty confident the init sequence is OK.? 
>>>> I did move the setting of a few data members toward the end of the 
>>>> init sequence but setting the key and nonce is necessary before 
>>>> creating the initial state, which is then used for generating an 
>>>> authentication key for AEAD mode and generating keystream.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>>
>>>> Also the CSR has been finalized and can be found here:
>>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>>
>>>> --Jamil
>>>>
>>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>>
>>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>>> mostly:
>>>>>
>>>>>   * Added words in the description of javax.crypto.Cipher
>>>>>     recommending callers reinitialize the Cipher to use different
>>>>>     nonces after each complete encryption or decryption (similar
>>>>>     language to what exists already for AES-GCM encryption).
>>>>>   * Added an additional test case for ChaCha20NoReuse
>>>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>>>     cleaned up the code a bit based on comments from the field.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --Jamil
>>>>>
>>>>>
>>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>>
>>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>>> for catching this)
>>>>>>
>>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances 
>>>>>> of these ciphers will no longer allow you to do subsequent 
>>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>>> throw an IllegalStateException.? This is similar to the behavior 
>>>>>> of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done 
>>>>>> for both encrypt and decrypt.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>>
>>>>>> Thanks,
>>>>>> --Jamil
>>>>>>
>>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>> This is a quick update to the previous webrev:
>>>>>>>
>>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>>> and random, the nonce will always be random even if the random 
>>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>>
>>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>>
>>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>>> separator from a System property directly. It calls 
>>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --Jamil
>>>>>>>
>>>>>>>
>>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>>> the ciphers are listed below.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> --Jamil
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From tom.w.hood at gmail.com  Tue May 22 14:31:31 2018
From: tom.w.hood at gmail.com (Tom Hood)
Date: Tue, 22 May 2018 07:31:31 -0700
Subject: JNLP launched legacy app needs to override
 jdk.tls.disabledAlgorithms
In-Reply-To: <528DB0B9-9A13-4B49-B957-0028BE23A9A9@oracle.com>
References: 
 <528DB0B9-9A13-4B49-B957-0028BE23A9A9@oracle.com>
Message-ID: 

Clarification.  When I said for option (1) "none had the desired effect", I
mean at the start of main I confirmed with System.getProperty that the
java.security.properties property isn't getting set thru the JNLP launch,
so I doubt "==" will make any difference compared to "=".  As far as
"override" vs. "append" either one in theory could be made to work for our
use case.  The goal is to be able to change the value of the
"jdk.tls.disabledAlgorithms" property so it no longer has 3DES_EDE_CBC at
the start of the jvm.

On Mon, May 21, 2018 at 8:56 PM, Anthony Scarpino <
anthony.scarpino at oracle.com> wrote:

> The property can get loaded very early and it can be hard to get ahead of
> it.
>
> The only suggestion I can think of is your option 1 isn't doing what you
> expect. To append to the existing java.security properties, you use one
> equals, ?=?. To override you use 2, ?==?.  So you may want something like:
>
> java-vm-args="-Djava.security.properties==override_file"
>
>
> Tony
>
> On May 21, 2018, at 7:48 PM, Tom Hood  wrote:
>
> Hi,
>
> Our legacy app will no longer launch with JNLP as of Java 8u171 and 8u172
> due to the addition of "3DES_EDE_CBC" to the global java.security file's
> "jdk.tls.disabledAlgorithms" property.
>
> Schedule constraints do not allow us to upgrade our application to a
> stronger cipher suite at this time and our customer is okay with continuing
> to run with a compromised cipher suite in the near term for our legacy app.
>
> Problem is we cannot (and probably should not) simply edit the global
> /lib/security/java.security file.  Also, we would prefer not
> to edit "Runtime Parameters" in the java control panel on each user's PC to
> specify an override property file.  We would like a way to override in a
> JNLP launch.  Is this possible?
>
> Other info about the app:
> - JNLP has security element:  
> - SSL connection that uses the compromised cipher suite is coming from
> inside the guts of an antiquated, unsupported ORB implementation
> (Visibroker 5.2.1).  Its source code is not available.  It does not support
> a stronger cipher suite.
>
> Things I've tried:
>
> (1) add an overrides file with System property "java.security.properties"
>
> It doesn't appear there is a way to do this for a JNLP launch.  I tried
> each of the following individually and none had the desired effect:
>
>  .../>
> 
> 
>
> None of them have any effect except the last one which sets the system
> property before main() starts, but that doesn't help, because it has the
> "jnlp." prefix which isn't what the Security class expects.
>
> Since "-D" is not listed as a secure arg for "java-vm-args", it looks like
> this is not possible by design, despite the jnlp file having
> .  Reference doc:
> https://docs.oracle.com/javase/8/docs/technotes/
> guides/javaws/developersguide/syntax.html#resources
>
> (2) At start of app's main(), call Security.setProperty("jdk.tls.disabledAlgorithms",
> newvalue)
>
> JNLP launch: no change; fails same way
> Eclipse run as regular Java app: now works
>
> This leads me to believe the old value for the property is used and/or
> cached in places other than the Security class *before* main starts for a
> JNLP launch compared to when run as a regular Java app.
>
> (3) At start of app's main, use reflection as follows:
>
> (a) with reflection: force loading of sun.security.ssl.SSLAlgorithmConstraints
> class via Class.forName
> (b) call Security.setProperty("jdk.tls.disabledAlgorithms", newvalue)
> (c) with reflection: SSLAlgorithmConstraints.tlsDisabledAlgorithms = new
> sun.security.util.DisabledAlgorithmConstraints(PROPERTY_TLS_DISABLED_ARGS)
> (d) call Security.setProperty("jdk.tls.disabledAlgorithms", oldvalue)
>
> JNLP launch: no change; fails same way
> Eclipse run as regular Java app: now works; without substep (c) it fails
> same way
>
> The old value must have been used and/or cached elsewhere besides
> SSLAgorithmConstraints for a JNLP launch compared to running as a regular
> java app.
>
> Unfortunately, I'm not sure I have the source code for sun.* that matches
> up with 8u172, otherwise I would try to find where else that property is
> read.  Even if I could get the reflection to work, it seems all too fragile
> and likely to break in future Java updates.  I'd prefer a different
> approach.
>
> Any suggestions?
>
> Thank you,
> -- Tom
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun.wang at oracle.com  Tue May 22 15:25:13 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Tue, 22 May 2018 23:25:13 +0800
Subject: RFR 8201815: Use Mozilla Public Suffix List
Message-ID: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com>

Please take a review at

   http://cr.openjdk.java.net/~weijun/8201815/webrev.00/

With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs.

There is no plan to update the data in a different channel other than a JDK release.

Thanks
Max



From erik.joelsson at oracle.com  Tue May 22 15:44:36 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 22 May 2018 08:44:36 -0700
Subject: RFR 8201815: Use Mozilla Public Suffix List
In-Reply-To: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com>
References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com>
Message-ID: <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com>

Build changes look ok.

/Erik


On 2018-05-22 08:25, Weijun Wang wrote:
> Please take a review at
>
>     http://cr.openjdk.java.net/~weijun/8201815/webrev.00/
>
> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs.
>
> There is no plan to update the data in a different channel other than a JDK release.
>
> Thanks
> Max
>



From sean.mullan at oracle.com  Tue May 22 17:29:40 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Tue, 22 May 2018 13:29:40 -0400
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <3dda646c-2854-cdf2-cc1b-4d2c3133d787@oracle.com>
 
Message-ID: <018ae094-578c-5282-c777-cf75190e6554@oracle.com>

Question on engineGetParameters() in ChaCha20Cipher.java:

  231     protected AlgorithmParameters engineGetParameters() {
  232         return null;
  233     }

Shouldn't this return the params that are passed into engineInit()? 
Also, when null is passed in and the params are generated using default 
values, this method should return those params. From 
CipherSpi.engineInit(int opmode, Key key, SecureRandom):

"The generated parameters can be retrieved using engineGetParameters or 
engineGetIV (if the parameter is an IV)."

--Sean

On 5/21/18 2:36 PM, Jamil Nimeh wrote:
> And the fun just keeps going!? Round 7.
> 
> This revision removes wrap/unwrap support for ChaCha20 and 
> ChaCha20-Poly1305 until there is a standardized key wrapping approach 
> for these ciphers (similar to how AES has its own key wrapping scheme in 
> RFC 3394).
> 
> Initializing the cipher with WRAP/UNWRAP mode will throw 
> UnsupportedOperationException and likewise the wrap/unwrap methods will 
> throw IllegalStateException.
> 
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.07/
> 
> Thanks,
> 
> --Jamil
> 
> 
> On 05/16/2018 12:05 PM, Jamil Nimeh wrote:
>>
>> Round 6.
>>
>> This brings ChaCha20/ChaCha20-Poly1305 into conformance with Cipher's 
>> specification when forms of init that take AlgorithmParameters or 
>> AlgorithmParameterSpec are used. Previously, a non-null AP or APS 
>> object was required.? In order to better conform to the specification, 
>> if a null AP or APS is provided for these ciphers, a random nonce will 
>> be generated and the counter will be set to 1, just as is currently 
>> done with valid forms of init that don't take an AP or APS object 
>> (e.g. Cipher.init(int, Key, SecureRandom) ).? Per the spec in Cipher, 
>> this is only true for ENCRYPT_MODE and will throw InvalidKeyException 
>> when done in DECRYPT_MODE.
>>
>> I also added a few test cases that exercise these code paths in the 
>> ChaCha20Poly1305Parameters.java test case.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>>
>> Thanks,
>>
>> --Jamil
>>
>>
>> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>>
>>> Round 5.
>>>
>>> This adds Sean's comments.? Sean, I was never able to execute a case 
>>> on init where a half-baked object would fail.? In most cases it would 
>>> fail in checks in javax.crypto.Cipher before it ever made it down to 
>>> my code.? I'm pretty confident the init sequence is OK.? I did move 
>>> the setting of a few data members toward the end of the init sequence 
>>> but setting the key and nonce is necessary before creating the 
>>> initial state, which is then used for generating an authentication 
>>> key for AEAD mode and generating keystream.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>
>>> Also the CSR has been finalized and can be found here:
>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>
>>> --Jamil
>>>
>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>
>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>> mostly:
>>>>
>>>>   * Added words in the description of javax.crypto.Cipher
>>>>     recommending callers reinitialize the Cipher to use different
>>>>     nonces after each complete encryption or decryption (similar
>>>>     language to what exists already for AES-GCM encryption).
>>>>   * Added an additional test case for ChaCha20NoReuse
>>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>>     cleaned up the code a bit based on comments from the field.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>
>>>> Thanks!
>>>>
>>>> --Jamil
>>>>
>>>>
>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>
>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>> and only retain the key bytes as an object field (thanks Thomas for 
>>>>> catching this)
>>>>>
>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances of 
>>>>> these ciphers will no longer allow you to do subsequent 
>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>> throw an IllegalStateException.? This is similar to the behavior of 
>>>>> AES-GCM in encrypt mode, but for ChaCha20 it needs to be done for 
>>>>> both encrypt and decrypt.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>
>>>>> Thanks,
>>>>> --Jamil
>>>>>
>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>> Hello everyone,
>>>>>>
>>>>>> This is a quick update to the previous webrev:
>>>>>>
>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>> and random, the nonce will always be random even if the random 
>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>
>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>
>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>> separator from a System property directly.? It calls 
>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --Jamil
>>>>>>
>>>>>>
>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>> the ciphers are listed below.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --Jamil
>>>>>>
>>>>>
>>>>
>>>
>>
> 


From jamil.j.nimeh at oracle.com  Tue May 22 17:37:06 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 22 May 2018 10:37:06 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <018ae094-578c-5282-c777-cf75190e6554@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <3dda646c-2854-cdf2-cc1b-4d2c3133d787@oracle.com>
 
 <018ae094-578c-5282-c777-cf75190e6554@oracle.com>
Message-ID: <7b8aa27e-d5d1-1d2a-1b03-632684cd8364@oracle.com>

Wow, good catch.? This is something that got left by the wayside, 
probably from one of the earliest revisions of the code when we didn't 
have an AlgorithmParameters implementation.? I'll get this fixed up 
today.? Shouldn't take too long to get this working.? I think it should 
return null if it is ChaCha20 since there's no AlgorithmParameters 
definition for ChaCha20, and return a ChaCha20Poly1305Parameters for 
ChaCha20-Poly1305.

For the latter Cipher, it shouldn't matter how you init the Cipher.? We 
can return the AP with the nonce value, however it came into being 
(random, AP or APS).

--Jamil


On 05/22/2018 10:29 AM, Sean Mullan wrote:
> Question on engineGetParameters() in ChaCha20Cipher.java:
>
> ?231???? protected AlgorithmParameters engineGetParameters() {
> ?232???????? return null;
> ?233???? }
>
> Shouldn't this return the params that are passed into engineInit()? 
> Also, when null is passed in and the params are generated using 
> default values, this method should return those params. From 
> CipherSpi.engineInit(int opmode, Key key, SecureRandom):
>
> "The generated parameters can be retrieved using engineGetParameters 
> or engineGetIV (if the parameter is an IV)."
>
> --Sean
>
> On 5/21/18 2:36 PM, Jamil Nimeh wrote:
>> And the fun just keeps going!? Round 7.
>>
>> This revision removes wrap/unwrap support for ChaCha20 and 
>> ChaCha20-Poly1305 until there is a standardized key wrapping approach 
>> for these ciphers (similar to how AES has its own key wrapping scheme 
>> in RFC 3394).
>>
>> Initializing the cipher with WRAP/UNWRAP mode will throw 
>> UnsupportedOperationException and likewise the wrap/unwrap methods 
>> will throw IllegalStateException.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.07/
>>
>> Thanks,
>>
>> --Jamil
>>
>>
>> On 05/16/2018 12:05 PM, Jamil Nimeh wrote:
>>>
>>> Round 6.
>>>
>>> This brings ChaCha20/ChaCha20-Poly1305 into conformance with 
>>> Cipher's specification when forms of init that take 
>>> AlgorithmParameters or AlgorithmParameterSpec are used. Previously, 
>>> a non-null AP or APS object was required.? In order to better 
>>> conform to the specification, if a null AP or APS is provided for 
>>> these ciphers, a random nonce will be generated and the counter will 
>>> be set to 1, just as is currently done with valid forms of init that 
>>> don't take an AP or APS object (e.g. Cipher.init(int, Key, 
>>> SecureRandom) ). Per the spec in Cipher, this is only true for 
>>> ENCRYPT_MODE and will throw InvalidKeyException when done in 
>>> DECRYPT_MODE.
>>>
>>> I also added a few test cases that exercise these code paths in the 
>>> ChaCha20Poly1305Parameters.java test case.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>>>
>>> Thanks,
>>>
>>> --Jamil
>>>
>>>
>>> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>>>
>>>> Round 5.
>>>>
>>>> This adds Sean's comments.? Sean, I was never able to execute a 
>>>> case on init where a half-baked object would fail.? In most cases 
>>>> it would fail in checks in javax.crypto.Cipher before it ever made 
>>>> it down to my code. I'm pretty confident the init sequence is OK.? 
>>>> I did move the setting of a few data members toward the end of the 
>>>> init sequence but setting the key and nonce is necessary before 
>>>> creating the initial state, which is then used for generating an 
>>>> authentication key for AEAD mode and generating keystream.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>>
>>>> Also the CSR has been finalized and can be found here:
>>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>>
>>>> --Jamil
>>>>
>>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>>
>>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>>> mostly:
>>>>>
>>>>> ? * Added words in the description of javax.crypto.Cipher
>>>>> ??? recommending callers reinitialize the Cipher to use different
>>>>> ??? nonces after each complete encryption or decryption (similar
>>>>> ??? language to what exists already for AES-GCM encryption).
>>>>> ? * Added an additional test case for ChaCha20NoReuse
>>>>> ? * Made accessor methods for ChaCha20ParameterSpec final and
>>>>> ??? cleaned up the code a bit based on comments from the field.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --Jamil
>>>>>
>>>>>
>>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>>
>>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>>> for catching this)
>>>>>>
>>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances 
>>>>>> of these ciphers will no longer allow you to do subsequent 
>>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>>> throw an IllegalStateException.? This is similar to the behavior 
>>>>>> of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done 
>>>>>> for both encrypt and decrypt.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>>
>>>>>> Thanks,
>>>>>> --Jamil
>>>>>>
>>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>> This is a quick update to the previous webrev:
>>>>>>>
>>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>>> and random, the nonce will always be random even if the random 
>>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>>
>>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>>
>>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>>> separator from a System property directly. It calls 
>>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --Jamil
>>>>>>>
>>>>>>>
>>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>>> the ciphers are listed below.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> --Jamil
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>



From ecki at zusammenkunft.net  Tue May 22 18:19:51 2018
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 22 May 2018 18:19:51 +0000
Subject: JNLP launched legacy app needs to override
 jdk.tls.disabledAlgorithms
In-Reply-To: 
References: 
 <528DB0B9-9A13-4B49-B957-0028BE23A9A9@oracle.com>,
 
Message-ID: 

You probably don?t want to hear that, but now is a good time to convert this JNLP App into a stand alone Installer (possibly with updater).that will not only allow you to ship a pre-configured and matching JRE, but it will also solve the problem that you do not get javaws updates starting on January (easily) anymore.

JNLP does not allow to overwrite random properties for the started app.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: security-dev  on behalf of Tom Hood 
Sent: Tuesday, May 22, 2018 4:31:31 PM
To: Anthony Scarpino
Cc: security Dev OpenJDK; Smith, M'Lissa (Mission Systems)
Subject: Re: JNLP launched legacy app needs to override jdk.tls.disabledAlgorithms

Clarification.  When I said for option (1) "none had the desired effect", I mean at the start of main I confirmed with System.getProperty that the java.security.properties property isn't getting set thru the JNLP launch, so I doubt "==" will make any difference compared to "=".  As far as "override" vs. "append" either one in theory could be made to work for our use case.  The goal is to be able to change the value of the "jdk.tls.disabledAlgorithms" property so it no longer has 3DES_EDE_CBC at the start of the jvm.

On Mon, May 21, 2018 at 8:56 PM, Anthony Scarpino > wrote:
The property can get loaded very early and it can be hard to get ahead of it.

The only suggestion I can think of is your option 1 isn't doing what you expect. To append to the existing java.security properties, you use one equals, ?=?. To override you use 2, ?==?.  So you may want something like:
java-vm-args="-Djava.security.properties==override_file"

Tony

On May 21, 2018, at 7:48 PM, Tom Hood > wrote:

Hi,

Our legacy app will no longer launch with JNLP as of Java 8u171 and 8u172 due to the addition of "3DES_EDE_CBC" to the global java.security file's "jdk.tls.disabledAlgorithms" property.

Schedule constraints do not allow us to upgrade our application to a stronger cipher suite at this time and our customer is okay with continuing to run with a compromised cipher suite in the near term for our legacy app.

Problem is we cannot (and probably should not) simply edit the global /lib/security/java.security file.  Also, we would prefer not to edit "Runtime Parameters" in the java control panel on each user's PC to specify an override property file.  We would like a way to override in a JNLP launch.  Is this possible?

Other info about the app:
- JNLP has security element:  
- SSL connection that uses the compromised cipher suite is coming from inside the guts of an antiquated, unsupported ORB implementation (Visibroker 5.2.1).  Its source code is not available.  It does not support a stronger cipher suite.

Things I've tried:

(1) add an overrides file with System property "java.security.properties"

It doesn't appear there is a way to do this for a JNLP launch.  I tried each of the following individually and none had the desired effect:





None of them have any effect except the last one which sets the system property before main() starts, but that doesn't help, because it has the "jnlp." prefix which isn't what the Security class expects.

Since "-D" is not listed as a secure arg for "java-vm-args", it looks like this is not possible by design, despite the jnlp file having .  Reference doc:  https://docs.oracle.com/javase/8/docs/technotes/guides/javaws/developersguide/syntax.html#resources

(2) At start of app's main(), call Security.setProperty("jdk.tls.disabledAlgorithms", newvalue)

JNLP launch: no change; fails same way
Eclipse run as regular Java app: now works

This leads me to believe the old value for the property is used and/or cached in places other than the Security class *before* main starts for a JNLP launch compared to when run as a regular Java app.

(3) At start of app's main, use reflection as follows:

(a) with reflection: force loading of sun.security.ssl.SSLAlgorithmConstraints class via Class.forName
(b) call Security.setProperty("jdk.tls.disabledAlgorithms", newvalue)
(c) with reflection: SSLAlgorithmConstraints.tlsDisabledAlgorithms = new sun.security.util.DisabledAlgorithmConstraints(PROPERTY_TLS_DISABLED_ARGS)
(d) call Security.setProperty("jdk.tls.disabledAlgorithms", oldvalue)

JNLP launch: no change; fails same way
Eclipse run as regular Java app: now works; without substep (c) it fails same way

The old value must have been used and/or cached elsewhere besides SSLAgorithmConstraints for a JNLP launch compared to running as a regular java app.

Unfortunately, I'm not sure I have the source code for sun.* that matches up with 8u172, otherwise I would try to find where else that property is read.  Even if I could get the reflection to work, it seems all too fragile and likely to break in future Java updates.  I'd prefer a different approach.

Any suggestions?

Thank you,
-- Tom


-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From magnus.ihse.bursie at oracle.com  Tue May 22 20:21:55 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 22 May 2018 22:21:55 +0200
Subject: RFR 8201815: Use Mozilla Public Suffix List
In-Reply-To: <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com>
References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com>
 <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com>
Message-ID: <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com>

.. but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last. 

/Magnus

> 22 maj 2018 kl. 17:44 skrev Erik Joelsson :
> 
> Build changes look ok.
> 
> /Erik
> 
> 
>> On 2018-05-22 08:25, Weijun Wang wrote:
>> Please take a review at
>> 
>>    http://cr.openjdk.java.net/~weijun/8201815/webrev.00/
>> 
>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs.
>> 
>> There is no plan to update the data in a different channel other than a JDK release.
>> 
>> Thanks
>> Max
>> 
> 



From mbalao at redhat.com  Tue May 22 20:27:08 2018
From: mbalao at redhat.com (Martin Balao)
Date: Tue, 22 May 2018 17:27:08 -0300
Subject: RFR JDK-8029661: JDK-Support TLS v1.2 algorithm in SunPKCS11
 provider
In-Reply-To: 
References: 
 <42dcb5c2-0d98-1ae4-a26d-b79e0a5c9345@oracle.com>
 
Message-ID: 

Hi Valerie,

Webrev 03 with changes to TestTLS12.java is here:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.03
 * http://cr.openjdk.java.net/~mbalao/webrevs/8029661/8029661.webrev.03.zip

The reason why we need a dependency to sun.security.pkcs11.SunPKCS11 is to
instance such provider in run time with a custom configuration -instead of
getting one with a configuration from java.security-. In this particular
case, I'm interested in the SunPKCS11 provider to be FIPS -as this
reproduces a real case-. Other SunPKCS11 tests have this dependency too, as
you can see in PKCS11Test class [1]. This dependency sounds reasonable to
me, as we are developing a SunPKCS11 test. However, if you see a different
way of doing this and removing this dependency, I'd be glad to remove it.

NSS hardcoded paths and SunPKCS11 instance creation removed leveraging on
PKCS11Test machinery. sun.security.pkcs11.SunPKCS11 dependency is now
indirect through PKCS11Test. Existing FIPS certificates (in
test/jdk/sun/security/pkcs11/fips) are not suitable for this test because
of the algorithms and expirity date. I can merge certificates and private
key files if you want.

Dependencies removed:
 * sun.security.rsa.RSAPrivateCrtKeyImpl
 * sun.security.rsa.RSAPublicKeyImpl
 * sun.security.ec.SunEC
 * sun.security.jca.ProviderList
 * java.io.ByteArrayInputStream
 * java.io.InputStream
 * java.lang.reflect.Constructor
 * java.nio.charset.StandardCharsets
 * sun.security.jca.Providers

Dependencies added:
 * PKCS11Test
 * java.security.interfaces.RSAPublicKey
 * java.security.spec.X509EncodedKeySpec
 * java.security.spec.PKCS8EncodedKeySpec
 * java.security.KeyFactory added.

White spaces on empty lines and unnecessary white spaces removed.

Regarding sun.security.internal.spec.TlsMasterSecretParameterSpec,
sun.security.internal.spec.TlsPrfParameterSpec and
sun.security.internal.spec.TlsRsaPremasterSecretParameterSpec dependencies,
test includes 2 assertions:

 1) Self-integrity assertion
  * A plain text message is transmitted over TLS 1.2 between 2 parties and
message integrity is verified at both endpoints
  * This is a functional test that uses public APIs.

 2) Cross-provider assertion
  * Keys for a TLS 1.2 communication are derived and asserted against a
well-known provider.

To do assertion 2), classes from SunJSSE are required. I think this
assertion adds value because the self-integrity test does not check that
negotiated keys are correct: comparing to a third-party provides more
guarantee. The reason why we are not comparing against fixed values is
because there are timestamps and random values involved and making them
fixed will require some more hacking. I agree with you that including
cross-package references on a unit test has a higher maintainance cost
-even when SunPKCS11 and TLS features are closely related-, but I suggest
to make an exception here given the value it provides.

Look forward to your answer.

Kind regards,
Martin.-

--
[1] -
http://hg.openjdk.java.net/jdk/jdk/file/9bdd233f270d/test/jdk/sun/security/pkcs11/PKCS11Test.java#l124
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From jamil.j.nimeh at oracle.com  Tue May 22 20:43:51 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Tue, 22 May 2018 13:43:51 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: 
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <3dda646c-2854-cdf2-cc1b-4d2c3133d787@oracle.com>
 
Message-ID: <9b97fb7b-eee0-7c48-d962-cc5f4812c65a@oracle.com>

A couple updates:

  * Touched up the comments surrounding init/wrap/unwrap methods. None
    of these affect public javadocs.
  * Added an implementation for engineGetParameters.? This was something
    that just got forgotten from the initial development of the cipher
    when there were no AlgorithmParameter implementations.
      o There are a couple tests added to ChaCha20Poly1305ParamTest to
        exercise these new code paths.

http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.08

Thanks,

--Jamil


On 5/21/2018 11:36 AM, Jamil Nimeh wrote:
>
> And the fun just keeps going!? Round 7.
>
> This revision removes wrap/unwrap support for ChaCha20 and 
> ChaCha20-Poly1305 until there is a standardized key wrapping approach 
> for these ciphers (similar to how AES has its own key wrapping scheme 
> in RFC 3394).
>
> Initializing the cipher with WRAP/UNWRAP mode will throw 
> UnsupportedOperationException and likewise the wrap/unwrap methods 
> will throw IllegalStateException.
>
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.07/
>
> Thanks,
>
> --Jamil
>
>
> On 05/16/2018 12:05 PM, Jamil Nimeh wrote:
>>
>> Round 6.
>>
>> This brings ChaCha20/ChaCha20-Poly1305 into conformance with Cipher's 
>> specification when forms of init that take AlgorithmParameters or 
>> AlgorithmParameterSpec are used. Previously, a non-null AP or APS 
>> object was required.? In order to better conform to the 
>> specification, if a null AP or APS is provided for these ciphers, a 
>> random nonce will be generated and the counter will be set to 1, just 
>> as is currently done with valid forms of init that don't take an AP 
>> or APS object (e.g. Cipher.init(int, Key, SecureRandom) ). Per the 
>> spec in Cipher, this is only true for ENCRYPT_MODE and will throw 
>> InvalidKeyException when done in DECRYPT_MODE.
>>
>> I also added a few test cases that exercise these code paths in the 
>> ChaCha20Poly1305Parameters.java test case.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>>
>> Thanks,
>>
>> --Jamil
>>
>>
>> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>>
>>> Round 5.
>>>
>>> This adds Sean's comments.? Sean, I was never able to execute a case 
>>> on init where a half-baked object would fail.? In most cases it 
>>> would fail in checks in javax.crypto.Cipher before it ever made it 
>>> down to my code. I'm pretty confident the init sequence is OK.? I 
>>> did move the setting of a few data members toward the end of the 
>>> init sequence but setting the key and nonce is necessary before 
>>> creating the initial state, which is then used for generating an 
>>> authentication key for AEAD mode and generating keystream.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>
>>> Also the CSR has been finalized and can be found here:
>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>
>>> --Jamil
>>>
>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>
>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>> mostly:
>>>>
>>>>   * Added words in the description of javax.crypto.Cipher
>>>>     recommending callers reinitialize the Cipher to use different
>>>>     nonces after each complete encryption or decryption (similar
>>>>     language to what exists already for AES-GCM encryption).
>>>>   * Added an additional test case for ChaCha20NoReuse
>>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>>     cleaned up the code a bit based on comments from the field.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>
>>>> Thanks!
>>>>
>>>> --Jamil
>>>>
>>>>
>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>
>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>> for catching this)
>>>>>
>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances of 
>>>>> these ciphers will no longer allow you to do subsequent 
>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>> throw an IllegalStateException.? This is similar to the behavior 
>>>>> of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done 
>>>>> for both encrypt and decrypt.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>
>>>>> Thanks,
>>>>> --Jamil
>>>>>
>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>> Hello everyone,
>>>>>>
>>>>>> This is a quick update to the previous webrev:
>>>>>>
>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>> and random, the nonce will always be random even if the random 
>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>
>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>
>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>> separator from a System property directly.? It calls 
>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --Jamil
>>>>>>
>>>>>>
>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>> Hello all,
>>>>>>>
>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>> the ciphers are listed below.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --Jamil
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun.wang at oracle.com  Wed May 23 00:01:53 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 23 May 2018 08:01:53 +0800
Subject: RFR 8201815: Use Mozilla Public Suffix List
In-Reply-To: <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com>
References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com>
 <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com>
 <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com>
Message-ID: <61048D27-07DB-4283-82E6-B7909296171F@oracle.com>



> On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie  wrote:
> 
> ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last. 

I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.)

In below cases, CHMOD is called after MV/CP.

gendata/Gendata-java.base.gmk
59-	$(MV) $@.tmp $@
60:	$(CHMOD) 444 $@
61-

common/JavaCompilation.gmk
80-	$(CP) $$< $$@
81:	$(CHMOD) -f ug+w $$@

Thanks
Max

> 
> /Magnus
> 
>> 22 maj 2018 kl. 17:44 skrev Erik Joelsson :
>> 
>> Build changes look ok.
>> 
>> /Erik
>> 
>> 
>>> On 2018-05-22 08:25, Weijun Wang wrote:
>>> Please take a review at
>>> 
>>>   http://cr.openjdk.java.net/~weijun/8201815/webrev.00/
>>> 
>>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs.
>>> 
>>> There is no plan to update the data in a different channel other than a JDK release.
>>> 
>>> Thanks
>>> Max
>>> 
>> 
> 



From tom.w.hood at gmail.com  Wed May 23 02:25:25 2018
From: tom.w.hood at gmail.com (Tom Hood)
Date: Tue, 22 May 2018 19:25:25 -0700
Subject: JNLP launched legacy app needs to override
 jdk.tls.disabledAlgorithms
In-Reply-To: 
References: 
 <528DB0B9-9A13-4B49-B957-0028BE23A9A9@oracle.com>
 
 
Message-ID: 

Thanks.  It's not what I wanted to hear, but is what I expected.

It looks like java reflection might be the only solution for us in the
short-term.  I will dig into the code to see if I can figure out what's
needed.

Re: "stand alone installer" -- The support timeline for our legacy app is
unlikely to extend past Oracle's Java 8 + Webstart stated commercial
support date of 3/2025
,
so unless our app needs to be supported longer, it'll remain a JNLP app.

On Tue, May 22, 2018 at 11:19 AM, Bernd Eckenfels 
wrote:

> You probably don?t want to hear that, but now is a good time to convert
> this JNLP App into a stand alone Installer (possibly with updater).that
> will not only allow you to ship a pre-configured and matching JRE, but it
> will also solve the problem that you do not get javaws updates starting on
> January (easily) anymore.
>
> JNLP does not allow to overwrite random properties for the started app.
>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net
> ------------------------------
> *From:* security-dev  on behalf of
> Tom Hood 
> *Sent:* Tuesday, May 22, 2018 4:31:31 PM
> *To:* Anthony Scarpino
> *Cc:* security Dev OpenJDK; Smith, M'Lissa (Mission Systems)
> *Subject:* Re: JNLP launched legacy app needs to override
> jdk.tls.disabledAlgorithms
>
> Clarification.  When I said for option (1) "none had the desired effect",
> I mean at the start of main I confirmed with System.getProperty that the
> java.security.properties property isn't getting set thru the JNLP launch,
> so I doubt "==" will make any difference compared to "=".  As far as
> "override" vs. "append" either one in theory could be made to work for our
> use case.  The goal is to be able to change the value of the
> "jdk.tls.disabledAlgorithms" property so it no longer has 3DES_EDE_CBC at
> the start of the jvm.
>
> On Mon, May 21, 2018 at 8:56 PM, Anthony Scarpino <
> anthony.scarpino at oracle.com> wrote:
>
>> The property can get loaded very early and it can be hard to get ahead of
>> it.
>>
>> The only suggestion I can think of is your option 1 isn't doing what you
>> expect. To append to the existing java.security properties, you use one
>> equals, ?=?. To override you use 2, ?==?.  So you may want something like:
>>
>> java-vm-args="-Djava.security.properties==override_file"
>>
>>
>> Tony
>>
>> On May 21, 2018, at 7:48 PM, Tom Hood  wrote:
>>
>> Hi,
>>
>> Our legacy app will no longer launch with JNLP as of Java 8u171 and 8u172
>> due to the addition of "3DES_EDE_CBC" to the global java.security file's
>> "jdk.tls.disabledAlgorithms" property.
>>
>> Schedule constraints do not allow us to upgrade our application to a
>> stronger cipher suite at this time and our customer is okay with continuing
>> to run with a compromised cipher suite in the near term for our legacy app.
>>
>> Problem is we cannot (and probably should not) simply edit the global
>> /lib/security/java.security file.  Also, we would prefer not
>> to edit "Runtime Parameters" in the java control panel on each user's PC to
>> specify an override property file.  We would like a way to override in a
>> JNLP launch.  Is this possible?
>>
>> Other info about the app:
>> - JNLP has security element:  
>> - SSL connection that uses the compromised cipher suite is coming from
>> inside the guts of an antiquated, unsupported ORB implementation
>> (Visibroker 5.2.1).  Its source code is not available.  It does not support
>> a stronger cipher suite.
>>
>> Things I've tried:
>>
>> (1) add an overrides file with System property "java.security.properties"
>>
>> It doesn't appear there is a way to do this for a JNLP launch.  I tried
>> each of the following individually and none had the desired effect:
>>
>> > .../>
>> 
>> 
>>
>> None of them have any effect except the last one which sets the system
>> property before main() starts, but that doesn't help, because it has the
>> "jnlp." prefix which isn't what the Security class expects.
>>
>> Since "-D" is not listed as a secure arg for "java-vm-args", it looks
>> like this is not possible by design, despite the jnlp file having
>> .  Reference doc:
>> https://docs.oracle.com/javase/8/docs/technotes/guides/
>> javaws/developersguide/syntax.html#resources
>>
>> (2) At start of app's main(), call Security.setProperty("jdk.tls.disabledAlgorithms",
>> newvalue)
>>
>> JNLP launch: no change; fails same way
>> Eclipse run as regular Java app: now works
>>
>> This leads me to believe the old value for the property is used and/or
>> cached in places other than the Security class *before* main starts for a
>> JNLP launch compared to when run as a regular Java app.
>>
>> (3) At start of app's main, use reflection as follows:
>>
>> (a) with reflection: force loading of sun.security.ssl.SSLAlgorithmConstraints
>> class via Class.forName
>> (b) call Security.setProperty("jdk.tls.disabledAlgorithms", newvalue)
>> (c) with reflection: SSLAlgorithmConstraints.tlsDisabledAlgorithms = new
>> sun.security.util.DisabledAlgorithmConstraints(PROPERTY_TLS_
>> DISABLED_ARGS)
>> (d) call Security.setProperty("jdk.tls.disabledAlgorithms", oldvalue)
>>
>> JNLP launch: no change; fails same way
>> Eclipse run as regular Java app: now works; without substep (c) it fails
>> same way
>>
>> The old value must have been used and/or cached elsewhere besides
>> SSLAgorithmConstraints for a JNLP launch compared to running as a regular
>> java app.
>>
>> Unfortunately, I'm not sure I have the source code for sun.* that matches
>> up with 8u172, otherwise I would try to find where else that property is
>> read.  Even if I could get the reflection to work, it seems all too fragile
>> and likely to break in future Java updates.  I'd prefer a different
>> approach.
>>
>> Any suggestions?
>>
>> Thank you,
>> -- Tom
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sha.jiang at oracle.com  Wed May 23 07:03:10 2018
From: sha.jiang at oracle.com (sha.jiang at oracle.com)
Date: Wed, 23 May 2018 15:03:10 +0800
Subject: RFR[11] JDK-8203686: Add JDK 11 major version to
 javax/net/ssl/compatibility/JdkRelease.java
Message-ID: <8842510f-3915-a39a-5192-68c11238f7dd@oracle.com>

Hi,
javax/net/ssl/compatibility/JdkRelease.java has to include the latest 
JDK major release, namely JDK 11; otherwise, manual test 
javax/net/ssl/compatibility/Compatibility.java cannot run on JDK 11 builds.

Webrev: http://cr.openjdk.java.net/~jjiang/8203686/webrev.00/
Issue: https://bugs.openjdk.java.net/browse/JDK-8203686

Best regards,
John Jiang



From magnus.ihse.bursie at oracle.com  Wed May 23 10:54:39 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 23 May 2018 12:54:39 +0200
Subject: RFR 8201815: Use Mozilla Public Suffix List
In-Reply-To: <61048D27-07DB-4283-82E6-B7909296171F@oracle.com>
References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com>
 <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com>
 <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com>
 <61048D27-07DB-4283-82E6-B7909296171F@oracle.com>
Message-ID: <792D6BE1-1563-4953-BE5D-F60905D39483@oracle.com>

mv should not modify attributes. cp will, but mv should not. 

Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anything is missing. 

I believe the other cases that you quote are also incorrect. 

But I'd like to hear Erik's input on this as well. 

/Magnus

> 23 maj 2018 kl. 02:01 skrev Weijun Wang :
> 
> 
> 
>> On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie  wrote:
>> 
>> ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last.
> 
> I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.)
> 
> In below cases, CHMOD is called after MV/CP.
> 
> gendata/Gendata-java.base.gmk
> 59-    $(MV) $@.tmp $@
> 60:    $(CHMOD) 444 $@
> 61-
> 
> common/JavaCompilation.gmk
> 80-    $(CP) $$< $$@
> 81:    $(CHMOD) -f ug+w $$@
> 
> Thanks
> Max
> 
>> 
>> /Magnus
>> 
>>> 22 maj 2018 kl. 17:44 skrev Erik Joelsson :
>>> 
>>> Build changes look ok.
>>> 
>>> /Erik
>>> 
>>> 
>>>> On 2018-05-22 08:25, Weijun Wang wrote:
>>>> Please take a review at
>>>> 
>>>>  http://cr.openjdk.java.net/~weijun/8201815/webrev.00/
>>>> 
>>>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs.
>>>> 
>>>> There is no plan to update the data in a different channel other than a JDK release.
>>>> 
>>>> Thanks
>>>> Max
> 



From xuelei.fan at oracle.com  Wed May 23 15:10:51 2018
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Wed, 23 May 2018 08:10:51 -0700
Subject: RFR[11] JDK-8203686: Add JDK 11 major version to
 javax/net/ssl/compatibility/JdkRelease.java
In-Reply-To: <8842510f-3915-a39a-5192-68c11238f7dd@oracle.com>
References: <8842510f-3915-a39a-5192-68c11238f7dd@oracle.com>
Message-ID: <63282498-286b-6dfb-e882-0fa0df147660@oracle.com>

Looks fine to me.  Thanks!

Xuelei

On 5/23/2018 12:03 AM, sha.jiang at oracle.com wrote:
> Hi,
> javax/net/ssl/compatibility/JdkRelease.java has to include the latest 
> JDK major release, namely JDK 11; otherwise, manual test 
> javax/net/ssl/compatibility/Compatibility.java cannot run on JDK 11 builds.
> 
> Webrev: http://cr.openjdk.java.net/~jjiang/8203686/webrev.00/
> Issue: https://bugs.openjdk.java.net/browse/JDK-8203686
> 
> Best regards,
> John Jiang
> 


From shubhamnba2009 at gmail.com  Wed May 23 07:29:34 2018
From: shubhamnba2009 at gmail.com (Shubham Rajput)
Date: Wed, 23 May 2018 12:59:34 +0530
Subject: Signature from User-specified URIDereferencers NodeSetData
 objects is wrong
In-Reply-To: 
References: 
 
Message-ID: 

Hi Sean,
Thanks for your reply.
I tried with the input that were given by you to use  XPathFilter2Transform
with an
XPathFilter2ParameterSpec.
But the thing is in output XML, Under signature tag I am getting the
following output::

---------------------------------------------------Source-start------------------------------------







/descendant::*[name()='ds:Signature']




mCvp/VNBFGQZFGJKBjT6dOifpoeS6G2j+t88RQEwnFQ=


IEzsw0I0qQ00s0r1iigXBg+KwiDilclQfvnqC2QpdS1F6CaKHMOWsWm76oFaCXClAK18A0pMwxTw
E7DKmkGQfYHyFyt/XojuFsF9CwObS5TItsG4hdcD9MFaTUOe0D44nI3GU6g5dUB4eI1/F51GvWYd
dN1CXLFhsgrj1GfvDCSa6bM5U700aFX5WqiM73COf40h0/uHYRgW69zn+gqAidZqqDWJ9t55rUYk
9kOCLZr5JsLkE0fiwy/Ep37JgDxVDn5Lyi1x24T7inBo8jivtSkex9hjTtSBmzR0wxZTvaJAW/bx
JBxbRsIEMw5Hz6rDgFcCNA5WRB6l5Yf4pVuB+w==

----------------------------------------------------Source-end-------------------------------------


So the issue is the below tag info also gets add in :

---------------------------------------------------Source-start------------------------------------

/descendant::*[name()='ds:Signature']

----------------------------------------------------Source-end-------------------------------------

Which is not required and if I remove this tag from the output I will face
signature verification failure issue!!

Any leads how to pivot or remedy for this issue?

Thanks in advance,

Regards,
Shubham




On Fri, May 18, 2018 at 7:58 PM Sean Mullan  wrote:

> On 5/17/18 1:54 AM, Shubham Rajput wrote:
> >
> > Any lead why the signature is forming for the node element name only and
> > not for the whole node?
>
> I can't remember for sure now, but it probably has something to do with
> the way you are returning the nodes from your URIDereferencer.
>
> You are probably better off defining an XPathFilter2Transform with an
> XPathFilter2ParameterSpec [1] for your signature and letting that do the
> filtering for you automatically.
>
> HTH,
> Sean
>
> [1]
>
> https://docs.oracle.com/javase/10/docs/api/javax/xml/crypto/dsig/spec/XPathFilter2ParameterSpec.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From erik.joelsson at oracle.com  Wed May 23 16:30:11 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 23 May 2018 09:30:11 -0700
Subject: RFR 8201815: Use Mozilla Public Suffix List
In-Reply-To: <792D6BE1-1563-4953-BE5D-F60905D39483@oracle.com>
References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com>
 <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com>
 <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com>
 <61048D27-07DB-4283-82E6-B7909296171F@oracle.com>
 <792D6BE1-1563-4953-BE5D-F60905D39483@oracle.com>
Message-ID: <550260ec-9470-4f88-e1a0-05ee1ef62a4f@oracle.com>

On 2018-05-23 03:54, Magnus Ihse Bursie wrote:
> mv should not modify attributes. cp will, but mv should not.
>
> Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anything is missing.
>
> I believe the other cases that you quote are also incorrect.
>
> But I'd like to hear Erik's input on this as well.
We have the pseudo target .DELETE_ON_ERROR defined globally (in 
MakeBase.gmk) which causes make to delete the target of any failed or 
interrupted recipe. This should actually remove any need for using .tmp 
files and mv on the last line. We still have a lot of those constructs 
around since forever though. The recipe copied here (and the two other 
examples) are based on a template from very early build-infra makefile 
history and do not represent current best practices. If anything I would 
recommend getting rid of the .tmp and mv completely, but if you prefer 
both belt and suspenders, putting the move last should be the correct 
construct.

/Erik
> /Magnus
>
>> 23 maj 2018 kl. 02:01 skrev Weijun Wang :
>>
>>
>>
>>> On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie  wrote:
>>>
>>> ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last.
>> I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.)
>>
>> In below cases, CHMOD is called after MV/CP.
>>
>> gendata/Gendata-java.base.gmk
>> 59-    $(MV) $@.tmp $@
>> 60:    $(CHMOD) 444 $@
>> 61-
>>
>> common/JavaCompilation.gmk
>> 80-    $(CP) $$< $$@
>> 81:    $(CHMOD) -f ug+w $$@
>>
>> Thanks
>> Max
>>
>>> /Magnus
>>>
>>>> 22 maj 2018 kl. 17:44 skrev Erik Joelsson :
>>>>
>>>> Build changes look ok.
>>>>
>>>> /Erik
>>>>
>>>>
>>>>> On 2018-05-22 08:25, Weijun Wang wrote:
>>>>> Please take a review at
>>>>>
>>>>>   http://cr.openjdk.java.net/~weijun/8201815/webrev.00/
>>>>>
>>>>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs.
>>>>>
>>>>> There is no plan to update the data in a different channel other than a JDK release.
>>>>>
>>>>> Thanks
>>>>> Max



From sean.mullan at oracle.com  Wed May 23 20:47:14 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 23 May 2018 16:47:14 -0400
Subject: RFR CSR 8203460: Update xmldsig implementation to latest version
 of Apache Santuario
In-Reply-To: <54D9DAEE-F409-47CC-8F0B-AC606FCA565A@oracle.com>
References: <54D9DAEE-F409-47CC-8F0B-AC606FCA565A@oracle.com>
Message-ID: <07490f97-1fb3-1a64-013f-48a2be20ffaf@oracle.com>

I don't think you should change the names of the algorithms to the JCE 
style (eg: SHA1withDSA). You should keep the names as defined by the W3C 
Recommendation and related RFCs. Even if the naming convention is 
different than JCE, these are the names that were chosen by the 
standards bodies and these are XML DSig specific algorithm names.

Otherwise looks good.

Thanks,
Sean

On 5/21/18 10:57 PM, Weijun Wang wrote:
> Please take a review at
> 
>     https://bugs.openjdk.java.net/browse/JDK-8203460
> 
> The current XMLDSig provider implementation is based on Apache Santuario 1.5.4. We'll update it to be 2.1.1. New algorithms are added.
> 
> Thanks
> Max
> 


From weijun.wang at oracle.com  Thu May 24 00:19:45 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 24 May 2018 08:19:45 +0800
Subject: RFR CSR 8203460: Update xmldsig implementation to latest version
 of Apache Santuario
In-Reply-To: <07490f97-1fb3-1a64-013f-48a2be20ffaf@oracle.com>
References: <54D9DAEE-F409-47CC-8F0B-AC606FCA565A@oracle.com>
 <07490f97-1fb3-1a64-013f-48a2be20ffaf@oracle.com>
Message-ID: <0EB794F2-9855-41B0-BECC-830072C8A36F@oracle.com>

Updated. I'm now using uri.substr(uri.indexOf("#") + 1).toUpperCase() as the names.

Thanks
Max

> On May 24, 2018, at 4:47 AM, Sean Mullan  wrote:
> 
> I don't think you should change the names of the algorithms to the JCE style (eg: SHA1withDSA). You should keep the names as defined by the W3C Recommendation and related RFCs. Even if the naming convention is different than JCE, these are the names that were chosen by the standards bodies and these are XML DSig specific algorithm names.
> 
> Otherwise looks good.
> 
> Thanks,
> Sean
> 
> On 5/21/18 10:57 PM, Weijun Wang wrote:
>> Please take a review at
>>    https://bugs.openjdk.java.net/browse/JDK-8203460
>> The current XMLDSig provider implementation is based on Apache Santuario 1.5.4. We'll update it to be 2.1.1. New algorithms are added.
>> Thanks
>> Max



From weijun.wang at oracle.com  Thu May 24 04:52:43 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 24 May 2018 12:52:43 +0800
Subject: RFR 8201815: Use Mozilla Public Suffix List
In-Reply-To: <550260ec-9470-4f88-e1a0-05ee1ef62a4f@oracle.com>
References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com>
 <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com>
 <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com>
 <61048D27-07DB-4283-82E6-B7909296171F@oracle.com>
 <792D6BE1-1563-4953-BE5D-F60905D39483@oracle.com>
 <550260ec-9470-4f88-e1a0-05ee1ef62a4f@oracle.com>
Message-ID: 

Good. It's now simply

$(GENDATA_PUBLICSUFFIXLIST): $(GENDATA_PUBLICSUFFIXLIST_SRC) $(BUILD_TOOLS)
   $(call LogInfo, Generating public suffix list)
   $(call MakeDir, $(@D))
   $(RM) $@
   $(TOOL_PUBLICSUFFIXLIST) $< $@
   $(CHMOD) 444 $@

Thanks
Max

> On May 24, 2018, at 12:30 AM, Erik Joelsson  wrote:
> 
> On 2018-05-23 03:54, Magnus Ihse Bursie wrote:
>> mv should not modify attributes. cp will, but mv should not.
>> 
>> Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anything is missing.
>> 
>> I believe the other cases that you quote are also incorrect.
>> 
>> But I'd like to hear Erik's input on this as well.
> We have the pseudo target .DELETE_ON_ERROR defined globally (in MakeBase.gmk) which causes make to delete the target of any failed or interrupted recipe. This should actually remove any need for using .tmp files and mv on the last line. We still have a lot of those constructs around since forever though. The recipe copied here (and the two other examples) are based on a template from very early build-infra makefile history and do not represent current best practices. If anything I would recommend getting rid of the .tmp and mv completely, but if you prefer both belt and suspenders, putting the move last should be the correct construct.
> 
> /Erik
>> /Magnus
>> 
>>> 23 maj 2018 kl. 02:01 skrev Weijun Wang :
>>> 
>>> 
>>> 
>>>> On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie  wrote:
>>>> 
>>>> ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last.
>>> I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.)
>>> 
>>> In below cases, CHMOD is called after MV/CP.
>>> 
>>> gendata/Gendata-java.base.gmk
>>> 59-    $(MV) $@.tmp $@
>>> 60:    $(CHMOD) 444 $@
>>> 61-
>>> 
>>> common/JavaCompilation.gmk
>>> 80-    $(CP) $$< $$@
>>> 81:    $(CHMOD) -f ug+w $$@
>>> 
>>> Thanks
>>> Max
>>> 
>>>> /Magnus
>>>> 
>>>>> 22 maj 2018 kl. 17:44 skrev Erik Joelsson :
>>>>> 
>>>>> Build changes look ok.
>>>>> 
>>>>> /Erik
>>>>> 
>>>>> 
>>>>>> On 2018-05-22 08:25, Weijun Wang wrote:
>>>>>> Please take a review at
>>>>>> 
>>>>>>  http://cr.openjdk.java.net/~weijun/8201815/webrev.00/
>>>>>> 
>>>>>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs.
>>>>>> 
>>>>>> There is no plan to update the data in a different channel other than a JDK release.
>>>>>> 
>>>>>> Thanks
>>>>>> Max
> 



From weijun.wang at oracle.com  Thu May 24 05:50:45 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 24 May 2018 13:50:45 +0800
Subject: RFR 8177334: Update xmldsig implementation to Apache Santuario 2.1.1
Message-ID: <2C946CE7-6E09-45B0-AC46-7C0C2EE505AB@oracle.com>

Please review the change at

  webrev: http://cr.openjdk.java.net/~weijun/8177334/webrev.00/
     CSR: https://bugs.openjdk.java.net/browse/JDK-8203460

New features include the support of SHA-224 and SHA-3 MessageMethod, and RSASSA-PSS SignatureMethods.

The change is done in 2 steps:

1. Copying files from Apache Santuario Release 2.1.1 [1]. Making cosmetic changes like changing package names.

2. More changes, including

   a. Applying patches in OpenJDK that were not pushed to Apache Santuario (yet)
   b. Using the RSASSA-PSS Signature algorithm in OpenJDK, because we don't have names like SHA256withRSAandMGF1
   c. Copying standard digest method and signature method names into public API (see the CSR)

For your convenience, there is a separate webrev for step 2 above at

   http://cr.openjdk.java.net/~weijun/8177334/changes/

Thanks
Max

[1] http://www.apache.org/dyn/closer.lua/santuario/java-library/2_1_1/xmlsec-2.1.1-source-release.zip

From weijun.wang at oracle.com  Thu May 24 06:12:53 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Thu, 24 May 2018 14:12:53 +0800
Subject: RFR 8072996: Deprecate stream-based GSSContext methods
Message-ID: 

RFC 8353 has removed stream-based GSSContext methods [1]. Therefore we deprecate them in JDK. Please take a review at

   webrev: http://cr.openjdk.java.net/~weijun/8072996/webrev.00/
      CSR: https://bugs.openjdk.java.net/browse/JDK-8202953

Thanks
Max

[1] https://tools.ietf.org/html/rfc8353#section-11

From magnus.ihse.bursie at oracle.com  Thu May 24 12:47:53 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 24 May 2018 14:47:53 +0200
Subject: RFR 8201815: Use Mozilla Public Suffix List
In-Reply-To: 
References: <35BB388A-D2BA-4936-827F-B211E379A2DF@oracle.com>
 <539c8303-a2b4-d217-6817-d28925cd0e27@oracle.com>
 <0ED42EC2-C0E2-4DFB-BD63-0BB5C121FA85@oracle.com>
 <61048D27-07DB-4283-82E6-B7909296171F@oracle.com>
 <792D6BE1-1563-4953-BE5D-F60905D39483@oracle.com>
 <550260ec-9470-4f88-e1a0-05ee1ef62a4f@oracle.com>
 
Message-ID: 

On 2018-05-24 06:52, Weijun Wang wrote:
> Good. It's now simply
>
> $(GENDATA_PUBLICSUFFIXLIST): $(GENDATA_PUBLICSUFFIXLIST_SRC) $(BUILD_TOOLS)
>     $(call LogInfo, Generating public suffix list)
>     $(call MakeDir, $(@D))
>     $(RM) $@
>     $(TOOL_PUBLICSUFFIXLIST) $< $@
>     $(CHMOD) 444 $@
>
> Thanks
> Max
Great! Looks good to me now.

I've forgotten that we started using .DELETE_ON_ERROR. Thanks for 
reminding me Erik. :)

/Magnus

>
>> On May 24, 2018, at 12:30 AM, Erik Joelsson  wrote:
>>
>> On 2018-05-23 03:54, Magnus Ihse Bursie wrote:
>>> mv should not modify attributes. cp will, but mv should not.
>>>
>>> Your solution might fail in the (admittedly unlikely) case that the build is interrupted before the chmod but after the mv. In that case, an incremental rebuild will not see that anything is missing.
>>>
>>> I believe the other cases that you quote are also incorrect.
>>>
>>> But I'd like to hear Erik's input on this as well.
>> We have the pseudo target .DELETE_ON_ERROR defined globally (in MakeBase.gmk) which causes make to delete the target of any failed or interrupted recipe. This should actually remove any need for using .tmp files and mv on the last line. We still have a lot of those constructs around since forever though. The recipe copied here (and the two other examples) are based on a template from very early build-infra makefile history and do not represent current best practices. If anything I would recommend getting rid of the .tmp and mv completely, but if you prefer both belt and suspenders, putting the move last should be the correct construct.
>>
>> /Erik
>>> /Magnus
>>>
>>>> 23 maj 2018 kl. 02:01 skrev Weijun Wang :
>>>>
>>>>
>>>>
>>>>> On May 23, 2018, at 4:21 AM, Magnus Ihse Bursie  wrote:
>>>>>
>>>>> ... but you should switch order on the chmod and the mv in the new gensrc file, so the mv comes last.
>>>> I thought it's safer to call CHMOD last so MV won't change file mode back. (I'm not saying it will, just afraid.)
>>>>
>>>> In below cases, CHMOD is called after MV/CP.
>>>>
>>>> gendata/Gendata-java.base.gmk
>>>> 59-    $(MV) $@.tmp $@
>>>> 60:    $(CHMOD) 444 $@
>>>> 61-
>>>>
>>>> common/JavaCompilation.gmk
>>>> 80-    $(CP) $$< $$@
>>>> 81:    $(CHMOD) -f ug+w $$@
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>>> /Magnus
>>>>>
>>>>>> 22 maj 2018 kl. 17:44 skrev Erik Joelsson :
>>>>>>
>>>>>> Build changes look ok.
>>>>>>
>>>>>> /Erik
>>>>>>
>>>>>>
>>>>>>> On 2018-05-22 08:25, Weijun Wang wrote:
>>>>>>> Please take a review at
>>>>>>>
>>>>>>>   http://cr.openjdk.java.net/~weijun/8201815/webrev.00/
>>>>>>>
>>>>>>> With this change, We switch from a home-grown public suffix list (implemented in sun/net/RegisteredDomain.java) to Mozilla's PSL. The PSL data was re-encoded as a zip file with entries for different TLDs.
>>>>>>>
>>>>>>> There is no plan to update the data in a different channel other than a JDK release.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Max



From sean.mullan at oracle.com  Thu May 24 15:39:52 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 24 May 2018 11:39:52 -0400
Subject: RFR CSR 8203460: Update xmldsig implementation to latest version
 of Apache Santuario
In-Reply-To: <0EB794F2-9855-41B0-BECC-830072C8A36F@oracle.com>
References: <54D9DAEE-F409-47CC-8F0B-AC606FCA565A@oracle.com>
 <07490f97-1fb3-1a64-013f-48a2be20ffaf@oracle.com>
 <0EB794F2-9855-41B0-BECC-830072C8A36F@oracle.com>
Message-ID: 

I think the MGF1 based SignatureMethod algs should be named 
SHA256_RSA_MGF1, etc to be consistent with the URI names in the RFC.

Otherwise the update looks good.

I think we should also file an RFE to add a new RSAPSSParams class 
(which would be a subclass of SignatureMethodParameterSpec), and would 
contain the parameters for the RSASSA-PSS algorithm defined in 
https://tools.ietf.org/html/rfc6931#2.3.9.

--Sean

On 5/23/18 8:19 PM, Weijun Wang wrote:
> Updated. I'm now using uri.substr(uri.indexOf("#") + 1).toUpperCase() as the names.
> 
> Thanks
> Max
> 
>> On May 24, 2018, at 4:47 AM, Sean Mullan  wrote:
>>
>> I don't think you should change the names of the algorithms to the JCE style (eg: SHA1withDSA). You should keep the names as defined by the W3C Recommendation and related RFCs. Even if the naming convention is different than JCE, these are the names that were chosen by the standards bodies and these are XML DSig specific algorithm names.
>>
>> Otherwise looks good.
>>
>> Thanks,
>> Sean
>>
>> On 5/21/18 10:57 PM, Weijun Wang wrote:
>>> Please take a review at
>>>     https://bugs.openjdk.java.net/browse/JDK-8203460
>>> The current XMLDSig provider implementation is based on Apache Santuario 1.5.4. We'll update it to be 2.1.1. New algorithms are added.
>>> Thanks
>>> Max
> 


From sean.mullan at oracle.com  Thu May 24 17:06:50 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 24 May 2018 13:06:50 -0400
Subject: RFR 8072996: Deprecate stream-based GSSContext methods
In-Reply-To: 
References: 
Message-ID: <90969db7-adc4-5ec0-a6dc-4f720b8362da@oracle.com>

For the new paragraph in GSSContext, I think you should quote RFC 8353 
since you are taking the wording from that. You should also say "Java SE 
11" instead of "JDK 11". So here is a possible re-wording:

The stream-based methods of {@code GSSContext} have been deprecated in 
Java SE 11. These methods have also been removed from 
RFC 8353: Generic Security Service API Version 2: Java Bindings 
Update for the following reasons (see section 11): "The overloaded 
methods of GSSContext that use input and output streams as the means to 
convey authentication and per-message GSS-API tokens as described in 
Section 5.15 of RFC 5653 [RFC5653] are removed in this update as the 
wire protocol should be defined by an application and not a library. 
It's also impossible to implement these methods correctly when the token 
has no self-framing (where the end cannot be determined), or the library 
has no knowledge of the token format (for example, as a bridge talking
to another GSS library)". These methods include {@link 
#initSecContext(InputStream, OutputStream)}, {@link 
#acceptSecContext(InputStream, OutputStream)},
{@link #wrap(InputStream, OutputStream, MessageProp)}, {@link 
#unwrap(InputStream, OutputStream, MessageProp)}, {@link 
#getMIC(InputStream, OutputStream, MessageProp)}, and {@link 
#verifyMIC(InputStream, InputStream, MessageProp)}.

I would probably also move this paragraph higher up in the class 
summary, before the example.

--Sean

On 5/24/18 2:12 AM, Weijun Wang wrote:
> RFC 8353 has removed stream-based GSSContext methods [1]. Therefore we deprecate them in JDK. Please take a review at
> 
>     webrev: http://cr.openjdk.java.net/~weijun/8072996/webrev.00/
>        CSR: https://bugs.openjdk.java.net/browse/JDK-8202953
> 
> Thanks
> Max
> 
> [1] https://tools.ietf.org/html/rfc8353#section-11
> 


From mbalao at redhat.com  Thu May 24 19:13:22 2018
From: mbalao at redhat.com (Martin Balao)
Date: Thu, 24 May 2018 16:13:22 -0300
Subject: [RFR]: JDK-8203182 - Release session if initialization of
 SunPKCS11 Signature fails
In-Reply-To: 
References: 
 
Message-ID: 

Hi Valerie,

Thanks for your review.

These are the cases I identified:

 * engineSign and engineVerify include a try-finally block that releases
the session under any circumstances.

 * engineUpdate may leak. Session release added if failure occurs.

 * cancelOperation may leak. If session has no objects, it's killed. If it
has, a "cancel operation by finishing it" code is executed. This code can
fail on sign/verify operations, and a session may be leaked. It's not clear
to me why this "cancel operation by finishing it" code is needed, though.
Added a try-finally block anyways.

Webrev 01:

 * http://cr.openjdk.java.net/~mbalao/webrevs/8203182/8203182.webrev.01/
 * http://cr.openjdk.java.net/~mbalao/webrevs/8203182/8203182.webrev.01.zip

Look forward to your answer.

Kind regards,
Martin.-

On Tue, May 15, 2018 at 7:30 PM, Valerie Peng 
wrote:

> Hi Martin,
>
> Your fix only addresses the initialization case. Have you considered
> fixing the same problem under difference calls?
>
> Regards,
> Valerie
>
> On 5/14/2018 3:25 PM, Martin Balao wrote:
>
>> Hi,
>>
>> Can I have a review for "JDK-8203182 - Release session if initialization
>> of SunPKCS11 Signature fails" [1]?
>>
>>  * http://cr.openjdk.java.net/~mbalao/webrevs/8203182/8203182.webrev.00/
>> 
>>  * http://cr.openjdk.java.net/~mbalao/webrevs/8203182/8203182.
>> webrev.00.zip > Embalao/webrevs/8203182/8203182.webrev.00.zip>
>>
>> Thanks in advanced!
>>
>> Martin.-
>>
>> --
>> [1] - https://bugs.openjdk.java.net/browse/JDK-8203182
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From rajan.halade at oracle.com  Thu May 24 19:31:55 2018
From: rajan.halade at oracle.com (Rajan Halade)
Date: Thu, 24 May 2018 12:31:55 -0700
Subject: RFR: 8191844: Remove root secomevrootca1
Message-ID: <4e3fbdb6-0c6f-cd88-4a5c-73d4c1195860@oracle.com>

Please review this simple fix to remove "secomevrootca1" from cacerts.

Webrev: http://cr.openjdk.java.net/~rhalade/8191844/webrev.00/

Thanks,
Rajan


From sean.mullan at oracle.com  Thu May 24 19:51:04 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 24 May 2018 15:51:04 -0400
Subject: RFR: 8191844: Remove root secomevrootca1
In-Reply-To: <4e3fbdb6-0c6f-cd88-4a5c-73d4c1195860@oracle.com>
References: <4e3fbdb6-0c6f-cd88-4a5c-73d4c1195860@oracle.com>
Message-ID: <6c2ec1b3-1215-4714-b3d3-1f4db12e4e3b@oracle.com>

Looks good.

--Sean

On 5/24/18 3:31 PM, Rajan Halade wrote:
> Please review this simple fix to remove "secomevrootca1" from cacerts.
> 
> Webrev: http://cr.openjdk.java.net/~rhalade/8191844/webrev.00/
> 
> Thanks,
> Rajan


From rajan.halade at oracle.com  Thu May 24 21:05:05 2018
From: rajan.halade at oracle.com (Rajan Halade)
Date: Thu, 24 May 2018 14:05:05 -0700
Subject: RFR: 8203793: cacerts/VerifyCACerts.java fails with
 java.lang.Exception: At least one cacert test failed
Message-ID: 

Please review this fix to allow exception for equifaxsecureca 90-day 
expiry policy. This will allow test to pass but we should work on 
removing / replacing this CA later on.

Webrev: http://cr.openjdk.java.net/~rhalade/8203793/webrev.00/

Thanks,
Rajan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From weijun.wang at oracle.com  Fri May 25 00:16:00 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 25 May 2018 08:16:00 +0800
Subject: RFR CSR 8203460: Update xmldsig implementation to latest version
 of Apache Santuario
In-Reply-To: 
References: <54D9DAEE-F409-47CC-8F0B-AC606FCA565A@oracle.com>
 <07490f97-1fb3-1a64-013f-48a2be20ffaf@oracle.com>
 <0EB794F2-9855-41B0-BECC-830072C8A36F@oracle.com>
 
Message-ID: 



> On May 24, 2018, at 11:39 PM, Sean Mullan  wrote:
> 
> I think the MGF1 based SignatureMethod algs should be named SHA256_RSA_MGF1, etc to be consistent with the URI names in the RFC.

Updated.

I've also updated my local code, no new webrev.

> 
> Otherwise the update looks good.
> 
> I think we should also file an RFE to add a new RSAPSSParams class (which would be a subclass of SignatureMethodParameterSpec), and would contain the parameters for the RSASSA-PSS algorithm defined in https://tools.ietf.org/html/rfc6931#2.3.9.

https://bugs.openjdk.java.net/browse/JDK-8203804.

Thanks
Max

> 
> --Sean
> 
> On 5/23/18 8:19 PM, Weijun Wang wrote:
>> Updated. I'm now using uri.substr(uri.indexOf("#") + 1).toUpperCase() as the names.
>> Thanks
>> Max
>>> On May 24, 2018, at 4:47 AM, Sean Mullan  wrote:
>>> 
>>> I don't think you should change the names of the algorithms to the JCE style (eg: SHA1withDSA). You should keep the names as defined by the W3C Recommendation and related RFCs. Even if the naming convention is different than JCE, these are the names that were chosen by the standards bodies and these are XML DSig specific algorithm names.
>>> 
>>> Otherwise looks good.
>>> 
>>> Thanks,
>>> Sean
>>> 
>>> On 5/21/18 10:57 PM, Weijun Wang wrote:
>>>> Please take a review at
>>>>    https://bugs.openjdk.java.net/browse/JDK-8203460
>>>> The current XMLDSig provider implementation is based on Apache Santuario 1.5.4. We'll update it to be 2.1.1. New algorithms are added.
>>>> Thanks
>>>> Max



From weijun.wang at oracle.com  Fri May 25 00:27:02 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Fri, 25 May 2018 08:27:02 +0800
Subject: RFR 8072996: Deprecate stream-based GSSContext methods
In-Reply-To: <90969db7-adc4-5ec0-a6dc-4f720b8362da@oracle.com>
References: 
 <90969db7-adc4-5ec0-a6dc-4f720b8362da@oracle.com>
Message-ID: <57F8E1AF-62A2-406A-B121-163AF222C3D5@oracle.com>

CSR and webrev updated.

   webrev: http://cr.openjdk.java.net/~weijun/8072996/webrev.01/
      CSR: https://bugs.openjdk.java.net/browse/JDK-8202953

Thanks
Max

> On May 25, 2018, at 1:06 AM, Sean Mullan  wrote:
> 
> For the new paragraph in GSSContext, I think you should quote RFC 8353 since you are taking the wording from that. You should also say "Java SE 11" instead of "JDK 11". So here is a possible re-wording:
> 
> The stream-based methods of {@code GSSContext} have been deprecated in Java SE 11. These methods have also been removed from 
> RFC 8353: Generic Security Service API Version 2: Java Bindings Update for the following reasons (see section 11): "The overloaded methods of GSSContext that use input and output streams as the means to convey authentication and per-message GSS-API tokens as described in Section 5.15 of RFC 5653 [RFC5653] are removed in this update as the wire protocol should be defined by an application and not a library. It's also impossible to implement these methods correctly when the token has no self-framing (where the end cannot be determined), or the library has no knowledge of the token format (for example, as a bridge talking
> to another GSS library)". These methods include {@link #initSecContext(InputStream, OutputStream)}, {@link #acceptSecContext(InputStream, OutputStream)},
> {@link #wrap(InputStream, OutputStream, MessageProp)}, {@link #unwrap(InputStream, OutputStream, MessageProp)}, {@link #getMIC(InputStream, OutputStream, MessageProp)}, and {@link #verifyMIC(InputStream, InputStream, MessageProp)}.
> 
> I would probably also move this paragraph higher up in the class summary, before the example.
> 
> --Sean
> 
> On 5/24/18 2:12 AM, Weijun Wang wrote:
>> RFC 8353 has removed stream-based GSSContext methods [1]. Therefore we deprecate them in JDK. Please take a review at
>>    webrev: http://cr.openjdk.java.net/~weijun/8072996/webrev.00/
>>       CSR: https://bugs.openjdk.java.net/browse/JDK-8202953
>> Thanks
>> Max
>> [1] https://tools.ietf.org/html/rfc8353#section-11



From claes.redestad at oracle.com  Fri May 25 12:25:59 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Fri, 25 May 2018 14:25:59 +0200
Subject: RFR: 8203793: cacerts/VerifyCACerts.java fails with
 java.lang.Exception: At least one cacert test failed
In-Reply-To: 
References: 
Message-ID: 

On 2018-05-24 23:05, Rajan Halade wrote:
> Please review this fix to allow exception for equifaxsecureca 90-day 
> expiry policy. This will allow test to pass but we should work on 
> removing / replacing this CA later on.
>
> Webrev: http://cr.openjdk.java.net/~rhalade/8203793/webrev.00/

Looks good to me.

/Claes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From xuelei.fan at oracle.com  Fri May 25 23:45:24 2018
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Fri, 25 May 2018 16:45:24 -0700
Subject: Code Review Request: TLS 1.3 Implementation
Message-ID: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com>

Hi,

I'd like to invite you to review the TLS 1.3 implementation.  I 
appreciate it if I could have compatibility and specification feedback 
before May 31, 2018, and implementation feedback before June 7, 2018.

Here is the webrev:
     http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00

The formal TLS 1.3 specification is not finalized yet, although it had 
been approved to be a standard.  The implementation is based on the 
draft version 28:
     https://tools.ietf.org/html/draft-ietf-tls-tls13-28

For the overall description of this enhancement, please refer to JEP 332:
     http://openjdk.java.net/jeps/332

For the compatibility and specification update, please refer to CSR 8202625:
     https://bugs.openjdk.java.net/browse/JDK-8202625

Note that we are using the sandbox for the development right now.  For 
more information, please refer to Bradford's previous email:
 
http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html

Thanks & Regards,
Xuelei


From weijun.wang at oracle.com  Sat May 26 10:06:19 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Sat, 26 May 2018 18:06:19 +0800
Subject: RFR 8072996: Deprecate stream-based GSSContext methods
In-Reply-To: <57F8E1AF-62A2-406A-B121-163AF222C3D5@oracle.com>
References: 
 <90969db7-adc4-5ec0-a6dc-4f720b8362da@oracle.com>
 <57F8E1AF-62A2-406A-B121-163AF222C3D5@oracle.com>
Message-ID: <1C6A0360-F663-4462-9517-E8CCE91E315C@oracle.com>

Please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8203846.

Thanks.

> On May 25, 2018, at 8:27 AM, Weijun Wang  wrote:
> 
> CSR and webrev updated.
> 
>   webrev: http://cr.openjdk.java.net/~weijun/8072996/webrev.01/
>      CSR: https://bugs.openjdk.java.net/browse/JDK-8202953
> 
> Thanks
> Max



From florian.bruckner at 3kraft.com  Tue May 29 12:42:27 2018
From: florian.bruckner at 3kraft.com (Florian Bruckner (3kraft))
Date: Tue, 29 May 2018 14:42:27 +0200
Subject: JDK-8180819 No installed provider supports this key:
 sun.security.pkcs.PKCS8Key
In-Reply-To: 
References: <63f00010-f1cc-9200-7eae-d1d7b425dd41@3kraft.com>
 
Message-ID: <449d8fec-c812-c793-e435-c9655de7ad8a@3kraft.com>

Hi Adam,

i know it has been a long time since I have asked this - the procedure you suggested worked.

regards,

Florian

On 14/11/2017 16:34, Adam Petcher wrote:
> On 11/13/2017 2:20 PM, Florian Bruckner (3kraft) wrote:
>
>> Hi,
>>
>> have just stumbled upon a quite strange behavior in a SSL connection with a client certificate.
>
> Looks like your private key is BER encoded. I think this is supposed to be fine, but the code is 
> being a bit too strict and rejecting it. There was a change around 8u121 that added some more DER 
> enforcement. Can you try converting everything to DER to see if that clears up the problem? You 
> can do this with openssl e.g.:
>
> openssl pkcs12 -in pkcs12-file -out key-and-cert -nodes -passin pass:abcXYZ
> openssl pkcs12 -in key-and-cert -export -out new-pkcs12-file -passout pass:abcXYZ
>
> The JKS exception doesn't really provide a lot of information. It would be helpful if you could 
> import the DER-formatted PKCS#12 file back into JKS and let me know if that works.
>
>
>
>
>



From weijun.wang at oracle.com  Wed May 30 00:13:16 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 30 May 2018 08:13:16 +0800
Subject: RFR CSR 8203460: Update xmldsig implementation to latest version
 of Apache Santuario
In-Reply-To: 
References: <54D9DAEE-F409-47CC-8F0B-AC606FCA565A@oracle.com>
 <07490f97-1fb3-1a64-013f-48a2be20ffaf@oracle.com>
 <0EB794F2-9855-41B0-BECC-830072C8A36F@oracle.com>
 
 
Message-ID: <7E2B5A1D-C25C-4912-81EA-392E4E7D5A90@oracle.com>

Ping again.

> On May 25, 2018, at 8:16 AM, Weijun Wang  wrote:
> 
> 
> 
>> On May 24, 2018, at 11:39 PM, Sean Mullan  wrote:
>> 
>> I think the MGF1 based SignatureMethod algs should be named SHA256_RSA_MGF1, etc to be consistent with the URI names in the RFC.
> 
> Updated.
> 
> I've also updated my local code, no new webrev.
> 
>> 
>> Otherwise the update looks good.
>> 
>> I think we should also file an RFE to add a new RSAPSSParams class (which would be a subclass of SignatureMethodParameterSpec), and would contain the parameters for the RSASSA-PSS algorithm defined in https://tools.ietf.org/html/rfc6931#2.3.9.
> 
> https://bugs.openjdk.java.net/browse/JDK-8203804.
> 
> Thanks
> Max
> 
>> 
>> --Sean
>> 
>> On 5/23/18 8:19 PM, Weijun Wang wrote:
>>> Updated. I'm now using uri.substr(uri.indexOf("#") + 1).toUpperCase() as the names.
>>> Thanks
>>> Max
>>>> On May 24, 2018, at 4:47 AM, Sean Mullan  wrote:
>>>> 
>>>> I don't think you should change the names of the algorithms to the JCE style (eg: SHA1withDSA). You should keep the names as defined by the W3C Recommendation and related RFCs. Even if the naming convention is different than JCE, these are the names that were chosen by the standards bodies and these are XML DSig specific algorithm names.
>>>> 
>>>> Otherwise looks good.
>>>> 
>>>> Thanks,
>>>> Sean
>>>> 
>>>> On 5/21/18 10:57 PM, Weijun Wang wrote:
>>>>> Please take a review at
>>>>>   https://bugs.openjdk.java.net/browse/JDK-8203460
>>>>> The current XMLDSig provider implementation is based on Apache Santuario 1.5.4. We'll update it to be 2.1.1. New algorithms are added.
>>>>> Thanks
>>>>> Max
> 



From weijun.wang at oracle.com  Wed May 30 00:18:55 2018
From: weijun.wang at oracle.com (Weijun Wang)
Date: Wed, 30 May 2018 08:18:55 +0800
Subject: RFR 8072996: Deprecate stream-based GSSContext methods
In-Reply-To: <1C6A0360-F663-4462-9517-E8CCE91E315C@oracle.com>
References: 
 <90969db7-adc4-5ec0-a6dc-4f720b8362da@oracle.com>
 <57F8E1AF-62A2-406A-B121-163AF222C3D5@oracle.com>
 <1C6A0360-F663-4462-9517-E8CCE91E315C@oracle.com>
Message-ID: <16C35904-AE42-4810-BC83-2DFB746DFAC9@oracle.com>

CSR approved. Please review the code change and release note.

Thanks
Max

> On May 26, 2018, at 6:06 PM, Weijun Wang  wrote:
> 
> Please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8203846.
> 
> Thanks.
> 
>> On May 25, 2018, at 8:27 AM, Weijun Wang  wrote:
>> 
>> CSR and webrev updated.
>> 
>>  webrev: http://cr.openjdk.java.net/~weijun/8072996/webrev.01/
>>     CSR: https://bugs.openjdk.java.net/browse/JDK-8202953
>> 
>> Thanks
>> Max
> 



From rajan.halade at oracle.com  Wed May 30 05:11:38 2018
From: rajan.halade at oracle.com (Rajan Halade)
Date: Tue, 29 May 2018 22:11:38 -0700
Subject: RFR: 8189949: Remove Baltimore Cybertrust Code Signing CA
Message-ID: 

May I request you to review this fix to remove baltimorecodesigningca 
from cacerts.

Webrev: http://cr.openjdk.java.net/~rhalade/8189949/webrev.00/

Thanks,
Rajan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sean.mullan at oracle.com  Wed May 30 11:16:17 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 30 May 2018 07:16:17 -0400
Subject: RFR: 8189949: Remove Baltimore Cybertrust Code Signing CA
In-Reply-To: 
References: 
Message-ID: <241b8e5a-e67b-7c39-f297-e6693cee64b2@oracle.com>

Looks good, but can you also add a release note to the bug?

--Sean

On 5/30/18 1:11 AM, Rajan Halade wrote:
> May I request you to review this fix to remove baltimorecodesigningca 
> from cacerts.
> 
> Webrev: http://cr.openjdk.java.net/~rhalade/8189949/webrev.00/
> 
> Thanks,
> Rajan


From sean.mullan at oracle.com  Wed May 30 14:14:24 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 30 May 2018 10:14:24 -0400
Subject: RFR 8072996: Deprecate stream-based GSSContext methods
In-Reply-To: <16C35904-AE42-4810-BC83-2DFB746DFAC9@oracle.com>
References: 
 <90969db7-adc4-5ec0-a6dc-4f720b8362da@oracle.com>
 <57F8E1AF-62A2-406A-B121-163AF222C3D5@oracle.com>
 <1C6A0360-F663-4462-9517-E8CCE91E315C@oracle.com>
 <16C35904-AE42-4810-BC83-2DFB746DFAC9@oracle.com>
Message-ID: 

On 5/29/18 8:18 PM, Weijun Wang wrote:
> CSR approved. Please review the code change and release note.

Looks good.

--Sean

> 
> Thanks
> Max
> 
>> On May 26, 2018, at 6:06 PM, Weijun Wang  wrote:
>>
>> Please also review the release note at https://bugs.openjdk.java.net/browse/JDK-8203846.
>>
>> Thanks.
>>
>>> On May 25, 2018, at 8:27 AM, Weijun Wang  wrote:
>>>
>>> CSR and webrev updated.
>>>
>>>   webrev: http://cr.openjdk.java.net/~weijun/8072996/webrev.01/
>>>      CSR: https://bugs.openjdk.java.net/browse/JDK-8202953
>>>
>>> Thanks
>>> Max
>>
> 


From sean.mullan at oracle.com  Wed May 30 14:26:59 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 30 May 2018 10:26:59 -0400
Subject: RFR CSR 8203460: Update xmldsig implementation to latest version
 of Apache Santuario
In-Reply-To: 
References: <54D9DAEE-F409-47CC-8F0B-AC606FCA565A@oracle.com>
 <07490f97-1fb3-1a64-013f-48a2be20ffaf@oracle.com>
 <0EB794F2-9855-41B0-BECC-830072C8A36F@oracle.com>
 
 
Message-ID: 

Looks good.

--Sean

On 5/24/18 8:16 PM, Weijun Wang wrote:
> 
> 
>> On May 24, 2018, at 11:39 PM, Sean Mullan  wrote:
>>
>> I think the MGF1 based SignatureMethod algs should be named SHA256_RSA_MGF1, etc to be consistent with the URI names in the RFC.
> 
> Updated.
> 
> I've also updated my local code, no new webrev.
> 
>>
>> Otherwise the update looks good.
>>
>> I think we should also file an RFE to add a new RSAPSSParams class (which would be a subclass of SignatureMethodParameterSpec), and would contain the parameters for the RSASSA-PSS algorithm defined in https://tools.ietf.org/html/rfc6931#2.3.9.
> 
> https://bugs.openjdk.java.net/browse/JDK-8203804.
> 
> Thanks
> Max
> 
>>
>> --Sean
>>
>> On 5/23/18 8:19 PM, Weijun Wang wrote:
>>> Updated. I'm now using uri.substr(uri.indexOf("#") + 1).toUpperCase() as the names.
>>> Thanks
>>> Max
>>>> On May 24, 2018, at 4:47 AM, Sean Mullan  wrote:
>>>>
>>>> I don't think you should change the names of the algorithms to the JCE style (eg: SHA1withDSA). You should keep the names as defined by the W3C Recommendation and related RFCs. Even if the naming convention is different than JCE, these are the names that were chosen by the standards bodies and these are XML DSig specific algorithm names.
>>>>
>>>> Otherwise looks good.
>>>>
>>>> Thanks,
>>>> Sean
>>>>
>>>> On 5/21/18 10:57 PM, Weijun Wang wrote:
>>>>> Please take a review at
>>>>>     https://bugs.openjdk.java.net/browse/JDK-8203460
>>>>> The current XMLDSig provider implementation is based on Apache Santuario 1.5.4. We'll update it to be 2.1.1. New algorithms are added.
>>>>> Thanks
>>>>> Max
> 


From rajan.halade at oracle.com  Wed May 30 14:46:07 2018
From: rajan.halade at oracle.com (Rajan Halade)
Date: Wed, 30 May 2018 07:46:07 -0700
Subject: RFR: 8189949: Remove Baltimore Cybertrust Code Signing CA
In-Reply-To: <241b8e5a-e67b-7c39-f297-e6693cee64b2@oracle.com>
References: 
 <241b8e5a-e67b-7c39-f297-e6693cee64b2@oracle.com>
Message-ID: <1c9b7379-00e3-0d7a-0d7d-cc54a0ee57f7@oracle.com>

On 5/30/18 4:16 AM, Sean Mullan wrote:
> Looks good, 
thanks!
> but can you also add a release note to the bug?
good catch! I will add the release note to it and to earlier fix as well.

Thanks,
Rajan
>
> --Sean
>
> On 5/30/18 1:11 AM, Rajan Halade wrote:
>> May I request you to review this fix to remove baltimorecodesigningca 
>> from cacerts.
>>
>> Webrev: http://cr.openjdk.java.net/~rhalade/8189949/webrev.00/
>>
>> Thanks,
>> Rajan



From rajan.halade at oracle.com  Wed May 30 19:05:50 2018
From: rajan.halade at oracle.com (Rajan Halade)
Date: Wed, 30 May 2018 12:05:50 -0700
Subject: RFR: 8191031: Remove several Symantec Root CAs
Message-ID: 

May I request you to review this fix to remove listed Symantec root 
certificates.

Webrev: http://cr.openjdk.java.net/~rhalade/8191031/webrev.00/

Thanks,
Rajan


From sean.mullan at oracle.com  Wed May 30 20:23:26 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Wed, 30 May 2018 16:23:26 -0400
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <9b97fb7b-eee0-7c48-d962-cc5f4812c65a@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <3dda646c-2854-cdf2-cc1b-4d2c3133d787@oracle.com>
 
 <9b97fb7b-eee0-7c48-d962-cc5f4812c65a@oracle.com>
Message-ID: <6511336c-3601-4f0e-7a27-0aa88da621fc@oracle.com>

The updated webrev looks good. I have no further comments.

--Sean

On 5/22/18 4:43 PM, Jamil Nimeh wrote:
> A couple updates:
> 
>   * Touched up the comments surrounding init/wrap/unwrap methods. None
>     of these affect public javadocs.
>   * Added an implementation for engineGetParameters.? This was something
>     that just got forgotten from the initial development of the cipher
>     when there were no AlgorithmParameter implementations.
>       o There are a couple tests added to ChaCha20Poly1305ParamTest to
>         exercise these new code paths.
> 
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.08
> 
> Thanks,
> 
> --Jamil
> 
> 
> On 5/21/2018 11:36 AM, Jamil Nimeh wrote:
>>
>> And the fun just keeps going!? Round 7.
>>
>> This revision removes wrap/unwrap support for ChaCha20 and 
>> ChaCha20-Poly1305 until there is a standardized key wrapping approach 
>> for these ciphers (similar to how AES has its own key wrapping scheme 
>> in RFC 3394).
>>
>> Initializing the cipher with WRAP/UNWRAP mode will throw 
>> UnsupportedOperationException and likewise the wrap/unwrap methods 
>> will throw IllegalStateException.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.07/
>>
>> Thanks,
>>
>> --Jamil
>>
>>
>> On 05/16/2018 12:05 PM, Jamil Nimeh wrote:
>>>
>>> Round 6.
>>>
>>> This brings ChaCha20/ChaCha20-Poly1305 into conformance with Cipher's 
>>> specification when forms of init that take AlgorithmParameters or 
>>> AlgorithmParameterSpec are used. Previously, a non-null AP or APS 
>>> object was required.? In order to better conform to the 
>>> specification, if a null AP or APS is provided for these ciphers, a 
>>> random nonce will be generated and the counter will be set to 1, just 
>>> as is currently done with valid forms of init that don't take an AP 
>>> or APS object (e.g. Cipher.init(int, Key, SecureRandom) ). Per the 
>>> spec in Cipher, this is only true for ENCRYPT_MODE and will throw 
>>> InvalidKeyException when done in DECRYPT_MODE.
>>>
>>> I also added a few test cases that exercise these code paths in the 
>>> ChaCha20Poly1305Parameters.java test case.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>>>
>>> Thanks,
>>>
>>> --Jamil
>>>
>>>
>>> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>>>
>>>> Round 5.
>>>>
>>>> This adds Sean's comments.? Sean, I was never able to execute a case 
>>>> on init where a half-baked object would fail.? In most cases it 
>>>> would fail in checks in javax.crypto.Cipher before it ever made it 
>>>> down to my code. I'm pretty confident the init sequence is OK.? I 
>>>> did move the setting of a few data members toward the end of the 
>>>> init sequence but setting the key and nonce is necessary before 
>>>> creating the initial state, which is then used for generating an 
>>>> authentication key for AEAD mode and generating keystream.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>>
>>>> Also the CSR has been finalized and can be found here:
>>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>>
>>>> --Jamil
>>>>
>>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>>
>>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>>> mostly:
>>>>>
>>>>>   * Added words in the description of javax.crypto.Cipher
>>>>>     recommending callers reinitialize the Cipher to use different
>>>>>     nonces after each complete encryption or decryption (similar
>>>>>     language to what exists already for AES-GCM encryption).
>>>>>   * Added an additional test case for ChaCha20NoReuse
>>>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>>>     cleaned up the code a bit based on comments from the field.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --Jamil
>>>>>
>>>>>
>>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>>
>>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>>> for catching this)
>>>>>>
>>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances of 
>>>>>> these ciphers will no longer allow you to do subsequent 
>>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>>> throw an IllegalStateException.? This is similar to the behavior 
>>>>>> of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done 
>>>>>> for both encrypt and decrypt.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>>
>>>>>> Thanks,
>>>>>> --Jamil
>>>>>>
>>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>> This is a quick update to the previous webrev:
>>>>>>>
>>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>>> and random, the nonce will always be random even if the random 
>>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>>
>>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>>
>>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>>> separator from a System property directly.? It calls 
>>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --Jamil
>>>>>>>
>>>>>>>
>>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>>> the ciphers are listed below.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> --Jamil
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 


From jamil.j.nimeh at oracle.com  Wed May 30 21:39:38 2018
From: jamil.j.nimeh at oracle.com (Jamil Nimeh)
Date: Wed, 30 May 2018 14:39:38 -0700
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <9b97fb7b-eee0-7c48-d962-cc5f4812c65a@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <3dda646c-2854-cdf2-cc1b-4d2c3133d787@oracle.com>
 
 <9b97fb7b-eee0-7c48-d962-cc5f4812c65a@oracle.com>
Message-ID: <3108ed41-3c43-6f4c-ef70-acd415eb4ed8@oracle.com>

Hopefully the final set of updates before committing this feature:

  * Updated the ChaChaEngine implementations in ChaCha20Cipher.java to
    properly conform to Cipher's specification when the output buffer
    used in doUpdate is too small.? Instead of throwing
    IndexOutOfBoundsException like it was doing, it will now throw a
    ShortBufferException per the spec.

http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.09

Thanks,

--Jamil


On 05/22/2018 01:43 PM, Jamil Nimeh wrote:
> A couple updates:
>
>   * Touched up the comments surrounding init/wrap/unwrap methods.?
>     None of these affect public javadocs.
>   * Added an implementation for engineGetParameters.? This was
>     something that just got forgotten from the initial development of
>     the cipher when there were no AlgorithmParameter implementations.
>       o There are a couple tests added to ChaCha20Poly1305ParamTest to
>         exercise these new code paths.
>
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.08
>
> Thanks,
>
> --Jamil
>
>
> On 5/21/2018 11:36 AM, Jamil Nimeh wrote:
>>
>> And the fun just keeps going!? Round 7.
>>
>> This revision removes wrap/unwrap support for ChaCha20 and 
>> ChaCha20-Poly1305 until there is a standardized key wrapping approach 
>> for these ciphers (similar to how AES has its own key wrapping scheme 
>> in RFC 3394).
>>
>> Initializing the cipher with WRAP/UNWRAP mode will throw 
>> UnsupportedOperationException and likewise the wrap/unwrap methods 
>> will throw IllegalStateException.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.07/
>>
>> Thanks,
>>
>> --Jamil
>>
>>
>> On 05/16/2018 12:05 PM, Jamil Nimeh wrote:
>>>
>>> Round 6.
>>>
>>> This brings ChaCha20/ChaCha20-Poly1305 into conformance with 
>>> Cipher's specification when forms of init that take 
>>> AlgorithmParameters or AlgorithmParameterSpec are used. Previously, 
>>> a non-null AP or APS object was required.? In order to better 
>>> conform to the specification, if a null AP or APS is provided for 
>>> these ciphers, a random nonce will be generated and the counter will 
>>> be set to 1, just as is currently done with valid forms of init that 
>>> don't take an AP or APS object (e.g. Cipher.init(int, Key, 
>>> SecureRandom) ).? Per the spec in Cipher, this is only true for 
>>> ENCRYPT_MODE and will throw InvalidKeyException when done in 
>>> DECRYPT_MODE.
>>>
>>> I also added a few test cases that exercise these code paths in the 
>>> ChaCha20Poly1305Parameters.java test case.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>>>
>>> Thanks,
>>>
>>> --Jamil
>>>
>>>
>>> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>>>
>>>> Round 5.
>>>>
>>>> This adds Sean's comments.? Sean, I was never able to execute a 
>>>> case on init where a half-baked object would fail.? In most cases 
>>>> it would fail in checks in javax.crypto.Cipher before it ever made 
>>>> it down to my code.? I'm pretty confident the init sequence is OK.? 
>>>> I did move the setting of a few data members toward the end of the 
>>>> init sequence but setting the key and nonce is necessary before 
>>>> creating the initial state, which is then used for generating an 
>>>> authentication key for AEAD mode and generating keystream.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>>
>>>> Also the CSR has been finalized and can be found here:
>>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>>
>>>> --Jamil
>>>>
>>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>>
>>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>>> mostly:
>>>>>
>>>>>   * Added words in the description of javax.crypto.Cipher
>>>>>     recommending callers reinitialize the Cipher to use different
>>>>>     nonces after each complete encryption or decryption (similar
>>>>>     language to what exists already for AES-GCM encryption).
>>>>>   * Added an additional test case for ChaCha20NoReuse
>>>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>>>     cleaned up the code a bit based on comments from the field.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --Jamil
>>>>>
>>>>>
>>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>>
>>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>>> for catching this)
>>>>>>
>>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances 
>>>>>> of these ciphers will no longer allow you to do subsequent 
>>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>>> throw an IllegalStateException.? This is similar to the behavior 
>>>>>> of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done 
>>>>>> for both encrypt and decrypt.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>>
>>>>>> Thanks,
>>>>>> --Jamil
>>>>>>
>>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>>> Hello everyone,
>>>>>>>
>>>>>>> This is a quick update to the previous webrev:
>>>>>>>
>>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>>> and random, the nonce will always be random even if the random 
>>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>>
>>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>>
>>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>>> separator from a System property directly. It calls 
>>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> --Jamil
>>>>>>>
>>>>>>>
>>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>>> Hello all,
>>>>>>>>
>>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>>> the ciphers are listed below.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> --Jamil
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: 

From sean.mullan at oracle.com  Thu May 31 12:55:16 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 31 May 2018 08:55:16 -0400
Subject: RFR: ChaCha20 and ChaCha20/Poly1305 Cipher implementations
In-Reply-To: <3108ed41-3c43-6f4c-ef70-acd415eb4ed8@oracle.com>
References: 
 <5dca59d9-e79b-91de-810a-e544c0b3b9ba@oracle.com>
 <4cdfa771-b222-2986-b1fa-2a67a89b9212@oracle.com>
 
 
 <3dda646c-2854-cdf2-cc1b-4d2c3133d787@oracle.com>
 
 <9b97fb7b-eee0-7c48-d962-cc5f4812c65a@oracle.com>
 <3108ed41-3c43-6f4c-ef70-acd415eb4ed8@oracle.com>
Message-ID: 

Looks fine to me.

--Sean

On 5/30/18 5:39 PM, Jamil Nimeh wrote:
> Hopefully the final set of updates before committing this feature:
> 
>   * Updated the ChaChaEngine implementations in ChaCha20Cipher.java to
>     properly conform to Cipher's specification when the output buffer
>     used in doUpdate is too small.? Instead of throwing
>     IndexOutOfBoundsException like it was doing, it will now throw a
>     ShortBufferException per the spec.
> 
> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.09
> 
> Thanks,
> 
> --Jamil
> 
> 
> On 05/22/2018 01:43 PM, Jamil Nimeh wrote:
>> A couple updates:
>>
>>   * Touched up the comments surrounding init/wrap/unwrap methods. 
>>     None of these affect public javadocs.
>>   * Added an implementation for engineGetParameters.? This was
>>     something that just got forgotten from the initial development of
>>     the cipher when there were no AlgorithmParameter implementations.
>>       o There are a couple tests added to ChaCha20Poly1305ParamTest to
>>         exercise these new code paths.
>>
>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.08
>>
>> Thanks,
>>
>> --Jamil
>>
>>
>> On 5/21/2018 11:36 AM, Jamil Nimeh wrote:
>>>
>>> And the fun just keeps going!? Round 7.
>>>
>>> This revision removes wrap/unwrap support for ChaCha20 and 
>>> ChaCha20-Poly1305 until there is a standardized key wrapping approach 
>>> for these ciphers (similar to how AES has its own key wrapping scheme 
>>> in RFC 3394).
>>>
>>> Initializing the cipher with WRAP/UNWRAP mode will throw 
>>> UnsupportedOperationException and likewise the wrap/unwrap methods 
>>> will throw IllegalStateException.
>>>
>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.07/
>>>
>>> Thanks,
>>>
>>> --Jamil
>>>
>>>
>>> On 05/16/2018 12:05 PM, Jamil Nimeh wrote:
>>>>
>>>> Round 6.
>>>>
>>>> This brings ChaCha20/ChaCha20-Poly1305 into conformance with 
>>>> Cipher's specification when forms of init that take 
>>>> AlgorithmParameters or AlgorithmParameterSpec are used. Previously, 
>>>> a non-null AP or APS object was required.? In order to better 
>>>> conform to the specification, if a null AP or APS is provided for 
>>>> these ciphers, a random nonce will be generated and the counter will 
>>>> be set to 1, just as is currently done with valid forms of init that 
>>>> don't take an AP or APS object (e.g. Cipher.init(int, Key, 
>>>> SecureRandom) ).? Per the spec in Cipher, this is only true for 
>>>> ENCRYPT_MODE and will throw InvalidKeyException when done in 
>>>> DECRYPT_MODE.
>>>>
>>>> I also added a few test cases that exercise these code paths in the 
>>>> ChaCha20Poly1305Parameters.java test case.
>>>>
>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.06/
>>>>
>>>> Thanks,
>>>>
>>>> --Jamil
>>>>
>>>>
>>>> On 05/04/2018 07:06 AM, Jamil Nimeh wrote:
>>>>>
>>>>> Round 5.
>>>>>
>>>>> This adds Sean's comments.? Sean, I was never able to execute a 
>>>>> case on init where a half-baked object would fail.? In most cases 
>>>>> it would fail in checks in javax.crypto.Cipher before it ever made 
>>>>> it down to my code.? I'm pretty confident the init sequence is OK.  
>>>>> I did move the setting of a few data members toward the end of the 
>>>>> init sequence but setting the key and nonce is necessary before 
>>>>> creating the initial state, which is then used for generating an 
>>>>> authentication key for AEAD mode and generating keystream.
>>>>>
>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.05
>>>>>
>>>>> Also the CSR has been finalized and can be found here:
>>>>> https://bugs.openjdk.java.net/browse/JDK-8198925
>>>>>
>>>>> --Jamil
>>>>>
>>>>> On 04/27/2018 02:21 PM, Jamil Nimeh wrote:
>>>>>>
>>>>>> Round 4 of updates for ChaCha20 and ChaCha20-Poly1305, minor stuff 
>>>>>> mostly:
>>>>>>
>>>>>>   * Added words in the description of javax.crypto.Cipher
>>>>>>     recommending callers reinitialize the Cipher to use different
>>>>>>     nonces after each complete encryption or decryption (similar
>>>>>>     language to what exists already for AES-GCM encryption).
>>>>>>   * Added an additional test case for ChaCha20NoReuse
>>>>>>   * Made accessor methods for ChaCha20ParameterSpec final and
>>>>>>     cleaned up the code a bit based on comments from the field.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.04/
>>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> --Jamil
>>>>>>
>>>>>>
>>>>>> On 04/13/2018 11:59 AM, Jamil Nimeh wrote:
>>>>>>> Round 3 of updates for ChaCha20 and ChaCha20-Poly1305:
>>>>>>>
>>>>>>> * Removed the key field in ChaCha20 and Poly1305 implementations 
>>>>>>> and only retain the key bytes as an object field (thanks Thomas 
>>>>>>> for catching this)
>>>>>>>
>>>>>>> * Added additional protections against key/nonce reuse. This is a 
>>>>>>> behavioral change to ChaCha20 and ChaCha20-Poly1305.? Instances 
>>>>>>> of these ciphers will no longer allow you to do subsequent 
>>>>>>> doUpdate/doFinal calls after the first doFinal without 
>>>>>>> re-initializing the cipher with either a new key or nonce. 
>>>>>>> Attempting to reuse the cipher without a new initialization will 
>>>>>>> throw an IllegalStateException.? This is similar to the behavior 
>>>>>>> of AES-GCM in encrypt mode, but for ChaCha20 it needs to be done 
>>>>>>> for both encrypt and decrypt.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.03/
>>>>>>>
>>>>>>> Thanks,
>>>>>>> --Jamil
>>>>>>>
>>>>>>> On 04/10/2018 03:34 PM, Jamil Nimeh wrote:
>>>>>>>> Hello everyone,
>>>>>>>>
>>>>>>>> This is a quick update to the previous webrev:
>>>>>>>>
>>>>>>>> * When using the form of engineInit that does only takes op, key 
>>>>>>>> and random, the nonce will always be random even if the random 
>>>>>>>> parameter is null.? A default instance of SecureRandom will be 
>>>>>>>> used to create the nonce in this case, instead of all zeroes.
>>>>>>>>
>>>>>>>> * Unused debug code was removed from the ChaCha20Cipher.java file
>>>>>>>>
>>>>>>>> * ChaCha20Parameters.engineToString no longer obtains the line 
>>>>>>>> separator from a System property directly. It calls 
>>>>>>>> System.lineSeparator() similar to how other AlgorithmParameter 
>>>>>>>> classes in com.sun.crypto.provider do it.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.02/
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> --Jamil
>>>>>>>>
>>>>>>>>
>>>>>>>> On 03/26/2018 12:08 PM, Jamil Nimeh wrote:
>>>>>>>>> Hello all,
>>>>>>>>>
>>>>>>>>> This is a request for review for the ChaCha20 and 
>>>>>>>>> ChaCha20-Poly1305 cipher implementations.? Links to the webrev 
>>>>>>>>> and the JEP which outlines the characteristics and behavior of 
>>>>>>>>> the ciphers are listed below.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~jnimeh/reviews/8153028/webrev.01/
>>>>>>>>> http://openjdk.java.net/jeps/329
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> --Jamil
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
> 


From ivan.gerasimov at oracle.com  Thu May 31 17:20:18 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 31 May 2018 10:20:18 -0700
Subject: [8u-dev] Request for Review and Approval to Backport 8189760 :
 sun/security/ssl/CertPathRestrictions/TLSRestrictions.java failed with
 unexpected Exception intermittently
Message-ID: <9ad953fb-aabf-95a0-5338-abcfe09ab485@oracle.com>

Hello!

The test failure (in the subj. line) was observed in JDK 8u, so I'd like 
to backport the fix.

The patch did not apply cleanly due to the difference in couple of 
lines, thus the re-review request.

(Specifically, the difference is in TLSRestrictions.java, lines 216 and 
221 of patched version; otherwise, the fix is essentially the same.)

The patched test passed well on all supported platforms.

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

Jdk 8u webrev: http://cr.openjdk.java.net/~igerasim/8189760/00/webrev/

Jdk 11 change: 
http://closedjdk.us.oracle.com/jdk/jdk-cpu/open/rev/2d250a0174a6

Jdk 11 review: 
http://mail.openjdk.java.net/pipermail/security-dev/2018-January/016675.html

Thanks in advance!

-- 
With kind regards,
Ivan Gerasimov



From sean.mullan at oracle.com  Thu May 31 19:00:43 2018
From: sean.mullan at oracle.com (Sean Mullan)
Date: Thu, 31 May 2018 15:00:43 -0400
Subject: RFR: 8191031: Remove several Symantec Root CAs
In-Reply-To: 
References: 
Message-ID: 

Looks good.

--Sean

On 5/30/18 3:05 PM, Rajan Halade wrote:
> May I request you to review this fix to remove listed Symantec root 
> certificates.
> 
> Webrev: http://cr.openjdk.java.net/~rhalade/8191031/webrev.00/
> 
> Thanks,
> Rajan


From sean.coffey at oracle.com  Thu May 31 19:13:05 2018
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Thu, 31 May 2018 20:13:05 +0100
Subject: [8u-dev] Request for Review and Approval to Backport 8189760 :
 sun/security/ssl/CertPathRestrictions/TLSRestrictions.java failed with
 unexpected Exception intermittently
In-Reply-To: <9ad953fb-aabf-95a0-5338-abcfe09ab485@oracle.com>
References: <9ad953fb-aabf-95a0-5338-abcfe09ab485@oracle.com>
Message-ID: <3e1e1db8-11eb-40a2-487f-d14bd6927591@oracle.com>

Looks fine Ivan.

Approved for jdk8u-dev.

regards,
Sean.


On 31/05/2018 18:20, Ivan Gerasimov wrote:
> Hello!
>
> The test failure (in the subj. line) was observed in JDK 8u, so I'd 
> like to backport the fix.
>
> The patch did not apply cleanly due to the difference in couple of 
> lines, thus the re-review request.
>
> (Specifically, the difference is in TLSRestrictions.java, lines 216 
> and 221 of patched version; otherwise, the fix is essentially the same.)
>
> The patched test passed well on all supported platforms.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8189760
>
> Jdk 8u webrev: http://cr.openjdk.java.net/~igerasim/8189760/00/webrev/
>
> Jdk 11 change: 
> http://closedjdk.us.oracle.com/jdk/jdk-cpu/open/rev/2d250a0174a6
>
> Jdk 11 review: 
> http://mail.openjdk.java.net/pipermail/security-dev/2018-January/016675.html
>
> Thanks in advance!
>



From ivan.gerasimov at oracle.com  Thu May 31 19:33:29 2018
From: ivan.gerasimov at oracle.com (Ivan Gerasimov)
Date: Thu, 31 May 2018 12:33:29 -0700
Subject: [8u-dev] Request for Review and Approval to Backport 8189760 :
 sun/security/ssl/CertPathRestrictions/TLSRestrictions.java failed with
 unexpected Exception intermittently
In-Reply-To: <3e1e1db8-11eb-40a2-487f-d14bd6927591@oracle.com>
References: <9ad953fb-aabf-95a0-5338-abcfe09ab485@oracle.com>
 <3e1e1db8-11eb-40a2-487f-d14bd6927591@oracle.com>
Message-ID: 

Thanks Se?n!


On 5/31/18 12:13 PM, Se?n Coffey wrote:
> Looks fine Ivan.
>
> Approved for jdk8u-dev.
>
> regards,
> Sean. 



From xuelei.fan at oracle.com  Thu May 31 22:43:37 2018
From: xuelei.fan at oracle.com (Xuelei Fan)
Date: Thu, 31 May 2018 15:43:37 -0700
Subject: Code Review Request: TLS 1.3 Implementation
In-Reply-To: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com>
References: <9a98c066-d214-5d47-f8ca-473adefe9d42@oracle.com>
Message-ID: <131b1645-d297-f39b-f119-97b0eaa77c44@oracle.com>

 > Here is the webrev:
 >      http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00

Update:
    http://hg.openjdk.java.net/jdk/sandbox/rev/e57205a6e4ee

The above update took care of integer overflow, and removed a few unused 
code and comments.

Thanks,
Xuelei


On 5/25/2018 4:45 PM, Xuelei Fan wrote:
> Hi,
> 
> I'd like to invite you to review the TLS 1.3 implementation.? I 
> appreciate it if I could have compatibility and specification feedback 
> before May 31, 2018, and implementation feedback before June 7, 2018.
> 
> Here is the webrev:
>  ??? http://cr.openjdk.java.net/~xuelei/8196584/webrev-full.00
> 
> The formal TLS 1.3 specification is not finalized yet, although it had 
> been approved to be a standard.? The implementation is based on the 
> draft version 28:
>  ??? https://tools.ietf.org/html/draft-ietf-tls-tls13-28
> 
> For the overall description of this enhancement, please refer to JEP 332:
>  ??? http://openjdk.java.net/jeps/332
> 
> For the compatibility and specification update, please refer to CSR 
> 8202625:
>  ??? https://bugs.openjdk.java.net/browse/JDK-8202625
> 
> Note that we are using the sandbox for the development right now.? For 
> more information, please refer to Bradford's previous email:
> 
> http://mail.openjdk.java.net/pipermail/security-dev/2018-May/017139.html
> 
> Thanks & Regards,
> Xuelei


From valerie.peng at oracle.com  Thu May 31 23:46:14 2018
From: valerie.peng at oracle.com (Valerie Peng)
Date: Thu, 31 May 2018 16:46:14 -0700
Subject: [RFR]: JDK-8203182 - Release session if initialization of
 SunPKCS11 Signature fails
In-Reply-To: 
References: 
 
 
Message-ID: <252488ad-9741-f381-49dd-e5cf9eff2ce9@oracle.com>

Hi Martin,

Thanks for covering additional scenarios.

The updated webrev looks good to me. I will sponsor your patch.

Thanks,
Valerie

On 5/24/2018 12:13 PM, Martin Balao wrote:
> Hi Valerie,
>
> Thanks for your review.
>
> These are the cases I identified:
>
> ?* engineSign and engineVerify include a try-finally block that 
> releases the session under any circumstances.
>
> ?* engineUpdate may leak. Session release added if failure occurs.
>
> ?* cancelOperation may leak. If session has no objects, it's killed. 
> If it has, a "cancel operation by finishing it" code is executed. This 
> code can fail on sign/verify operations, and a session may be leaked. 
> It's not clear to me why this "cancel operation by finishing it" code 
> is needed, though. Added a try-finally block anyways.
>
> Webrev 01:
>
> ?* 
> http://cr.openjdk.java.net/~mbalao/webrevs/8203182/8203182.webrev.01/ 
> 
> ?* 
> http://cr.openjdk.java.net/~mbalao/webrevs/8203182/8203182.webrev.01.zip 
> 
>
> Look forward to your answer.
>
> Kind regards,
> Martin.-
>
> On Tue, May 15, 2018 at 7:30 PM, Valerie Peng  > wrote:
>
>     Hi Martin,
>
>     Your fix only addresses the initialization case. Have you
>     considered fixing the same problem under difference calls?
>
>     Regards,
>     Valerie
>
>     On 5/14/2018 3:25 PM, Martin Balao wrote:
>
>         Hi,
>
>         Can I have a review for "JDK-8203182 - Release session if
>         initialization of SunPKCS11 Signature fails" [1]?
>
>         ?*
>         http://cr.openjdk.java.net/~mbalao/webrevs/8203182/8203182.webrev.00/
>         
>                  >
>         ?*
>         http://cr.openjdk.java.net/~mbalao/webrevs/8203182/8203182.webrev.00.zip
>         
>                  >
>
>         Thanks in advanced!
>
>         Martin.-
>
>         --
>         [1] - https://bugs.openjdk.java.net/browse/JDK-8203182
>         
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: