[foaf-protocols] revoking FOAF+SSL sites' certs. easy? hard? effective? what does it mean, anyways?

peter williams home_pw at msn.com
Sat Dec 4 19:28:30 CET 2010

Indeed I'm discussing the FOAF+SSL systems that exists, as designed, as written about and advocated for adoption. Those actual systems depend and require server authentication using https, as it exists in the wild. 

Since the wild is browser-based (based on trust from an OS, in the IE case), one should consider CRLs and the impact on CRLs on the certs and private key usages  ...post suspension/revocation.  We should at least understand all this... because that is what browsers do by DEFAULT. I never seen a FOAF+DNSsec system, so really cannot comment. I'd be delighted to review one, build one from commodity components in windows, or consider a working conceptual model of some well-worked theories involving DNSsec and FOAF.

In my view, folks applying FOAF+SSL channels must consider the CRLS of https; and then more than just CRLs. There is actually more theory involved about CRLs than folks are generally aware of; and it goes to the concept of operations of https as used for formenting public trust. Wikileaks is a useful analysis point, since it brings to the fore the notions and allows one to distinguish between denying that cell the instruments of public trust while not denying them basic rights of leading opinion making (or anarchist-grade crypto itself). They are good example of how the system assurances were intended to work, allowing the public trust to wrap itself around an invader, much like a white blood cell does. That doesn’t deny the legitimacy of the attacking virus as a life form... though! It simply keeps them separate.

I objected to the wikileaks cell's abuse of the public trust - and their use of a DomainSSL cert class. I have little objection to them and their supporters using self-signed certs or certs classes other than domainSSL - as that is not an abuse of the public trust associated with the SSL brand and/or the public trust iconography. Ive rarely found folks in government being other than quite comfortable with the cryptoanarchism wing of the crypto community - that seems quite useful for getting R&D done in what is an esoteric discipline. 

Now, in commodity browsers from the dominant American brands, there are PRESUMPTIONS of crypto behavior for exceptions; and its in those exception at the UI that express the real trust model of https. By default FOAF+SSL inherits this model, which may not be what the team here intends.

Beyond the military trust model (see any James Bond movie), the ability to override warnings from the system is what allows one to express ones individual or group-based trust models. For example, one can accept self-signed certs (and build one's own trust anchor net), one can let's one enterprise sponsor do the same using AD to distributed the local trust anchor lists, one can even override CRL or expired cert warnings issued by the system, or not (if the sponsoring enterprise of the browser removes the default flexibility points of individual overrides of trust anchor learning, mismatched name ignoring, CRL suspension overrides...). The system expresses discretionay vs mandatory access controls, that is; while allowing sponsors of browser distributions (employers, and ISP, and cloud providers such as google/paypal) to impose more or less mandatory controls as suits their politics for making money, or protecting their capital. 

The original motives of leveraging discretionary (vs the mandatory) doctrines were: leverage the original OFFLINE design features of the key management that once supported the resilience of cryptonets in theatres subject to radio-silences to enable the "measurement" of "social dimensions" of trustworthiness; and then engender social adoption by allowing for a new "medium of negotiation" over the very topic of non-compliance to those flexible trust notions. 

For example, get a domainSSL cert for peter.com, and use it at www.peter.com. Given a suspension notice from the CA that objects on formal grounds to the (minor) abuse, the well meaning admin still has time to get back into compliance (and get the suspension removed); or one opts to let users receive warning about mis-matched domain name and/or suspended/revoked certs -  because that is less painful than moving a server... There is a space of compliance and non-compliance, that is.
So, in essence, we  created a social trust space - expressed through the error handling at the UI and the offline protocol between the CA and the subscriber that today hinges on suspension/revocation notices in the CRL. The US company "supporting" the wikileak's chat.wikileaks.org doesn’t seem to quite get it all though - not appearing to have completed the loop on CRLs and the trust protocols. But, such is the nature of discretion. There is and must be continual evolution of the discretionary variables themselves.

-----Original Message-----
From: Henry Story [mailto:henry.story at bblfish.net] 
Sent: Friday, December 03, 2010 7:20 AM
To: peter williams
Cc: foaf-protocols at lists.foaf-project.org
Subject: Re: [foaf-protocols] revoking FOAF+SSL sites' certs. easy? hard? effective? what does it mean, anyways?

Hi Peter,
   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.
> <DomainVal1.crl><wiki.cer>____________________________________________
> ___
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols

Social Web Architect

More information about the foaf-protocols mailing list