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

Dirk Meyer dmeyer at tzi.de
Fri Dec 5 10:57:56 UTC 2008


Kurt Zeilenga wrote:
> On Dec 4, 2008, at 10:18 AM, Dirk Meyer wrote:
>
>> 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,
>
> I don't see why a user would not use a single certificate in multiple
> clients, especially for certificates issued by a non-user-operated CA.

The idea behind this proposal ist to make it possible to remove one
client from the system later. If all clients share the same certificate,
there isn't much difference to the password based login or the current
SASL EXTERNAL XEP. The whole idea is that each client has its own
certificate so every client uses something different to log in which can
be revoked on a per-client-bases.

> Deactivation, to me, means that it has been removed from a list of
> acceptable user certificates.  A deactivated certificate can certainly
> be used in the future.  For instance, by adding back to the list of
> acceptable user certificates.  Deactivation does not imply revocation.

I have to think about what I want here. I guess deactivation is easier
because it does not require a list of certificates that can not be added
again later. The revoke/deactivate has nothing to do with the mechanism
defined by X.509. There is no URL were you can check if a certificate is
valid or not. They may be self-signed and the list handled by my
proposal ist the list of certificates that are allowed to be used for
login.

> A user can request its CA revoke the certificate, but a user can
> deactivate the certificate (remove it from the list of acceptable
> certificates).

With self-signed certificates this is not possible.


Dirk

-- 
Freedom of speech is wonderful - right up there with the freedom not to
listen.



More information about the Standards mailing list