mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 00:35:02 -05:00
Update references to new XEPs and RFCs
This commit is contained in:
Evgeny Khramtsov
parent
6c624a2937
commit
f45b32f7f0
@ -43,7 +43,7 @@
|
||||
</revision>
|
||||
</header>
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>REsource LOcation And Discovery (RELOAD) (RFC6940) specifies a peer-to-peer (P2P) signaling protocol for general use on the Internet. This document defines an XMPP Usage of RELOAD that allows XMPP clients to establish peer-to-peer XMPP streams without routing them through XMPP servers.</p>
|
||||
<p>REsource LOcation And Discovery (RELOAD) (&rfc6940;) specifies a peer-to-peer (P2P) signaling protocol for general use on the Internet. This document defines an XMPP Usage of RELOAD that allows XMPP clients to establish peer-to-peer XMPP streams without routing them through XMPP servers.</p>
|
||||
<p>The XMPP Usage involves two basic functions:</p>
|
||||
<ol>
|
||||
<li><strong>Address Location</strong>: XMPP clients can use the RELOAD data storage functionality to store a mapping from their XMPP address to their Node-ID in the overlay and to retrieve the Node-ID of other clients.</li>
|
||||
@ -82,13 +82,13 @@
|
||||
</section1>
|
||||
<section1 topic='Glossary' anchor='glossary'>
|
||||
<dl>
|
||||
<di><dt>RELOAD</dt><dd>REsource LOcation And Discovery (RFC6940) - a P2P signaling protocol for general use on the Internet. The terminology and definitions from this protocol are used extensively in this document.</dd></di>
|
||||
<di><dt>RELOAD</dt><dd>REsource LOcation And Discovery (&rfc6940;) - a P2P signaling protocol for general use on the Internet. The terminology and definitions from this protocol are used extensively in this document.</dd></di>
|
||||
<di><dt>Address Location</dt><dd>One or many RELOAD Node-IDs to which a peer-to-peer connection can be established in order to contact an owner of the XMPP address.</dd></di>
|
||||
</dl>
|
||||
</section1>
|
||||
<section1 topic='Storing an Address Location' anchor='addr-loc'>
|
||||
<section2 topic='Overview' anchor='addr-loc-overview'>
|
||||
<p>In XMPP Core &rfc6120;, a client fully relies on servers for its XMPP address location. In XMPP Usage of RELOAD, this location function is provided by the overlay as a whole. To register its location, a RELOAD peer stores an XmppLocation Resource Record for its own XMPP address using the XMPP-LOCATION Kind, which is formally defined below. Note that if a client wishes to set the location lifetime it MUST use lifetime of the basic RELOAD StoredData structure (see Section 7 of RFC6940).</p>
|
||||
<p>In XMPP Core &rfc6120;, a client fully relies on servers for its XMPP address location. In XMPP Usage of RELOAD, this location function is provided by the overlay as a whole. To register its location, a RELOAD peer stores an XmppLocation Resource Record for its own XMPP address using the XMPP-LOCATION Kind, which is formally defined below. Note that if a client wishes to set the location lifetime it MUST use lifetime of the basic RELOAD StoredData structure (see Section 7 of &rfc6940;).</p>
|
||||
<p>As a simple example, consider Juliet with an XMPP address "juliet@capulet.lit" at Node-ID "1234". She might store the mapping "juliet@capulet.lit -> 1234" telling anyone who wants to contact her to establish a direct XMPP stream with node "1234".</p>
|
||||
<p>RELOAD peers can store two kinds of XMPP mappings,</p>
|
||||
<ul>
|
||||
@ -236,7 +236,7 @@
|
||||
<tr>
|
||||
<td>XMPP-LOCATION</td>
|
||||
<td>0x5</td>
|
||||
<td>XEP-XOR</td>
|
||||
<td>XEP-0415</td>
|
||||
</tr>
|
||||
</table>
|
||||
</section2>
|
||||
|
||||
14
xep-0416.xml
14
xep-0416.xml
@ -46,7 +46,7 @@
|
||||
<dl>
|
||||
<di><dt>E2E encryption</dt><dd>For end-to-end encryption, XMPP clients may use certificates to mutually identify each other, i.e. check that the cryptographic key belongs to this exact XMPP address.</dd></di>
|
||||
<di><dt>External services</dt><dd>An XMPP server may authenticate users of other servers at its local services, such as an HTTP Upload component (&xep0363;), e.g. for granting file uploads, or a TURN server (&rfc5766;).</dd></di>
|
||||
<di><dt>XMPP Usage of RELOAD</dt><dd>XMPP entities attached to the XOR overlay (XEP-XOR) are supposed to use certificates for mutual authentication.</dd></di>
|
||||
<di><dt>XMPP Usage of RELOAD</dt><dd>XMPP entities attached to the XOR overlay (XEP-0415) are supposed to use certificates for mutual authentication.</dd></di>
|
||||
<di><dt>SPAM protection</dt><dd>Since certificate authorities are required to be Sybil resistant (XEP-EAX-CAR), a spammer is limited in ability to create accounts massively. Thus it is expected that SPAM dissemination will fall to negligible levels.</dd></di>
|
||||
<di><dt>Registration delegation</dt><dd>XMPP accounts registration typically creates a huge burden for operators of public servers. An operator may want to delegate a registration of accounts of its own server to a trusted CA. The CA will validate the users' identities and will issue certificates for them. The users can use these certificates in c2s SASL EXTERNAL authentication at the operator's server as well as for e2e authentication with other entities.</dd></di>
|
||||
</dl>
|
||||
@ -84,7 +84,7 @@
|
||||
<section2 topic='General Requirements' anchor='gen-req'>
|
||||
<ol>
|
||||
<li>The leaf certificate MUST be compliant with c2s SASL EXTERNAL authentication (&rfc6120;, &xep0178;).</li>
|
||||
<li>The leaf certificate MUST be compliant with RELOAD authentication (RFC6940).</li>
|
||||
<li>The leaf certificate MUST be compliant with RELOAD authentication (&rfc6940;).</li>
|
||||
</ol>
|
||||
</section2>
|
||||
<section2 topic='Certificate Requirements' anchor='cert-req'>
|
||||
@ -100,11 +100,11 @@
|
||||
<li>The certificate MUST NOT contain a basicConstraints extension with the cA boolean set to TRUE.</li>
|
||||
<li>The certificate MUST include a CRL Distribution Points extension that specifies an URI of a Certificate Revocation List.</li>
|
||||
<li>The certificate MUST possess a single XMPP address represented as an XmppAddr as specified under Section 13.7.1.4 of &rfc6120;.</li>
|
||||
<li>The SubjectAltName field in the certificate MUST contain a single RELOAD URI as specified under Section 14.15 of RFC6940 encoded as uniformResourceIdentifier type. The "destination" part of the URI MUST be a RELOAD Node-ID. The Node-ID MAY be hexadecimal-encoded. The "overlay" part of the URI MUST be "xmpp.org". The "specifier" part of the URI MUST be empty.</li>
|
||||
<li>The SubjectAltName field in the certificate MUST contain a single RELOAD URI as specified under Section 14.15 of &rfc6940; encoded as uniformResourceIdentifier type. The "destination" part of the URI MUST be a RELOAD Node-ID. The Node-ID MAY be hexadecimal-encoded. The "overlay" part of the URI MUST be "xmpp.org". The "specifier" part of the URI MUST be empty.</li>
|
||||
<li>If the XMPP address doesn't contain non-ASCII characters, it MUST be encoded in the SubjectAltName field as rfc822Name type.</li>
|
||||
</ol>
|
||||
<p>Note that the rules for leaf certificates comply with the rules defined for client certificates under Sections 13.7.1.1 and 13.7.1.4 of &rfc6120;. Thus they can be used for c2s SASL EXTERNAL authentication.</p>
|
||||
<p>The requirement to possess a RELOAD URI and an rfc822Name address makes it possible to use the certificate for RELOAD authentication. Even if XOR extension (XEP-XOR) is unused, the RELOAD URI uniquely identifies a user device: a user MAY have several certificates assigned to their XMPP address but with different RELOAD URIs.</p>
|
||||
<p>The requirement to possess a RELOAD URI and an rfc822Name address makes it possible to use the certificate for RELOAD authentication. Even if XOR extension (XEP-0415) is unused, the RELOAD URI uniquely identifies a user device: a user MAY have several certificates assigned to their XMPP address but with different RELOAD URIs.</p>
|
||||
<p>The following rules apply to domain-associated certificates:</p>
|
||||
<ol>
|
||||
<li>The certificate MUST contain a keyUsage extension with the keyCertSign bit set.</li>
|
||||
@ -134,15 +134,15 @@
|
||||
</section1>
|
||||
<section1 topic='Root Certificates Discovery' anchor='root-cert-disco'>
|
||||
<p>An XMPP entity MAY maintain its own list of root certificates. However, in practice it's convenient to retrieve this list from a trusted source. For example, several organizations in the Internet maintain and provide such lists for certificates verification in the Web. This section specifies how the list of root certificates can be retrieved for the purpose of e2e authentication in XMPP.</p>
|
||||
<p>Since the authentication is intended to be compliant with RELOAD and creating new document formats or DNS TXT records without exigency are in general discouraged, the Overlay Configuration document is reused to provide the list of root certificates (see Section 11.1 of RFC6940). The root certificates are PEM-encoded (RFC7468) with encapsulation boundaries removed and are included in <root-cert/> elements of the Overlay Configuration.</p>
|
||||
<p>In order to retrieve the Overlay Configuration, an HTTP GET request is performed to "https://xmpp.org/.well-known/reload-config". The requesting UA MUST be prepared to process HTTP redirects. In the case of a failure, the UA MAY repeat the request. In this case exponential backoff MUST be applied. Since the list of root certifcates is not a subject for frequent updates, under normal conditions, the UA SHOULD NOT request the Overlay Configuration more often than once per day. Usage of 'If-Modified-Since' is RECOMMENDED (RFC7232).</p>
|
||||
<p>Since the authentication is intended to be compliant with RELOAD and creating new document formats or DNS TXT records without exigency are in general discouraged, the Overlay Configuration document is reused to provide the list of root certificates (see Section 11.1 of &rfc6940;). The root certificates are PEM-encoded (&rfc7468;) with encapsulation boundaries removed and are included in <root-cert/> elements of the Overlay Configuration.</p>
|
||||
<p>In order to retrieve the Overlay Configuration, an HTTP GET request is performed to "https://xmpp.org/.well-known/reload-config". The requesting UA MUST be prepared to process HTTP redirects. In the case of a failure, the UA MAY repeat the request. In this case exponential backoff MUST be applied. Since the list of root certifcates is not a subject for frequent updates, under normal conditions, the UA SHOULD NOT request the Overlay Configuration more often than once per day. Usage of 'If-Modified-Since' is RECOMMENDED (&rfc7232;).</p>
|
||||
<p>Further versions of this specification MAY extend the Overlay Configuration with new XML elements.</p>
|
||||
</section1>
|
||||
<section1 topic='Leaf Certificates Discovery' anchor='leaf-cert-disco'>
|
||||
<p>An XMPP entity MAY want to publish its certificate so other XMPP entities MAY retrieve it. The method to accomplish this depends on the usage:</p>
|
||||
<ul>
|
||||
<li>In the case of an ordinary XMPP usage (&rfc6120;) a special PEP node (&xep0163;) is used as specified in XEP-EAX-SIGN.</li>
|
||||
<li>In the case of XMPP Usage of RELOAD (XEP-XOR) a peer is REQUIRED to store its certificate in the RELOAD overlay (see Section 8 of RFC6940).</li>
|
||||
<li>In the case of XMPP Usage of RELOAD (XEP-0415) a peer is REQUIRED to store its certificate in the RELOAD overlay (see Section 8 of &rfc6940;).</li>
|
||||
</ul>
|
||||
</section1>
|
||||
<section1 topic='Accessibility Considerations' anchor='access'>
|
||||
|
||||
5
xep.ent
5
xep.ent
@ -671,7 +671,10 @@ THE SOFTWARE.
|
||||
<!ENTITY rfc6763 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6763'>RFC 6763</link></span> <note>RFC 6763: DNS-Based Service Discovery <<link url='http://tools.ietf.org/html/rfc6763'>http://tools.ietf.org/html/rfc6763</link>>.</note>" >
|
||||
<!ENTITY rfc6797 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6797'>RFC 6797</link></span> <note>RFC 6797: HTTP Strict Transport Security (HSTS) <<link url='http://tools.ietf.org/html/rfc6797'>http://tools.ietf.org/html/rfc6797</link>>.</note>" >
|
||||
<!ENTITY rfc6920 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6920'>RFC 6920</link></span> <note>RFC 6920: Naming Things with Hashes <<link url='http://tools.ietf.org/html/rfc6920'>http://tools.ietf.org/html/rfc6920</link>>.</note>" >
|
||||
<!ENTITY rfc6940 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6940'>RFC 6940</link></span> <note>RFC 6940: REsource LOcation And Discovery (RELOAD) Base Protocol <<link url='http://tools.ietf.org/html/rfc6940'>http://tools.ietf.org/html/rfc6940</link>>.</note>" >
|
||||
<!ENTITY rfc7081 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7081'>RFC 7081</link></span> <note>RFC 7081: CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP) <<link url='http://tools.ietf.org/html/rfc7081'>http://tools.ietf.org/html/rfc7081</link>>.</note>" >
|
||||
<!ENTITY rfc7232 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7232'>RFC 7232</link></span> <note>RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests <<link url='http://tools.ietf.org/html/rfc7232'>http://tools.ietf.org/html/rfc7232</link>>.</note>" >
|
||||
<!ENTITY rfc7468 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7468'>RFC 7468</link></span> <note>RFC 7468: Textual Encodings of PKIX, PKCS, and CMS Structures <<link url='http://tools.ietf.org/html/rfc7468'>http://tools.ietf.org/html/rfc7468</link>>.</note>" >
|
||||
<!ENTITY rfc7469 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7469'>RFC 7469</link></span> <note>RFC 7469: Public Key Pinning Extension for HTTP <<link url='http://tools.ietf.org/html/rfc7469'>http://tools.ietf.org/html/rfc7469</link>>.</note>" >
|
||||
<!ENTITY rfc7519 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7519'>RFC 7519</link></span> <note>RFC 7519: JSON Web Token (JWT) <<link url='http://tools.ietf.org/html/rfc7519'>http://tools.ietf.org/html/rfc7519</link>>.</note>" >
|
||||
<!ENTITY rfc7572 "<span class='ref'><link url='http://tools.ietf.org/html/rfc7572'>RFC 7572</link></span> <note>RFC 7572: Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging <<link url='http://tools.ietf.org/html/rfc7572'>http://tools.ietf.org/html/rfc7572</link>>.</note>" >
|
||||
@ -1544,3 +1547,5 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates</link></span> <note>
|
||||
<!ENTITY xep0412 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0412.html'>XMPP Compliance Suites 2019 (XEP-0412)</link></span> <note>XEP-0412: XMPP Compliance Suites 2019 <<link url='https://xmpp.org/extensions/xep-0412.html'>https://xmpp.org/extensions/xep-0412.html</link>>.</note>" >
|
||||
<!ENTITY xep0413 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0413.html'>Order-By (XEP-0413)</link></span> <note>XEP-0413: Order-By <<link url='https://xmpp.org/extensions/xep-0413.html'>https://xmpp.org/extensions/xep-0413.html</link>>.</note>" >
|
||||
<!ENTITY xep0414 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0414.html'>Cryptographic Hash Function Recommendations for XMPP (XEP-0414)</link></span> <note>XEP-0414: Cryptographic Hash Function Recommendations for XMPP <<link url='https://xmpp.org/extensions/xep-0414.html'>https://xmpp.org/extensions/xep-0414.html</link>>.</note>" >
|
||||
<!ENTITY xep0415 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0415.html'>XMPP Over RELOAD (XEP-0415)</link></span> <note>XEP-0415: XMPP Over RELOAD (XOR) <<link url='https://xmpp.org/extensions/xep-0415.html'>https://xmpp.org/extensions/xep-0415.html</link>>.</note>" >
|
||||
<!ENTITY xep0416 "<span class='ref'><link url='https://xmpp.org/extensions/xep-0416.html'>E2E Authentication in XMPP (XEP-0416)</link></span> <note>XEP-0416: E2E Authentication in XMPP <<link url='https://xmpp.org/extensions/xep-0416.html'>https://xmpp.org/extensions/xep-0416.html</link>>.</note>" >
|
||||
|
||||
Loading…
Reference in New Issue
Block a user