mirror of
https://github.com/moparisthebest/xeps
synced 2024-12-21 23:28:51 -05:00
initial version
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2598 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre
parent
080e157a29
commit
64a830c57f
198
xep-0257.xml
Normal file
198
xep-0257.xml
Normal file
@ -0,0 +1,198 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Client Certificate Management for SASL EXTERNAL</title>
|
||||
<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.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0257</number>
|
||||
<status>Experimental</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0178</spec>
|
||||
<spec>XEP-0189</spec>
|
||||
</dependencies>
|
||||
<supersedes>None</supersedes>
|
||||
<supersededby>None</supersededby>
|
||||
<shortname>NOT YET ASSIGNED</shortname>
|
||||
<author>
|
||||
<firstname>Dirk</firstname>
|
||||
<surname>Meyer</surname>
|
||||
<email>dmeyer@tzi.de</email>
|
||||
<jid>dmeyer@jabber.org</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
<date>2009-01-05</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Initial published version.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.2</version>
|
||||
<date>2008-11-28</date>
|
||||
<initials>dm</initials>
|
||||
<remark><p>Add Security Considerations, improve reference to XEP-0178.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.1</version>
|
||||
<date>2008-11-18</date>
|
||||
<initials>dm</initials>
|
||||
<remark><p>First draft.</p></remark>
|
||||
</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>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. This document provides a mechanism to manage different user certificates.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Certificate Management' anchor='manage'>
|
||||
<p>From the user's point of view the initial client configuration is the same. The user needs to provide the user name and the password for the client to connect to the XMPP server. The main difference is that the client MUST NOT store the password for later use and MUST create an X.509 certificate for future logins. It does not matter if the certificate is self-signed or issued by a trusted third party.</p>
|
||||
<section2 topic='Add X.509 Certificate' anchor='add'>
|
||||
<p>After the client has logged in and created the certificate, it uploads the certificate to the server. The XML representation of the certificate from &xep0189; is used to describe a certificate. The client also SHOULD provide a name for the certificate to make it possible for the user to manage the different client certificates.</p>
|
||||
<example caption='Client Uploads an X.509 Certificate'><![CDATA[
|
||||
<iq type='set'
|
||||
from='hamlet@shakespeare.lit/denmark'
|
||||
id='append'>
|
||||
<append xmlns='urn:xmpp:tmp:saslcert'>
|
||||
<name>Mobile Client</name>
|
||||
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
|
||||
<name>428b1358a286430f628da23fb33ddaf6e474f5c5</name>
|
||||
<x509cert>
|
||||
MIICCTCCAXKgAwIBAgIJALhU0Id6xxwQMA0GCSqGSIb3DQEBBQUAMA4xDDAKBgNV
|
||||
BAMTA2ZvbzAeFw0wNzEyMjgyMDA1MTRaFw0wODEyMjcyMDA1MTRaMA4xDDAKBgNV
|
||||
BAMTA2ZvbzCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0DPcfeJzKWLGE22p
|
||||
RMINLKr+CxqozF14DqkXkLUwGzTqYRi49yK6aebZ9ssFspTTjqa2uNpw1U32748t
|
||||
qU6bpACWHbcC+eZ/hm5KymXBhL3Vjfb/dW0xrtxjI9JRFgrgWAyxndlNZUpN2s3D
|
||||
hKDfVgpPSx/Zp8d/ubbARxqZZZkCAwEAAaNvMG0wHQYDVR0OBBYEFJWwFqmSRGcx
|
||||
YXmQfdF+XBWkeML4MD4GA1UdIwQ3MDWAFJWwFqmSRGcxYXmQfdF+XBWkeML4oRKk
|
||||
EDAOMQwwCgYDVQQDEwNmb2+CCQC4VNCHesccEDAMBgNVHRMEBTADAQH/MA0GCSqG
|
||||
SIb3DQEBBQUAA4GBAIhlUeGZ0d0msNVxYWAXg2lRsJt9INHJQTCJMmoUeTtaRjyp
|
||||
ffJtuopguNNBDn+MjrEp2/+zLNMahDYLXaTVmBf6zvY0hzB9Ih0kNTh23Fb5j+yK
|
||||
QChPXQUo0EGCaODWhfhKRNdseUozfNWOz9iTgMGw8eYNLllQRL//iAOfOr/8
|
||||
</x509cert>
|
||||
</keyinfo>
|
||||
</append>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>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.</p>
|
||||
</section2>
|
||||
<section2 topic='Request a list of all Certificates'>
|
||||
<p>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.</p>
|
||||
<example caption='Client requests List of X.509 Certificates'><![CDATA[
|
||||
<iq type='get'
|
||||
from='hamlet@shakespeare.lit/denmark'
|
||||
id='query'>
|
||||
<items xmlns='urn:xmpp:tmp:saslcert'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The server then returns the list of all known certificates including the user provided name.</p>
|
||||
<example caption='Server sends List of known X.509 Certificates'><![CDATA[
|
||||
<iq type='result'
|
||||
to='hamlet@shakespeare.lit/denmark'
|
||||
id='query'>
|
||||
<items xmlns='urn:xmpp:tmp:saslcert'>
|
||||
<item id='428b1358a286430f628da23fb33ddaf6e474f5c5'>
|
||||
<name>Mobile Client</name>
|
||||
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
|
||||
<name>428b1358a286430f628da23fb33ddaf6e474f5c5</name>
|
||||
<x509cert>
|
||||
...
|
||||
</x509cert>
|
||||
</keyinfo>
|
||||
</item>
|
||||
<item id='571b23d99892f4566017426e92c377288ed6c983'>
|
||||
<name>Laptop</name>
|
||||
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
|
||||
<name>571b23d99892f4566017426e92c377288ed6c983</name>
|
||||
<x509cert>
|
||||
...
|
||||
</x509cert>
|
||||
</keyinfo>
|
||||
</item>
|
||||
</items>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section2>
|
||||
<section2 topic='Revoke a Certificate'>
|
||||
<p>The user may want to revoke a certificate from a stolen or compromised device. Another reason is that the client created a new certificate because the current one will expire in some days. After the client created a new certificate for itself it MAY revoke the old certificate for future usage.</p>
|
||||
<example caption='Client revokes an X.509 Certificate'><![CDATA[
|
||||
<iq type='get'
|
||||
from='hamlet@shakespeare.lit/denmark'
|
||||
id='revoke'>
|
||||
<revoke xmlns='urn:xmpp:tmp:saslcert'/>
|
||||
<item id='428b1358a286430f628da23fb33ddaf6e474f5c5'>
|
||||
<compromised/>
|
||||
</item>
|
||||
</revoke>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The revoke stanza can contain more than one item to revoke. The server MUST remove the certificates with the given ids from the list. If the additional information compromised is added, the server SHOULD close the stream to a client logged in using that certificate for the SASL EXTERNAL mechanism.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='SASL EXTERNAL' anchor='sasl'>
|
||||
<p>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.</p>
|
||||
<example caption='subjectAltName using the "id-on-xmppAddr" format'><![CDATA[
|
||||
subjectAltName=otherName:id-on-xmppAddr;UTF8:hamlet@shakespeare.lit
|
||||
]]></example>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>&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.</p>
|
||||
<example caption='Password Change'><![CDATA[
|
||||
<iq type='set' to='shakespeare.lit' id='change1'>
|
||||
<query xmlns='jabber:iq:register'>
|
||||
<username>hamlet</username>
|
||||
<password>newpass</password>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If the sending client has logged in using SASL EXTERNAL and the server supports XEP-0077 password changes it returns a form to change the password. If the client has logged in with the current password, the server MAY change the password without a form as specified in XEP-0077.</p>
|
||||
<example caption='Server Returns Password Change Form With Error'><![CDATA[
|
||||
<iq type='error' from='shakespeare.lit' to='hamlet@shakespeare.lit/denmark' id='change1'>
|
||||
<query xmlns='jabber:iq:register'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<title>Password Change</title>
|
||||
<instructions>Use this form to change your password.</instructions>
|
||||
<field type='hidden' var='FORM_TYPE'>
|
||||
<value>jabber:iq:register:changepassword</value>
|
||||
</field>
|
||||
<field type='text-single' label='Username' var='username'>
|
||||
<required/>
|
||||
</field>
|
||||
<field type='text-private' label='Old Password' var='old_password'>
|
||||
<required/>
|
||||
</field>
|
||||
<field type='text-private' label='New Password' var='password'>
|
||||
<required/>
|
||||
</field>
|
||||
</x>
|
||||
</query>
|
||||
<error code='405' type='cancel'>
|
||||
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
|
||||
</error>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>If a client is allowed to change the password without knowing the current password, the additional security provided by this document is compromised</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<section2 topic='Protocol Namespaces' anchor='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 ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<section1 topic='XML Schema' anchor='schema'>
|
||||
<p>The XML schema will be provided in a later version of this document.</p>
|
||||
</section1>
|
||||
</xep>
|
||||
681
xep-0258.xml
Normal file
681
xep-0258.xml
Normal file
@ -0,0 +1,681 @@
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
||||
<!ENTITY % ents SYSTEM 'xep.ent'>
|
||||
<!ENTITY LABEL "<label/>">
|
||||
<!ENTITY SECURITYLABEL "<securitylabel/>">
|
||||
<!ENTITY DISPLAYMARKING "<displaymarking/>">
|
||||
<!ENTITY EQUIVALENTLABEL "<equivalentlabel/>">
|
||||
<!ENTITY HEADLINE "<headline/>">
|
||||
<!ENTITY IDENTITY "<identity/>">
|
||||
<!ENTITY rfc2634 "<span class='ref'><link url='http://tools.ietf.org/html/rfc2634'>RFC 2634</link></span> <note>RFC 2634: Enhanced Security Services for S/MIME <<link url='http://tools.ietf.org/html/rfc2634'>http://tools.ietf.org/html/rfc2634</link>>.</note>" >
|
||||
<!ENTITY ASN.1 "<span class='ref'><link url='http://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf'>ASN.1</link></span> <note>X.680: Abstract Syntax Notation One (ASN.1): Specification of basic notation <<link url='http:://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf'>http:://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf</link>>.</note>" >
|
||||
<!ENTITY BER "<span class='ref'><link url='http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf'>BER</link></span> <note>X.690: ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) <<link url='http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf'>http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf</link>>.</note>" >
|
||||
<!ENTITY X.500 "<span class='ref'><link url='http://www.itu.int/rec/T-REC-X.500-200102-I/en'>X.500</link></span> <note>X.500: The Directory: Overview of concepts, models and service <<link url='http://www.itu.int/rec/T-REC-X.500-200102-I/en'>http://www.itu.int/rec/T-REC-X.500-200102-I/en</link>>.</note>" >
|
||||
<!ENTITY X.841 "<span class='ref'><link url='http://www.itu.int/rec/T-REC-X.841-200010-I/en'>X.841</link></span> <note>X.841: Security techniques - Security information objects for access control <<link url='http://www.itu.int/rec/T-REC-X.841-200010-I/en'>http://www.itu.int/rec/T-REC-X.841-200010-I/en</link>>.</note>" >
|
||||
<!ENTITY SDN.801c "<span class='ref'>SDN.801c</span> <note>SDN.801c: Access Control Concept and Mechanism, US National Security Agency, Revision C, 12 May 1999.</note>" >
|
||||
<!ENTITY IC-ISM "<span class='ref'>IC-ISM</span> <note>Common Information Sharing Standard for Information Security Marking: XML Implementation, Office of the Director of National Intelligence,
|
||||
Release 2.0.3, 15 February 2006.</note>" >
|
||||
%ents;
|
||||
]>
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Security Labels in XMPP</title>
|
||||
<abstract>This document describes the use of security labels in XMPP. The document
|
||||
specifies how security label metadata is carried in XMPP, when this metadata
|
||||
should or should not be provided, and how the metadata is to be processed.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0258</number>
|
||||
<status>Experimental</status>
|
||||
<type>Standards Track</type>
|
||||
<sig>Standards</sig>
|
||||
<approver>Council</approver>
|
||||
<dependencies>
|
||||
<spec>XMPP Core</spec>
|
||||
<spec>XEP-0001</spec>
|
||||
<spec>Etc.</spec>
|
||||
</dependencies>
|
||||
<supersedes/>
|
||||
<supersededby/>
|
||||
<shortname>sec-label</shortname>
|
||||
<author>
|
||||
<firstname>Kurt</firstname>
|
||||
<surname>Zeilenga</surname>
|
||||
<email>Kurt.Zeilenga@Isode.COM</email>
|
||||
<jid>Kurt.Zeilenga@Isode.COM</jid>
|
||||
</author>
|
||||
<revision>
|
||||
<version>0.1</version>
|
||||
<date>2009-01-05</date>
|
||||
<initials>psa</initials>
|
||||
<remark><p>Initial published version.</p></remark>
|
||||
</revision>
|
||||
<revision>
|
||||
<version>0.0.081203</version>
|
||||
<date>2008-12-03</date>
|
||||
<initials>kdz</initials>
|
||||
<remark><p>Initial draft.</p></remark>
|
||||
</revision>
|
||||
</header>
|
||||
|
||||
<section1 topic='Introduction' anchor='intro'>
|
||||
<p>A security label, sometimes referred to as a confidentiality label, is
|
||||
a structured representation of the sensitivity of a piece of information. They are
|
||||
used in conjunction with a clearance, a structured representation of what information
|
||||
sensitivities a person (or other entity) is authorized to access, and a security
|
||||
policy to control access to each piece of information. For instance, message could be
|
||||
labeled as "SECRET", and hence requiring the sender and the receiver to have a
|
||||
clearance granting access to "SECRET" information. &X.841; provides a discussion of
|
||||
security labels, clearances, and security policy.</p>
|
||||
<p>Sensitivity-based authorization is used in networks which operate under a set of
|
||||
information classification rules, such as in government defense agency networks. The
|
||||
standardized formats for security labels, clearances, and security policy are
|
||||
generalized and do have application in non-government networks.</p>
|
||||
<p>This document describes the use of security labels in &xmpp;. The document specifies
|
||||
how security label metadata is carried in XMPP. It standardizes a mechanism for
|
||||
carrying ESS Security Labels in XMPP, as well as provides for use of other label
|
||||
formats. ESS Security Labels are specified in &rfc2634;. ESS Security Labels are
|
||||
commonly used in conjunction with &X.500; clearances and either X.841 or &SDN.801c;
|
||||
security policies.</p>
|
||||
<example caption="Message with ESS Security Label"><![CDATA[
|
||||
<message to='romeo@example.net' from='juliet@example.com/balcony'>
|
||||
<body>This content is classified.</body>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
|
||||
<label><esssecuritylabel xmlns='urn:xmpp:sec-label:ess:0'
|
||||
>MQYCAQIGASk=</esssecurityLabel></label>
|
||||
</securityLabel>
|
||||
</message>
|
||||
]]></example>
|
||||
<example caption="Message with IC-ISM Label"><![CDATA[
|
||||
<message to='romeo@example.net' from='juliet@example.com/balcony'>
|
||||
<body>This content is classified.</body>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
|
||||
<label><icismlabel xmlns='http://example.gov/IC-ISM/0'
|
||||
classification='S' ownerProducer='USA' disseminationControls='FOUO'/></label>
|
||||
</securityLabel>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>Note: The &IC-ISM; label example is for <em>illustrative purposes only</em>.</p>
|
||||
|
||||
<p>The document details when security label metadata should or should not be provided, and how
|
||||
this metadata is to be processed.</p>
|
||||
<p>This document does <em>not</em> (yet?) provide:
|
||||
<ul>
|
||||
<li>any mechanism for a client might discover the security policy enforce at its home server,
|
||||
or any other server;</li>
|
||||
<li>any mechanism for a client to discover the user's clearance,
|
||||
or the clearance of associated with any resource; nor</li>
|
||||
<li>any administrative mechanism for a client to configure configure policy,
|
||||
clearance, and labels of any resource.</li>
|
||||
</ul>
|
||||
Such mechanisms may be introduced in subsequent documents.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Discovering Feature Support' anchor='disco'>
|
||||
<p>If an entity supports the XMPP Security Label protocol, it MUST report that fact
|
||||
by including a service discovery feature of "<tt>urn:xmpp:sec-label:0</tt>" in
|
||||
response to a &xep0030; information request. Clients wishing to include a XMPP
|
||||
Security Label element in any stanza they generate SHOULD determine if their
|
||||
server supports the XMPP Security Label protocol. If their server does not
|
||||
support XMPP Security Label, the client SHOULD NOT generate XMPP Security Labels
|
||||
as the server not supporting this protocol will generally ignore XMPP Security
|
||||
Labels as they would any other unrecognized element.</p>
|
||||
<p>As each service domain may have different support for security labels, servers
|
||||
should advertise and clients should perform appropriate discovery lookups on a
|
||||
per service basis.</p>
|
||||
<example caption="Service Discovery information request"><![CDATA[
|
||||
<iq type='get'
|
||||
from='user@example.com/Work'
|
||||
to='example.com'
|
||||
id='disco1'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption="Service Discovery information response"><![CDATA[
|
||||
<iq type='result'
|
||||
from='example.com'
|
||||
to='user@example.com/Work'
|
||||
id='disco1'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
...
|
||||
<feature var='urn:xmpp:sec-label:0'/>
|
||||
...
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<!--
|
||||
<p>A server should only include &IDENTITY; elements in the response for services
|
||||
the user is cleared to use.</p>
|
||||
-->
|
||||
</section1>
|
||||
|
||||
<section1 topic='Protocol' anchor='protocol'>
|
||||
<p>An element, &SECURITYLABEL;, is defined to carry security label metadata. This metadata
|
||||
includes a security label, zero or more equivalent security labels, and optionally display
|
||||
marking data.</p>
|
||||
<example caption="Labeled Message"><![CDATA[
|
||||
<message to='romeo@example.net' from='juliet@example.com/balcony'>
|
||||
<body>This content is classified.</body>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'
|
||||
>MQYCAQIGASk=</esssecuritylabel>
|
||||
</label>
|
||||
<equivalentlabel>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'
|
||||
>MRACAgEABgIpARMGT3Jhbmdl</esssecuritylabel>
|
||||
</equivalentlabel>
|
||||
</securityLabel>
|
||||
</message>
|
||||
]]></example>
|
||||
<p>The security label metadata is carried in an &SECURITYLABEL; element.
|
||||
The &SECURITYLABEL; element which contains one and only one &LABEL; element,
|
||||
zero or more &EQUIVALENTLABEL; elements, and an optional &DISPLAYMARKING; element.</p>
|
||||
<p>The &LABEL; contains the primary security label. It is commonly issued by the
|
||||
sender under the security policy of that they and their home server operating under.
|
||||
Each &EQUIVALENTLABEL; holds equivalent security labels under other policies.
|
||||
This element might be used when a recepient is known to hold a clearance under a
|
||||
different policy than the sender.</p>
|
||||
<p>The &LABEL; and &EQUIVALENTLABEL; elements each require a <tt>type=</tt> attribute.
|
||||
The <tt>type=</tt> attribute indicates the type and encoding of the element's value.
|
||||
The attribute <tt>type=</tt> value '<tt>ESS</tt>' indicates the label is the
|
||||
base64, as specified in &rfc4648;, encoding of the &BER; encoding of the &ASN.1;
|
||||
<tt>eSSSecurityLabel</tt> type as specified in &rfc2634;.
|
||||
Additional types may be registered (see 'XMPP Registrar Considerations').</p>
|
||||
<p>The &DISPLAYMARKING; element contains a display string for use by
|
||||
implementations which are unable to utilize the applicable security policy
|
||||
to generate display markings. The element may optionally contain two
|
||||
attributes, <tt>fgcolor=</tt> and <tt>bgcolor=</tt>, whose values are HTML
|
||||
color strings (e.g., '<tt>red</tt>' or '<tt>#ff0000</tt>'), for use in
|
||||
colorizing the display marking.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Label Information Discovery' anchor='label-disco'>
|
||||
<p>It is RECOMMENDED the server publish security label information, including a
|
||||
catalog of labels, for use by clients.</p>
|
||||
<p>The catalog provided should only contain labels for which the client is allowed to use
|
||||
(based upon the user's authorization). The catalog may not be include the complete
|
||||
set of labels available for the use by the client.</p>
|
||||
<p>As each service domain may have different support for security labels, servers
|
||||
should advertise and clients should perform appropriate discovery lookups on a
|
||||
per service basis.</p>
|
||||
<p>To indicate the support for label information discovery, a server advertises the
|
||||
<tt>urn:xmpp:sec-label:info:0</tt> feature.</p>
|
||||
<example caption="Label Information Feature Discovery request"><![CDATA[
|
||||
<iq type='get'
|
||||
from='user@example.com/Work'
|
||||
to='example.com'
|
||||
id='disco1'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
<example caption="Label Information Feature Discovery response"><![CDATA[
|
||||
<iq type='result'
|
||||
from='example.com'
|
||||
to='user@example.com/Work'
|
||||
id='disco1'>
|
||||
<query xmlns='http://jabber.org/protocol/disco#info'>
|
||||
...
|
||||
<feature var='urn:xmpp:sec-label:0'/>
|
||||
<feature var='urn:xmpp:sec-label:info:0'/>
|
||||
...
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
<p>The following example illustrates catalog discovery.</p>
|
||||
|
||||
<!-- Hierarchy of labels? -->
|
||||
<example caption="Label Information request"><![CDATA[
|
||||
<iq type='get'
|
||||
from='user@example.com/Work'
|
||||
to='example.com'
|
||||
id='catalog1'>
|
||||
<query xmlns='urn:xmpp:sec-label:info:0'/>
|
||||
</iq>
|
||||
]]></example>
|
||||
|
||||
<example caption="Label Information response"><![CDATA[
|
||||
<iq type='result'
|
||||
from='example.com'
|
||||
to='user@example.com/Work'
|
||||
id='catalog1'>
|
||||
<query xmlns='urn:xmpp:sec-label:info:0'>
|
||||
<labelcatalog>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='red'>SECRET</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'
|
||||
>MQYCAQQGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securityLabel>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='navy'>CONFIDENTIAL</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'
|
||||
>MQYCAQMGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securityLabel>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='aqua'>RESTRICTED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'
|
||||
>MQYCAQIGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securityLabel>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'
|
||||
>MQMGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securityLabel>
|
||||
</labelcatalog>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The label information may contain other elements.</p>
|
||||
</section1>
|
||||
|
||||
<section1 topic='Use in XMPP' anchor='xmpp-use'>
|
||||
<p>The sensitivity-based access control decisions discussed herein are to be
|
||||
made independently of other access control decisions or other facilities.
|
||||
That is, the sensitivity-based access control decisions are not conditional
|
||||
on other factors.</p>
|
||||
<p>It is intended that &SECURITYLABEL; elements are only used as prescribed by
|
||||
this document, or other formal specifications. Any other use of
|
||||
&SECURITYLABEL; SHOULD be viewed as a protocol violation. The stanza SHOULD
|
||||
be discarded with, if approrpriate, an error response. Such error responses
|
||||
SHOULD NOT include content from the violating stanza, excepting that
|
||||
necessary to well-formed error responses.</p>
|
||||
<p>When use of a &SECURITYLABEL; element is prescribed, that use is RECOMMENDED.
|
||||
Absence of a &SECURITYLABEL; element implies the stanza has the default label
|
||||
as specified in the governing security policy. Given that the governing
|
||||
policy may not specify a default label, hence denying access to the stanza,
|
||||
supporting clients SHOULD provide a &SECURITYLABEL; element where prescribed.</p>
|
||||
<p>Typically, a client would allow the user to choose populate the
|
||||
&SECURITYLABEL; from one of from a small set of security labels selections
|
||||
known to it (through configuration and/or discovery and/or other means),
|
||||
such as from a pull-down menu. That selection would include appropriate
|
||||
values for the &LABEL;, &DISPLAYMARKING;, and &EQUIVALENTLABEL; elements.</p>
|
||||
<p>A policy-aware client may provide the user with an interface allowing the
|
||||
user to produce custom labeling data for inclusion in this set. A
|
||||
policy-aware client SHOULD preclude the user from producing &LABEL; values
|
||||
which the user's own clearance does not grant access to, and SHOULD preclude
|
||||
sending any label which the user's own clearance does not grant access to.
|
||||
Each &EQUIVALENTLABEL; value, if any, MUST be equivalent under an equivalent
|
||||
policy to the &LABEL;. The &DISPLAYMARKING; element SHOULD be set the
|
||||
display marking prescribed for the &LABEL; under the governing policy, or,
|
||||
if the governing policy prescribes no display marking for the &LABEL;,
|
||||
absent.</p>
|
||||
<p>A client which receives a stanza with &SECURITYLABEL; element is to promiently
|
||||
display the &DISPLAYMARKING; value. A policy-aware may alternatively
|
||||
promiently display the marking for the &LABEL; prescribed by the governing
|
||||
policy.</p>
|
||||
<p>Each server is expected to make a number of sensitivity-based authorization
|
||||
decisions. Each decision is made by evaluating an Access Control Decision
|
||||
Function (ACDF) with a governing policy, a clearance, and a security label.
|
||||
The ACDF yields either <em>Grant</em> or <em>Deny</em>.</p>
|
||||
<p>If the user holds a valid clearance (known to the server) under the
|
||||
governing policy, the clearance input is the user's clearance. Otherwise,
|
||||
if the governing policy provides a default clearance, the clearance input
|
||||
is the default clearance. Otherwise, the clearance input is the nil clearance.
|
||||
The nil clearance is a clearance for which the ACDF always returns Deny when
|
||||
given as the clearance input.</p>
|
||||
<p>If the stanza contains a &SECURITYLABEL; element and the either the &LABEL;
|
||||
element or one of the &EQUIVALENTLABEL; elements contain an appropriate label,
|
||||
that label input is that label. Otherwise, the label input is the default
|
||||
label provided the governing policy or, if no default label is provided,
|
||||
the nil label. The nil label is a label for which the ACDF always returns
|
||||
Deny when given as the label input.</p>
|
||||
<p>The term "effective clearance" and "effective label" refer, respectively,
|
||||
to the clearance and label provided as input to the ACDF.</p>
|
||||
<p>Not all sensitivity-based authorization decisions an XMPP server might make
|
||||
involve a user clearance and/or stanza label. A server may only provide
|
||||
service to users which hold an appropriate clearance as determined by calling
|
||||
the ACDF with the user's clearance and a label associated with the service.
|
||||
A clearance might also be associated with the service to restrict the set
|
||||
of labels may be used in labeling stanzas. Labels and clearances can also
|
||||
be associated with network interfaces, remote servers, chatrooms, pubsub
|
||||
notes.</p>
|
||||
<section2 topic='Use in Instant Messaging' anchor='im-use'>
|
||||
<p>A client may provide a &SECURITYLABEL; element in any &MESSAGE; it sends.</p>
|
||||
<!--
|
||||
<p>The server will make, at a minimum, the following accessing control decisions:
|
||||
<ul>
|
||||
<li>TBD</li>
|
||||
</ul>
|
||||
</p>
|
||||
-->
|
||||
</section2>
|
||||
<section2 topic='Use in Group Chat and Multi-User Chat' anchor='muc-use'>
|
||||
<p>A client may provide a &SECURITYLABEL; element in &MESSAGE; stanzas.</p>
|
||||
|
||||
<section3 topic='Discovery' anchor='muc-disco'>
|
||||
<p>A server SHOULD provide a label feature and information discovery for the room.</p>
|
||||
<p>Clients SHOULD discover label feature and information on a per room basis.</p>
|
||||
</section3>
|
||||
<section3 topic='Sending Messages' anchor='muc-send'>
|
||||
<p>Sending groupchat messages is similiar to sending normal messages, however
|
||||
their are a few differences.</p>
|
||||
<p>Groupchat messages are addressed to the room. The room clearance must
|
||||
be suitable for the message label, else it should be rejected.</p>
|
||||
<p>The room's clearance may allow a variety of labels to be used. Not all
|
||||
partipants may be cleared for all labels allowed in the room. The server
|
||||
MUST only deliver messages to partipants for which they are cleared to
|
||||
receive.</p>
|
||||
</section3>
|
||||
<section3 topic='Private Messages' anchor='muc-private'>
|
||||
<p>Private messages are treated as discussed in the "Use in Instant Messaging"
|
||||
section. (Should private messages be restricted by room's configuration?)</p>
|
||||
</section3>
|
||||
<section3 topic='Invitations' anchor='muc-invite'>
|
||||
<p>Invitations may be labeled.</p>
|
||||
</section3>
|
||||
<section3 topic='Changing Subject' anchor='muc-subject'>
|
||||
<p>This section discusses semantics of &SECURITYLABEL; elements contained
|
||||
in &MESSAGE; stanzas containing a &SUBJECT; element.</p>
|
||||
<p>The presence of a &SECURITYLABEL; element indicates a request to change
|
||||
the room's label, either to the provided label or, if the element is empty,
|
||||
to unset the room's label. The server is to refuse the request if the
|
||||
requestor is not authorized to change the subject, not cleared for the
|
||||
requested label, or if the server is otherwise unwilling or unable to make
|
||||
the change. If the label change is refused, so must the accompanied
|
||||
subject change. Likewise, if the subject change is refused, so must the
|
||||
accompanied label change.</p>
|
||||
<p>Upon change of the room's label, the server MUST immediately remove from
|
||||
the room all members whom are not cleared for that label.</p>
|
||||
<p>In absence of a &SECURITYLABEL; element, the label associated with the
|
||||
room is unchanged.</p>
|
||||
<p>The room's label can also be changed through room configuration (to be
|
||||
discussed in later revision of this document).</p>
|
||||
</section3>
|
||||
<!--
|
||||
<section3 topic='Room Configuration' anchor='muc-config'>
|
||||
<p>The server may allow for configuration of security label parameters
|
||||
via room configuration mechanisms. The approach is intended to be
|
||||
ad-hoc. Hence this section is intended to be illustrative, not
|
||||
prescriptive.</p>
|
||||
<example caption="Room Configuration Form"><![CDATA[
|
||||
<iq from='room@muc.example.com'
|
||||
id='create1'
|
||||
to='user@example.com/Work'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/muc#owner'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<title>"darkcave" room configuration</title>
|
||||
...
|
||||
<field label='Room Label' type='list-single' var='sec-label#label'>
|
||||
<value>Catalog:UNCLASSIFIED</value>
|
||||
<option label='SECRET'><value>Catalog:SECRET</value></option>
|
||||
<option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option>
|
||||
<option label='UNCLASSIFED'><value>Catalog:UNCLASSIFIED</value></option>
|
||||
<option label='Custom'><value>Custom</value></option>
|
||||
</field>
|
||||
<field label='Custom Room Label' type='text-single'
|
||||
var='sec-label#custom-label'/>
|
||||
<field label='Room Allowed Markings' type='list-multi' var='sec-label#clearance'>
|
||||
<value>Catalog:UNCLASSIFIED</value>
|
||||
<option label='SECRET'><value>Catalog:SECRET</value></option>
|
||||
<option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option>
|
||||
<option label='UNCLASSIFED'><value>Catalog:UNCLASSIFIED</value></option>
|
||||
<option label='Custom'><value>Custom</value></option>
|
||||
</field>
|
||||
<field label='Custom Room Clearance' type='text-single'
|
||||
var='sec-label#custom-clearance'/>
|
||||
<field label='Default Label' type='list-single' var='sec-label#default-label'>
|
||||
<value>Catalog:UNCLASSIFIED</value>
|
||||
<option label='SECRET'><value>Catalog:SECRET</value></option>
|
||||
<option label='CONFIDENTIAL'><value>Catalog:CONFIDENTIAL</value></option>
|
||||
<option label='UNCLASSIFED'><value>Catalog:UNCLASSIFIED</value></option>
|
||||
<option label='Custom'><value>Custom</value></option>
|
||||
</field>
|
||||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>In the above example, the server allows the room label to be set to one of
|
||||
to a subset of labels from the label catalog (see below), using the display
|
||||
name for selection, as well as custom label support. For custom label choice
|
||||
support, the server offers an appropriate choice (the label= string should
|
||||
be selected to avoid confusion with display markings used in label=
|
||||
attributes). as well as a field for providing the custom label. Likewise
|
||||
for the room clearance. The server also allows configuration of a default
|
||||
label for use in handling of unlabeled messages.</p>
|
||||
<p>Though offering choices from the label catalog is often desirable,
|
||||
a server may only offer custom label and/or clearance support.</p>
|
||||
<example caption="Room Configuration Form"><![CDATA[
|
||||
<iq from='room@muc.example.com'
|
||||
id='create1'
|
||||
to='user@example.com/Work'
|
||||
type='result'>
|
||||
<query xmlns='http://jabber.org/protocol/muc#owner'>
|
||||
<x xmlns='jabber:x:data' type='form'>
|
||||
<title>"darkcave" room configuration</title>
|
||||
...
|
||||
<field label='Room Label' type='text-single'
|
||||
var='sec-label#custom-label'/>
|
||||
<field label='Room Clearance' type='text-single'
|
||||
var='sec-label#custom-clearance'/>
|
||||
</x>
|
||||
</query>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section3>
|
||||
-->
|
||||
</section2>
|
||||
<section2 topic='Use in Presence' anchor='presence-use'>
|
||||
<p>&SECURITYLABEL; elements are not to appear in &PRESENCE; stanzas. Server
|
||||
SHALL treat any &PRESENCE; stanza that contains a &SECURITYLABEL; as a
|
||||
protocol violation.</p>
|
||||
<p>Presence information is subject to sensitivity-base authorization decisions,
|
||||
however these decisions are made are made using a label associated with the
|
||||
presence resource, such as a chatroom's label.</p>
|
||||
</section2>
|
||||
<section2 topic='Use in PubSub' anchor='pubsub-use'>
|
||||
<section3 topic='Discovery' anchor='pubsub-disco'>
|
||||
<p>A server SHOULD provide a label feature and information discovery for each node.</p>
|
||||
<p>Clients SHOULD discover label feature and information on a per node basis.</p>
|
||||
</section3>
|
||||
<section3 topic='Publishing items with Security Labels' anchor='muc-send'>
|
||||
<p>Each item may be individually labeled.</p>
|
||||
<example caption="Publishing with a Security Label"><![CDATA[
|
||||
<iq type='set'
|
||||
from='hamlet@denmark.lit/blogbot'
|
||||
to='pubsub.shakespeare.lit'
|
||||
id='pub1'>
|
||||
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
|
||||
<publish node='princely_musings'>
|
||||
<item>
|
||||
<entry xmlns='http://www.w3.org/2005/Atom'>
|
||||
<title>Soliloquy</title>
|
||||
<summary>
|
||||
To be, or not to be: that is the question:
|
||||
Whether 'tis nobler in the mind to suffer
|
||||
The slings and arrows of outrageous fortune,
|
||||
Or to take arms against a sea of troubles,
|
||||
And by opposing end them?
|
||||
</summary>
|
||||
<link rel='alternate' type='text/html'
|
||||
href='http://denmark.lit/2003/12/13/atom03'/>
|
||||
<id>tag:denmark.lit,2003:entry-32397</id>
|
||||
<published>2003-12-13T18:30:02Z</published>
|
||||
<updated>2003-12-13T18:30:02Z</updated>
|
||||
</entry>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'>MQMGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securityLabel>
|
||||
</item>
|
||||
</publish>
|
||||
</pubsub>
|
||||
</iq>
|
||||
]]></example>
|
||||
<p>The service then notifies appropriately cleared subscribers.</p>
|
||||
<example caption="Publishing with a Security Label"><![CDATA[
|
||||
<message from='pubsub.shakespeare.lit' to='francisco@denmark.lit' id='foo'>
|
||||
<event xmlns='http://jabber.org/protocol/pubsub#event'>
|
||||
<items node=princely_musings'>
|
||||
<item id='ae890ac52d0df67ed7cfdf51b644e901'>
|
||||
<entry xmlns='http://www.w3.org/2005/Atom'>
|
||||
<title>Soliloquy</title>
|
||||
<summary>
|
||||
To be, or not to be: that is the question:
|
||||
Whether 'tis nobler in the mind to suffer
|
||||
The slings and arrows of outrageous fortune,
|
||||
Or to take arms against a sea of troubles,
|
||||
And by opposing end them?
|
||||
</summary>
|
||||
<link rel='alternate' type='text/html'
|
||||
href='http://denmark.lit/2003/12/13/atom03'/>
|
||||
<id>tag:denmark.lit,2003:entry-32397</id>
|
||||
<published>2003-12-13T18:30:02Z</published>
|
||||
<updated>2003-12-13T18:30:02Z</updated>
|
||||
</entry>
|
||||
<securitylabel xmlns='urn:xmpp:sec-label:0'>
|
||||
<displaymarking fgcolor='black' bgcolor='green'>UNCLASSIFIED</displaymarking>
|
||||
<label>
|
||||
<esssecuritylabel xmlns='urn:xmpp:sec-label:0'>MQMGASk=</esssecuritylabel>
|
||||
</label>
|
||||
</securityLabel>
|
||||
</item>
|
||||
</items>
|
||||
</event>
|
||||
</iq>
|
||||
]]></example>
|
||||
</section3>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
<!--
|
||||
<section1 topic='Implementation Notes' anchor='impl'>
|
||||
<p>OPTIONAL.</p>
|
||||
</section1>
|
||||
-->
|
||||
<section1 topic='Security Considerations' anchor='security'>
|
||||
<p>This document is all about authorization, a key aspect of security. Hence,
|
||||
security considerations are discussed through this document.</p>
|
||||
<p>Security labels generally should be securely bound to the object. This may be
|
||||
accomplished through use of &xmppe2e; signing, or possibly other signing
|
||||
mechanisms.</p>
|
||||
<p>Certain XMPP stanzas, such as &PRESENCE; stanzas, are not themselves subject
|
||||
to any sensitity-based authorization decisions, and may be forwarded throughout
|
||||
the XMPP network. The content of these stanzas should not contain information
|
||||
requiring sensitivity-based dissemination controls.</p>
|
||||
</section1>
|
||||
<section1 topic='IANA Considerations' anchor='iana'>
|
||||
<p>This document requires no interaction with &IANA;.</p>
|
||||
</section1>
|
||||
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
|
||||
<p>It is requested the ®ISTRAR; add the extension's namespace and schema to
|
||||
appropriate XMPP registries.</p>
|
||||
<p>It is requested the Registrar maintain a registry of label types. The
|
||||
type string "<tt>ESS</tt>" is reserved for use as described in this document.</p>
|
||||
</section1>
|
||||
<section1 topic='XML Schemas' anchor='schema'>
|
||||
<section2 topic='<securitylabel/> schema' anchor='schema-sl'>
|
||||
<p>
|
||||
<code><![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<xs:schema
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||||
targetNamespace='urn:xmpp:sec-label:0'
|
||||
xmlns='urn:xmpp:sec-label:0'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:annotation>
|
||||
<xs:documentation>
|
||||
The protocol documented by this schema is defined in XEP-XXXX:
|
||||
http://www.xmpp.org/extensions/xep-XXXX.html
|
||||
</xs:documentation>
|
||||
</xs:annotation>
|
||||
|
||||
<xs:element name='securitylabel'>
|
||||
<xs:complexType>
|
||||
<xs:sequence>
|
||||
<xs:element ref='displaymarking' name='displaymarking'/>
|
||||
<xs:element ref='label' type='label'/>
|
||||
<xs:element ref='equivalentlabel' type='label'
|
||||
minOccurs='0' maxOccurs='unbounded'/>
|
||||
</xs:sequence>
|
||||
<xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
<xs:element name='displaymarking' type='xs:string'>
|
||||
<xs:attribute name='bgcolor' type='xs:string' use='optional'/>
|
||||
<xs:attribute name='fgcolor' type='xs:string' use='optional'/>
|
||||
</xs:element>
|
||||
|
||||
<xs:complexType name='label'/>
|
||||
</xs:schema>
|
||||
]]></code>
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='<esssecuritylabel/> schema' anchor='schema-ess'>
|
||||
<p>
|
||||
<code><![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<xs:schema
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||||
targetNamespace='urn:xmpp:sec-label:ess:0'
|
||||
xmlns='urn:xmpp:sec-label:ess:0'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:annotation>
|
||||
<xs:documentation>
|
||||
The protocol documented by this schema is defined in XEP-XXXX:
|
||||
http://www.xmpp.org/extensions/xep-XXXX.html
|
||||
</xs:documentation>
|
||||
</xs:annotation>
|
||||
|
||||
<xs:element name='esssecuritylabel' type=xs:string'/>
|
||||
</xs:schema>
|
||||
]]></code>
|
||||
</p>
|
||||
</section2>
|
||||
<section2 topic='Label Information schema' anchor='schema-info'>
|
||||
<p>
|
||||
<code><![CDATA[
|
||||
<?xml version='1.0' encoding='UTF-8'?>
|
||||
<xs:schema
|
||||
xmlns:xs='http://www.w3.org/2001/XMLSchema'
|
||||
targetNamespace='urn:xmpp:sec-label:info:0'
|
||||
xmlns='urn:xmpp:sec-label:info:0'
|
||||
elementFormDefault='qualified'>
|
||||
|
||||
<xs:annotation>
|
||||
<xs:documentation>
|
||||
The protocol documented by this schema is defined in XEP-XXXX:
|
||||
http://www.xmpp.org/extensions/xep-XXXX.html
|
||||
</xs:documentation>
|
||||
</xs:annotation>
|
||||
|
||||
<xs:element name='query'>
|
||||
<xs:complexType>
|
||||
<xs:sequence>
|
||||
<xs:element ref='labelcatalog' name='labelcatalog'
|
||||
minOccurs='0' maxOccurs='1'/>
|
||||
<!-- additional elements here -->
|
||||
<xs:sequence>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
<xs:element name='labelcatalog'>
|
||||
<xs:complexType>
|
||||
<xs:element ref='securitylabel' type='securitylabel'
|
||||
minOccurs='1' maxOccurs='unbounded'/>
|
||||
</xs:complexType>
|
||||
</xs:element>
|
||||
|
||||
<xs:complexType name='securitylabel'/>
|
||||
</xs:schema>
|
||||
]]></code>
|
||||
</p>
|
||||
</section2>
|
||||
</section1>
|
||||
</xep>
|
||||
Loading…
Reference in New Issue
Block a user