W3C home > Mailing lists > Public > public-xg-webid@w3.org > February 2011

RE: [keyassure] dane-04 trust anchors

From: Peter Williams <home_pw@msn.com>
Date: Mon, 21 Feb 2011 14:36:16 -0800
Message-ID: <SNT143-w193C78358761EF15B14EC692D90@phx.gbl>
To: <henry.story@bblfish.net>
CC: "public-xg-webid@w3.org" <public-xg-webid@w3.org>

One has to be careful in webid, since the pickup of the profile document may be subkect to active attacks (including SSL proxies).
 
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.
 
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).
 
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.
 
 

> 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.
 		 	   		  
Received on Monday, 21 February 2011 22:36:48 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:06:22 UTC