From 1402ff98a6077cdf7eec96b9b07edec0048d9a51 Mon Sep 17 00:00:00 2001 From: Dirk Meyer Date: Thu, 12 Feb 2009 13:12:15 +0000 Subject: [PATCH] update XEP-0257 to version 0.3 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2729 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0257.xml | 46 +++++++++++++++++++++++++++++++++++++--------- 1 file changed, 37 insertions(+), 9 deletions(-) diff --git a/xep-0257.xml b/xep-0257.xml index 138b5d1f..c10b21ac 100644 --- a/xep-0257.xml +++ b/xep-0257.xml @@ -27,6 +27,17 @@ dmeyer@tzi.de dmeyer@jabber.org + + 0.3 + 2009-02-12 + dm + +

Add note about full JID in subjectAltName

+

Additional information about certificates signed by a CA

+

Make it possible to restrict access with no-cert-management

+

Example updates

+ + 0.2 2009-02-01 @@ -93,6 +104,23 @@ ]]>

The server either returns an empty result or an error. From now on the client can use that certificate to authenticate the user using SASL EXTERNAL.

The client adding the certificate does not need to be the client using it. A user may use a client to upload a certificate for a bot. The bot creates its certificate and private key, and the user uploads the certificate to the server (and may also sign the certificate outside the X.509 infrastructure to be used in &xep0189;). After that procedure the bot can log in to the XMPP network and even participate in secure end-to-end communication without ever knowing the user's password.

+

An optional element <no-cert-management/> inside the keyinfo element indicates that a client logged in with that certificate is not allowed to add or remove certificates from the list. A server MAY allow such a client to query the list of certificates.

+ + + Simple Bot + + 89d099a3428481cc63fe3fa44e7df2d002b4ce44 + + + ... + + + + + ]]>

A user may want to get a list of all certificates that can be used for SASL EXTERNAL. The client can query the list of the items by sending an items iq stanza.

@@ -100,7 +128,7 @@ - + ]]>

The server then returns the list of all known certificates including the user provided name.

@@ -132,9 +160,9 @@ ]]> -

A client has to create a new certification before its current one expires. After the new certificate is added to the server, it MAY want to disable the old certificate to keep the list of certificates short. Without that, the list will grow indefinitely, making the certificate handling for the user more difficult. Once a certificate is removed it can no longer be used for SASL EXTERNAL.

+

A client has to create a new certification before its current one expires. After the new certificate is added to the server, it MAY want to disable the old certificate to keep the list of certificates short. Without that, the list will grow indefinitely, making the certificate handling for the user more difficult. Once a certificate is removed it can no longer be used for SASL EXTERNAL. A server MAY automatically remove expired certificates for this list.

@@ -146,13 +174,11 @@

The user may want to revoke a certificate from a stolen or compromised device. The mechanism is similar to disabling a certificate. The difference is that if a client is logged in with that compromised certificate using SASL EXTERNAL, the server SHOULD close the stream to that client forcing a log out of the client.

- - - + ]]> @@ -160,15 +186,17 @@ -

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 15.2.1.2. and 15.2.1.3. in rfc3920bis: a JID MUST be represented as an XmppAddr, i.e., as a UTF8String within an otherName entity inside the subjectAltName.

+

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. In a company environment the server MAY only accept signed certificates; the behavior depends on the company's security policy. A free public XMPP server MUST allow self-signed certificates and certificates signed by a CA unknown to the server.

+

The client certificate SHOULD include a JID as defined in sections 15.2.1.2. and 15.2.1.3. in rfc3920bis: a JID MUST be represented as an XmppAddr, i.e., as a UTF8String within an otherName entity inside the subjectAltName.

+

If the subjectAltName contains a full JID the server MUST force the client to the given resource during resource binding. The client is only allowed to use the provided resource name. If a client with the same resource name is currently logged in and that client is not forced to that resource name, it SHOULD be logged out by the server.

 -

This specification allows the user to manipulate an alternative way to log into the server. The certificates are not signed and any certificate can be used. 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 to prevent a man-in-the-middle to modify the certificate.

+

This specification allows the user to manipulate an alternative way to log into the server. The certificates are not required to be signed and any certificate can be used. 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 to prevent a man-in-the-middle to modify the certificate.

&xep0077; 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.