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

Kurt Zeilenga Kurt.Zeilenga at Isode.com
Thu Dec 4 15:52:28 UTC 2008


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

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

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.

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.

>
>
> I will write some more doc about this.


Looking forward to this...  - Kurt



More information about the Standards mailing list