Re: [certid] URI match

[Bruno Harbulot <[e-mail]>]

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

Ludwig Nussel wrote:
> 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
>