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
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
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
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
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
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
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
>
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
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'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
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
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
> 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
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
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
@
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:
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
> 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/
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
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/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
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
;-) 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
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
26 matches
Mail list logo
