If an entity wishes to request the public keys of another entity and it cannot access the keys via Personal Eventing via Pubsub, then the entity MAY send an &IQ; of type 'get' to the other entity, containing an empty <pubkeys/> element qualified by the 'urn:xmpp:pubkey:0' namespace &VNOTE;.

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 Personal Eventing via Pubsub). 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 <keyinfo/> element MUST contain the 'jid' attribute of the public key even it is belongs to the same user.

If the receiving entity decides not to return the public keys, it MUST return an IQ error, which SHOULD be &unavailable; (to avoid divulging presence to unauthorized entities), but MAY be some other appropriate error, such as &forbidden; or ¬allowed;:

An entity MAY request one or more specific public keys by specifying their fingerprints (see Public Key Publication via PEP) as the content of <fingerprint/> child elements:

An entity can request the public keys of another entity from a third party using the 'jid' attribute of the <pubkeys/> element to specify the JID that the keys belong to:

If an entity wishes to send public keys to another entity then it MAY include them in a &MESSAGE; stanza. The entity MAY use the 'jid' attribute of the <keyinfo/> element to specify the JID that the keys belong to. If no 'jid' attribute is specified then the other entity SHOULD assume the keys belong to the sender of the stanza.

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.

The signing client SHOULD only accept signing requests from clients of the same user (sharing a bare JID) and it is RECOMMENDED to use a secure end-to-end communicate according to &xtls; or &xep0250; for serverless-messing.

Possible error conditions are that the signing client does not have the requested private key, the client is not authorized to request a signature, or that the signing client requires a secure connection and the request was issued over an insecure link.

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

• Each client has its own certificate. This certificate is most likely self-signed.

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

• Users SHOULD sign all their client certificates with their user certificate. To accomplish this in a userfriendly way, the user MAY log into the account with more than one client simultaneously. One client MUST have the user's private key or is trusted to issue a 'sign' request. The two clients open a secure connection between themselves based on TLS-SRP (see XTLS, Section 6). After a secure communicate between the two clients is established, the client without the user certificate requests its certificate to be signed. After that it can be uploaded to the pubsub node. The new client SHOULD also request the user certificate to be able to validate signatures for other clients.

• If a client opens a secure connection to another user based on TLS-SRP, it SHOULD request the user certificate of its peer. It will either sign the certificate itself or ask another client with the user's private key to do so. The friend's user certificate can then be uploaded to the pubsub node of the user (not the friend). The <keyinfo/> element SHOULD contain the bare JID of the friend in the 'jid' attribute.

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

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

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.

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

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

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.

The usage of secure end-to-end communication is RECOMMENDED for exchanging public keys without a pubsub service.

This document requires no interaction with &IANA;.