0.7

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

xep-0178.xml

@@ -6,8 +6,8 @@
 <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
 <xep>
 <header>
-  <title>Best Practices for Use of SASL EXTERNAL</title>
+  <title>Best Practices for Use of SASL EXTERNAL with Certificates</title>
-  <abstract>This document specifies best practices for use of the SASL EXTERNAL mechanism within XMPP.</abstract>
+  <abstract>This document specifies best practices for XMPP usage of the SASL EXTERNAL mechanism in the context of X.509 certificates.</abstract>
   &LEGALNOTICE;
   <number>0178</number>
   <status>Proposed</status>
@@ -22,6 +22,12 @@
   <shortname>N/A</shortname>
   &stpeter;
   &pgmillard;
+  <revision>
+    <version>0.7</version>
+    <date>2007-02-06</date>
+    <initials>psa</initials>
+    <remark><p>Clarified that the scope of this specification is limited to X.509 certificates.</p></remark>
+  </revision>
   <revision>
     <version>0.6</version>
     <date>2007-01-29</date>
@@ -78,12 +84,10 @@
   </revision>
 </header>
 <section1 topic='Introduction' anchor='intro'>
-  &RFC3920BISNOTE;
+  <p>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. This document specifies a recommended protocol flow for such use in the context of X.509 certificates, specifically when negotiation of TLS is required by a deployment. <note>The protocol flows when TLS is not required are more complicated (e.g., alternate flows involving server dialback) and may be described in a future version of this document.</note> <note>This specification focuses on the use of the SASL EXTERNAL mechanism with X.509 certificates. Future specifications may document best practices for use of SASL EXTERNAL outside the context of the X.509 infrastructure, for example via Internet Protocol Security (IPSec) as specified in &rfc4301;.</note></p>
-  <p><cite>RFC 3920</cite> allows the use of any SASL mechanism (see &rfc4422;) in XMPP authentication, including the SASL EXTERNAL mechanism. This document specifies a recommended protocol flow for such use, specifically when negotiation of TLS is required by a deployment. <note>The protocol flows when TLS is not required are more complicated (e.g., alternate flows involving server dialback) and may be described in a future version of this document.</note></p>
-  <p>Note: This specification focuses on the use of the SASL EXTERNAL mechanism with X.509 certificates. A future version of this specification may document best practices for use of SASL EXTERNAL outside the context of the X.509 infrastructure, for example via Internet Protocol Security (IPSec) as specified in &rfc4301;.</p>
 </section1>
 <section1 topic='Client-to-Server Recommendation' anchor='c2s'>
-  <p>As specified in <cite>RFC 3920</cite>, if a JabberID is included in an X.509 certificate, it MUST be encapsulated as an id-on-xmppAddr Object Identifier. Although it is not necessary for an X.509 certificate to include a JabberID, it is RECOMMENDED that client certificates include at least one id-on-xmppAddr OID encapsulating the JabberID of associated user (e.g., "juliet@example.org"), and OPTIONAL for client certificates to include either more than one id-on-xmppAddr or no id-on-xmppAddr. This specification includes recommendations that address all three cases.</p>
+  <p>As specified in <cite>RFC 3920</cite> and provisionally clarified in <cite>rfc3920bis</cite>, if a JabberID is included in an X.509 certificate, it MUST be encapsulated as an id-on-xmppAddr Object Identifier. Although it is not necessary for an X.509 certificate to include a JabberID, it is RECOMMENDED that client certificates include at least one id-on-xmppAddr OID encapsulating the JabberID of associated user (e.g., "juliet@example.org"), and OPTIONAL for client certificates to include either more than one id-on-xmppAddr or no id-on-xmppAddr. This specification includes recommendations that address all three cases.</p>
   <p>The RECOMMENDED protocol flow for client-to-server use of SASL EXTERNAL with end-user certificates is as follows:</p>
   <ol>
     <li>
@@ -222,7 +226,7 @@
   </ol>
 </section1>
 <section1 topic='Server-to-Server Recommendation' anchor='s2s'>
-  <p>As specified in <cite>RFC 3920</cite>, if a JabberID is included in an X.509 certificate, it MUST be encapsulated as an id-on-xmppAddr Object Identifier. Although it is not necessary for an X.509 certificate to include a JabberID, it is RECOMMENDED that server certificates include the id-on-xmppAddr OID encapsulating the JabberID of the bare XMPP server domain only (e.g., "example.org"). In addition, it is RECOMMENDED in the case of server certificates for the server's hostname to be encapsulated as a subjectAltName extension of type dNSName. Furthermore it is quite common for XMPP servers to also offer associated services as subdomains of the server; if a server offers such services then it is RECOMMENDED to either include an id-on-xmppAddr OID for each subdomain or to include a dnsName containing the wildcard character '*' applying to the left-most domain name component or component fragment (this is considered to match any single component or component fragment, e.g., *.example.org matches foo.example.org but not bar.foo.example.org, and im*.example.net matches im1.example.net and im2.example.net but not chat.example.net). This specification includes recommendations that address all three cases.</p>
+  <p>As specified in <cite>RFC 3920</cite> and provisionally clarified in <cite>rfc3920bis</cite>, if a JabberID is included in an X.509 certificate, it MUST be encapsulated as an id-on-xmppAddr Object Identifier. Although it is not necessary for an X.509 certificate to include a JabberID, it is RECOMMENDED that server certificates include the id-on-xmppAddr OID encapsulating the JabberID of the bare XMPP server domain only (e.g., "example.org"). In addition, it is RECOMMENDED in the case of server certificates for the server's hostname to be encapsulated as a subjectAltName extension of type dNSName. Furthermore it is quite common for XMPP servers to also offer associated services as subdomains of the server; if a server offers such services then it is RECOMMENDED to either include an id-on-xmppAddr OID for each subdomain or to include a dnsName containing the wildcard character '*' applying to the left-most domain name component or component fragment (this is considered to match any single component or component fragment, e.g., *.example.org matches foo.example.org but not bar.foo.example.org, and im*.example.net matches im1.example.net and im2.example.net but not chat.example.net). This specification includes recommendations that address all three cases.</p>
   <p>The RECOMMENDED protocol flow for server-to-server use of SASL EXTERNAL with server (domain) certificates is as follows:</p>
   <ol>
     <li>