RE: [keyassure] dane-04 trust anchors

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

 

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

 

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.

 

If recommend we don't go too far down the road of saying: well, we assume a
correct, logical, and adversary free world; and buyer beware if it's 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. 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.

 

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/