[Security] TLS Certificates Verification

Eric Rescorla ekr at rtfm.com
Tue Aug 19 16:42:55 CDT 2008

On Tue, Aug 19, 2008 at 2:38 PM, Jonathan Dickinson <jonathanD at k2.com> wrote:
>> -----Original Message-----
>> From: security-bounces at xmpp.org [mailto:security-bounces at xmpp.org] On
>> Behalf Of Dave Cridland
>> Sent: Tuesday, August 19, 2008 11:31 PM
>> To: XMPP Security
>> Subject: Re: [Security] TLS Certificates Verification
>> On Tue Aug 19 22:19:31 2008, Jonathan Schleifer wrote:
>> > "Eric Rescorla" <ekr at rtfm.com> wrote:
>> >
>> > There would be several changes needed as already stated on this
>> > list. And new XEPs would need to be created. XEPs for stuff for
>> > which
>> > already XEPs exist. If that's not reinventing, I don't know.
> One far-out and crazy problem that we probably need to keep in mind is that this stuff needs to be configurable, and the current XEPs don't really cut it.
> "Who cares if it's configurable?" I hear you say. Quantum computers are just around the corner, and we will be sitting here in a few years time coming up with new XEPs to deal with cryptography issues introduced by quantum computers. Rather save ourselves the work now and make sure we can negotiate other ways of encrypting data.
> Not only that, but what if someone figures out a blocker with the protocol we decide on? Firstly, if it happens before 3290bis is out we can easily change our direction with a new protocol (for example, SCRAM is found to be fatally flawed). It just keeps us fluid.

So, I would definitely hope that any new protocol we decided on would
have enough algorithm agility to
let us upgrade to newer algorithms--though as the experience with TLS
1.2 showed, this is often
easier said than done.

That said, if Quantum Computing suddenly allows us to factor 1024-bit
numbers in practical periods
of time, we've probably got a huge problem and it's not clear how to
salvage any of our


More information about the Security mailing list