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

Kurt Zeilenga 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
>>>>> 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.

I know little of what's behind the proposal, I'm just reading the  
proposal.

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  
a password.

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  
clients.

> 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.

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  
certificates.

>> 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.

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
> 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.

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).

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




More information about the Standards mailing list