[xmppwg] Review of draft-meyer-xmpp-sasl-cert-management-01
dave at cridland.net
Fri Mar 20 15:42:24 CDT 2009
On Fri Mar 20 17:18:38 2009, Eric Rescorla wrote:
> This document describes a set of mechanisms for using
> TLS client authentication between XMPP clients and servers. In
> it allows a user who has already authenticated to add, remove, etc.
> new certificates to be used for future authentications. Generally,
> this seems like a sound idea--indeed one that is so useful it might
> be nice to put it in SASL or something so it could be reused by
> other protocols. Comments below.
I'd note that Kurt Zeilenga has posted a draft outlining an alternate
method for subordinate credentials in a more generic manner, which
might be more generically applicable, see
> S 3.
> I think it's important to be clear on what role certificates are
> here. As far as I can tell, they're basically being used as a key
> carrier, because that's what TLS requires. Accordingly, the rest
> of the contents of the cert aren't really that important, just
> the public key. In fact, a digest of the cert/public key would
> be enough. Is there some other concept in play? If not, I would
> remove all these requirements about what's in the subject alt name.
I see no reason not to upload the certificate entire, and I do see
reasons to actually have a certificate with useful Stuff in.
Uploading the certificate means that a simple equality check can be
made, rather than relying on a hash (and, therefore, having to decide
on a hash, and hash agility, and all that stuff).
> S 5.
> There needs to be a requirement that this happen over TLS, no?
> You probably need to specify what goes in the CertificateRequest,
> since that's intended to include CAs but there won't be any
> here. Probably empty...
> Again, I think it's a mistake to look in the certificate for the
> user name. that should just be associated with the account.
I can live without the XmppAddr subject alt name, as long as clients
always specify it as the authzid in SASL EXTERNAL. I am *not* going
to be happy with matching all certificates in the system to try and
Server should be responding with type='result' or type='error' surely?
Either make <no-cert-management/> mean the client can read the cert
list, or make it so it can't. Optional behaviour will end up as a
de-facto MUST, or else a buggy user experience.
I don't see that a client SHOULD NOT send authzid in step 11, but
it's nice to ensure that servers will understand it. I suspect that
rephrasing it as "clients MAY, and servers MUST understand" is better.
> S 6.
> <Why specify SHA-1 as the only digest?
I don't think the document specifies that, it merely specifies a
unique identifier. I agree it's confusing to mention the
implementation of an example, though.
"uniquely identified by the value of the 'id' attribute, for example
by usingthe textual form of a hash or fingerprint of the certificate
as the id."
> S 7.
> Again, why does expiration matter here?
Users might want to control the lifetime of the access, so having
expiry seems reasonable.
Users who don't want this could set the expiry to be very far in the
future, or possibly omit it entirely.
> S 8.
> This may be quite hard to implement if, for instance, servers
> fork for each client.
This is a highly unlikely architecture for an XMPP server, and pretty
unlikely in this day and age for any server.
However, it's also a SHOULD, and "my architecture prevents this" is a
reasonable reason for not following this.
Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
More information about the xmppwg