-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Peter Saint-Andre wrote: > Speaking of cert handling, how do jabber/xmpp clients currently handle > server certificates? One approach would be to use the existing Mozilla > NSS store, which is on Linux distros and even many Windows distros. But > it would be good for clients to "do the right thing" in handling the > certs for jabber/xmpp servers (I guess that would mean following best > practices derived from the browser and email client markets). > > Perhaps it would be good to document such best practices? Section 14.2 > of RFC 3920 talks about this, but the text there may be a bit opaque for > many client developers...
BTW, Section 14.2 saith:
******
14.2. Certificate Validation
When an XMPP peer communicates with another peer securely, it MUST
validate the peer's certificate. There are three possible cases:
Case #1: The peer contains an End Entity certificate which appears to
be certified by a chain of certificates terminating in a trust
anchor (as described in Section 6.1 of [X509]).
Case #2: The peer certificate is certified by a Certificate Authority
not known to the validating peer.
Case #3: The peer certificate is self-signed.
In Case #1, the validating peer MUST do one of two things:
1. Verify the peer certificate according to the rules of [X509].
The certificate SHOULD then be checked against the expected
identity of the peer following the rules described in [HTTP-TLS],
except that a subjectAltName extension of type "xmpp" MUST be
used as the identity if present. If one of these checks fails,
user-oriented clients MUST either notify the user (clients MAY
give the user the opportunity to continue with the connection in
any case) or terminate the connection with a bad certificate
error. Automated clients SHOULD terminate the connection (with a
bad certificate error) and log the error to an appropriate audit
log. Automated clients MAY provide a configuration setting that
disables this check, but MUST provide a setting that enables it.
2. The peer SHOULD show the certificate to a user for approval,
including the entire certificate chain. The peer MUST cache the
certificate (or some non-forgeable representation such as a
hash). In future connections, the peer MUST verify that the same
certificate was presented and MUST notify the user if it has
changed.
In Case #2 and Case #3, implementations SHOULD act as in (2) above.
******
/psa
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFEdNV4NF1RSzyt3NURAm0aAKCXf4OUki0XS6FQswR4/Za3yd+WOgCfWBZb
fFk9N+8alg3Bf7GOJvB0faA=
=2qkD
-----END PGP SIGNATURE-----
smime.p7s
Description: S/MIME Cryptographic Signature
