0.2 including XEP Editor fixes

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2730 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0257.xml

@@ -28,24 +28,19 @@
     <jid>dmeyer@jabber.org</jid>
   </author>
   <revision>
-    <version>0.3</version>
+    <version>0.2</version>
     <date>2009-02-12</date>
     <initials>dm</initials>
     <remark>
-      <p>Add note about full JID in subjectAltName</p>
+      <ul>
-      <p>Additional information about certificates signed by a CA</p>
+        <li>Added note about full JID in subjectAltName.</li>
-      <p>Make it possible to restrict access with no-cert-management</p>
+        <li>Added information about certificates signed by a CA.</li>
-      <p>Example updates</p>
+        <li>Made it possible to restrict access with no-cert-management.</li>
-    </remark>
+        <li>Updated the examples.</li>
-  </revision>
+        <li>Split revoke command into disable and revoke.</li>
-  <revision>
+        <li>Added more documentation including more detailed use cases.</li>
-    <version>0.2</version>
+        <li>Additional security considerations.</li>
-    <date>2009-02-01</date>
+      </ul>
-    <initials>dm</initials>
-    <remark>
-      <p>Split revoke command into disable and revoke</p>
-      <p>Add more documentation including more detailed use cases</p>
-      <p>Additional security considerations</p>
     </remark>
   </revision>
   <revision>
@@ -68,9 +63,9 @@
   </revision>
 </header>
 <section1 topic='Introduction' anchor='intro'>
-  <p>An XMPP client needs a user name and a password to log into an account. Many clients provide a mechanism to store these credentials to automatically log in into an account. While this practice is very user friendly, it is a security risk for some devices. Mobile devices like a phone or a laptop may get stolen, providing the thief with the required password. Mobile phones are particular insecure: providing the password on the keypad for each log in is too complicated and the risk of loosing the phone is high.</p>
+  <p>An XMPP client typically needs a user name and a password to log into an account. Many clients provide a mechanism to store these credentials to automatically log in into an account. While this practice is very user friendly, it is a security risk for some devices. Mobile devices like a phone or a laptop may get stolen, providing the thief with the required password. Mobile phones are particularly insecure: providing the password on the keypad for each log in is too complicated and the risk of losing the phone is high.</p>
   <p>A solution to this problem is to allow a client to log in without knowing the password. XMPP as specified in &rfc3920; and provisionally clarified in &rfc3920bis; allows the use of any SASL mechanism (see &rfc4422;) in the authentication of XMPP entities, including the SASL EXTERNAL mechanism. &xep0178; defines the usage of X.509 certificates used in the TLS handshake.</p>
-  <p>XEP-0178 assumes that the certificates used for SASL EXTERNAL are signed by a trusted CA. This could be a problem for the average user: signing a certificate is both an expensive and a complicated procedure. If the device gets stolen, the user also has to provide the required information to the CA to revoke the certificate, and the server needs to keep its list of revoked certificates up-to-date. The end-to-end security mechanism as described in &xep0250; rely on self-signed certificates. A client capable of secure end-to-end communicate already has a self-signed X.509 certificate for that purpose. The same client certificate should be used for a client to log in. Since the certificates are not signed by a trusted CA, the server must be aware of the list of certificates that are used by the users' clients. This document describes how to manage the list of client certificates.</p>
+  <p>XEP-0178 assumes that the certificates used for SASL EXTERNAL are signed by a trusted CA. This could be a problem for the average user: signing a certificate is both an expensive and a complicated procedure. If the device gets stolen, the user also needs to provide the required information to the CA to revoke the certificate, and the server needs to keep its list of revoked certificates up-to-date. The end-to-end security mechanism described in &xep0250; relies on self-signed certificates (although CA-issued certificates are allowed). A client capable of secure end-to-end communicate already has a self-signed X.509 certificate for that purpose. The same client certificate should be used for a client to log in. Since the certificates are not signed by a trusted CA, the server must be aware of the list of certificates that are used by the users' clients. This document describes how to manage the list of client certificates.</p>
 </section1>
 
 <section1 topic='Certificate Management' anchor='manage'>
