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
