[Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
Kurt.Zeilenga at Isode.com
Fri Dec 5 15:37:12 UTC 2008
On Dec 5, 2008, at 2:57 AM, Dirk Meyer wrote:
> 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
>>>>> 1. A certificate is about to expire. The client uploads a new one
>>>>> revokes the old. The client should stay connected.
>>>> More interestingly, is what about other sesssions using the old
>>> 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
> The idea behind this proposal ist to make it possible to remove one
> client from the system later.
I know little of what's behind the proposal, I'm just reading the
The proposal talks about:
This specification defines a method to manage client certificates
that can be used with SASL External to allow clients to log in without
It's a very general certificate management protocol.
If there are some hidden assumptions/use cases, I think they should be
more clearly called out and discussed in the proposal.
> If all clients share the same certificate,
> there isn't much difference to the password based login or the current
> SASL EXTERNAL XEP.
Right, this is no better than sharing a password amongst multiple
> The whole idea is that each client has its own
> certificate so every client uses something different to log in which
> be revoked on a per-client-bases.
Some XMPP server implementations already support multiple passwords
per user. Of course, the server has no clue how such passwords are
shared amongst a user's clients, likewise for user certificates.
I think this proposal needs to be written from a perspective that
users will share certificates, to some degree, between their clients.
What this proposal offers is a mechanism to manage multiple user
certificates, such that if one (or more) is comprised, that
certificate can be deactivated and hence disallowing continued use of
those clients that rely on that particular certificate. While a user
may choose to have per-client certificates, and thereby having per-
client deactivation control, a user may choose to share client
>> Deactivation, to me, means that it has been removed from a list of
>> acceptable user certificates. A deactivated certificate can
>> be used in the future. For instance, by adding back to the list of
>> acceptable user certificates. Deactivation does not imply
> 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
> again later. The revoke/deactivate has nothing to do with the
> defined by X.509.
Then don't use the term "revoke" as this term has quite a different
meaning than disable or deactivate.
> There is no URL were you can check if a certificate is
> valid or not.
Information about how to check for revocation may be in the
certificate itself, the CA certificate (if known), or otherwise
known. (but see my comment below about avoiding discussion of
revocation in this proposal).
> They may be self-signed and the list handled by my
> proposal ist the list of certificates that are allowed to be used for
>> A user can request its CA revoke the certificate, but a user can
>> deactivate the certificate (remove it from the list of acceptable
> With self-signed certificates this is not possible.
Yes, but your proposal covers cases where it is possible.
I think what your proposal needs to focus on activation/deactivation
of user certificates, leaving revocation handling to other documents
(but noting that leave revocation handling to other documents).
> Freedom of speech is wonderful - right up there with the freedom not
More information about the Standards