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.
