Use keyinfo from updated XEP-0189 version 0.8

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2228 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Dirk Meyer 2008-09-08 19:29:55 +00:00
parent 1d73af0bc1
commit e1cab24b20
1 changed files with 47 additions and 61 deletions

View File

@ -27,6 +27,12 @@
<email>dmeyer@tzi.de</email>
<jid>dmeyer@jabber.org</jid>
</author>
<revision>
<version>0.2</version>
<date>2008-09-08</date>
<initials>dm</initials>
<remark><p>Use keyinfo from updated XEP-0189 version 0.8</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2008-09-03</date>
@ -76,75 +82,61 @@
<section1 topic='Protocol'>
<section2 topic='Extension Negotiation'>
<p>The main problem is what TLS extension to choose. It makes no sense to use OpenPGP if the clients have no trust-relationship or SRP if the users did not exchange a secret. To resolve this problem a client describes its extension in an offer to the peer. The offer lists all supported authentication methods including additional parameter like the certificate that will be used. &xep0189; can be used to look-up the keys or the client can look in its OpenPGP keyring. A client could also know a certificate or password from an earlier connection.</p>
<p>The main problem is what TLS extension to choose. It makes no sense to use OpenPGP if the clients have no trust-relationship or SRP if the users did not exchange a secret. To resolve this problem a client describes its extension in an offer to the peer. The offer lists all supported authentication methods including additional parameter like the certificate that will be used. &xep0189; can be used to look-up the keys or the client can look in its OpenPGP keyring. A client could also know a certificate or password from an earlier connection. The following example contains the X.509 certificate and the OpenPGP key from the examples in XEP-0189.</p>
<example caption='Client Offer Supporting X.509, OpenPGP and SRP'><![CDATA[
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<x509>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>julietDSAkey1hash</KeyName>
<X509Data>
<X509IssuerSerial>
<X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM, L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
<X509SerialNumber>12345678</X509SerialNumber>
</X509IssuerSerial>
<X509SKI>31d97bd7</X509SKI>
<X509SubjectName>Subject of Certificate B</X509SubjectName>
<X509Certificate>...</X509Certificate>
<X509Certificate>...</X509Certificate>
<X509Certificate>...</X509Certificate>
</X509Data>
</KeyInfo>
</x509>
<openpgp>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
<KeyName>julietPGPkey1hash</KeyName>
<PGPData>
<PGPKeyId>...</PGPKeyId>
<PGPKeyPacket>...</PGPKeyPacket>
</PGPData>
</KeyInfo>
</openpgp>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>428b1358a286430f628da23fb33ddaf6e474f5c5</name>
</keyinfo>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>89d099a3428481cc63fe3fa44e7df2d002b4ce44</name>
</keyinfo>
<srp/>
</offer>
]]></example>
<p><em>Authors Note: XMLSIG is very complicated but is was chosen because XEP-0189 also uses this namespace. If a future version of XEP-0189 uses the ASCII representation of keys this document must be adjusted.</em>
</p>
<p>Note: the keyinfo only contains the name and not the public key itself. If the peer does not know the key, it can not determine if it is an X.509 certificate or OpenPGP key. This does not matter because if the client does not know the key, it can not use it for secure communication.</p>
<p>If both clients know the offer of the other, they can determine what method to use to complete the TLS handshake without an error. Note: this information will be exchanged over an insecure communication channel and may be forged. If the information is altered it will be detected when doing the TLS handshake.</p>
</section2>
<section2 topic='Extension Probing'>
<p>I client MAY want to know the supported extension of the peer before opening the client-to-client stream. For serverless messaging this is not possible but for server based communication a client can exchange offers with the peer without using Jingle to open a client-to-client stream. The methods the peer supports depend on additional information from the client. Depending on the X.509 certificate of the client the peer may not support this extension because it can not verify the certificate. To receive the offer from the peer the client sends an IQ stanza with its own offer.</p>
<p>I client MAY want to know the supported extensions of the peer before opening the client-to-client stream. For serverless messaging this is not possible but for server based communication a client can exchange offers with the peer without using Jingle to open a client-to-client stream. The methods the peer supports depend on additional information from the client. Depending on the X.509 certificate of the client the peer may not support this extension because it can not verify the certificate. To receive the offer from the peer the client sends an IQ stanza with its own offer.</p>
<example caption='Client Sends Extension Probing IQ'><![CDATA[
<iq type='get'
from='romeo@montague.net/b345687ba7607d3ddf401a0257464843a0a1c0b7'
to='juliet@capulet.com/da39a3ee5e6b4b0d3255bfef95601890afd80709'
id='info'>
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<x509>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
...
</KeyInfo>
</x509>
<openpgp>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
...
</KeyInfo>
</openpgp>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>RomeoX509CertificateHash</name>
</keyinfo>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>RomeoOpenPGPFingerprint</name>
</keyinfo>
<srp/>
</offer>
</iq>
]]></example>
<p>The receiver sends its offer back to the client. A client MAY support X.509 certificates it can not verify to be verified later. In that case the X.509 information MUST be marked as insecure. In the following example the receiver supports SRP and X.509, but can not verify the certificate from the offer. OpenPGP is either not supported or skipped because the key can not be verified.</p>
<p>The receiver sends its offer back to the client. It MUST only send the keyinfo elements that match a keyinfo of the offer. E.g. if the responder does not find an X.509 certificate it can verify in the offer it MUST NOT send its own X.509 certificate. In the following example the receiver supports SRP and X.509. OpenPGP is either not supported or skipped because the key can not be verified.</p>
<example caption='Peer Sends Extension Probing Result'><![CDATA[
<iq type='result'
from='juliet@capulet.com/da39a3ee5e6b4b0d3255bfef95601890afd80709'
to='romeo@montague.net/b345687ba7607d3ddf401a0257464843a0a1c0b7'
id='info'>
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<x509 insecure='true'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
...
</KeyInfo>
</x509>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>JulietX509CertificateHash</name>
</keyinfo>
<srp/>
</offer>
</iq>
]]></example>
<p>A client MAY support X.509 certificates it can not verify to be verified later. In that case it adds the authentication method &lt;insecure&gt;. In the following example the receiver supports SRP and X.509, but can not verify the certificate from the offer.</p>
<example caption='Peer Sends Extension Probing Result'><![CDATA[
<iq type='result'
from='juliet@capulet.com/da39a3ee5e6b4b0d3255bfef95601890afd80709'
to='romeo@montague.net/b345687ba7607d3ddf401a0257464843a0a1c0b7'
id='info'>
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<insecure/>
<srp/>
</offer>
</iq>
@ -159,16 +151,12 @@
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<x509>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
...
</KeyInfo>
</x509>
<openpgp>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
...
</KeyInfo>
</openpgp>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>RecipientX509CertificateHash</name>
</keyinfo>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>RecipientOpenPGPFingerprint</name>
</keyinfo>
<srp/>
</offer>
</starttls>
@ -177,15 +165,13 @@
<p>If the recipient does not supply this additional information it is assumed that it does not support this extension and the TLS handshake continues as described in the XMPP core. If and how the users trust each other in that case is out of the scope of this document.</p>
</section3>
<section3 topic='Choosing the STARTTLS Feature'>
<p>When the initiator starts the TLS feature it also enhances the STARTTLS with its supported extensions and additional key information based on the recipient's offer. In the following example the initiator has no OpenPGP key and can not verify the recipient's X.509 certificate. It also supports SRP.</p>
<p>When the initiator starts the TLS feature it also enhances the STARTTLS with its supported extensions and additional key information based on the recipient's offer. In the following example the initiator can only verify one keyinfo. It also supports SRP.</p>
<example caption='Initiator Starts TLS Feature'><![CDATA[
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<offer xmlns='urn:xmpp:tmp:c2ctls'>
<x509 insecure='true'>
<KeyInfo xmlns='http://www.w3.org/2000/09/xmldsig#'>
...
</KeyInfo>
</x509>
<keyinfo xmlns='urn:xmpp:tmp:pubkey'>
<name>InitiatorX509CertificateHash</name>
</keyinfo>
<srp/>
</offer>
</starttls>