XEP-0258: Security Labels in XMPP

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.

WARNING: This Standards-Track document is Experimental. Publication as an XMPP Extension Protocol does not imply approval of this proposal by the XMPP Standards Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.

1. Introduction
2. Discovering Feature Support
3. Protocol
4. Label Information Discovery
5. Use in XMPP
    5.1. Use in Instant Messaging
    5.2. Use in Group Chat and Multi-User Chat
       5.2.1. Discovery
       5.2.2. Sending Messages
       5.2.3. Private Messages
       5.2.4. Invitations
       5.2.5. Changing Subject
    5.3. Use in Presence
    5.4. Use in PubSub
       5.4.1. Discovery
       5.4.2. Publishing items with Security Labels
6. Security Considerations
7. IANA Considerations
8. XMPP Registrar Considerations
9. XML Schemas
    9.1. <securitylabel/> schema
    9.2. <esssecuritylabel/> schema
    9.3. Label Information schema

Appendices
    A: Document Information
    B: Author Information
    C: Legal Notices
    D: Relation to XMPP
    E: Discussion Venue
    F: Requirements Conformance
    G: Notes
    H: Revision History

1. Introduction

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 [1] provides a discussion of security labels, clearances, and security policy.

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.

This document describes the use of security labels in XMPP [2]. 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 RFC 2634 [3]. ESS Security Labels are commonly used in conjunction with X.500 [4] clearances and either X.841 or SDN.801c [5] security policies.

    <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>

    <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>

The document details when security label metadata should or should not be provided, and how this metadata is to be processed.

2. Discovering Feature Support

If an entity supports the XMPP Security Label protocol, it MUST report that fact by including a service discovery feature of "urn:xmpp:sec-label:0" in response to a Service Discovery [7] 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.

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.

<iq type='get'
    from='user@example.com/Work'
    to='example.com'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<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>

3. Protocol

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.

        <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>

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.

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.

The <label/> and <equivalentlabel/> elements each require a type= attribute. The type= attribute indicates the type and encoding of the element's value. The attribute type= value 'ESS' indicates the label is the base64, as specified in RFC 4648 [8], encoding of the BER [9] encoding of the ASN.1 [10] eSSSecurityLabel type as specified in RFC 2634 [11]. Additional types may be registered (see 'XMPP Registrar Considerations').

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, fgcolor= and bgcolor=, whose values are HTML color strings (e.g., 'red' or '#ff0000'), for use in colorizing the display marking.

4. Label Information Discovery

It is RECOMMENDED the server publish security label information, including a catalog of labels, for use by clients.

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.

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.

To indicate the support for label information discovery, a server advertises the urn:xmpp:sec-label:info:0 feature.

<iq type='get'
    from='user@example.com/Work'
    to='example.com'
    id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<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>

<iq type='get'
    from='user@example.com/Work'
    to='example.com'
    id='catalog1'>
  <query xmlns='urn:xmpp:sec-label:info:0'/>
</iq>

<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>

5. Use in XMPP

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.

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.

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.

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.

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.

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.

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 Grant or Deny.

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.

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.

The term "effective clearance" and "effective label" refer, respectively, to the clearance and label provided as input to the ACDF.

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.

5.1 Use in Instant Messaging

A client may provide a <securitylabel/> element in any <message/> it sends.

5.2 Use in Group Chat and Multi-User Chat

A client may provide a <securitylabel/> element in <message/> stanzas.

5.2.1 Discovery

A server SHOULD provide a label feature and information discovery for the room.

Clients SHOULD discover label feature and information on a per room basis.

5.2.2 Sending Messages

Sending groupchat messages is similiar to sending normal messages, however their are a few differences.

Groupchat messages are addressed to the room. The room clearance must be suitable for the message label, else it should be rejected.

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.

5.2.3 Private Messages

