[jdev] cert handling in xmpp *client* implementations

[Peter Saint-Andre]

-----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-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20060524/6354dede/attachment-0002.bin>