Re: Request for new work item - Defining an SRV RR otherName

[Sam Hartman <[e-mail]>]

Hi.  I'm speaking as an individual not as an AD.

This proposal was originally introduced as a use of dnsname in the
Kerberos working group for pkinit.

The authors of the proposal would like to name services as they are
identified by users.  For example a user types foo.bar.example.com
into some program.  The program looks up a SRV record for some service
and then connects to that service.  If insecure DNS is used then the
dns lookup should not be part of the name against which a certificate
is checkde.

We're seeing a similar situation in the kitten working group ; see
draft-ietf-kitten-gssapi-domain-based-names-00.txt.


The idea of this proposal is that the certificate contain the name
that the client system would look up in the same form as the client
uses to look in DNS.

I'm not sure how this proposal has evolved since it was first
presented to me.  Originally the goal was so that application
libraries could use some sort of automatic mechanism to:

* Look up SRV records

* Bind to TLS certificates

* Find the Kerberos principal name

* Bind to pkinit certificates.

All the application author would do would be to pass the service
protocol and name into some magic function.

That bothers me.  There is no guarantee that the SRV record tag will
match the GSS/Kerberos principal name.  There is no guarantee that the
service in question doesn't have some better choice for certificate
binding like one of the IMPP-specific solutions.


I'm also not quite sure that SRV tags are real/really the right thing
to be binding to.

If the PKIX working group does adopt this proposal I would recommend
being very careful.  Make sure to scope it only to be used for
applications/services where it is appropriate.  Make sure to discuss
applications that already have a mechanism for binding their
certificates.

It might also be important to find out if there is actually a use case
for this name type before standardizing it.  There wasn't really that
much support in krb-wg for the earlier version of this.

--Sam