RE: PKI signing of certs with SAN URIs : NVSI : openid domain procedures

Webid's security model is a variety of the openid model - proving a user controls an http(s) identifier at which is found a file containing the same public key as was signed/validated in the SSL handshake - that proves the user controls the private key. The SSL in webid requires nothing about cert/chain trust or cert formats, and neither does the webid validation process. We only even consider the X.509 blob, because its legacy crap in the way. We can prove this when the typical webid validator accept client certs (just a convenient old format, recall) with signature algorithms fields they do NOT even recognize (yet webid validation still concludes). Then, we know that no one bothered with the cert, as a value, limiting its role to be an old [technically unsigned] format! If its signed, its only to get passed legacy guard code, in older model https servers - built to enforce PKI.

The ONLY thing that matters in the world webid is that the SSL signature matches the pubkey in the cert (old format), and said pubkey exists in the referenced file. In claims theory, the user signs the webid URI, the SSL signature authenticate the user signed the SAN_URI field (as yet, still encoded in some old cert format on the wire), and the foaf card once retrieved shows someone had write-power to stuff the public key at the URI. 

This proves identifier control - the openid thesis cast in webid terms. Openid auth protocol proves the same, using a layer 7 protocol for crypto rather than layer 4 ssl.

The only complication we know of to the above, is when the foaf card exists on an https URI. Then, some real world agents will or will not connect to the https endpoint of the foaf card (depending on what their vendor stuffed in the root key file, used by the https client). If the foaf card happens to be on an endpoint whose SSL authority is "trusted" by the platform of the resource server, then it may work. Otherwise it won't, unless the https implementation of the client is programmer to "ignore" and all cert errors when collecting foaf cards.

Everything else falls in the space of "Federate social networks" - which happen to apply webid to social web ideas. This largely use linked data spaces. They typically deny that cert chains are linked data spaces (even though they obviously).

And there lies the issue.

We are CLAIMING that webid works when the self-signed cert is replaced by the CA-signed cert. Yes. We do that! Read carefully the blurb.

IN that OPTIONAL world, all the self-signed steps are performed, but the validating agent MAY then also do PKI stuff. If they do, they have all the usual PKI problems to address. 

Now, this is what we SAY to the world. I recognize that only 4 of the folks of the 12 agree with the position, or agree that this is what we say to the world. And, that is what confuses the CA community. 8 folks say webid exists to eliminate them; and 4 say it harmonises.

Which is it?

If it harmonizes, there are things one can do that build upon the properties of self-signed certs at endpoint - so user-centricity is preserved (despite re-introducing the evil CA world). It’s a hybrid trust model space.

AS we turn to trust models, for the Berlin paper, we get to have the same debate we had over multiple schemes in URIs. Are we truly committed to that position, or was our agreement in the charter "just a way" to say yes to get the group formulated in W3C (but then we do what we wanted all along, and deny the multi-protocol'ness, deny the multiple trust model world, etc - so as to re-argue/impose the religion of PURE web architecture linked data).

Let's see. The core proposition of public trust is full disclosure, and knowledge of the [changing] positions. One quickly detects deception or just double-speak. My experience tells me , the more double-speak, the less the public adopts. Something about the residuals in the message convey to mass audiences "untrustworthiness". Its not acting in the public interest, somewho.









-----Original Message-----
From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of Andrei Sambra
Sent: Saturday, April 30, 2011 1:31 PM
To: Melvin Carvalho
Cc: WebID Incubator Group WG
Subject: Re: PKI signing of certs with SAN URIs : NVSI : openid domain procedures

If I understand the first question, it should suffice for the CA to extract the WebID and then dereference the foaf card indicated by the URI. It's pretty much the same steps involved in performing WebID authentication.

For the second question, I don't why we couldn't. However, I wonder why we should do it. The question is, what are you looking to do? Trust a certificate (it's owner), or trust the people using it (the owner of the FOAF card)?

If you are referring to something similar to the PGP, then there is an article on one of the wiki pages which describes why WebID makes it easier to implement a web of trust, without signing anything. If you are referring to the general case, as a way to improve trust, then I still don't see why signing anything would improve trust. 

Now, let me rant for a little, since I've seen lots of emails on this list discussing CAs and general issues related to PKI, and I also fear some of the mailing list members still don't understand WebID.

Quick recap: WebID offers first and foremost a way to authenticate users. This is done using self-signed certificates (as far as CAs/PKI systems are concerned) which contain a reference to the certificate owner's public foaf card. This card serves as the user's "identity", and contains one or more public keys belonging to one or more x509 certificates, which in turn serve to verify that browser certificate which was used to point to this foaf card does indeed belong to the card's identity.

As you can see, the browser certificate is only useful to establish that a user connecting to a service is indeed the owner of the foaf card which contains his/her identity. Whatever trust relationships we intend to form, do not involve the certificates! This is where the linked data comes into play, and for example, we could simply use foaf:knows to create a web of trust. 

I hope I've made myself clear. Oh, please do not consider this post as personal attack to someone, or my way to start a flame war. 

Andrei

On Sat, 2011-04-30 at 21:49 +0200, Melvin Carvalho wrote:
> A couple of questions:
> 
> Is it possible for a trusted CA to assert that a certificate is tied to a WebID?
> 
> Can we become notaries or CAs ourselves and sign each others certs?
> 
> >
> >
> >
> >
>

Received on Saturday, 30 April 2011 22:48:21 UTC