git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2842 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2009-03-08 21:13:01 +00:00
parent 6ed1993ddc
commit 1de225472c
1 changed files with 59 additions and 52 deletions

View File

@ -26,9 +26,9 @@
&dmeyer;
<revision>
<version>0.9</version>
<date>2009-03-07</date>
<initials>dm</initials>
<remark><p>Require to specify an algorithm for elements with hashes; remove fingerprint in &lt;keyinfo/&gt;; add sign request; add guidelines for key management; and improve examples.</p></remark>
<date>2009-03-08</date>
<initials>dm/psa</initials>
<remark><p>Required specification of an algorithm for elements with hashes; removed fingerprint in &lt;keyinfo/&gt;; added sign request; added guidelines for key management; improved examples; changed namespace from urn:xmpp:tmp:pubkey to urn:xmpp:pubkey:0.</p></remark>
</revision>
<revision>
<version>0.8</version>
@ -86,15 +86,15 @@
<li>Querying another entity for its public keys.</li>
<li>Sign one key with another</li>
</ul>
<p>An entity MAY have multiple public keys with different formats, signatures, algorithms, strengths and expiry dates. Each client used by a user may use different keys. Guidelines how to manage different public keys in included in this document.</p>
<p>An entity MAY have multiple public keys with different formats, signatures, algorithms, strengths and expiry dates. Each client used by a user MAY use different keys. Guidelines how to manage different public keys in included in this document.</p>
</section1>
<section1 topic='The KeyInfo Format' anchor='keyinfo'>
<p>This document does not use the 'http://www.w3.org/2000/09/xmldsig#' namespace as specified in &w3xmlsig; because it is too complicated and the complexity is not needed for this use case. The &lt;keyinfo/&gt; element defined in the 'urn:xmpp:tmp:pubkey' namespace is based on the ASCII output most cryptographic libraries support. It has two parts: the public key data and signatures from other keys (optional). The optional argument 'jid' SHOULD be set if the X.509 certificate or OpenPGP key does not belong to the user providing it to another.</p>
<p>This document does not use the 'http://www.w3.org/2000/09/xmldsig#' namespace as specified in &w3xmlsig; because it is too complicated and the complexity is not needed for this use case. The &lt;keyinfo/&gt; element defined in the 'urn:xmpp:pubkey:0' namespace &VNOTE; is based on the ASCII output most cryptographic libraries support. It has two parts: the public key data and signatures from other keys (optional). The optional argument 'jid' SHOULD be set if the X.509 certificate or OpenPGP key does not belong to the user providing it to another.</p>
<section2 topic='X.509 Certificate' anchor='x509'>
<p>The public key data is the X.509 certificate in DER encoding. To be included in an XML stream the data is Base64 encoded.</p>
<example caption='X.509 Certificate'><![CDATA[
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<x509cert>
MIICCTCCAXKgAwIBAgIJALhU0Id6xxwQMA0GCSqGSIb3DQEBBQUAMA4xDDAKBgNV
BAMTA2ZvbzAeFw0wNzEyMjgyMDA1MTRaFw0wODEyMjcyMDA1MTRaMA4xDDAKBgNV
@ -112,9 +112,9 @@
]]></example>
</section2>
<section2 topic='OpenPGP' anchor='openpgp'>
<p>The public key data is the OpenPGP public key (&rfc4880;) using binary output. Like X.509 certificates the data must be Base64 encoded to fit in an XML stream.</p>
<p>The public key data is the OpenPGP public key (&rfc4880;) using binary output. Like X.509 certificates the data MUST be Base64 encoded to fit in an XML stream.</p>
<example caption='OpenPGP Public Key'><![CDATA[
<keyinfo xmlns='urn:xmpp:tmp:pubkey'
<keyinfo xmlns='urn:xmpp:pubkey:0'
jid='romeo@montague.net'>
<pgpdata>
mQGiBDsKPy8RBACG1vVC8+5jMbtr8YUSfL2ciIu/Zb7/dDhwFd4iFlH7BIEt3RjR
@ -129,12 +129,12 @@
]]></example>
</section2>
<section2 topic='Signatures' anchor='signature'>
<p>Besides the data, a key can have one or more signatures. A signature can be used to sign an X.509 certificate with an OpenPGP key or the other way around. This makes it possible to verify a self-signed X.509 certificate with the OpenPGP web-of-trust. A second use case is the concept of user and client keys. A user may choose to use a different X.509 certificates for each client for &xtls; or &saslext;. All these client key can be signed by a user key. Once the user key is known, all clients can be verified. This XMPP based approach makes it possible to use self-signed certificates without setting up a CA (see <link url='#management'>Key Management Guidelines for Secure End-on-End Communication</link>).</p>
<p>Besides the data, a key can have one or more signatures. A signature can be used to sign an X.509 certificate with an OpenPGP key or the other way around. This makes it possible to verify a self-signed X.509 certificate with the OpenPGP web-of-trust. A second use case is the concept of user and client keys. A user MAY choose to use a different X.509 certificates for each client for &xtls; or &saslext;. All these client key can be signed by a user key. Once the user key is known, all clients can be verified. This XMPP based approach makes it possible to use self-signed certificates without setting up a CA (see <link url='#management'>Key Management Guidelines for Secure End-to-End Communication</link>).</p>
<p>The signature has an issuer and the signature data. The issuer contains the fingerprint of the key that was used to create the signature. An optional argument 'jid' SHOULD be set if the issuer has a different base JID than the key to sign. This makes it possible to find the issuer key using PEP (see <link url='#pub'>Public Key Publication via PEP</link>).</p>
<p>While OpenPGP defines how to sign a string, X.509 does not specify the hash algorithm. For X.509 the signature data MUST contain an attribute what hash and sign algorithms were used. This document only defines 'RSA-SHA1' at this time. To make it easier to use standard cryptographic libraries the hash must contain the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1. See XML-SIG section 6.4.2 how to hash and sign a string using RSA-SHA1. In most cases the cryptographic library will automatically take care of this. The data to sign is the X.509 certificate in DER encoding or the OpenPGP binary string of the fingerprint (the provided key data without Base64 encoding).</p>
<p>While OpenPGP defines how to sign a string, X.509 does not specify the hash algorithm. For X.509 the signature data MUST contain an attribute what hash and sign algorithms were used. This document only defines 'RSA-SHA1' at this time. To make it easier to use standard cryptographic libraries the hash MUST contain the ASN.1 BER SHA1 algorithm designator prefix required in PKCS1. See XML-SIG section 6.4.2 how to hash and sign a string using RSA-SHA1. In most cases the cryptographic library will automatically take care of this. The data to sign is the X.509 certificate in DER encoding or the OpenPGP binary string of the fingerprint (the provided key data without Base64 encoding).</p>
<p>The next example contains an X.509 certificate signed by the key defined in the first example.</p>
<example caption='X.509 Certificate with external Signature'><![CDATA[
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<x509cert>
MIICXDCCAcWgAwIBAgIJAKBfLqul2lj3MA0GCSqGSIb3DQEBBQUAMCkxJzAlBgNV
BAMUHmRtZXllckBqYWJiZXIuY29tXDJmdGVzdGNsaWVudDAeFw0wODA5MDYxOTI0
@ -166,7 +166,7 @@
<section1 topic='Public Key Publication via PEP' anchor='pub'>
<p>An entity SHOULD follow the best practices defined in &xep0222; to publish its long-term public keys via its own server. Processes for doing so are described in the following sections.</p>
<section2 topic='Creating the Node' anchor='pub-create'>
<p>If the pubkeys PEP node does not exist already then the entity must create it. The node MUST have a NodeID of "urn:xmpp:tmp:pubkey" &NSNOTE;.</p>
<p>If the pubkeys PEP node does not exist already then the entity needs to create it. The node MUST have a NodeID of "urn:xmpp:pubkey:0" &VNOTE;.</p>
<p>The node MUST be configured as follows:</p>
<ul>
<li>Items published to the node are persistent (this is done by setting the "persist_items" option to true).</li>
@ -178,7 +178,7 @@
id='hfgt54ew'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<create node='urn:xmpp:tmp:pubkey'/>
<create node='urn:xmpp:pubkey:0'/>
<configure>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE' type='hidden'>
@ -207,9 +207,9 @@
id='hfgt54ed'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:tmp:pubkey'>
<publish node='urn:xmpp:pubkey:0'>
<item id='Juliet-PGP-Key-Hash'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<openpgp>PKP-Key-Base64-encoded</openpgp>
</keyinfo>
</item>
@ -244,9 +244,9 @@
id='gfy54e66'
type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<publish node='urn:xmpp:tmp:pubkey'>
<publish node='urn:xmpp:pubkey:0'>
<item id='Juliet-X509-Cert-Hash'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<x509cert>
Certificate-in-DER-format-Base64-encoded
</x509cert>
@ -266,9 +266,9 @@
<example caption='Pubsub Service Sends Notification with Key'><![CDATA[
<message to='romeo@montague.net/garden' from='juliet@capulet.com' type='headline'>
<event xmlns='http://jabber.org/protocol/pubsub#event'>
<items node='urn:xmpp:tmp:pubkey'>
<items node='urn:xmpp:pubkey:0'>
<item id='Juliet-X509-Cert-Hash'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<x509cert>
Certificate-in-DER-format-Base64-encoded
</x509cert>
@ -298,7 +298,7 @@
id='hfgtredy'
type='get'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:tmp:pubkey'/>
<items node='urn:xmpp:pubkey:0'/>
</pubsub>
</iq>
]]></example>
@ -308,16 +308,16 @@
id='hfgtredy'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:tmp:pubkey'>
<items node='urn:xmpp:pubkey:0'>
<item id='Juliet-PGP-Key-Hash'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<pgpdata>
PKP-Key-Base64-encoded
</pgpdata>
</keyinfo>
</item>
<item id='Juliet-X509-Cert-Hash'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<x509cert>
Certificate-in-DER-format-Base64-encoded
</x509cert>
@ -333,7 +333,7 @@
id='gf654ewq'
type='get'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:tmp:pubkey'>
<items node='urn:xmpp:pubkey:0'>
<item id='Juliet-X509-Cert-Hash'/>
</items>
</pubsub>
@ -345,9 +345,9 @@
id='gf654ewq'
type='result'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:tmp:pubkey'>
<items node='urn:xmpp:pubkey:0'>
<item id='Juliet-X509-Cert-Hash'>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<keyinfo xmlns='urn:xmpp:pubkey:0'>
<x509cert>
Certificate-in-DER-format-Base64-encoded
</x509cert>
@ -360,13 +360,13 @@
</section1>
<section1 topic='Requesting Public Keys Directly From Another Entity' anchor='request'>
<p>If an entity wishes to request the public keys of another entity and it cannot access the keys via <cite>Personal Eventing via Pubsub</cite>, then the entity MAY send an &IQ; of type 'get' to the other entity, containing an empty &lt;pubkeys/&gt; element qualified by the 'urn:xmpp:tmp:pubkey' namespace &NSNOTE;.</p>
<p>If an entity wishes to request the public keys of another entity and it cannot access the keys via <cite>Personal Eventing via Pubsub</cite>, then the entity MAY send an &IQ; of type 'get' to the other entity, containing an empty &lt;pubkeys/&gt; element qualified by the 'urn:xmpp:pubkey:0' namespace &VNOTE;.</p>
<example caption='Public keys request'><![CDATA[
<iq from='romeo@montague.net/garden'
to='juliet@capulet.com/balcony'
id='hfgt654s'
type='get'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'/>
<pubkeys xmlns='urn:xmpp:pubkey:0'/>
</iq>
]]></example>
<p>The other entity MUST make a careful access control decision before returning only those public keys for which it holds the corresponding private key (not necessarily the full list of keys being published via <cite>Personal Eventing via Pubsub</cite>). The client MAY also include the public key which was used to sign its keys even if it does not hold the private key. In that case the &lt;keyinfo/&gt; element MUST contain the 'jid' attribute of the public key even it is belongs to the same user.</p>
@ -375,7 +375,7 @@
to='romeo@montague.net/garden'
id='hfgt654s'
type='result'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'>
<pubkeys xmlns='urn:xmpp:pubkey:0'>
<keyinfo>
<x509cert>Juliet-X509-Client-Cert</x509cert>
<signature>
@ -400,7 +400,7 @@
to='romeo@montague.net/garden'
id='hfgt654s'
type='error'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'/>
<pubkeys xmlns='urn:xmpp:pubkey:0'/>
<error code='503' type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
@ -412,7 +412,7 @@
to='romeo@montague.net/garden'
id='54fgtyre'
type='get'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'>
<pubkeys xmlns='urn:xmpp:pubkey:0'>
<fingerprint algo='sha1'>Juliet-X509-Cert-Hash</fingerprint>
<fingerprint>Juliet-PKP-Hash</fingerprint>
</pubkeys>
@ -423,7 +423,7 @@
to='romeo@montague.net/garden'
id='54fgtyre'
type='result'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'>
<pubkeys xmlns='urn:xmpp:pubkey:0'>
<keyinfo>
<x509cert>
Certificate-in-DER-format-Base64-encoded
@ -440,13 +440,13 @@
</section1>
<section1 topic='Requesting Public Keys Directly From a Third Party' anchor='third'>
<p>An entity may request the public keys of another entity from a third party using the 'jid' attribute of the &lt;pubkeys/&gt; element to specify the JID that the keys belong to:</p>
<p>An entity can request the public keys of another entity from a third party using the 'jid' attribute of the &lt;pubkeys/&gt; element to specify the JID that the keys belong to:</p>
<example caption='Requesting public keys from a third-party'><![CDATA[
<iq from='juliet@capulet.com/balcony'
to='romeo@montague.net/garden'
id='gftrse3w'
type='get'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey' jid='benvolio@montague.net'/>
<pubkeys xmlns='urn:xmpp:pubkey:0' jid='benvolio@montague.net'/>
</iq>
]]></example>
<example caption='Third-party responds with public keys'><![CDATA[
@ -454,7 +454,7 @@
to='juliet@capulet.com/balcony'
id='gftrse3w'
type='result'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey' jid='benvolio@montague.net'>
<pubkeys xmlns='urn:xmpp:pubkey:0' jid='benvolio@montague.net'>
<keyinfo jid='benvolio@montague.net'>
...
</keyinfo>
@ -469,7 +469,7 @@
to='juliet@capulet.com/balcony'
id='gftrse3w'
type='error'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey' jid='benvolio@montague.net'/>
<pubkeys xmlns='urn:xmpp:pubkey:0' jid='benvolio@montague.net'/>
<error code='404' type='cancel'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
@ -482,7 +482,7 @@
<example caption='Sending public keys'><![CDATA[
<message from='romeo@montague.net/garden'
to='juliet@capulet.com/balcony'>
<pubkeys xmlns='urn:xmpp:tmp:pubkey'>
<pubkeys xmlns='urn:xmpp:pubkey:0'>
<keyinfo>
...
</keyinfo>
@ -495,13 +495,13 @@
</section1>
<section1 topic='Signing Public Keys' anchor='sign'>
<p>A client may want to add another client's X.509 certificate to the pubsub node or send it directly to another client, and the client wants that certificate signed with the user's private key. If the client is not in possession of the private key, it can send a 'sign' request to another client of the user having access to the certificate.</p>
<p>A client can add another client's X.509 certificate to the pubsub node or send it directly to another client, and the client wants that certificate signed with the user's private key. If the client is not in possession of the private key, it can send a 'sign' request to another client of the user having access to the certificate.</p>
<example caption='Client sends Signing Request'><![CDATA[
<iq from='juliet@capulet.com/chamber'
to='juliet@capulet.com/balcony'
type='set'
id='hft65du8'>
<sign node='urn:xmpp:tmp:pubkey'>
<sign node='urn:xmpp:pubkey:0'>
<issuer algo='sha1'>UserCertificateHash</issuer>
<pubkeys>
<keyinfo>
@ -551,8 +551,8 @@
]]></example>
</section1>
<section1 topic='Key Management Guidelines for Secure End-on-End Communication' anchor='management'>
<p>Different X.509 certificates for each client, a user X.509 certificate to sign client certificates, and secure communication with friends make the scenario quite confusing. This section provides guidelines how to manage the different public keys and what kind of key to sign. The desired use case is to manage for secure end-on-end communication as defined by <cite>XTLS</cite>.</p>
<section1 topic='Key Management Guidelines for Secure End-to-End Communication' anchor='management'>
<p>Different X.509 certificates for each client, a user X.509 certificate to sign client certificates, and secure communication with friends make the scenario quite confusing. This section provides guidelines how to manage the different public keys and what kind of key to sign. The desired use case is to manage for secure end-to-end communication as defined by <cite>XTLS</cite>.</p>
<ul>
<li><p>Each client has its own certificate. This certificate is most likely self-signed.</p></li>
<li><p>The user has a user certificate and one or more clients can have access to the user's private key to sign certificates. To bootstrap the system, one client generates the certificate on behalf of the user.</p></li>
@ -561,11 +561,11 @@
<li><p>If a client wants to open a secure end-to-end connection to another client of the same user, it SHOULD check the pubsub node for the certificate. The certificate MUST be signed by the user's certificate.</p></li>
<li><p>If a client wants to open a secure end-to-end connection to a client of another user, it SHOULD check the its pubsub node for the friend's user certificate and the friend's pubsub node for the client certificate. The friend's user certificate MUST be signed by its own user certificate and the clients certificate MUST be signed by the friend's user certificate.</p></li>
</ul>
<p>If a user possess an OpenPGP key, the user certificate SHOULD be signed with that key. This allows another users to verify the certificate based on the OpenPGP web-of-trust, and two users may be able to bootstrap a secure communicate without the usage of TLS-SRP.</p>
<p>If a user possess an OpenPGP key, the user certificate SHOULD be signed with that key. This allows another users to verify the certificate based on the OpenPGP web-of-trust, and two users might be able to bootstrap a secure communicate without the usage of TLS-SRP.</p>
</section1>
<section1 topic='Determining Support' anchor='support'>
<p>If an entity can sign certificates or OpenPGP keys with the user's private key, it MUST report that by including a service discovery feature of "urn:xmpp:tmp:pubkey:sign" in response to disco#info requests &NSNOTE;.</p>
<p>If an entity can sign certificates or OpenPGP keys with the user's private key, it MUST report that by including a service discovery feature of "urn:xmpp:pubkey:0:sign" in response to disco#info requests &VNOTE;.</p>
<example caption="Initial Service Discovery Information Request"><![CDATA[
<iq from='juliet@capulet.com/chamber'
to='juliet@capulet.com/balcony'
@ -580,8 +580,8 @@
id='gfd68yt4'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:tmp:pubkey'/>
<feature var='urn:xmpp:tmp:pubkey:sign'/>
<feature var='urn:xmpp:pubkey:0'/>
<feature var='urn:xmpp:pubkey:0:sign'/>
</query>
</iq>
]]></example>
@ -589,7 +589,7 @@
<section1 topic='Security Considerations' anchor='security'>
<p>The reliable association between a user or entity and its public keys is beyond the scope of this document. However, each client SHOULD maintain its own secure library of the public keys (or the "fingerprints" of the keys) it associates with other users (not necessarily JIDs).</p>
<p>Whenever public keys are published an identity is typically associated with a JID. Although the public keys are public information, it may be critically important for the user of the JID to keep his identity secret from all but a few specified people. Implementors MUST take great care to ensure that the identity of the user of a JID is never divulged to anyone except the entities who have been permitted by the user to access the public key.</p>
<p>Whenever public keys are published an identity is typically associated with a JID. Although the public keys are public information, it can be critically important for the user of the JID to keep his identity secret from all but a few specified people. Implementors MUST take great care to ensure that the identity of the user of a JID is never divulged to anyone except the entities who have been permitted by the user to access the public key.</p>
<p>The usage of secure end-to-end communication is RECOMMENDED for exchanging public keys without a pubsub service.</p>
</section1>
@ -598,14 +598,21 @@
</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:pubkey"; upon advancement of this specification, the &REGISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.</p>
<section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>This specification defines the following XML namespace:</p>
<ul>
<li>urn:xmpp:pubkey:0</li>
</ul>
<p>Upon advancement of this specification to a status of Draft, the &REGISTRAR; shall add this namespace in the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
</section2>
<section2 topic='Protocol Versioning' anchor='registrar-versioning'>
&NSVER;
</section2>
<section2 topic='Service Discovery Features' anchor='registrar-features'>
<p>The XMPP Registrar shall include the following features in its registry of service discovery features (see &DISCOFEATURES;), where the string "urn:xmpp:tmp:pubkey" shall be replaced with the URN issued by the XMPP Registrar:</p>
<p>The XMPP Registrar shall include the following features in its registry of service discovery features (see &DISCOFEATURES;), where the string "urn:xmpp:pubkey:0" shall be replaced with the URN issued by the XMPP Registrar:</p>
<code><![CDATA[
<var>
<name>urn:xmpp:tmp:pubkey:sign</name>
<name>urn:xmpp:pubkey:0:sign</name>
<desc>The client is in possession of the user's private client to sign certificates.</desc>
<doc>XEP-0189</doc>
</var>
@ -619,8 +626,8 @@
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:tmp:pubkey'
xmlns='urn:xmpp:tmp:pubkey'
targetNamespace='urn:xmpp:pubkey:0'
xmlns='urn:xmpp:pubkey:0'
elementFormDefault='qualified'>
<xs:element name='pubkeys'>