Is TLS1.3 support missing the "certificate_authorities" extension?

Xue-Lei Fan xuelei.fan at oracle.com
Tue Jan 15 15:53:28 UTC 2019


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_leonard at uk.ibm.com
> 
> 
> 
> 
> From: Sean Mullan <sean.mullan at oracle.com>
> To: Andrew Leonard <andrew_m_leonard at uk.ibm.com>, 
> security-dev at openjdk.java.net
> Cc: Ajay Reddy <areddy at us.ibm.com>, Alaine DeMyers <alaine at 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_leonard at 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


More information about the security-dev mailing list