@@ -81,7 +76,7 @@
 <iq type='set'
     from='hamlet@shakespeare.lit/denmark'
     id='append'>
-  <append xmlns='urn:xmpp:tmp:saslcert'>
+  <append xmlns='urn:xmpp:saslcert:0'>
     <name>Mobile Client</name>
     <keyinfo xmlns='urn:xmpp:tmp:pubkey'>
       <name>428b1358a286430f628da23fb33ddaf6e474f5c5</name>
@@ -109,11 +104,11 @@
 <iq type='set'
     from='hamlet@shakespeare.lit/denmark'
     id='nocert'>
-  <append xmlns='urn:xmpp:tmp:saslcert'>
+  <append xmlns='urn:xmpp:saslcert:0'>
     <name>Simple Bot</name>
     <keyinfo xmlns='urn:xmpp:tmp:pubkey'>
       <name>89d099a3428481cc63fe3fa44e7df2d002b4ce44</name>
-      <no-cert-management xmlns='urn:xmpp:tmp:saslcert'/>
+      <no-cert-management xmlns='urn:xmpp:saslcert:0'/>
       <x509cert>
           ...
       </x509cert>
@@ -128,7 +123,7 @@
 <iq type='get'
     from='hamlet@shakespeare.lit/denmark'
     id='query'>
-  <query xmlns='urn:xmpp:tmp:saslcert'/>
+  <items xmlns='urn:xmpp:saslcert:0'/>
 </iq>
   ]]></example>
   <p>The server then returns the list of all known certificates including the user provided name.</p>
@@ -136,7 +131,7 @@
 <iq type='result'
     to='hamlet@shakespeare.lit/denmark'
     id='query'>
-  <items xmlns='urn:xmpp:tmp:saslcert'>
+  <items xmlns='urn:xmpp:saslcert:0'>
     <item id='428b1358a286430f628da23fb33ddaf6e474f5c5'>
       <name>Mobile Client</name>
       <keyinfo xmlns='urn:xmpp:tmp:pubkey'>
@@ -165,7 +160,7 @@
 <iq type='set'
     from='hamlet@shakespeare.lit/denmark'
     id='disable'>
-  <disable xmlns='urn:xmpp:tmp:saslcert'/>
+  <disable xmlns='urn:xmpp:saslcert:0'/>
     <item id='428b1358a286430f628da23fb33ddaf6e474f5c5'/>
   </disable>
 </iq>
@@ -177,7 +172,7 @@
 <iq type='set'
     from='hamlet@shakespeare.lit/denmark'
     id='revoke'>
-  <revoke xmlns='urn:xmpp:tmp:saslcert'/>
+  <revoke xmlns='urn:xmpp:saslcert:0'/>
     <item id='428b1358a286430f628da23fb33ddaf6e474f5c5'/>
   </revoke>
 </iq>
@@ -191,7 +186,7 @@
   <example caption='subjectAltName using the "id-on-xmppAddr" format'><![CDATA[
     subjectAltName=otherName:id-on-xmppAddr;UTF8:hamlet@shakespeare.lit
     ]]></example>
-  <p>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.</p>
+  <p>If the subjectAltName contains a full JID the server MUST force the client to use 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 use that resource name, it SHOULD be logged out by the server.</p>
 </section1>
 
 <section1 topic='Security Considerations' anchor='security'>
@@ -243,8 +238,15 @@
 </section1>
 
 <section1 topic='XMPP Registrar Considerations' anchor='registrar'>
-  <section2 topic='Protocol Namespaces' anchor='ns'>
+  <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
-    <p>Until this specification advances to a status of Draft, its associated namespace shall be "urn:xmpp:tmp:saslcert"; upon advancement of this specification, the &REGISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
+    <p>This specification defines the following XML namespace:</p>
+    <ul>
+      <li>urn:xmpp:saslcert:0</li>
+    </ul>
+    <p>Upon advancement of this specification from a status of Experimental to a status of Draft, the &REGISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
+  </section2>
+  <section2 topic='Protocol Versioning' anchor='registrar-versioning'>
+    &NSVER;
   </section2>
 </section1>