Re: Last Call: Discovering LDAP Services with DNS to Proposed Standard

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

On Fri, 8 Feb 2002, Lawrence Greenfield wrote:

> On further thought, I'm actually fairly unhappy about this approach to
> constructing the name of the certificate needed.
>
> There are other uses of SRV records; let's say I have the IMAP
> protocol running, so I look up
>
> _imap._tcp.example.net.  IN  SRV 0 0 143 imap.example.net.
>
> If I then execute STARTTLS on this service, should I be expecting a
> certificate for "example.net"?
>
> Now all of the services for example.net share the same certificate,
> even though administratively IMAP and LDAP might be in two separate
> groups/organizations/whatever and should have no business being able
> to spoof each other.  Delegating one service to a subgroup shouldn't
> compromise every other service for a domain.

So, trying to conclude all last-call issues ...

Larry makes an excellent point, that it would be better for the service
name to be not just the name of the host but the name of the host
qualified by (at least) the name of the protocol/service in question, in
this case "ldap".  As Paul notes there is well-established practice for
this in Kerberos (service principals like "ldap/example.net") and GSSAPI
("ldap@example.net").  Unfortunately there is (to my knowledge) zero
existing practice for this in the X.509 certificate world, either in
commercially-sold certs or home-minted certs.

I'm reluctant to try to establish new practice in this area with a note in
the security considerations section of this already venerable document.
So unless other voices chime in in favor of protocol-qualified service
names in certificates, or Larry can persuade us that this is worth doing,
I think we'll move on with this part of the doc as is.

 - RL "Bob"