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

Dirk Meyer dmeyer at tzi.de
Sat Mar 21 13:32:57 CDT 2009

Eric Rescorla wrote:
> On Sat, Mar 21, 2009 at 2:39 AM, Dirk Meyer <dmeyer at tzi.de> wrote:
>> Eric Rescorla wrote:
>>> S 5.
>>> There needs to be a requirement that this happen over TLS, no?
>> I don't understand. In 5.6 TLS is started. The stuff before happens over
>> the raw stream, everything from 5.8 is TLS secured. I don't know what
>> you want to add here.
> I'm talking about the certificate management operations *before*
> the client certificate has been uploaded.

Section 9.2:

   Therefore the server MUST reject any communication described in this
   document if the link between client and server is not secured with
   both STARTTLS and SASL.

>>> 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...
>> Request what you want,
> It's more complicated than that. SOMETHING needs to go in that
> field, and if you don't provide guidance, people will screw it up.

With "Request what you want" I wanted to say that I don't care which
one. But I agree, we should write that a client is allowed to get the
list or not. I only don't care which one we should use. Maybe someone
else has a reason for or against it.

> 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
> burden.

A stolen device can not lock me out because I still have the password as

Section 9.4:

   [XEP-0077] defines a mechanism to change the password without knowing
   the current one.  If the server supports password change it MUST
   return not-authorized for clients logged in using SASL EXTERNAL and
   MAY include a password change form requiring the old password.  If
   the client has logged in with the current password, the server MAY
   change the password without a form as specified in XEP-0077.

   If a client is allowed to change the password without knowing the
   current password, the additional security provided by this document
   is compromised.


Education is what you get from reading the small print; experience is
what you get from not reading it.

More information about the xmppwg mailing list