Subject: RE: Required binding method - Was RE: PKINIT-26 changes: identifying the kdc certificates

From: "Stefan Santesson" <[email-masked]>
Date: Tue, 24 May 2005 00:37:11 +0100

Sam,

> I hope the PKIX working group does not approve a version of the SRV
> OtherName that would allow it to be used with an application without
> some standard enabling such usage.  So I would expect some document to
> explicitly mention that it can be used with pkinit.  But I agree that
> if PKIX were to approve an overly broad standard, the current text
> would allow it to be used.
> 
> 

[Stefan] I don't think you can constrain its usage in a PKIX RFC or
force some RFC to enable it for each service type.

RFC 2782 already makes it possible to bind to a service only based on
service name, protocol and domain. There are no limitations to that.

And in this case the only thing the client knows about the service is
its SRV RR. Every other knowledge is obtained from the DNS server or
learned through using the service.

So, if the client wants to validate that the host it accesses is a
legitimate provider of the requested service then asserting the SRV RR
in the server certificate can only increase security of a binding that
already is allowed and already takes place in an insecure manner.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 23 May 2005 23:03:05 -0400

>>>>> "Stefan" == Stefan Santesson <[email-masked]> writes:

    Stefan> Sam,

    >> I hope the PKIX working group does not approve a version of the
    >> SRV OtherName that would allow it to be used with an
    >> application without some standard enabling such usage.  So I
    >> would expect some document to explicitly mention that it can be
    >> used with pkinit.  But I agree that if PKIX were to approve an
    >> overly broad standard, the current text would allow it to be
    >> used.
    >> 
    >> 

    Stefan> [Stefan] I don't think you can constrain its usage in a
    Stefan> PKIX RFC or force some RFC to enable it for each service
    Stefan> type.

    Stefan> RFC 2782 already makes it possible to bind to a service
    Stefan> only based on service name, protocol and domain. There are
    Stefan> no limitations to that.

Please See the following text  from RFC 2782:

  Applicability Statement

     In general, it is expected that SRV records will be used by clients
        for applications where the relevant protocol specification indicates
           that clients should use the SRV record. Such specification MUST
              define the symbolic name to be used in the Service field of the SRV
                 record as described below. It also MUST include security
                    considerations. Service SRV records SHOULD NOT be used in the absence
                       of such specification.

So your proposal clearly should not be used for applications that do
not use SRV records in the first place.  Some applications that use
SRV records (most of the IMPP protocols fall into this examlpe)
already specify how certificates should be bound to these
applications.  It is undesirable to have two methods of doing the same
certificate binding without compelling reason to do so.Failing this
would lead to decreased interoperability.  From this I conclude that
your name type should only be used when explicitly specified.  Things
are of course more fuzzy for applications that do not have formal
published specifications.