Private messages are treated as discussed in the "Use in Instant Messaging" section. (Should private messages be restricted by room's configuration?)

5.2.4 Invitations

Invitations may be labeled.

5.2.5 Changing Subject

This section discusses semantics of <securitylabel/> elements contained in <message/> stanzas containing a <subject/> element.

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.

Upon change of the room's label, the server MUST immediately remove from the room all members whom are not cleared for that label.

In absence of a <securitylabel/> element, the label associated with the room is unchanged.

The room's label can also be changed through room configuration (to be discussed in later revision of this document).

5.3 Use in Presence

<securitylabel/> elements are not to appear in <presence/> stanzas. Server SHALL treat any <presence/> stanza that contains a <securitylabel/> as a protocol violation.

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.

5.4 Use in PubSub

5.4.1 Discovery

A server SHOULD provide a label feature and information discovery for each node.

Clients SHOULD discover label feature and information on a per node basis.

5.4.2 Publishing items with Security Labels

Each item may be individually labeled.

Example 10. Publishing with a Security Label

<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>

The service then notifies appropriately cleared subscribers.

Example 11. Publishing with a Security Label

<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>

6. Security Considerations

This document is all about authorization, a key aspect of security. Hence, security considerations are discussed through this document.

Security labels generally should be securely bound to the object. This may be accomplished through use of XMPP E2E [12] signing, or possibly other signing mechanisms.

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.

7. IANA Considerations

8. XMPP Registrar Considerations

It is requested the XMPP Registrar [14] add the extension's namespace and schema to appropriate XMPP registries.

It is requested the Registrar maintain a registry of label types. The type string "ESS" is reserved for use as described in this document.

9. XML Schemas

9.1 <securitylabel/> schema

    <?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>

9.2 <esssecuritylabel/> schema

    <?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>

9.3 Label Information schema

    <?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>

Appendices

Appendix A: Document Information

Appendix B: Author Information

Kurt Zeilenga

Email: Kurt.Zeilenga@Isode.COM
JabberID: Kurt.Zeilenga@Isode.COM

Appendix C: Legal Notices

Copyright

Permissions

Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.

Disclaimer of Warranty

## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. In no event shall the XMPP Standards Foundation or the authors of this Specification be liable for any claim, damages, or other liability, whether in an action of contract, tort, or otherwise, arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification. ##

Limitation of Liability

In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising out of the use or inability to use the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.

IPR Conformance

This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which may be found at <http://xmpp.org/extensions/ipr-policy.shtml> or obtained by writing to XSF, P.O. Box 1641, Denver, CO 80201 USA).

Appendix D: Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Appendix F: Requirements Conformance

The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".

Appendix G: Notes

1. X.841: Security techniques - Security information objects for access control <http://www.itu.int/rec/T-REC-X.841-200010-I/en>.

2. Extensible Messaging and Presence Protocol (XMPP) <http://xmpp.org/>.

3. RFC 2634: Enhanced Security Services for S/MIME <http://tools.ietf.org/html/rfc2634>.

4. X.500: The Directory: Overview of concepts, models and service <http://www.itu.int/rec/T-REC-X.500-200102-I/en>.

5. SDN.801c: Access Control Concept and Mechanism, US National Security Agency, Revision C, 12 May 1999.

6. Common Information Sharing Standard for Information Security Marking: XML Implementation, Office of the Director of National Intelligence, Release 2.0.3, 15 February 2006.

7. XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.

8. RFC 4648: The Base16, Base32, and Base64 Data Encodings <http://tools.ietf.org/html/rfc4648>.

9. X.690: ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) <http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf>.

10. X.680: Abstract Syntax Notation One (ASN.1): Specification of basic notation <http:://www.itu.int/ITU-T/studygroups/com17/languages/X.680-0207.pdf>.

11. RFC 2634: Enhanced Security Services for S/MIME <http://tools.ietf.org/html/rfc2634>.

12. RFC 3923: End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) <http://tools.ietf.org/html/rfc3923>.

13. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

14. The XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <http://xmpp.org/registrar/>.