[Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL

Dirk Meyer dmeyer at tzi.de
Thu Dec 4 18:18:40 UTC 2008

Kurt Zeilenga wrote:
> On Dec 4, 2008, at 2:04 AM, Dirk Meyer wrote:
>> It is part of urn:xmpp:tmp:saslcert (or will be once I write the
>> schema). The problem is that there are two reason to revoke a
>> certificate:
>> 1. A certificate is about to expire. The client uploads a new one and
>>   revokes the old. The client should stay connected.
> More interestingly, is what about other sesssions using the old
> certificate.

There is only one. Each client has its own certificate, otherwise it is
not possible to remove one bad client from the network without affecting
others. The same certificate can also be used for XEP-0250.

>> 2. A device should be removed (e.g. stolen). In that case the
>>   certificate is compromised and if the device is logged in right now,
>>   it should be disconnected by the server.
> First, it's not clear to me what you mean be 'revoke' a certificate.
> In particular, whether you mean to 'revoke' in the X.509 sense of the
> word, or whether you simply mean to no longer consider a certificate
> as suitable for gaining access (that is, removing it from a list of
> acceptable user certificates, or deactivated).   Second, I'm not sure
> it matters all that much.

Yes, I mean revoke it exactly that way. It will not be possible to log
in with that certificate anymore.

> Anyways, there are many reasons why a certificate could be 'revoked'
> or 'deactivated'.

Agreed. Maybe revoke and deactivate mean something different: revoke
means it is a compromised certificate, deactivate means it can not be
used in the future.

> While some might argue that existing sessions should not be impacted
> by either a 'revocation' or 'deactiviation', some might also argue
> that all sessions (including those used to 'revocate' or 'deactivate')
> should be immediately disconnected or at least quarantined in some
> manner (for instance, all subsequent messages generate 'please
> reconnect' errors).  And there is some who are somewhere in the
> middle.
> Now back to your cases...
> If a user 'revokes' or 'deactivates' a clearance, he might be doing so
> as he thinks it is compromised, regardless of the proximity to the
> expiration time of the old certificate.

Right. My mobile phone gets stolen or I simply loose it, I revoke the
certificate and my maybe currently connected phone should disconnect at

> If an implementation is going to disconnect (or fail requests)
> existing session on revocation and/or deactivation, I would argue this
> should occur either on all sessions, or to all but the session which
> issued the revocation/deactivation order.  And for this session, it
> should discontinued (or fail requests) very soon after the order.

That problem should not exist if each client has its own certificate. In
that case there is only one session.

>> I will write some more doc about this.
> Looking forward to this...

And I will add some text about each client having its own certificate :)


We live in a society where pizza gets to your house before the police.

More information about the Standards mailing list