Hi Xuelei, thanks for the feedback. A couple comments in-line below.
On 6/5/2019 5:37 PM, Xuelei Fan wrote:
On 6/5/2019 4:57 PM, Jamil Nimeh wrote:
I think what it's saying is that what was explicitly called out in
4507 (where there is both the extension_data length bytes AND the
opaque vec
;-) I want to try again by putting all things together.
Per RFC 5077 (page 18, appendix A):
"Note that the encoding of an empty SessionTicket extension was
ambiguous in RFC 4507. An RFC 4507 implementation may have encoded
it as:
00 23 Extension type 35
00 02 L
On 6/5/2019 8:25 PM, Anthony Scarpino wrote:
On 6/5/19 7:30 PM, Xuelei Fan wrote:
On 6/5/2019 7:21 PM, Anthony Scarpino wrote:
On Jun 5, 2019, at 5:37 PM, Xuelei Fan wrote:
On 6/5/2019 4:57 PM, Jamil Nimeh wrote:
I think what it's saying is that what was explicitly called out in
4507 (whe
On 6/5/19 7:30 PM, Xuelei Fan wrote:
On 6/5/2019 7:21 PM, Anthony Scarpino wrote:
On Jun 5, 2019, at 5:37 PM, Xuelei Fan wrote:
On 6/5/2019 4:57 PM, Jamil Nimeh wrote:
I think what it's saying is that what was explicitly called out in
4507 (where there is both the extension_data length byt
Hi Jamil,
Thanks much for reviewing this~
On 6/5/2019 9:21 AM, Jamil Nimeh wrote:
Hi Valerie, on the whole it looks really good. I do have some
comments below:
* SunPKCS11.java
o 728-738: I think you could add 2.16.840.1.101.3.4.3.3 and .4
for dsa-with-sha384 and dsa-with-sha
On 6/5/2019 7:21 PM, Anthony Scarpino wrote:
On Jun 5, 2019, at 5:37 PM, Xuelei Fan wrote:
On 6/5/2019 4:57 PM, Jamil Nimeh wrote:
I think what it's saying is that what was explicitly called out in 4507 (where
there is both the extension_data length bytes AND the opaque vector length) is
n
> On Jun 5, 2019, at 5:37 PM, Xuelei Fan wrote:
>
>
>
>> On 6/5/2019 4:57 PM, Jamil Nimeh wrote:
>> I think what it's saying is that what was explicitly called out in 4507
>> (where there is both the extension_data length bytes AND the opaque vector
>> length) is not how deployed implement
It looks fine to me.
Xuelei
On 6/5/2019 7:19 PM, Weijun Wang wrote:
Please review the patch below. Bug is
https://bugs.openjdk.java.net/browse/JDK-8225304.
Thanks,
Max
*diff --git
a/src/java.security.jgss/share/classes/org/ietf/jgss/package-info.java
b/src/java.security.jgss/share/classes/
Please review the patch below. Bug is
https://bugs.openjdk.java.net/browse/JDK-8225304.
Thanks,
Max
diff --git
a/src/java.security.jgss/share/classes/org/ietf/jgss/package-info.java
b/src/java.security.jgss/share/classes/org/ietf/jgss/package-info.java
--- a/src/java.security.jgss/share/classe
It looks good to me.
Xuelei
On 6/5/2019 7:01 PM, [email protected] wrote:
Hi,
Test sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java should be in
ProblemList until JDK-8161536 is resolved.
diff -r 184b05daf50f test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt Wed Jun 05 21:50:
Hi,
Test sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java should be in
ProblemList until JDK-8161536 is resolved.
diff -r 184b05daf50f test/jdk/ProblemList.txt
--- a/test/jdk/ProblemList.txt Wed Jun 05 21:50:29 2019 -0400
+++ b/test/jdk/ProblemList.txt Thu Jun 06 09:58:13 2019 +0800
@
Hi Martin,
The new test in the changeset uses a simple homemade KDC and we might want to
develop some internal tests that access real KDCs. For the server referral
part, I think we can clone some existing cross-realm authentication test and
remove the [domain_realm] part in the client's krb5.co
> On Jun 6, 2019, at 3:22 AM, Martin Balao wrote:
>
> If there are no further comments and jdk-submit tests succeed, I'll push
> tomorrow (2019-06-06) at around 11 am EST.
None from me.
Such a new feature would need a release note. I've created a skeleton at
https://bugs.openjdk.java.net/br
On 6/5/2019 4:57 PM, Jamil Nimeh wrote:
I think what it's saying is that what was explicitly called out in 4507
(where there is both the extension_data length bytes AND the opaque
vector length) is not how deployed implementations did it. It implies
that deployed implementations do what you
I think what it's saying is that what was explicitly called out in 4507
(where there is both the extension_data length bytes AND the opaque
vector length) is not how deployed implementations did it. It implies
that deployed implementations do what you laid out below where you just
have 2 bytes
I'm not sure I understand the following words in page 17, RFC 5077.
" An error in the encoding caused the specification to differ from
deployed implementations. At the time of this writing there are no
known implementations that follow the encoding specified in RFC 4507.
"
Is it means th
On 6/5/2019 3:37 PM, Jamil Nimeh wrote:
I think we're overstating the "otherwise" case. A client that uses this
strict 4507 format would initially send a ticket that looks like { 00 23
00 02 00 00 } to which our server would reject this extension (since the
final 00 00 would be interpreted as
I think we're overstating the "otherwise" case. A client that uses this
strict 4507 format would initially send a ticket that looks like { 00 23
00 02 00 00 } to which our server would reject this extension (since the
final 00 00 would be interpreted as a ticket when the client did not
intend
I don’t know if there are any deployment of RFC 4507. If not, we are safe;
otherwise there are interop problems for session resumption.
Xuelei
> On Jun 5, 2019, at 2:19 PM, Jamil Nimeh wrote:
>
> Hi Xuelei,
>
> Given that 4507 is obsoleted in favor of 5077 is there really that much value
>
Hi Xuelei,
Given that 4507 is obsoleted in favor of 5077 is there really that much
value to supporting this older/broken extension format? Do we know of
clients that still adhere to 4507? Otherwise it seems better to stick
to 5077 and the approach in TLS 1.3 and not try to go back and suppor
On 6/5/2019 12:41 PM, Anthony Scarpino wrote:
http://cr.openjdk.java.net/~ascarpino/stateless/webrev.02
SessionTicketExtension.java:
117 byte[] k = new byte[KEYLEN];
118 random.nextBytes(k);
119 key = new SecretKeySpec
On 6/4/19 9:02 PM, Xuelei Fan wrote:
Hi Tony,
There are a lot of pretty good designs in the update, for example, the
cooperation of the session timeout and key rotation timeout.
My following comments are mainly about the issues I can find. Most of
them are minors.
On 6/3/2019 5:42 PM, Ant
Hi Max,
Thanks for your feedback.
On 6/4/19 12:28 AM, Weijun Wang wrote:
> - java.security typos:
>
>492,497: ovewritten
>496: infite
>
Fixed.
> - CredentialsUtils.java:
>
>36: unused import
>
Fixed.
> - KDCRep.java:
>
>no need to move the position
>
Fixed.
> - Referra
Continue for the SessionTicketExtension.java.
On 6/3/2019 5:42 PM, Anthony Scarpino wrote:
http://cr.openjdk.java.net/~ascarpino/stateless/webrev.02
SessionTicketExtension.java (continue):
---
231 SessionStateSpec(ByteBuffer buf) throws IOException
Folks,
I am trying to perform TLS auth with a PKCS12 and Windows-MY keystores
with HttpClient 4.5.6 + Java 8, Update 212 in Windows 7.
While with the .p12 (contains one key and its cert) file everything goes
smoothly and fast, I am having trouble with Windows-MY with my smartcard.
Loading the st
Hi Valerie, on the whole it looks really good. I do have some comments
below:
* SunPKCS11.java
o 728-738: I think you could add 2.16.840.1.101.3.4.3.3 and .4 for
dsa-with-sha384 and dsa-with-sha512, respectively.
o 790-792: Are you sure that's the right OID? OID lookup shows
26 matches
Mail list logo
