Re: [TLS] How should inability to access key revocation lists impact the TLS handshake?
"certificate_unknown" seems like it should be fine for this On Mon, Oct 24, 2016 at 12:12 PM, Xiaoyin Liu <xiaoyi...@outlook.com> wrote: > But I think the problem is that there is no TLS alert for “revocation > status inaccessible”. > > > > Best, > > Xiaoyin > > *From: *Salz, Rich <rs...@akamai.com> > *Sent: *Monday, October 24, 2016 2:15 PM > *To: *Ryan Carboni <rya...@gmail.com>; tls@ietf.org > *Subject: *Re: [TLS] How should inability to access key revocation lists > impact the TLS handshake? > > > > How should inability to access key revocation lists impact the TLS > handshake, if previous public keys and/or certificate hashes are not cached? > > Nobody does revocation on the web, for some almost all encompassing > definition of nobody. > > Instead, OCSP and OCSP stapling. > > > I cannot see this in the standard. Considering that all one has to do is > DDOS a certificate authority nowadays... > > General PKI and key lifecycle issues are, properly, not part of the TLS > spec. > > /r$ > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] How should inability to access key revocation lists impact the TLS handshake?
But I think the problem is that there is no TLS alert for “revocation status inaccessible”. Best, Xiaoyin From: Salz, Rich<mailto:rs...@akamai.com> Sent: Monday, October 24, 2016 2:15 PM To: Ryan Carboni<mailto:rya...@gmail.com>; tls@ietf.org<mailto:tls@ietf.org> Subject: Re: [TLS] How should inability to access key revocation lists impact the TLS handshake? > How should inability to access key revocation lists impact the TLS handshake, > if previous public keys and/or certificate hashes are not cached? Nobody does revocation on the web, for some almost all encompassing definition of nobody. Instead, OCSP and OCSP stapling. > I cannot see this in the standard. Considering that all one has to do is DDOS > a certificate authority nowadays... General PKI and key lifecycle issues are, properly, not part of the TLS spec. /r$ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] How should inability to access key revocation lists impact the TLS handshake?
How should inability to access key revocation lists impact the TLS handshake, if previous public keys and/or certificate hashes are not cached? I cannot see this in the standard. Considering that all one has to do is DDOS a certificate authority nowadays... ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
