Re: [certid] URI match

[Peter Saint-Andre <[e-mail]>]

On 3/23/10 8:00 AM, Ludwig Nussel wrote:
> Hi,
> 
> What's the purpose of URIs in subjAltnames? Are they meant for
> things like "https://example.com/"?

One example is the Session Initiation Protocol, where the "sips:" URI
scheme is used for matching. See for instance Section 4 of
draft-ietf-sip-domain-certs-06, which has the following text:

   As an example, consider a request that is to be routed to the SIP
   address "sips:[e-mail]".  This address requires a secure
   connection to the SIP domain "example.com" (the 'sips' scheme
   mandates a secure connection).  Through a series of DNS
   manipulations, the domain name is mapped to a set of host addresses
   and transports.  The entity attempting to create the connection
   selects an address appropriate for use with TLS from this set.  When
   the connection is established to that server, the server presents a
   certificate asserting the identity "sip:example.com".  Since the
   domain part of the SIP AUS matches the subject of the certificate,
   the server is authenticated....

      SIPS borrows this pattern of server certificate matching from
      HTTPS.  However, RFC 2818 [7] prefers that the identity be
      conveyed as a subjectAltName extension of type dNSName rather than
      the common practice of conveying the identity in the CN field of
      the Subject field.  Similarly, this document recommends that the
      SIP domain identity be conveyed as a subjectAltName extension of
      type uniformResourceIdentifier (c.f.  Section 6, Section 7.1).

> If so, does "telnet://example.com/" match "https://example.com/"? I
> guess not as the URI schemes are different. The exact matching rules
> for URIs are not defined in the I-D though.

The basic idea is that the client would expect to connect to a SIP
service at "example.com" (the reference identity). Therefore it would
expect to find one of the following:

1. A dNSName of "example.com"

2. An SRVName of _sip.example.com"

3. A uniformResourceIdentifier of "sip:example.com" or
"sips:example.com" (not "https://example.com" or any other scheme).

You're right that this needs to be specified more clearly in the spec.
I'll fix that in the next version.

> The I-D allows multiple different types in subjAltnames so I guess
> it's legal to have subjAltnames of type dNSName and
> uniformResourceIdentifier in the same certificate. 

Yes.

> So a subjAltname
> 'URI:telnet://example.com/, DNS:example.com' would be valid. Assume
> the user wants to connect to a server with that subjAltname 

The user doesn't want to connect to a particular SAN, the user wants to
connect to a service of type X at domain Y (e.g., "the SIP service at
example.com").

> and
> enters 'https://example.com/' in the browser. Should that succeed?

Yes, because any match is fine. But see below.

> Again I guess the URI doesn't match. 

IMHO, users don't care much about the particular service type (at least
not in current practice). They want to connect to example.com, but they
are not too particular about the specific service type ("oh no, I really
want to connect to a SIP service but this URI says the service is a web
site instead"). Whether we want to train users to be more cautious about
the service type (or place additional rules upon user agent software) is
another matter.

> However, when mapping the URI
> to the host part only the dNSName would match and the connection
> succeeds. Also, clients that don't support URIs in subjAltnames (as
> almost all software out there) would ignore the URI and match
> dNSName only.

Correct. And I think that's fine, because as noted users care more about
the domain match than the service type match.

> So, without defining further constraints an URI in subjAltnames is
> rather useless, isn't it?

No, because we're trying to be inclusive regarding SANs at this point,
and SIP certificates (as one example) prefer uniformResourceIdentifier.

However, I will work to clean this up some more in -04.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/