RE: [keyassure] publishing the public key

One can look at the keyassure for trust anchors positively in my view,
without getting involved in the main IESG mission for the WG. The key assure
work seems complementary and useful, if one looks at is as a counter-signing
authority making statement about keys - no different to any other.

Lets remember that in webid land we look to an https channel to data origin
authenticate an RDF stream, encoded optionally as simple markedup HTML that
anyone can formulate. The document contains the control information that
assures the webid security protocol run. The https channel over which the
document travels provides integrity of the RDF stream and authenticates the
channel's source. (One can now infer that the channel speaks for the
document in webby logic, much as https://verisign.com speaks for its
homepage.) But, perhaps a giben verifier want "additional" assurance for
that very act of inference!

Should DNSsec and keyassure perform the same function as we current assign
to https and server certs (because now the self-signed trust anchor is
countersigned by a DNSsec .sig RR, where the self-signed cert contains the
HTML stream which bears the RDF triples), would we care? 

If one doesn't wants to limit dependency on DNS and its various political
actors but one DOES want to leverage DNS as a optional source of assurance,
it might make sense to allow the linked-data/RDF world to "augment" itself,
using DNS and keyassured self-signed certs. 

When a verification agent is presented with a webid claim (a URI), it
consults the channel source using https AND (perhaps) it  obtains a
keyassured record from DNS, for the domain-name in the authority subfield in
the URI. The key-assured RR is just a counter-signed self-signed cert,
pretending to be a trust anchor; and can have [encrypted] extensions. No
reason (since its self-signed) that an extension cannot be some cleartext
HTML...within which is to be found yet more triples that add to the RDF fact
store available to the verifier. The assurance facts from https plus the
assurance facts from the DNS record all feed into the verifiers confidence
measuring function, as normal. The DNS zone authority is just another
endorser.

As we expect, here if the verifier does opt to authenticate the webid claim
given these various evidence sources, it will state this to the world
publicly in its own foaf card using the SIOC vocab - publishing a document
and the "following" statement - which itself is available on an https
channel... which is available to the next webby link user which talks to the
server, inducing it to act as an https client role.

-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org]
On Behalf Of Henry Story
Sent: Tuesday, February 22, 2011 1:18 AM
To: Stephen Kent
Cc: WebID Incubator Group WG; keyassure@ietf.org
Subject: Re: [keyassure] publishing the public key


On 22 Feb 2011, at 03:00, Stephen Kent wrote:

> At 12:49 AM +0100 2/22/11, Henry Story wrote:
>> ...
>> >
>>> Do you mean "identifies" or "authenticates?" I think most folks view the
DNS name (or URL) as the identity of the web site.
>> 
>> Partly. The DNS domain name is a name that one could think of as
referring to a set of services, each of those having a name of the form
name:port. The relation between the service name and the public key forms an
identifying description, or I should say  a definite description  as it is
known in philosophy. I used the following example:
>> 
>>  name:port knowsPrivateKeyof pubK
> 
> I don't think that most users, who often can't even tell if they have
contacted a TLS-secured site, would think of a public key as part of the
identity for the service. I also don't think that most of them think about
the port either.

I was not speaking to most users but to this group of security specialists
during a discussion on a protocol. The public key is a definite description
that uniquely identifies the agent for the purpose of computers, not for the
general public.

> 
>> That sentence does not authenticate, it describes. But it is part of the
TLS authentication protocol. Authentication is the process that uses that
information to prove the authorship of the messages sent down a socket.
> 
> once the TLS session has been established, it is symmetric crypto, 
> using a key delivered or derived using a public key (or pair thereof) 
> that provides the data origin authentication and connection-oriented 
> integrity guarantees to which you allude.

I am aware of symmetric cryptography's role. But it is public key
cryptography that is core in authenticating the server, and setting up the
symmetric crypto channel. Symmetric cryptography is used because it is less
cpu intensive.

> 
>> > We're debating the mechanics of how to enable a client to verify that
the asserted identity matches the client's expectations, based on the
content of a series of DNS records.
>> 
>> Yes, that is what the next part of my e-mail was describing the logic of.
Now in the case of server identity the client knows what it wants the
server's identity to be, since it initiated the call, went to DNS, found the
ip address, and connected. The clienet can then use the public key found in
DNS (or returned  by the server) to authenticate the service it is connected
to.
> 
> right.
> 
> Steve

Social Web Architect
http://bblfish.net/

Received on Tuesday, 22 February 2011 10:48:43 UTC