Re: [keyassure] dane-04 trust anchors

On 22 Feb 2011, at 08:19, peter williams wrote:

> So we have two X, where one can consider these test cases, use case, or things to be denied:
>  
> Should the webid be http (not https), we recognize that any interceptor can actively manipulate the stream to make it falsely appear that a cert is revoked

  yes

>  
> Should the webid be https (not http), we recognize that a reverse proxy can be acting for the content server and maliciously manipulate the stream to make it falsely appear that a cert is revoked

No, that is not possible. If a reverse proxy is in play then it is because it is allowed to be there. Its key has been signed by a CA for that domain, or in the future its public key is published in the right space of DNSsec. That should be only the case if it is indeed in charge for that domain. Other cases are human security problems that need to be checked in court or with insurance agencies. 

> These are just consequences of relying on channels to data origin authenticate content – unlike signed XRDs say which are free from undetectable channel interference, unlike signed DNS RRs containing certs values that similarly do not rely on a channel security for integrity.

I doubt this. If you give away your XRD private key, or a virus gets hold of it, etc, etc. you are in the same position. Someone will make fake XRD signatures. 


> If recommend we don’t go too far down the road of saying: well, we assume a correct, logical, and adversary free world;

No we just assume, like very large companies do, Amazon, VISA, banks, etc. that it works well enough for business. The pressures that the system is under to work better is proportional to the amount of business going on the web. I doubt that XRD has anywhere near the same amount of pressure exerted on it every day. It is this pressure that will lead to secure DNS being rolled out, browsers to upgrade, and so on.

> and buyer beware if it’s not;

buyer sue if not

> and thus security threats to the abstract protocol just don’t need to be considered. Rather, the spec slowly starts to either characterize these unaddressed threats in a security section, or makes countermeasure claims to defeat the threat in the body of the text.

You keep coming up with false proxy issues, which  you portray as holes in TLS. They are not. If you walk with your computer into a building with such a proxy, you will notices that no https end point will work for you - that is unless they are using the key of one of the CAs you trust in your browser - and here be aware of using Microsoft OS, that OS downloads certificates without telling you. 

Of course if you use their computers to do your work, then you are completely open to being spied on. But everybody knew that.
And I doubt that XRDs have found away around that issue.

> We have to compete against signed XRDs over http, which can also contain an SEP (a service endpoint defn) with an embedded self-signed cert. If signed XRDs team up with keyassure for management of the XRD signature’s own trust anchor key management, that’s quite a integrity package.

WE compete by being very simple, very extensible, but only do the minimum we need to do. And we work with linked data. But in any case we need to look into XRD. Perhaps someone can write an XSPARQL transform for it into a well known ontology.

	Henry


>  
> From: public-xg-webid-request@w3.org [mailto:public-xg-webid-request@w3.org] On Behalf Of Henry Story
> Sent: Monday, February 21, 2011 4:17 PM
> To: Peter Williams
> Cc: public-xg-webid@w3.org
> Subject: Re: [keyassure] dane-04 trust anchors
>  
>  
> On 21 Feb 2011, at 23:36, Peter Williams wrote:
> 
> 
> One has to be careful in webid, since the pickup of the profile document may be subkect to active attacks (including SSL proxies).
>  
> if the profile document is protected by https then proxies are not an issue,  because they can only arise if the user has allowed them to be used, and therefore he trusts them. This is the case for company SSL proxies. If they are illegal proxies - worms, viruses, or such then they are beyond the protocol. A door works if it stops the intruder from coming in through it. If you leave the backdoor open that is a different issue.
> 
> 
>  
> An active attacker could remove the cert from the array to make it appear that the cert has been revoked, unless the pickup channel has integrity.
>  
> We assume everything is functioning in the writing of the spec. That is why the language is using MUST and SHOULD, not IS. We are not describing the way the world actually works, with its broken browsers, OSes, viruses and so on... but how they should work for the protocol to function.
> 
> 
>  
> Traditionally, there is a difference between having status = invalid (becuase I cannot affirm validity as a verifier), and having status = revoked (becuase an authority affirms revocation or suspension).
>  
> yes. The way the protocol is set up the IDP has to find a profile that is valid and check what it says. If it makes no mention of the public key, then we say the IDP cannot finish the authentication step. That does not mean there may not be other ways to do that.
> 
> 
> This obviously get one into the usual story of: who is authoritative to make statements about a key/cert, for each type of statement?
>  
> Obviously this induces a recursion: how does one authenticate the C authority, speaking about the authority of entity X?
>  
> IN PKIX certs you can have multiple URIs to multiple OCSP responder, each of which can be making different statements about the cert. One, managed typically by the CA and signing its responses using cert that chain to the CA's trust anchor, can be affirming that its "not-revokes" or "not-suspended" (meeting the rules of a qualified cert and signing device, say, that MUST confirm status affirmatively). A second can be saying: I see this is the 14th request about this cert in the last minute, I recommend temp-suspension (based on velocity counts); liability coverage goes to $0 if you disregard this notice.
>  
> Yes. There may be ways of building services such as this on top of WebID or orthogonally to it. 
>  
>  
> > From: henry.story@bblfish.net
> > Date: Mon, 21 Feb 2011 23:01:31 +0100
> > CC: keyassure@ietf.org; public-xg-webid@w3.org
> > To: i.grok@comcast.net
> > Subject: Re: [keyassure] dane-04 trust anchors
> 
> > 2. In WebID if the public key is no longer listed at the WebID Profile then the client certificate is revoked. In Dane when the key is removed from DNSsec the same happens.
> 
>  
> Social Web Architect
> http://bblfish.net/
>  

Social Web Architect
http://bblfish.net/