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/