[xmppwg] Review of draft-meyer-xmpp-sasl-cert-management-01

Kurt Zeilenga Kurt.Zeilenga at Isode.com
Fri Mar 20 16:34:40 CDT 2009

On Mar 20, 2009, at 1:42 PM, Dave Cridland wrote:

> On Fri Mar 20 17:18:38 2009, Eric Rescorla wrote:
>> This document describes a set of mechanisms for using certificate- 
>> based
>> TLS client authentication between XMPP clients and servers. In  
>> particular,
>> 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 http://tools.ietf.org/html/draft-zeilenga-xmpp-multi-passwd-00

Well, I might have alluded to "a more generic manner", and I certainly  
do think there is one to be had here.   The issue ought not be  
multiple passwords vs. multiple certificates, but just multiple  
>> S 3.
>> I think it's important to be clear on what role certificates are  
>> playing
>> 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 would oppose such use of the SASL authzid field, as authzid is for  
identity assumption, not specifying the whom is authenticating.

> I am *not* going to be happy with matching all certificates in the  
> system to try and guess, obviously.

In most certificate-based authentication systems I've dealt with, the  
subject name (and subject alternative names) has little to do identity  
that the server will in the end associate with the user.   Often the  
server will maintain a lookup table who key is issuer+serialNumber and  
whose value is the identity to be associated.

> S 4.
> 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.
> S 5.
> 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.
> Perhaps:
> "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.
> -- 
> Dave Cridland - mailto:dave at cridland.net - xmpp:dwd at dave.cridland.net
> - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
> - http://dave.cridland.net/
> Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

More information about the xmppwg mailing list