Hi Andrew,
If one point have more than one certificates, and one of the cert cannot
be verified by the peer, there is an impact. Normally, I think the peer
is configured to be able to validate the certificate. RFC 8466 marked
this extension as a "MAY" level feature.
Did you know any requirement in practice for this extension? It could
be a priority of us if there is a serious impact.
Thanks,
Xuelei
On 1/15/2019 6:08 AM, Andrew Leonard wrote:
Thanks for the feedback Sean,
Do we have a view on the "priority" for such an enhancement? While we
don't support it, what won't work or is limited? Ajay?
Cheers
Andrew
Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com
From: Sean Mullan <sean.mul...@oracle.com>
To: Andrew Leonard <andrew_m_leon...@uk.ibm.com>,
security-dev@openjdk.java.net
Cc: Ajay Reddy <are...@us.ibm.com>, Alaine DeMyers <ala...@us.ibm.com>
Date: 15/01/2019 13:39
Subject: Re: Is TLS1.3 support missing the "certificate_authorities"
extension?
------------------------------------------------------------------------
Hello,
On 1/15/19 4:03 AM, Andrew Leonard wrote:
Re-posting this question..
Isn't the "certificate_authorities" extension mandatory for TLS1.3?
The text in question says "SHOULD" and not "MUST" [1]. So while it is
very desirable, I would not categorize this as a mandatory requirement.
_https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8206925-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=fXR6uf8ytLCOekA3CJ9goijSOsnkE1wrBf0wfoa_czY&e=
See
_https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtls-2Dtls13-2D20-23section-2D4.2.4-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=4Znnq5ZgqzAESypi4g2C1Xd-Yr1FxK4cTa4_0k3amHs&e=
There's a known typo in
_https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dtls-2Dtls13-2D20-23section-2D4.4.2.2-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=K7autmuNw1rTGW0J32W1bDIiQXN0s2OfUD5ueAK6z7o&e=
which from this comment:
_https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_tls_current_msg23612.html-5F&d=DwIC-g&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=oBlMiJsdliKXCh6xlsC6g8rXysVIW6yBnRhW7uyqc8U&s=eagruzUipLL49ZtMHhrbAg3RIRRB1Ucbpx-VNLD6qvU&e=
indicates section 4.4.2.2 was a typo and "certificate_authorities" should
be used instead of "trusted_ca_keys"
Note that your links above are referencing the Internet Draft. This has
been corrected in the RFC:
https://tools.ietf.org/html/rfc8446#section-4.4.2.2
Should JDK-8206925 be a "bug"? Thoughts?
It seems correct as an Enhancement.
--Sean
[1] https://tools.ietf.org/html/rfc2119
Many thanks
Andrew
Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: andrew_m_leon...@uk.ibm.com
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
