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

Kurt Zeilenga Kurt.Zeilenga at Isode.com
Thu Dec 4 18:40:56 UTC 2008

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.

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

Sorry, but your response here doesn't clarify to me what you mean by  

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

To me, 'revoke' means the the certificate has been revoked in the X. 
509 sense.  A certificate can be revoked for many different reasons,  
including a possible compromise.

> deactivate means it can not be used in the future.

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.

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

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

> and my maybe currently connected phone should disconnect at once.

Well, in the revocation case, the CA has to publish the revocation and  
the server has to learn of it.  Now, what would be nice is for the  
user to advise the server that certificate is not longer acceptable.
>> 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 think there are use cases where clients share user certificates  
(they might even share device certificates, depending on how the  
certificate are bound to the device).

>>> 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 :)
> Dirk
> -- 
> We live in a society where pizza gets to your house before the police.

More information about the Standards mailing list