RFR: JDK-8140466: ChaCha20-Poly1305 TLS cipher suites
Hello all, This change will add ChaCha20-Poly1305 cipher suites to our TLS 1.2 and TLS 1.3 implementations. A few test cases had to be updated to reflect the new suites as well. JBS: https://bugs.openjdk.java.net/browse/JDK-8140466 CSR: https://bugs.openjdk.java.net/browse/JDK-8204192 Webrev: http://cr.openjdk.java.net/~jnimeh/reviews/8140466/webrev.01/ Thanks, --Jamil
Re: RFR: 8210432: Add additional TeliaSonera root certificate
Looks good. --Sean On 9/5/18 6:33 PM, Rajan Halade wrote: Please review this fix to add new TeliaSonera root certificate to the cacert store. Webrev: http://cr.openjdk.java.net/~rhalade/8210432/webrev.00/ Thanks, Rajan
RFR: 8210432: Add additional TeliaSonera root certificate
Please review this fix to add new TeliaSonera root certificate to the cacert store. Webrev: http://cr.openjdk.java.net/~rhalade/8210432/webrev.00/ Thanks, Rajan
Re: RFR 6913047: SunPKCS11 memory leak
On 9/4/2018 9:59 PM, Valerie Peng wrote: These sun.security.pkcs11.wrapper classes are internal and subject to changes without notice. No arguments there. But that interface has been stable since the initial contribution and to be blunt - the PKCS11 provider only works well if you use the keys you created through the provider. There's a set of idiosyncratic choices for how to map keys to certs to keys that make keys created by non-provider calls (e.g. C code or other non-java libs) to the token difficult to use through the provider and vice versa. That led to us using the wrapper classes directly. Maybe its time to provide a PKCS11AttributeSpec of some sort for key creation and for looking things up? The current model is literally 12-15 years old AFAICT. For the time being, maybe we can leave these method intact and add a comment about calling the new methods which use P11Key argument instead of the key handle argument. That should work. You may want to think about deprecating those methods and target removing them for a later release in a couple of years. Thanks - Mike Regards, Valerie On 9/1/2018 11:18 AM, Michael StJohns wrote: Hi Valerie - I may be speaking only for myself, but there are probably a number of folk using sun.security.pkcs11.wrapper.* in lieu of the PKCS11 provider for a number of reasons including an ability to manage the key storage and wrapping efficiently. Looking at this I'm thinking there will be a large number of things breaking because of the way you refactored things. While I understand that none of the sun.security.* classes are "public" - these were mostly taken directly from the IAIK contribution way back when and the folks I worked with used them in lieu of external libraries to have a consistent PKCS11 interface java-to-java. Perhaps instead you'd consider doing something like leaving the Java to Native public methods intact? Mike On 8/31/2018 7:53 PM, Valerie Peng wrote: Hi Martin, With the new model of "creating the key handle as needed", I think we should not allow the direct access of keyID field outside of P11Key class. This field should be made private and accessed through methods. In addition, existing PKCS11.C_XXX() methods with P11 keyID arguments can be made private and we can add wrapper methods with P11Key object argument to ensure proper usage of the P11Key object and its keyID field. I have also refactored the keyID management code into a separate holder class. The prototype code can be found at: http://cr.openjdk.java.net/~valeriep/6913047Exp/webrev.00/ The main changes that I made are in P11Key.java and PKCS11.java. The other java classes are updated to call the wrapper methods in PKCS11.java. Thanks & have a great Labor day weekend, Valerie On 8/16/2018 5:28 PM, Valerie Peng wrote: Hi Martin, Since there is no regression test for this test, you will need to add a "noreg-xxx" label to the bug record. For this issue, it'll probably be "noreg-hard". To understand the changes better, please find my questions and some review comments below: - line 397: It's incorrect to change initialize() to ensureInitialized(). If the cipher object were to be initialized twice with two different keys, you need to re-initialize again. - line 471: Why do you change it to Throwable from PKCS11Exception? - line 99: comment is somewhat unclear. typo: "temporal" should be "temporary". - line 148-149: JDK-8165996 has been fixed. This does not apply now, does it? - You changed the constructors of all the P11Key-related classes to take an additional boolean argument "tmpNativeKey". However, this boolean argument is only used when the underlying token is "NSS". Why limiting to NSS only? It seems that all callers except for PKCS11 KeyStore pass true for "tmpNativeKey". When "tmpNativeKey" is true, the keyID handle first destroyed in constructor and later created again (ref count == 1) and destroyed (when ref count drops to 0). This replaced the PhantomReference approach in SessionKeyRef class, right? Now both approaches seem to be used and key destruction is taking places at different methods. I think we should clarify the cleanup model and perhaps refactor the code so it's easier which approach is in use. Or grouping all these cleanup-related fields/variables into a separate class for readability/clarity. - line 157-175: nativeKeyWrapperKeyID is a static variable, shouldn't it be synchronized on a class level object? - line 1343: the impl doesn't look right. Why do you call both removeObject() and addObject() here with the same check? - line 1363: the change seems incorrect, you should still call session.removeObject(). the call setKeyIDAndSession(0, null) does not lower the session object count. Thanks, Valerie On 8/7/2018 5:41 PM, Valerie Peng wrote: Hi Martin, Thanks for the update, I will resume the review on this one with your latest webrev. BTW, there is no webr
Re: Conceptual feedback on new ECC JEP
On 9/5/2018 2:47 PM, Adam Petcher wrote: On 9/4/2018 5:20 PM, Michael StJohns wrote: On 9/4/2018 3:19 PM, Adam Petcher wrote: I think what you are suggesting is that the implementation should convert between BigInteger and the internal representation when necessary. The problem with this approach is that it is too easy to inadvertently supply a BigInteger to the implementation, and this would result in a branch. I understand that this branch may be acceptable in some circumstances, but we would need something in the API to tell the implementation whether it is okay to branch or not. I think the simplest way to do that is to have a provider that never branches. If branching is okay, then SunEC can be used. Basically yes. But I don't understand what you mean by "inadvertently supply a BigInteger"? AFAICT, you "supply" a BigInteger in an ECPrivateKeySpec and you retrieve one when you call getEncoded() or getS(). Your implementation would convert between the BigInteger and internal representation during the use of the engineGeneratePrivate() method of the KeyFactorySpi and would convert from your internal representation when exporting S, or encoding something as PKCS8. I mean that the JCA client code may put a private key value in an ECPrivateKeySpec and give it to the KeyFactory of the new ECC implementation. Also problematic is calling getS() on an ECPrivateKey from the new implementation and converting the private key to a BigInteger. Both of these situations may leak some bits of the private key value into side channels, and the use of the "NewEC" provider is an assertion by the programmer/environment that these side-channel leaks are unacceptable. So the new provider will prevent these problems by rejecting ECPrivateKeySpec in its KeyFactory, and by returning null from getS(). BigInteger will not be used by engineGeneratePrivate when the spec is a PKCS8EncodedKeySpec (the only option). BigInteger is also not required to encode/decode a PKCS#8 private key. BigInteger is not required to encode a PKCS8 key, but its trivial to translate from BigInteger to PKCS8 and vice versa. Note that internally, the current BigInteger stores the magnitude as an array of int in big endian order and stores the sign separately. The BigInteger (int sigNum, byte[] magnitude) constructor mostly just copies the magnitude bytes over (and converts 4 bytes to an integer) for positive integers. While the current BigInteger doesn't have a byte[] BigInteger.getMagnitude() call, it would be trivial to subclass BigInteger to copy the magnitude bytes (without branching) out. In any event, for NewEC to OldEc - you do use the sign/magnitude call to create the BigInteger - no leaking on the part of NewEC, and once it gets to OldEC its not your problem. For OldEc to NewEc you copy the BigInteger to NewBigInteger (trivial wrapper class) and do a getMagnitude(). Again - you're wrongly conflating interface requirements with implementation requirements. And how do you expect to move key material between SunEC and this implementation? See below for my commentary on that. That's essentially the plan. Calling PrivateKey::getEncoded will return null, which is a convention for non-extractable keys. Trying to convert from/to an ECPrivateKeySpec using the KeyFactory in the new provider will result in an exception---so you won't have an object to call getS() on. That's not what PKCS11 does - it just gives you a "PrivateKey" object with an internal type of sun.security.pkcs11.P11Key. While that object is not type safe exactly, it is provider safe. You're still wanting to use the various EC classes of java.security, java.security.spec, and java.security.interfaces, but you're unwilling to actually meet their contracts for some really suspect reasons. Sorry, I referred to the wrong methods in my last e-mail. ECPrivateKey::getS will return null in the new implementation. The getEncoded method will return the encoded key, as usual. The second sentence referred to ECPrivateKeySpec::getS, which will remain unchanged, but you won't be able to use ECPrivateKeySpec with the new provider. I don't believe my proposal violates the contracts of any of these classes, but if you believe that it does (after the correction above), then let me know which contracts are violated. While the contract for getEncoded() explicitly allows for a null result, getS() of ECPrivateKey does not. This more than any other reason appears to be why the PKCS 11 provider represents the ECPrivateKey as a simple PrivateKey object. To create the key from stored information, the best way is to construct a PKCS8EncodedKeySpec using the encoded key. If you are starting with a BigInteger, and if branching is acceptable, you can use the KeyFactory from SunEC to convert an ECPrivateKeySpec to PrivateKey to get the encoded value. Umm... what? If you were doing NewEC -> SunEC manually (
Re: RFR 8171279: Support X25519 and X448 in TLS 1.3
New webrev: http://cr.openjdk.java.net/~apetcher/8171279/webrev.02/ On 9/5/2018 1:35 PM, Xuelei Fan wrote: On 9/5/2018 10:09 AM, Adam Petcher wrote: Is there some place in the code where JSSE is doing something too complicated related to these parameters? Yes, the algorithm name is sufficient, I'm not sure the necessary to use XECParameters in sun.security.util. The algorithm name is not quite sufficient. See the new methods that were added to ECUtil that encode/decode public keys. We also need to know the key length (which is in XECParameters) in order to encode/decode public keys. I simply continued the pattern that was used in DH and ECDH. We can use a different string here, but I worry that people will be surprised if DH and ECDH support "TlsPreMasterSecret" but XDH doesn't. It could support "TlsPreMasterSecret", right? My concern is about not limited to this one only. Yes, it supports "TlsPreMasterSecret" in the webrev now. Perhaps I'm not sure what you are suggesting here. 3. NamedGroupFunctions It might be more straightforward to define these functions in NamedGroup. If comparing nameGroup.getFunctions().getParameterSpec() and namedGroup.getParameterSpec(), I'd prefer the latter. A simple way to accomplish this is to leave the structure alone and add methods in NamedGroup that pass through to the corresponding methods in NamedGroupFunctions. I made this change in the updated webrev. Let me know what you think. It looks like a problem to me to use this before it constructed. this.functions = new ECDHFunctions(this); and the use of new object for each named group is not effective. The current NamedGroupFunctions abstract class does not sound good enough to me, considering the numbers of the named groups. I have no idea so far, but I think you can improve it. Probably use static methods? In the latest webrev, I changed it so there is a single static NamedGroupFunctions of each type, and the NamedGroup is passed in as the first argument to each method that requires it (rather than being a member of NamedGroupFunctions).
Re: Conceptual feedback on new ECC JEP
On 9/4/2018 5:20 PM, Michael StJohns wrote: On 9/4/2018 3:19 PM, Adam Petcher wrote: I think what you are suggesting is that the implementation should convert between BigInteger and the internal representation when necessary. The problem with this approach is that it is too easy to inadvertently supply a BigInteger to the implementation, and this would result in a branch. I understand that this branch may be acceptable in some circumstances, but we would need something in the API to tell the implementation whether it is okay to branch or not. I think the simplest way to do that is to have a provider that never branches. If branching is okay, then SunEC can be used. Basically yes. But I don't understand what you mean by "inadvertently supply a BigInteger"? AFAICT, you "supply" a BigInteger in an ECPrivateKeySpec and you retrieve one when you call getEncoded() or getS(). Your implementation would convert between the BigInteger and internal representation during the use of the engineGeneratePrivate() method of the KeyFactorySpi and would convert from your internal representation when exporting S, or encoding something as PKCS8. I mean that the JCA client code may put a private key value in an ECPrivateKeySpec and give it to the KeyFactory of the new ECC implementation. Also problematic is calling getS() on an ECPrivateKey from the new implementation and converting the private key to a BigInteger. Both of these situations may leak some bits of the private key value into side channels, and the use of the "NewEC" provider is an assertion by the programmer/environment that these side-channel leaks are unacceptable. So the new provider will prevent these problems by rejecting ECPrivateKeySpec in its KeyFactory, and by returning null from getS(). BigInteger will not be used by engineGeneratePrivate when the spec is a PKCS8EncodedKeySpec (the only option). BigInteger is also not required to encode/decode a PKCS#8 private key. Again - you're wrongly conflating interface requirements with implementation requirements. And how do you expect to move key material between SunEC and this implementation? See below for my commentary on that. That's essentially the plan. Calling PrivateKey::getEncoded will return null, which is a convention for non-extractable keys. Trying to convert from/to an ECPrivateKeySpec using the KeyFactory in the new provider will result in an exception---so you won't have an object to call getS() on. That's not what PKCS11 does - it just gives you a "PrivateKey" object with an internal type of sun.security.pkcs11.P11Key. While that object is not type safe exactly, it is provider safe. You're still wanting to use the various EC classes of java.security, java.security.spec, and java.security.interfaces, but you're unwilling to actually meet their contracts for some really suspect reasons. Sorry, I referred to the wrong methods in my last e-mail. ECPrivateKey::getS will return null in the new implementation. The getEncoded method will return the encoded key, as usual. The second sentence referred to ECPrivateKeySpec::getS, which will remain unchanged, but you won't be able to use ECPrivateKeySpec with the new provider. I don't believe my proposal violates the contracts of any of these classes, but if you believe that it does (after the correction above), then let me know which contracts are violated. To create the key from stored information, the best way is to construct a PKCS8EncodedKeySpec using the encoded key. If you are starting with a BigInteger, and if branching is acceptable, you can use the KeyFactory from SunEC to convert an ECPrivateKeySpec to PrivateKey to get the encoded value. Umm... what? If you were doing NewEC -> SunEC manually (getEncoded() -> KeySpec) - you'll need to end up emitting a PKCS8 blob using RFC5915, which - unsurprisingly has BigEndian INTEGERs (yes, its an octet string, but the encoding is specified by RFC3447 as pretty much the big endian encoding of an integer). E.g. it may look opaque from Java's point of view, but it's not really opaque. (See below) Or have you got a different way of encoding the PKCS8 blob for the new provider? E.g. point me at a specification please. There is no issue with integers or endianness. The problem is specifically with BigInteger---it uses a variable-length representation, and it's spec does not give any guarantees about branching. The PKCS#8 encoding is fine because it is fixed length, so I can directly use the privateKey octet string (with bytes reversed, if necessary) in a branchless double-and-add loop. My head hurt when I tried to work through the various cases of translating a private key from your provider to SunEC or to BouncyCastle and vice versa. Basically, if you don't support the getS() call, then KeyFactory.translateKey() will fail. (Below from sun.security.ec.ECKeyFactory.java - the SunEC provider's implementation
Re: Code Review Request, JDK-8210334, TLS 1.3 server fails if ClientHello doesn't have pre_shared_key and psk_key_exchange_modes
Looks good. Brad On 9/5/2018 11:01 AM, Xuelei Fan wrote: Hi, Please review: http://cr.openjdk.java.net/~xuelei/8210334/webrev.00/ Simple update, no new regression test. Thanks, Xuelei
Re: Code Review Request, JDK-8210334, TLS 1.3 server fails if ClientHello doesn't have pre_shared_key and psk_key_exchange_modes
Looks fine > On Sep 5, 2018, at 11:01 AM, Xuelei Fan wrote: > > Hi, > > Please review: >http://cr.openjdk.java.net/~xuelei/8210334/webrev.00/ > > Simple update, no new regression test. > > Thanks, > Xuelei
Code Review Request, JDK-8210334, TLS 1.3 server fails if ClientHello doesn't have pre_shared_key and psk_key_exchange_modes
Hi, Please review: http://cr.openjdk.java.net/~xuelei/8210334/webrev.00/ Simple update, no new regression test. Thanks, Xuelei
Re: RFR 8171279: Support X25519 and X448 in TLS 1.3
On 9/5/2018 10:09 AM, Adam Petcher wrote: Updated webrev: http://cr.openjdk.java.net/~apetcher/8171279/webrev.01/ On 9/4/2018 3:25 PM, Xuelei Fan wrote: I have no finished the full code review. So far, I have a few question about the struct of the code. 1. XECParameters I can see the reason to dynamic parameters for something other than X25519/X448. But for JSSE, currently, only named curves are used. It would be nice to use the name for the static parameters. Sorry, I don't think I understand what you are suggesting here. As far as I know, nothing in sun.security.ssl uses XECParameters directly. Okay, it is used indirectly. It is used indirectly through ECUtil to encode and decode keys, and in this case the name is used to look up the parameters. Can the public NamedParameterSpec be used, instead of the private XECParameters? I think XECParameters may be better in the EC provider, please try to mitigate the dependence between modules. If one day the sun.security.util.XECParameters get updated, the EC implementation get impacted a lot. I prefer to use public APIs if possible. Is there some place in the code where JSSE is doing something too complicated related to these parameters? Yes, the algorithm name is sufficient, I'm not sure the necessary to use XECParameters in sun.security.util. 2. "TlsPremasterSecret" only XDH key agreement It would be nice the JCE implementation can support key agreement other than TLS protocols and providers other than SunJSSE provider. It would be nice if the JCE implementation does not bind to the SunJSSE provider private algorithm name. We used to use SunJSSE private name in the JCE crypto implementation. But there are some known problems with this dependence. Is there a problem to support generic key agreement? I simply continued the pattern that was used in DH and ECDH. We can use a different string here, but I worry that people will be surprised if DH and ECDH support "TlsPreMasterSecret" but XDH doesn't. It could support "TlsPreMasterSecret", right? My concern is about not limited to this one only. I would rather continue to use "TlsPreMasterSecret" for now, and then add support for a standard, TLS-independent name (that means the same thing) in a separate ticket. But if you feel strongly that XDH should not support "TlsPreMasterSecret", then perhaps we can use a different string now. In this case, let me know if you have any suggestions for what string to use. See above. 3. NamedGroupFunctions It might be more straightforward to define these functions in NamedGroup. If comparing nameGroup.getFunctions().getParameterSpec() and namedGroup.getParameterSpec(), I'd prefer the latter. A simple way to accomplish this is to leave the structure alone and add methods in NamedGroup that pass through to the corresponding methods in NamedGroupFunctions. I made this change in the updated webrev. Let me know what you think. It looks like a problem to me to use this before it constructed. this.functions = new ECDHFunctions(this); and the use of new object for each named group is not effective. The current NamedGroupFunctions abstract class does not sound good enough to me, considering the numbers of the named groups. I have no idea so far, but I think you can improve it. Probably use static methods? 4. SSLKeyAgreementCredentials I did not see too much benefit of this new interface. It is not always true that a key agreement could have a public key. Although we can simplify the key agreement for public key based, but it also add additional layers. I know where this improvement comes from. Maybe, you can consolidate the named group functions, and encode/decode the credentials there. This interface is only used to validate public keys against algorithm constraints. In the latest webrev, I moved all of this functionality into NamedGroupFunctions and removed the SSLKeyAgreementCredentials interface. Thanks, I like it the new design. Xuelei
Re: RFR 8171279: Support X25519 and X448 in TLS 1.3
Updated webrev: http://cr.openjdk.java.net/~apetcher/8171279/webrev.01/ On 9/4/2018 3:25 PM, Xuelei Fan wrote: I have no finished the full code review. So far, I have a few question about the struct of the code. 1. XECParameters I can see the reason to dynamic parameters for something other than X25519/X448. But for JSSE, currently, only named curves are used. It would be nice to use the name for the static parameters. Sorry, I don't think I understand what you are suggesting here. As far as I know, nothing in sun.security.ssl uses XECParameters directly. It is used indirectly through ECUtil to encode and decode keys, and in this case the name is used to look up the parameters. Is there some place in the code where JSSE is doing something too complicated related to these parameters? 2. "TlsPremasterSecret" only XDH key agreement It would be nice the JCE implementation can support key agreement other than TLS protocols and providers other than SunJSSE provider. It would be nice if the JCE implementation does not bind to the SunJSSE provider private algorithm name. We used to use SunJSSE private name in the JCE crypto implementation. But there are some known problems with this dependence. Is there a problem to support generic key agreement? I simply continued the pattern that was used in DH and ECDH. We can use a different string here, but I worry that people will be surprised if DH and ECDH support "TlsPreMasterSecret" but XDH doesn't. I would rather continue to use "TlsPreMasterSecret" for now, and then add support for a standard, TLS-independent name (that means the same thing) in a separate ticket. But if you feel strongly that XDH should not support "TlsPreMasterSecret", then perhaps we can use a different string now. In this case, let me know if you have any suggestions for what string to use. 3. NamedGroupFunctions It might be more straightforward to define these functions in NamedGroup. If comparing nameGroup.getFunctions().getParameterSpec() and namedGroup.getParameterSpec(), I'd prefer the latter. A simple way to accomplish this is to leave the structure alone and add methods in NamedGroup that pass through to the corresponding methods in NamedGroupFunctions. I made this change in the updated webrev. Let me know what you think. 4. SSLKeyAgreementCredentials I did not see too much benefit of this new interface. It is not always true that a key agreement could have a public key. Although we can simplify the key agreement for public key based, but it also add additional layers. I know where this improvement comes from. Maybe, you can consolidate the named group functions, and encode/decode the credentials there. This interface is only used to validate public keys against algorithm constraints. In the latest webrev, I moved all of this functionality into NamedGroupFunctions and removed the SSLKeyAgreementCredentials interface.
RE: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives
Hi Matthias, I have reviewed your change, +1 I also reviewed the CSR. Best regards Christoph > -Original Message- > From: Baesken, Matthias > Sent: Mittwoch, 5. September 2018 10:07 > To: security-dev@openjdk.java.net; Weijun Wang > ; core-libs-...@openjdk.java.net > Cc: Langer, Christoph > Subject: Re: [RFR] 8205525 : Improve exception messages during manifest > parsing of jar archives > > Hi Max, thanks for adding yourself as a reviewer. > > I set the CSR ( https://bugs.openjdk.java.net/browse/JDK-8207768 ) to > proposed. > > Best regards, Matthias > > > > > Message: 2 > > Date: Tue, 4 Sep 2018 21:31:58 +0800 > > From: Weijun Wang > > To: "Baesken, Matthias" > > Cc: "security-dev@openjdk.java.net" , > > "core-libs-...@openjdk.java.net" > d...@openjdk.java.net> > > Subject: Re: [RFR] 8205525 : Improve exception messages during > > manifest parsing of jar archives > > Message-ID: <058bd7b5-4d3a-4b56-acb0-0dedddea2...@oracle.com> > > Content-Type: text/plain; charset=us-ascii > > > > I've added myself as a reviewer. You might want to set scope to "JDK". > > > > A CSR is approved by the CSR group after you finalize it. First you should > > propose it. If you think it's urgent or trivial, you can also fast-track it. > > > > Read https://wiki.openjdk.java.net/display/csr/Main for more details. > > > > Thanks > > Max > > > > > On Sep 4, 2018, at 7:33 PM, Baesken, Matthias > > wrote: > > > > > >> The change looks fine. We can enhance the name if we want to support > > .SF > > >> parsing later. > > >> > > >> Please revise your CSR and get it approved first. > > > > > > Hi Max, Thanks ! > > > > > > I adjusted the CSR , please approve : > > > > > > https://bugs.openjdk.java.net/browse/JDK-8207768 > > > > > > Best regards, Matthias
Re: [RFR] 8205525 : Improve exception messages during manifest parsing of jar archives
Hi Max, thanks for adding yourself as a reviewer. I set the CSR ( https://bugs.openjdk.java.net/browse/JDK-8207768 ) to proposed. Best regards, Matthias > > Message: 2 > Date: Tue, 4 Sep 2018 21:31:58 +0800 > From: Weijun Wang > To: "Baesken, Matthias" > Cc: "security-dev@openjdk.java.net" , > "core-libs-...@openjdk.java.net" d...@openjdk.java.net> > Subject: Re: [RFR] 8205525 : Improve exception messages during > manifest parsing of jar archives > Message-ID: <058bd7b5-4d3a-4b56-acb0-0dedddea2...@oracle.com> > Content-Type: text/plain; charset=us-ascii > > I've added myself as a reviewer. You might want to set scope to "JDK". > > A CSR is approved by the CSR group after you finalize it. First you should > propose it. If you think it's urgent or trivial, you can also fast-track it. > > Read https://wiki.openjdk.java.net/display/csr/Main for more details. > > Thanks > Max > > > On Sep 4, 2018, at 7:33 PM, Baesken, Matthias > wrote: > > > >> The change looks fine. We can enhance the name if we want to support > .SF > >> parsing later. > >> > >> Please revise your CSR and get it approved first. > > > > Hi Max, Thanks ! > > > > I adjusted the CSR , please approve : > > > > https://bugs.openjdk.java.net/browse/JDK-8207768 > > > > Best regards, Matthias
