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

[Dave Cridland]

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



> 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 am *not* going  
to be happy with matching all certificates in the system to try and  
guess, obviously.

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