[Standards-JIG] clarifying certificate handling

[Peter Saint-Andre]

My apologies for the seriously delayed reply.

Philipp Hancke wrote:
> 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.

Sure, I have no objections to including the FQDN (or IP address) in the 
dNSName rather than the CN. But really we ought to be doing the right 
thing and using the XMPP OID.

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

That's right.

>> 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 3.1.3.1. of RFC 4513?

I was not familiar with those rules. Something like that approach would 
indeed be helpful. I'll see how we can adapt that to XMPP.

>> 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?

The distinction between handshake failure and post-handshake failure is 
not clear to me. We clarified the <failure/> vs. <proceed/> cases a bit 
here:

http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-00.html#tls-narr

I think that if the receiving entity considers the presented certificate 
to be unacceptable, the result would be TLS failure (rule #13).

> Long version:
> 
> In JEP 0178, S2S step 7:
>    1. If certificate has been revoked, Server2 closes Server1's TCP
>       connection.
> 
> 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? 

Yes we need to more clearly describe all the possible cases.

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

If we do wildcards, then the XMPP OID (or dNSName) could be *.jabber.org 
(another option: multiple XMPP OIDs, one for the home domain and one for 
each subdomain).

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

That seems like a bad idea. But we're not supposed to be checking the CN 
or dNSName anyway, we're supposed to be checking the XMPP OID.

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

Create a cert with all of the virtual hosts. Yes this is a pain if you 
have lots of virtual hosts, but it's not that hard to generate a new CSR 
and get a new cert.

> 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?

I think that is what we assumed in RFC 3920.

Peter

-- 
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20061108/f8141be2/smime.bin