[xmppwg] Review of draft-meyer-xmpp-sasl-cert-management-01
ekr at rtfm.com
Mon Mar 23 06:52:45 CDT 2009
On Mon, Mar 23, 2009 at 4:46 AM, Dave Cridland <dave at cridland.net> wrote:
> On Sat Mar 21 14:22:34 2009, Eric Rescorla wrote:
>> There's a distinction between "remove from the list" and "terminate
>> any existing connections." I'm talking about the second. And given
>> that the user of the stolen mobile phone could potentially change
>> the certificate list, locking you out entirely, I'm not convinced this
>> is that important a feature, especially given the implementation
> UW-IMAP, like Cyrus IMAP, supports an IPC mechanism for things like IMAP
> IDLE. I don't think that a SHOULD here which enforces terminating sessions
> at this point should be a disasterously tricky thing to do with either
> implementation - I think I could do it in Cyrus, for instance, easily
> enough. For SMTP servers it'd be much harder, but SMTP is sufficiently
> short-lived that I'm not concerned.
> XMPP servers, which this addresses in particular, have very long-lived
> sessions, and invariably have very strong IPC - indeed, for most
> implementations there is a single central process per-host at least, and
> code exists for terminating streams on other hosts.
Well, obviously, it's a simple matter of programming, but there is
a fair amount of daylight between "disastrously tricky" and "fairly
> It's not that you're not right to raise this, and we should provide guidance
> on when this SHOULD is really a MUST, and when it can be treated as a MAY,
Strongly disagree with this. This feature is security relevant and
unattractive to think youll be able to revoke only to find out in the event
that it doesn't work. Either this feature should be removed or it needs to
be a MUST so that users can count on it.
> but I think you're making this more important than I feel it is.
I don't think it's important. That's why I would remove it. Maybe you meant
something different here.
> (FWIW, one assumes that a mobile phone client would lock-down its
> certificate on upload - which is an interesting thing to document in and of
> itself - meaning that stealing the device won't cause the master account to
> be locked out).
I don't assume that and the document doesn't say it.
More information about the xmppwg