[Standards] Proposed XMPP Extension: Client Certificate Management for SASL EXTERNAL
alexey.melnikov at isode.com
Wed Dec 3 23:18:19 UTC 2008
XMPP Extensions Editor wrote:
>The XMPP Extensions Editor has received a proposal for a new XEP.
>Title: Client Certificate Management for SASL EXTERNAL
>Abstract: This specification defines a method to manage client certificates that can be used with SASL External to allow clients to log in without a password.
>The XMPP Council will decide at its next meeting whether to accept this proposal as an official XEP.
This is quite sensible reminds me of an older IETF effort called SACRED
(see RFC 3767 and friends).
I've scanned the document and have some quick comments/questions:
> Example 4. Client revokes an X.509 Certificate
> from='hamlet at shakespeare.lit/denmark'
> <revoke xmlns='urn:xmpp:tmp:saslcert'/>
> <item id='428b1358a286430f628da23fb33ddaf6e474f5c5'>
Where is <compromised> defined?
> 3. SASL EXTERNAL
> The protocol flow is similar to the one described in XEP-0178. Only
> step 9 is different: the certificate does not need to be signed by a
> trusted entity if the certificate was uploaded by the user. The server
> still MUST reject the certificate if it is expired. The client
> certificate SHOULD include a JID as defined in sections 126.96.36.199. and
> 188.8.131.52. in rfc3920bis: a JID MUST be represented as an XmppAddr,
> i.e., as a UTF8String within an otherName entity inside the
I assume this proposal doesn't prevent use of properly certificates
signed by a CA, which were not uploaded?
> 4. Security Considerations
I think this XEP-to-be should REQUIRE at least use of TLS integrity
protection and/or SASL security layer with integrity protection.
Without that any man-in-the-middle that can inject data into a TCP
stream can upload arbitrary certificates (for which he/she has the
private key), so effectively giving himself/herself full access to the
More information about the Standards