Daniel Pocock wrote:
On 03/03/12 12:46, Michael Ströder wrote:Using DNS SRV is simply not specified regarding SSL/TLS. There's no way to map a naming context to a server cert despite your local security policy says your DNS is trusted by some other means.A hostname can be a reference identity But a reference identity is not always a hostname. It depends on the client configuration.The naming context (aka search root) cannot be a reference identity in the context of SSL/TLS. Period.The RFC does not say that.
It does not have to say that.
Neither does it state that an implementation should support the concept. It appears to leave the implementor some discretion about their choice of reference identity.
Yes.
Feel free to write an Internet draft updating TLS-RFCs and RFC 2782. This could specify how a naming context is compared to some information in a subjectAltName extension since there's no standard saying something about this yet. A suitable GeneralName choice would be directoryName.It is already in RFC 6125: http://tools.ietf.org/html/rfc6125#section-6.2
I can't see any language which clearly defines rules how to derive the reference identity from a LDAP naming context. Just poiting out that it is no problem with SIP is not sufficient.
Many a mini-RFC about best practice for RFC 6125 in the LDAP world would be useful though
You would have to clearly define what a client has to do to derive and check the reference identity if its configuration simply contains ldaps:///dc=example,dc=com
Frankly I don't like RFC 6125. IIRC I gave up reviewing the I-Ds when the authors insisted on adding support for wildcard certs.
The right discussion forum could be the ldap-ext and ietf-tls mailing lists.My question is really about how OpenLDAP client code supports this (or is anyone working on such things already)
If there are no clear rules yet OpenLDAP IMO cannot support it.Basically we both disagree on what we consider to be sufficiently specified and secure: If I understood you correctly you propose that if a server's cert contains subjectAltname::dNSName:example.com this cert should be accepted for any application protocol having something like dc=example,dc=com, @example.com etc. I don't like that approach. It broadens the semantics in such a way that you cannot have distinct server certs for different services. Mainly I think that untyped GeneralName::dNSName was defined before we had several types of SRV RRs (except MX RRs) and no-one ever clearly specified its semantics.
Same problem like looking up MX RR for a domain and then connecting to the MX servers with StartTLS.
For a naming context ldaps:///dc=example,dc=com one could specify that subjectAltname MUST contain dNSName:_ldaps._tcp.example.com to at least express the connection to the SRV RR for the LDAP service. Or other approaches with other types of GeneralName.
Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature