Subject: Service name + host check [Re: Last Call: Discovering LDAP Services with DNS to Proposed Standard]

From: Michael Helm <[email-masked]>
Date: Sun, 24 Feb 2002 12:30:08 -0800

"Kurt D. Zeilenga" writes:
> >"example.net"  OR  "ldap/example.net"
> 
> How a client checks the certificate is defined in RFC 2830, not

> state that RFC 2830 provides the normative specification
> of the check algorithm, not this I-D).
> 
> Service base certificate issue is NOT specific to LDAP

> Defining a service-base certificate check mechanism, if
> desired, should be drafted as an update to RFC 2830.

(If there is further discussion on this ... perhaps we should
continue it in ldapbis and not on the DNS SRV thread.)

This would be a useful thing... we already have some deployment
with this kind of naming (cn=ldap/foobar.lbl.gov).

I assume this would mod
draft-ietf-ldapbis-authmeth-xx?

pkix gives me the impression of not liking subject names that
don't fit naturally in the directory, don't represent a real
object, and/or introduce some other hierarchical structure at
a point intermediate in the tree.  (cf the history of e=[email-masked]"
in subject names).  I think Microsoft has been putting kerberos
principal names in subjectaltname ... I don't have one I can 
get at to check at the moment.  So is this kind of naming viable?

Michael Helm
ESnet/LBL

---

From: "Kurt D. Zeilenga" <[email-masked]>
Date: Mon, 25 Feb 2002 11:31:48 -0800

I believe supporting service (protocol) information in TLS
checks would be useful.  I would think an optimal solution
would be service neutral.  That is, the TLS check would be
defined in a manner supporting not only LDAP, but all
protocols which use TLS.  Maybe this is something which
PKIX WG or interested individuals should consider taking
on.  Once a general mechanism for using service information
in TLS checks was establish, the LDAP "core" specification
could just use it by reference.

Kurt