This was received via the Java SE 10 umbrella JSR comments list; since
it relates to JEP 116, I am forwarding it here.
-------- Forwarded Message --------
Subject: [JCP]JSR-383(Java SE 18.3) Public review - JEP 116:Extended
Validation SSL Certificates
Date: Fri, 17 Nov 2017 10:33:41 +0000
From: kyosuke_yamag...@mufg.jp
To: java-se-spec-comme...@openjdk.java.net
CC: youji_3_fujik...@mufg.jp, takahiro_ishif...@mufg.jp,
kazuhiro_2_itak...@mufg.jp, tomoyuki_3_igu...@mufg.jp,
kenya_2_sa...@mufg.jp, hiromi_18_takaha...@mufg.jp
JSR-383 developer all
Hi, I’m Kyosuke Yamagata.
I can't send E-mail by mail form(Expert Group Comments) because of the office
network policy.
So I send this mail to you.
I work for Mitsubishi UFJ Information Technology.
Our company is in charge of Mitsubishi UFJ financial group system development,
operation and maintenance.
And then , We are in charge of in-house Java framework.
Our Java framework depends heavily on Java SE and Java EE technologies.
I reviewed JEP 116: Extended Validation SSL Certificates in JSR-383(Java SE
18.3) Public review
I think it's great.
On the other hand, to make things even better, I would like to suggest the
following:
We can import Self-signed certificates as Root certificate.
It used in SSL/TLS connections both Client-side and Server-side, and isn't
necessarily EV SSL certificates.
When the API takes these Non-EV SSL certificates, what kind of information does
return?
API user wants to take some information of the certificate without having to
worry about what kind of certificate using, I think.
For example, if I got some exceptions by using API, I MUST inject the judging
code that this certificate is EV or Non-EV into my code.
I want to support this usecase by this JEP(or other APIs).
This content is the personal opinion by the contributor, not the official
opinion of our company.
Best regards.
