[foaf-protocols] revoking FOAF+SSL sites' certs. easy? hard? effective? what does it mean, anyways?
henry.story at bblfish.net
Fri Dec 3 16:19:42 CET 2010
The CRL issue you point to is related to server side certificates. On the client side as you know we
don't need them anymore with foaf+ssl, since it just requires the dereferencing of the WebID to know
if the client certificate is still valid. That dereferencing of the WebID is what requires the server
certificate, and so the CRL. Well as far as I see it does not require it. It is just what we have at present. There are many other ways one could verify that the server cert is valid.
One option that is going to be feasible real soon is to do the same trick we are doing on WebIds with certificates, by publishing the public key of the certificate in the DNS. With DNSSEC that should be secure enough. There are a few RFCs being worked on along those lines
That has the advantage of being possibly very scalable. Other solutions are possible too. So whatever
solution comes up in that space will just make foaf+ssl better.
On 3 Dec 2010, at 16:04, peter williams wrote:
> Since folks decided to tie FOAF+SSL to the world of domain names, I’ve experimented on the topic revocation – and its effectiveness when disabling the certification of domains names in the CA world. I played with a “real” revocation, since the opportunity presented itself…
> As of a few moments ago, the site at wikileaks.de was presenting an SSL cert (see attached) – like many other sites do trying to leverage the public trust (such as it is, in the DARPA-designed internet) by using crypto for authentication and digital signatures. But, the site uses it in a manner that is, in my opinion, a blatant violation of the policies following in common by all reputable “public CAs”: it authenticates chat.wikileaks.org (tied to Sweden’s legal jurisdiction) but serves the cert from a server called wikileaks.de(presumably in Germany’s legal jurisdiction). I would not mind so much if they had not procured a “domain” class of cert (an offering in the certification world specifically assuring the public about domain names, website addreses, etc etc).
> The cert has serial 01 00 00 00 00 01 29 dc 53 61 92
> The controlling authority for private key associated with that certificate has apparently accepted my argument that the subscriber is not in compliance with the fundamental terms of the certification; and may have revoked the certificate. (I say may, as an email I received to that effect may have been spoofed….).
> Anyways, there is some evidence one can rely on – and here FOAF+SSL needs to take note. The hyperlink to the crl relevant to the cert delivered at wikileaks.de only has a few entries (and only couple in the last few days).
> 01 00 00 00 00 01 2c 83 6a 0e 5a Tuesday, November 30, 2010 1:10:03 AM
> 01 00 00 00 00 01 2c a5 1a 18 6b Thursday, December 02, 2010 1:55:34 AM
> The crl indicates that its due to be effective on Friday, December 03, 2010 3:28:08 AM (which is probably zulu time; but who knows…). At 5am PST, IE8 is not enforcing it…
> IE8’s lack of enforcement is not totally surprising on inspection, since the cert is not listed on the CRL! And, the records repository of the controlling authority does not enable me, in any obvious away, to check the status of serial numbers recently revoked. (VeriSign’s CA division did a better job, here…at least in the era when I was involved.)
> Assuming the revocation event for chat.wikileaks.org was represented in one of the two listed revocation notices, then either the authority revoked the wrong party’s cert, or they failed to revoke all the certs listed against the domain name - revoking only some of them). Or, of course, Im being spoofed…since communication with the CA is not signed!
> So, for FOAF+SSL, where the trust model was defined to tie into classical https that folks designed for the threats facing the 1995-era web (versus the threats facing the semantic web), there are several things to note:
> 1. After cert revocation, there may be a delay until the posted CRL itself becomes effective.
> a. there is a further delay until the (traditional) web properly caches that file so its highly available to a billion people, assuming its referenced properly by cert handling software
> b. CRLs do not do what military compromised key lists do (which is attempt to get broken systems out of the cryptonet IMMEDIATELY). Enforcement delay is NORMAL.
> c. the delay gives the subscriber the opportunity to come into partial compliance – and stop using the private key (per the agreement). This is part of the public bargain (don’t make CAs into big brother…)
> d. A party may compound non-compliance by continuing to use the private key, at which point the CA is supposed to issue legal injunctions to enforce the subscriber agreement, and stop the loss.
> e. We will see if the CA business in question actually does this, should that particular private key be used ANYWHERE, once the cert is revoked.
> 2. Note that not all authority policies are equal. The one wikileaks signed up to CONTROLs the private key’s use, note. It’s a very British style of policy, distinguished from other policy cultures that only control the use of the cert when relying (ignoring the private key aspect).
> a. Some policy designs allow the public function of the private key to be certified multiple times (and one has multiple certificates from different authorities). This is consistent with RFC 1422, which addressed policy control issues.
> b. When only reliance on the cert is controlled (vs private key use), no one authority has exclusive control over the private key usage (unlike the case ofchat.wikileaks.org).
> c. Ambiguous policy controls exist (especially concerning whose enforcement power is “operational”, upon during revocation acts, when policies are not compatible).
> Are folks really sure they want FOAF+SSL tied to all this?
> Given the expressive power of the semweb and FOAF documents in particular, I’d rather start again and use the datamesh to properly describe and share all these policy assumptions and implicit designs.
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
Social Web Architect
More information about the foaf-protocols