[Standards-JIG] clarifying certificate handling

Philipp Hancke fippo at goodadvice.pages.de
Sat Sep 16 09:10:14 UTC 2006

Peter Saint-Andre wrote:

> rfc3920bis may need to address certificate handling in a more complete
> manner than did RFC 3920. For example:
> 1. Section 5.1 of RFC 3920 says that an XMPP address must be represented
> in the id-on-xmppAddr OID but does not say if an XMPP address may be
> represented elsewhere in the certificate, specifically in the common
> name (CN), which seems to be a widespread practice right now since it is
> not easy to find a certification authority who will issue certificates
> with the id-on-xmppAddr OID.

Talking about a XMPP address which only consists of a domain
identifier... what about representation in the dNSName?
Using CN for this is deprecated afaik.

For clarification (and to have a more permanent reference):
If the address is an internationalized domain name, it has to be encoded 
(i.e. punycode) when included in the CN.
When included in the id-on-xmppAddr OID, the address must not be punycode.

> 2. RFC 3920 is silent about wildcards (e.g., "*.example.com"), which may
> be helpful in handling XMPP server components (ideally that would be
> done with a separate id-on-xmppAddr OID for each component, but that may
> not be realistic in the near term).

What about using rules similar to those defined in the second paragraph
of section of RFC 4513?


> Any other feedback on this issue?

One question... in a short and a long version.

Short version:
Does a failure applying rules #8 and #9 of §5.1 (rfc3920) result in a
TLS handshake failure or is this to be handled (rule #13) after the TLS
handshake has been completed successfully?

Long version:

In JEP 0178, S2S step 7:
    1. If certificate has been revoked, Server2 closes Server1's TCP

Is the connection closed because of a TLS handshake error or after
the handshake is complete?

What about handling of certificates which are expired, not yet valid,
etc? Is anything but the three cases mentioned in §14.2 of RFC 3920
* a certificate which could be sucessfully verified
* optionally, a certificate which is self-signed or signed by an
   unknown CA (depending on local security policy)
acceptable as a reason for not closing the connection after certificate
validation (e.g. considering TLS negotiation a failure and applying rule
#13 of §5.1).

What if my server connects to some other server and the remote server
presents a certificate which does not meet my expectations, even
though my server explicity included a 'to' attribute in the
stream header sent after starttls.
In other words, what is to be done when the expected identity does
not match?

For example:
* My server connects to conference.jabber.org, but the servers shows a
   certificate for jabber.org (see Matthias comments on JEP 0178,
   which are discussing this problem)

* My servers connects to jabber.org and the certificate only contains
   'Peter Saint-Andre' (in the CN). Yes, there are people who are using
   personal certificates for their jabber servers.

* I connect to jabber.org, but the certificate only contains jabber.eu
   (either in id-on-xmppAddr or CN). This is something frequently seen
   with servers doing virtual hosting.

The latter two are covered by the rule #8 of §5.1 (rfc 3920). But those 
rules lack a statement (red letters please!) about what to do if the 
hostname check fails - or do they assume TLS negotiation to be failed in 
which case rule #13 must be applied?


More information about the Standards mailing list