Subject: [certid] URI match

From: Ludwig Nussel <[email-masked]>
Date: Tue, 23 Mar 2010 15:00:04 +0100

Hi,

What's the purpose of URIs in subjAltnames? Are they meant for
things like "https://example.com/"?

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 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. 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 and
enters 'https://example.com/' in the browser. Should that succeed?
Again I guess the URI doesn't match. 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.

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

cu
Ludwig

-- 
 (o_   Ludwig Nussel
 //\   
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)

---

From: Bruno Harbulot <[email-masked]>
Date: Tue, 23 Mar 2010 15:11:42 +0000

Hi Ludwig,

We've been using URIs in subjectAltName in FOAF+SSL 
<http://esw.w3.org/Foaf%2Bssl> (currently only for client-certificate 
authentication).

FOAF+SSL is an authentication mechanism that provides global 
identifiers, typically the URI of a Person using semantic web technology 
(we call such a URI a 'WebID').
One of the objectives is to rely on social networks to make 
authentication and authorisation decisions. In principle, you can have 
both hierarchical and decentralised models to assert and verify the 
identity of an agent.

Just to give a bit of background, this relies on FOAF [1] 
(Friend-of-a-Friend), which is an RDF vocabulary to describe people, 
organisations and relations between them.
For example, my WebID is <http://www.harbulot.com/foaf/bruno#me>. If you 
get this document, you'll get a description saying that:
    <http://www.harbulot.com/foaf/bruno#me> is a foaf:Person
and some semantic description that binds a public key to it.
RDF allows you to build graphs made of statements like this, which can 
then be processed and reasoned about by a machine.

FOAF can be used to write statements like "someone knows someone" and 
"someone belongs to this organisation", for example. This allows for 
modelling peer-to-peer models of trusts as well as more hierarchical ones.

What we do is embedding the WebID in an X.509 certificate (which may or 
may not be self-signed) and replace the trust model on the server side, 
not to use PKIX.

When the client connects to the server, the server knows that the client 
has the private key for the certificate's public key (via the TLS 
handshake), irrespectively of whether the certificate is trusted or not.

Then, the server needs to check how it trusts this certificate to 
perform the authentication.
In its simplest form, we do an HTTP GET on the URI itself to get the 
FOAF document at that WebID. In turns, this document contains a graph 
that links the WebID to a public key: we verify that this matches the 
public key in the certificate. This level of assurance relies on the 
control over the hosting of this URI (and this is sufficient for a 
number of applications).
Alternatively, we've been working on signing parts of such graphs, or 
how to get better level of assurances by getting these graphs from 
better trusted sources.

This allows for the discovery of information related to an identifier, 
via the (semantic) web, as well as the decoupling of identifier and 
assertions made about an identifier.

While this is mainly targeted at client certificates, the WebID is in 
principle that of a foaf:Agent ("An agent (eg. person, group, software 
or physical artifact)." [2]), foaf:Person being a specialisation of 
foaf:Agent, so this might be usable for server certificates one day 
(although there's a bootstrapping issue then).
We still rely on traditional PKI and HTTPS hostname matching for the 
verification of the server's identity.

More generally, URIs have the advantage that they're universal 
identifiers, not just URLs. A URI identifies something, which may or may 
not resolve when you point a browser at it. On that basis, URIs in a 
cert could identify the signer (whatever that is), although verifying 
how you tie that thing to this identity would certainly fall outside the 
scope of this I-D if you can't get that URI.
If there's a service behind that URI, it would seem appropriate to use 
that (again, probably more useful for some message-level security, 
rather than TLS).
In principle the server (machine or daemon) itself could have access to 
the private key, but it's then a matter of making explicit what entity 
or sub-entity is referred to. That's the same problem as mentioned by 
Paul Hoffman in the previous thread; you could just dig further than the 
daemon and refer to what's specifically behind that URI I guess (e.g. a 
specific webapp):
> A public key listed in a certificate is associated with *something*
> that has access to the associated private key. The machine has access
> to that private key, as does the server application/daemon. If you
> want to make this distinction, you need to do so much more clearly in
> the draft.

Best wishes,

Bruno.

[1] http://www.foaf-project.org/
[2] http://xmlns.com/foaf/spec/#term_Agent

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Mar 2010 16:12:38 -0600

> 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:[email-masked]".  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).

> 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.

> uniformResourceIdentifier in the same certificate. 

Yes.

> So a subjAltname
> 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

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

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

> 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/

---

From: "Scott Cantor" <[email-masked]>
Date: Wed, 31 Mar 2010 19:46:59 -0400

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

Somewhat paraphrasing a question that I think was asked at the app area open meeting last week, is it the intention to encourage new protocols/services that adopt/reference this proposal to favor matching based on URIs where possible or appropriate?

That's something I'm in favor of, and I think worrying about what users think they're connecting to is really beside the point; users don't get this stuff. Our software is supposed to do the right things for them so that they don't have to.

-- Scott