unrest.ca

Just a quick update on the IN11-003 bug.. Most vendors are patched now, however a few holdouts remain.

I can however report that at least one of the oAuth provider libraries that was affected has now patched their software. So if you're a user of tmhOauth, (commonly used with Twitter) you will want to upgrade to at least version 0.61.

If you're an affected vendor who wants to go public, please let me know and I'll do what I can to help get the upgrade message out.

Also, developers please ensure that you do not set CURLOPT_SSL_VERIFYHOST to false or true, (the correct value is unset or 2). This will also cause the IN11-003 vulnerability in your code.

On July 14^th I found that SSL certificate verification had been disabled in a major credit card processor's PHP API and I began a responsible disclosure process with the vendor. Through this process it was identified that this problem was not unique to this vendor, but rather, it affected a wide variety of major payment processors and e-commerce application packages.

Throughout this disclosure I contacted the CBA (Canadian Bankers Association) the Privacy Commissioner of Canada and the Canadian Cyber Incident Response Centre (a division of Public Safety Canada) who helped with a six-month process of identification and responsible notification of the as many affected vendors as possible.

During this process new PCI-DSS encryption standards were released that cover the vulnerability, and vendors should promptly review their compliance with these new PCI-DSS standards.

Today, CCIRC is releasing the technical details of this vulnerability http://www.publicsafety.gc.ca/prg/em/ccirc/2011/in11-003-eng.aspx as IN11-003 to inform any other vendors that we have not been able to contact.

Full disclosure of affected libraries, and a paper describing the breadth and scope of this vulnerability will follow in the new year. It is my hope that with this technical information now public, vendors of affected software can begin the process of disclosure and notification to end-users and customers about the potential that their credit card, name, address and purchase information may have been intercepted while shopping online.

This is not a new vulnerability, and in-fact I wrote a strong warning about this very issue in my 2008 book Pro PHP. This vulnerability exists entirely in the vendor's API software and does not represent any issue with PHP or cURL themselves. Affected software must be patched directly on e-commerce websites, however, in most cases, automated patching mechanisms do not exist for central use by the affected vendors and manual upgrading will need to be performed by merchants themselves.

I would like to thank Tamir Israel from CIPPIC for providing much needed legal advice and support, as well as Christopher Parsons for sharing his resources, being a confidential sounding board and acting as a secure secondary storage location while this vulnerability was being disclosed.

In the new year, we will reveal the history of the bug, the affected vendors and their responses to this vulnerability. We will discuss the need for reforms in privacy law, the responsible disclosure system and in breach notification.

If you are an affected vendor, I suggest you contact the Privacy Commissioner of Canada and/or the Canadian Cyber Incident Response Centre for further mitigation advice.

Today I started a small twitter dust-up with Dan Kaminski, Jacob Applebaum and others after Dan Kaminski asserted via Tweet that DV (Domain Validation) needed to be moved to DNSSEC. I just couldn't let that one go by without chiming in.

Alt-Roots are to the DNS like Nuclear Weapons are to nations. They're big scary things that everyone around hopes will never ever be used -- but like the Nuclear Deterrent Alt-Roots are of extreme importance to internet geopolitical stability.

DNS is a simple system which is increasingly full of complicated politics. Some nations want to ban adult content (Saudi Arabia), others politically critical speech (Iran, China), hate speech (Canada), and linking to intellectual property (USA)... as nations we all have different thresholds for where free speech ends and censorship begins.

Right now, the USA and its delegates operate the root-zone, and most of the gTLDs. They generally wont agree to shut down specific gTLD ( example.com ) domains based on the interests of other nations. However, a recent development has emerged where the US is shutting down domains for its own censorship policy goals -- that is to combat the crime of "contributory infringement of intellectual property" (eg hyper-linking to potentially unauthorized copyrighted works). This 'crime' isn't considered a crime in most parts of the world -- especially in Canada and in Spain. Yet, recently we've seen a Spanish domain Rojadirecta.org removed from the Internet by the US in spite of its legality in our jurisdictions. Canadians are being blockaded from content that has not been found illegal in Canada and that has been specifically found legal in Spain. This seizure was an act performed as part of 'Operation in Our Sites', an action which I consider to be a US net sovereignty exercise.

The problem in this for me is that US doesn't own the root-zone, nor the GLDs -- rather, anyone can setup these infrastructures if they so choose. The ownership of these DNS properties is fiat -- that is, their only ownership legitimacy is in who agrees to use them.

Most of the Internet agreed a long time ago that we would use the US version of these properties because they had historically been doing a pretty good job. However, it hasn't all been roses and Canada has even withdrawn from ICANN and withheld funds in protest in the past due to some very questionable decision making. We've always been secure in the knowledge that we could revisit that US root decision later. This 'revisiting decision' is one of exploring alternative roots and when I recently ran for CIRA I proposed that CIRA begin to develop the infrastructure needed to deploy an alternative root, and run a public resolver service. Its policy I still believe CIRA should adopt and act upon.

Now, like the Nuclear Deterrent debate, some will argue this is dangerous. What happens if we were to actually employ an alt-root? It could, if operated cavalierly, damage the Internet in some serious ways and I don't think anyone wants to see a fractured DNS. But with that said, I think that an alt-root at CIRA is extremely important as a censorship deterrent and in a worst-case scenario where the US passes laws that effect policy in Canada, then it is an important facility for enforcing our net sovereignty. Certainly today it could be used to restore questionably seized domains like rojadirecta.org for Canadians.

So what does that have to do with Dan Kaminski, DNSSEC and DV (Domain Validation)? Well, first, the CA system today largely relies on DNS to prove ownership of a domain name. Certificate Authorities (CA's) generally send an email to the administrative contact of a domain name (found via the whois system) or require a DNS record with a verification code to be created for the domain. However, this validation activity is done from the network perspective of the certification authority. If the DNS system in their country says Joe Smith owns Google.com, then they can issue a certificate for Joe Smith as the rightful owner of Google.com. That said, I'm not aware of any nation operating an official alt-root or of any CA's relying on it, however, its a capability purposefully built into the system.

Enter DNSSEC. DNSSEC is an attempt to secure the DNS system by creating a chain of validation starting at the browser or OS's 'stub resolver' and a "root trust anchor". If the resolver's end-users are using the US root as the trust anchor, then the ability to just create an alt-root is destroyed. You could launch one, but the majority of users software would see the DNS chain as damaged and connections to sites would fail. It would be chaos. Questions abound over the root-trust-anchor and this is one of the key reasons why no major browser or OS is validating DNSSEC today -- deciding on the root trust anchor model is a hugely political decision and not one to be taken lightly.

It seems natural to ask if the trust anchor can come from the ISP? Unfortunately not, since that's precisely the layer that DNSSEC is most meant to prevent network interference within. Thus, as we move to singular-trust anchored DNSSEC we also move away from our sovereignty insurance plan.

The tying of DV to DNSSEC validated domains remains dubious though as the end-user may not trust his DNS hierarchy and results in a gap between who the DNS thinks is legitimately rojadirecta.org and the real Rojadirecta in spain. The user cannot really decide not to use this infrastructure as there are as-yet no dnssec-operating alt-roots.

Enter TACK, Convergence, Moxie Marlinspike and what I think is the future of trust authentication. TACK, (Tethered Assertions for Certificate Keys) https://github.com/moxie0/Convergence/wiki/TACK-ECC takes a more realistic view of the trust authentication world. It doesn't care what the DNS thinks, and allows the site operator, once introduced, to define a list of trusted authorities. The next time you visit, if the domain is disabled by the registry, you can simply add it back to your hosts file and continue to enjoy a secure experience as normal. It maintains the status quo separation of DNS, networking and trust assertions. It means that no matter who operates the DNS (or who filters it), you can always be secure in knowing you're talking to the same rojadirecta.org that you talked to yesterday, which is not the case with in-DNS certificates.

In the end, DNSSEC is an extremely valuable technology for securing DNS information provision, but I do not believe it can function as a CA facility given the varying network perspectives, lack of trust within the DNS system, and with the need for a legitimate alt-root option. Whats your take?

David Eaves penned an excellent post of the same name this morning ( http://eaves.ca/2011/10/21/the-state-of-open-data-2011/ ). I offer the following as another complimentary perspective on the state of the emerging Open Data field.

2011 has been a huge success for open data... there've been lots of awesome hackathons (events where every day people and programmers alike get together to use and extend government data and applications ) being hosted in BC. In-fact, there's one tomorrow at the Bard and Banker pub in Victoria.

Open Data truly has come a long way this year, but its path has also been damaged by certain events which I'll get to shortly.

So what's gone right? Well, first, governments in BC (both local and provincial) have embraced opendata in a big way. They know that citizen-centric, bi-directional government is the future. This is awesome and the Premier and Mayors from around BC must be applauded for their vision. This is space program type thinking, and shows a commitment not only to the needs of today but to building a truly participatory democracy in the future. It's the stuff people /should/ vote for and that I hope becomes the stuff of elections and, amazingly, its already happening in Victoria BC with the launch of OpenVictoria.ca.

But its not all roses and smart thinking -- While some governments have dived in head first and fully embraced the philosophy of open, others like the province itself are taking baby steps towards openness and making some critical mistakes along the way.

So what is the "Open" philosophy. Hows it different from FOI of the past, and what are governments not getting?

"Open"  contrary to popular belief isn't the act of sharing information. Its a philosophy, and its closer to a religion than it is a concrete set of rules. Open can be traced back to the early days of the Free Software Movement (F/LOSS) -- years ago, guys like Richard Stallman ran into the same problems with releasing information to the world. They said -- I want to share, to cooperate, but the law doesn't understand me. They set out to develop a legal framework for innovation. Stallman and others introduced the GPL and created the concept of Copyleft, while others introduced the BSD license, the MIT license and later licenses like the MPL and Apache License which all have different degrees of freedom and ecosystem obligations.

So what is 'Open'? To Stallman it was about access to source code, but to Open Data today it is about primary sources... what I'll call the source code of 'data'.

The Open Source Definition (OSI) includes a list of specific freedoms and today, those principles are complementarity transformed and defined for Open Data through the Open Definition. http://opendefinition.org/okd/ .

So what is the state of "Open" in government open-data? Well, some Municipalities like Surrey and Langley have embraced full-openess, and have released a significant amount of the data they hold to the public domain. No complex or revocable license terms, just public domain. On the other hand, the province has put forward the Open Government License -- which while a solid first step has made some critical mistakes in meeting the open definition.

First, "Open" is about creating market effects, competition and unintended consequences. If you can predict the outcome, its not open -- and this is where the province has made its first failure.

Failure 1: The province has not embraced license diversity and is declaring that a single license must be used for provincial open data. This restriction isn't found in the OGL license itself, but in the accompanying policy 'stack' which you can find at http://blog.data.gov.bc.ca/2011/10/the-databc-policy-stack/ .

The BC government has failed for decades by trying to define common standards and eschewing the open principle of ecosystem diversity. I still remember the days when BC government standard web development was on Microsoft Front Page and Front Page Extensions while the market was innovating with PHP, Python, Ruby and ColdFusion. The government found themselves wasting ungodly amounts of money on portal projects that were doomed to failure-by-standard before they even began. There were few successes sure, but the ones that won awards were the unauthorized skunkworks projects completed by ignoring the standards.

So what does diversity mean to the BC government? I think nearly everyone outside government recognises diversity as a critical element for long term success. Whether that's racial diversity, bio-diversity or conceptual diversity -- rational thinkers know that a marketplace of diverse ideas is better than commandments from upon high. For the PHB types, its the difference between a Market Economy and a Planned Economy. In Open Data, this means we need publisher diversity (not portals) we need license diversity (not standardized policy stacks) and we need data diversity (open, but not standardized formats).

It is what I often describe as the Saurons Ring fallacy. Governments are searching for that one ring that will rule them all. The one perfect piece of policy that can handle all circumstances. I call it policy alchemy and to me it is just as ridiculous as trying to turn lead into gold.

The BC government is searching for that ring. They have a monoculture license (which has issues that have been raised by the community), they've put extensive resources into a new portal, and are moving towards standardized formats for data publication. If achieved it would be revolutionary, we would have a perfect license, a portal overflowing with data and everything would be in perfectly useful formats. But its a pipe dream. It wont happen. It will fail. Sorry, the ring you are searching for does not exist.

In my opinion, this is the wrong path and it wont lead to "Open". Instead, the BC government and other jurisdictions attempting Open Data must truly embrace "Open" and stop trying to control everything. Be a participant not a provider. Create policy frameworks that handle the minimum legal requirements, like Intellectual Property and Privacy and Policy clearance, and then let Ministries apply those rules in whatever diverse way makes sense for their business case. Data like Hansard can never be Open in the same way that a Map can be -- and while some will try to categorize data here or there as exceptions to a rule, it is the exceptions that are key and the rule that is exceptional.

Failure 2: Data Publishing Architecture.

Civil servants around the province are passionate about publishing data and they know what free can achieve. So its time to publish, but for one reason or another data is not materializing at the needed rate. The BC data portal is adding about 1 dataset per day, and thats pretty amazing for a single team trying to seek out and claw data from ministries. By the end of any year they'll have put out ~365 new datasets -- which is -awesome-. However, how many new datasets were created by government this year? This architecture, despite how well everyone does their job, simply doesn't scale. The government could hire 100 people to clear data, and they might get up to 36,500 sets released a year -- but I'm told there are potentially hundreds of thousands of datasets held by the BC government. So how do we get them all out there? Only via Open frameworks and policies that encourage the direct participation between Ministry staff and citizens. that encourage communication of data bi-directionally at the civil servant layer. Think it can't be done? It can. The BC Social Media Guidelines are an example of this hands-off policy development going exactly right -- and they were received with great acclaim for their innovation. I'm sure people said that there would be all kinds of trouble if Socmed comments didnt go through official communcations lines... but to the contrary, the sky never fell.

Failure 3: Ignoring failures and not repeating success.

So if you believe as I do that one-size-fits-all government standards have failed for years and the new open social media standards are a huge success, then why are we not learning from our failures and successes? From the skunkworks projects that won awards or guidelines that made national news for their progressive thinking. Why are we repeating the failure architecture and not our success?

Failure 4: Getting over Cost recovery.

This failure is shared by pretty much every open-data publisher we've seen so far. If the data is being charged for, no one is stepping up to release it. At the pinnacle of insult, we cant even get the postal code database made open. From BC Laws, to DFO's Hydrographic Charts, data is extremely valuable, but charging for it is extremely costly to the government.

Rather than recovering costs, the government is costing themselves more money by not releasing data than they are by charging for it. Take the DFO Hydrographic Charts (Something known in GIS terms as S-57 ENC's). These files are massively expensive to create -- you literally need ships in the oceans and research teams, cartographers and GIS techs to make them. They're super expensive to create -- no doubt. But If we look to our US neighbours, they release all the data to the public domain. Totally free -- and the effect has been a marketplace of companies developing mapping and GIS applications for S-57 in the US. I have similar ambitions in Canada, and actually sought this data out. The agreement presented required notaries, royalty payments and access fees beyond anything that could be economicly viable for a small organization such as mine. I killed the product line after investing significant time into prototype development. Had the data been open, I may have been successful in creating a Canadian competitor to the US and other International firms, I would have made some money and the government would have got more tax dollars. Instead, they got $0 from me and Canada simply isn't an innovation leader in this area.

Beyond that, some agencies have shown what no-cost data can achieve. The BC Map Place (mapplace.ca) helps mining companies prospect, stake claims and do the research that is required for new mine development. These are typically huge companies with billions of dollars... one might think who better to charge for access to data? Wrong. The mapplace.ca has been a wild success and in the process has certainly created more mining opportunties than would have otherwise have been found. Small prospecting companies thrive in BC and new mines pay lot of taxes. If even one mine opened because of Mapplace then it brought in more than it could ever have charged to users. Progressive thinking.

So lets stop cutting off our nose to spite our face. Drop the cost for data and reap the economic rewards that come from broadly accessible data.

The State of Open Data in 2011

Depsite the failures noted above, we've also had major successes. The community around open-data grows stronger every day. Hackathons see participants from diverse backgrounds and have created some amazing apps with government data. The VanShelter app prototype is truly amazing and is a window into what can be achieved by open data. WhereDidItGo.ca, Waterly.ca, and the BC Property Tax Comparatron all stand out as amazing uses of Open Data that have emerged from OpenDataBC hackathons.

We've seen the data catalogs grow and agencies move towards greater transparency. The BC government has released several high value datasets for proactive financial disclosure and those sets now underpin proactivedisclosure.ca. This type of data release will result in unparalleled transparency and accountability and must be commended.

The province has also begun proactively publishing FOI information... which while it could be better (the data is accessible but not open licensed)... it has been an amazing turn towards transparency of data and the democratization of media. However, this transition isn't without controversy and the change draws into question the legitimacy of charging journalists high fees for FOI access when the results will be widely published. Charging one requesting user for government transparency seems grossly unfair to many folks and may actually result in fewer FOI requests being filed. The point? Traditional cost models will have to adapt to the new proactive transparency culture.

In the end the market place is developing largely as expected with successes and setbacks. Hopefully 2012 will see Open Data truly come to BC and the province correct their course towards a more diverse market economy model for open data.

Submitted for $0.02 as always.

Yesterday I launched HSTSCookie.ca as a reference implementation for Firefox 7's handling of HSTS. I'm not the first to think of using HSTS as a state machine, but I had not seen any other actual implementations to proove the theory in the wild.

So check out hstscookie.ca... It's a partial implementation and I chose only to pick on Firefox because they handle expiring HSTS info a little differently than Chrome does. In Chrome, deleting cookies will delete the HSTS information, in Firefox you have to delete 'site preferences' item. I chose not to put it on a real wildcard cert, mostly because I wanted there to be a real opt-in to try it out, but also because the cheapest wildcard cert I could find was $200 -- which is rediculus for something that costs nothing to create and only validates domain ownership.

So what does it mean for HSTS... well. It means that privacy interested users will see limited benefits from this technology. If you're like me and delete pretty much everything the browser tracks when closing the browser, then HSTS just wont add any security. The pins and sts state will disappear at shut down. On the other hand if you want the security of HSTS, you have to accept a persistent cookie policy and the tracking/privacy downsides that come with that.

In my opinion, HSTS is broken at the design level and can't be fixed in its current form. Instead, STS and Certificate Pinning should be handled in the DNS through a TXT or SRV record setup. Don't require the user's browser remember whether the site should be HSTS.

On the 28th of September two kayakers went missing near Sooke basin. My thoughts go out to their families.

I spend as much time as I can sailing the pacific north-west aboard my Macgregor 26M 'StormTide' and have grown to have a very serious respect for the ocean around Vancouver Island. Sadly, I spend much of my marina time saying 'I can't believe they're headed out right now', or 'I cant believe they're letting their child pet a wild seal'.

The pacific north-west provides some of the most beautiful coast line in the world, and there's nothing else like watching the sunset on a mooring ball and retiring to sleep on the sea. But it also contains some extreme dangers -- from currents, wind, waves and underwater rocks as well as a poorly educated boaters who do not have the appropriate level of respect for the ocean.

Just a week or so ago I saw two people on Stand Up Paddleboards, no life-jackets, outside of the Oak Bay marina breakwater by Robson Reef. The currents in that area can reach 6KN even on a calm and sunny day and just a few minutes submerged in the waters there can be deadly. A darwin award was nearly won that day.

So how do we prevent these tragedies from occurring and what is wrong with the current safety systems?

First, if you're going to be in the Pacific, you need to have a VHF radio and learn how to use it. Get your Restricted Operators Certificate (ROC-M) and obatin a GPS enabled VHF-DSC radio and a Mobile Maritime Service Identity (MMSI) number. If you are on the water regularly, it will probably save your life one day. If I made the rules, a VHF radio would be a requirement for all vessels operating in the Ocean, including Kayakers and SUP paddlers.

Next, when possible, file a float plan. (I'll get back to this shortly)... A float plan is basically telling people where you're going to go, and checking in when you return. If you're in a Kayak and out for the day, that means drawing a nice little map of where you intend to be and what time you'll be back. If conditions change, update your float plan from the water -- in an emergency the latest info is really important.

Get a Pleasure Craft Operators Card. This course is required for most boaters, and while it can be cheated extremely easily, I strongly suggest that any boater read and understand the material and genuinely participate in the program. Its clear from my time on the water, that most boaters who get their PCOC do not understand the material and dont have the collision regulations sufficiently memorized. More importantly, its also where you will discover the safety equipment you need to have on board.

Beyond that, while its not a requirement yet, all boaters should wear a floatation device at all times when the boat is moving. Theres lots of nice inflation-type vests today that will not get in the way. You should also treat your boat like your car, and know that drinking and driving on the water is as bad an idea as it is on the road. I've often had guests on StormTide complain about my no-drinking and wear a lifejacket rules -- but when challenged, show passengers how hard it is to retrieve a life-jacket from the water with a man-overboard drill. If you cant reboard a tossed-over life jacket within 3 minutes, the pacific has probably won. The danger is from hypothermia, not drowning.

So once you've got those rules figured out, check the weather and make sure conditions are appropriate for your vessel, the tide, wind, currents, etc are all extremely important to your trip, and even more so if you're in a small boat or kayak.

So whats wrong with the safety systems today?

I dont think this government is taking Maritime Safety seriously enough. We've seen the cut-backs to lighthouse keepers, whom are not just sources of information, but local experts who know how their areas respond to specific sea conditions. If you have a VHF, you can call them to get their opinion on the projections. The move towards automated lighthouses completely does away with this extremely important local knowledge.

Next the CRTC erred when they allowed the VHF radiotelephone service (previously operated by Telus) to be removed from operation. Cell-phones reduced the use and commercial viability of radiotelephone, but they do not provide GMDSS equivilent service levels. Because of this terrible decision (CRTC Telecom Order 2010-377) boaters on cruising trips can now no longer properly file float plans and close them when they arrive at their destination -- instead, they must now file a 'will try to check in if theres cell service' float plan, or contact the Coast Guard Rescue Co-ordination Center (RCC) via VHF to call off a rescue attempt initiated by concerned family members. This makes everyone less safe on the water and simply should not be the status-quo in this modern era. The government should subsidize and return the radiotelephone service to operation on safety grounds.

I would also recommend that 3g-over-water coverage be improved so that boaters can have their GPS systems report their progress to the web. During our last cruise around the southern gulf islands we regularly uploaded KML tracks recorded by our smartphones to facebook, which allowed our relatives to keep track of our progress and had their been any issue, to send help to the right place.

The government weather office is also terrible at predicting accurately. A local site BigWaveDave.ca has now become the defacto-standard in accurate weather prediction. This sad state of affairs means that when many boaters see the official warnings posted and glassy water outside, that they simply ignore the warnings as inaccurate and proceed with their boating activities, and sometimes get caught out in the storm. Accurate predictions are important for people to put trust in the system, but our government is not doing a good job predicting weather reliably. The office should hire more local staff in order to maintain more granular prediction networks, and help boaters make educated decisions about when to hit the water -- posting a Wind 15-25 warning more days than not will not achieve that goal and boaters will simply ignore the predictions.

In all, there is much that needs improvement with the safety of our pacific ocean despite our having an amazing Coast Guard and auxiliaries only moments away and ready to assist when boaters make bad choices. Hopefully it doesn't take too many more incidents like the events in Sooke for the government to start taking maritime safety more seriously.

Oh and P.S., parents, seals aren't friendly.

The 2011 CIRA election is now complete and four new directors were elected to the board. Unfortunately, I came second place on the members slate, which means I was not elected to the board this year.

I would like to thank CIRA's board members and staff for running the election in a fair and unbiased manner, and for executing the AGM so flawlessly. I would also like to thank Steve Anderson and all the OpenMedia.ca staff, Herb Lainchbury with OpenDataBC, Tamir Israel with CIPPIC, Kim Perkins, Michael Geist, Paul Andersen, Kerry Brown, Chris Parsons, Rob Wipond, David Bratzer and everyone else who really made it crystal clear that there is a democratic voice alive for Internet governance within the CIRA membership and Canadian public.

So what's next for CIRA?

The next year will be challenging for CIRA. The incoming board and staff will need to act quickly and decisively to emerging threats to our Internet while also recognizing and capitalizing on development opportunities that will lead to a safer and more secure Canadian Internet ecosystem.

Over the next year I hope that CIRA becomes more politically active, and lends their powerful voice to the Internet policy discussion occurring in this country and on the world stage. To be successful, I believe CIRA must engage in formal protests over gTLD domain seizures and must develop the tools, technologies and policies needed to protect our digital sovereignty.

CIRA must also become an advocacy organization and evangelize IPv6, DNSSEC, ENUM and all the other amazing technologies that the Canadian Internet must adopt in order to grow. They need to make big bets, and take on a complimentary role to the CRTC when it comes to Canadian Internet governance. They need to stand up for their right to communicate NXDOMAIN to Canadian Internet subscribers without ISPs interfering with their message.

Finally, CIRA must work to restore trust and security to our Internet by offering Certificate Authority services to Canadians. CIRA is uniquely situated to address this issue for all dot-ca websites, and with a little leadership could make Canada's ccTLD the most secure and an envy of the world.

I would also like to congratulate the other candidates who put their names forward for consideration and would invite you all to join in the pro-Internet policy movement which is forming in Canada. While CIRA is extremely important to our development, there are many other wonderful opportunities to build a more progressive and open Internet in Canada and I would welcome your assistance.

Thanks to all who voted for me and please stay tuned for future opportunities to support the open Internet.

Yesterday I attended the CIRA AGM, it was a flawlessly executed event featuring some really great speakers. Jonathan Zittrain took us through the history of the net and while Vint Cerf and Tim Berners-Lee were given lots of credit, mentioning the contributions of Van Jacobson would have been nice.

The meeting portion of the event ran smoothly, and the organization's finances were explained well. There was one question from the audience on lawful access that underscored how CIRA does not see itself as an advocacy organization today -- something I was very dissapointed in given that I see one of CIRA's key roles as advocacy in support of the Canadian Internet.

In-fact, on almost all of CIRA's branding today, was a consistent theme of "Have your say in shaping our internet and our future" -- CIRA's position as Canada's most democratic Internet governance organization could not have been more clear, nor could the importance of this election have been underscored any better. CIRA elections clearly matter in shaping the future of this medium.

After the meeting was Stewart Butterfield, whose presentation was funny and well put together, questions from the audience had the flickr founder pontificating on what local tech have come to know as 'business in vancouver'... I quite enjoyed his presentation.

After some draws and final notes was the networking reception. I spoke with a number of open-internet advocates, a bunch of board members a CRTC representative and a couple of the ex-officio members of the board, bringing up everything from how CIRA's board should be more active in policy development to what Canada is doing about the extremely serious issue of domain seizures.

Additionally, I was left with the impression that I have a very good chance of winning a seat on the board in this election, and that there are more allies ready to help CIRA shape policy than maybe people recognise. If elected I will be one of twelve, however, it does not appear my voice will stand alone.

On that note, voting opens today at 12 noon eastern time. Please head over to http://elections.cira.ca and cast your vote for me, Kevin McArthur. Together we truly can shape the future of Canada's Internet.

This morning CIRA notified me that I will be on the final members slate for the election - and that I tied for first place in the Show of Support phase.

A special thank you to Steve Anderson @ Open Media for nominating me and for going above and beyond in supporting my campaign. Your dedication to the pro-internet movement is truly inspiring and I hope that when I'm elected I can help do my part to "Cast an Open Net".

I would also like to thank all my other supporters and especially those who have helped me with grass roots organization of this campaign including:

Aaron Hall - Estate Agent, Macdonald Realty
Adam Withers
Andrei Tatartchenko
Annie Gibson
Bowen Moran
Caprina Valentine
Chris Parsons - PhD Candidate in Political Science, University of Victoria
David Bratzer - Founder - Scientific Victoria
David Eaves
David Metcalfe
Donna Horn
Ernie Urdal
Fergus Gibson - Owner - Sutainably Lush
Gib McArthur
Greg Britton
Herb Lainchbury - President & CEO, Dynamic Solutions Inc.
Iain McIntosh
Jay McKinnon - OpenDNA Project
Jean-Pascal Houde - Web developer / sysadmin - L3interactive
Julie Shasta MacTire - CEO - JulieScript Writing & Illustration
Kevin McArthur
Kim Perkins
Kris Constable - Director - PrivaSecTech
Liam McLachlan - YoungLions Computing
Lindsey Pinto - Communications Manager - OpenMedia.ca
Mads Rolsdorph - Developer - Dreamcloud
Paul Ramsey
Rob Wipond
Ryan Steele
Scott Leslie - Manager, Open Education, BCcampus
Sean McCaffrey
Shawn Gray - OCT Director-at-Large, Pirate Party of Canada
Shawn Vulliez - Director-At-Large - Pirate Party of Canada
Shelley McArthur - Communications Director
Stephane Bakhos - Director, Pirate Party of Canada
Travis Minaker
Tyler Battle - Software Developer - Cuttlefish Software

This would not be possible without your continued help and support -- so thank you!

The CIRA campaign forum starts tomorrow, and the vote begins on September 21st and with your help and some luck, I might just be elected!

Over a week ago it became known that the Dutch CA authority Diginotar had been compromised and certificates mis-issued by them had been seen live attacking users in the wild. Numerous other blogs have reported on various parts of this debacle, so I'll try not to re-state previous works.

Here's what you need to know.

1. This crisis is ongoing.

On August 31st Jacob Applebaum (@ioerror) reported that he had been notified that *.torproject.org was being targeted in this attack. He listed a number of serials and provided some background for how it might affect folks.

For my part, I find the torproject being targeted to be particularly interesting. Since we're not being given all the x509 data, as security researchers, we have to presume that that the certs are similar to the ones we've seen in the wild. That is, like the *.google.com certificate, which contains pointers to a CRL and an OCSP server of validation.diginotar.nl and that they have an expiry of 2 years since the signing.

Applebaum reported that he was told the certs had an exceptionally short expiration period and that they had all expired by Aug 17th. I don't beleive this claim to be likely as it deviates from the prior *.google.com cert, and was generated at the same time and in a similar way. Its far more likely they meant that they had revoked the certificates at those dates -- which as I'll get to shortly, has not happened.

On September 1, diginotar switched their OCSP server into a reversed mode. If you query for a serial number that is fictional, you'll get a revoked response, and the revoked timestamp will equal the timestamp the serial was first queried for.

For example on September 2nd, I queried their server for the serial 0x1234567890ABCDEF ... which if you query it today, you'll see that as the revocation time. If you query for a totally made up serial, you'll get the current time as the revocation time.

But what about the tor serials. It appears that they have been specifically whitelisted in the validation.diginotar.nl OCSP server. If you query for 899AE120CD44FCEC0FFCD62F6FC4BB81 for example, you'll get a OCSP response of

0x899AE120CD44FCEC0FFCD62F6FC4BB81: good
    This Update: Sep  8 09:40:05 2011 GMT
    Next Update: Sep 10 09:40:06 2011 GMT

Meaning that the cert is known to the ocsp server (they have unknown = revoked set now) and that it is being reported as GOOD.

This is quite disturbing as it indicates that the attackers certificates, if they are not expired as claimed (and that I tend to think unlikely), then they are still useful in the wild for browsers that have not been patched.

Diginotar could prove these certificates to be expired very easily by releasing the x509 data, however, short of that we have no independently verifiable reason to believe these certificates have an unusually short expiration time.

However, I also inquired on the 7e2236785477d7538e40153e8a7073db serial provided in Fox-IT's interim report. That gave an interesting answer from their OCSP server too:

openssl ocsp -issuer inter.crt -serial 0x7e2236785477d7538e40153e8a7073db -url http://validation.diginotar.nl
0x7e2236785477d7538e40153e8a7073db: revoked
    This Update: Sep  8 09:40:05 2011 GMT
    Next Update: Sep 10 09:40:06 2011 GMT
    Reason: unspecified
    Revocation Time: Sep  8 00:15:32 2011 GMT

(The revocation time being my inquiry time, indicating that this cert is not on the white-list, but was also not explicitly revoked and simply hit the catchall = revoked rule)

2. Serious allegations of an ongoing Cyber Warfare operation, with StartCom CEO Eddy Nigg ( "Lucky Eddy") saying: "No, I never imagined to take part in a state-sponsored cyber-war, but here we are." and posting a tweet - now deleted from twitter but preserved by retweet - "Run On Mean And Notoriously Insane Amok" which becomes ROMANIA when made acronym.

GlobalSign too has recently suspended, and is now talking about a Monday restoration of their certificate services, however have not yet said "the hacker's" claims hold no merit.

3. Chrome will not implement Convergence according to Adam Langley (@agl__)

4. The hacker controls codesigning certificates, and this was validated by signing calc.exe. Having codesigning ability may explain how he is able to penetrate systems.

5. There appears to be a commonly deployed Apache configuration issue that may allow someone with a rogue CA to create client certificates that will walk right past many client authentication schemes (See my prior post). This may explain certificates like Global Trustee and the repeated attempts to make very specifically named intermediate CA certificates.

6. Public security research continues to be hampered by the lack of transparency and non-publication of x509 data -- especially as it relates to the intermediate CA certificates.

7. I continue to investigate OCSP and revocation issues amongst the CA's affected. If you want to exclude my traffic look for bin2hex encoded serials with my email in them.

8. There does not appear to be a public response from Apple yet in relation to this crisis which is leading security experts to question the platforms reputation for security.

9. Mobile appears to be totally screwed, with few readily deployed update mechanisms. These devices (RIM, iPhone, Android) may be vulnerable in the wild for a very long time.

10. We have not seen the worst of this attack. So far no private key information has been publicly leaked. Yes, folks, it can, and likely will get worse.

11. The story of a single hacker from IRAN, diminishes in credibility daily. The attacks used represent significant engineering effort. If it is a single hacker, he is potentially the most skilled that has ever been publicly reported upon. The attacks instead feel much more like the Stuxnet virus authorship, and have a decidedly professional feeling to them. For example going after high value black-marketable communications certificates rather than directly usable certificates for financial organizations.

12. One scenario suggests that IRAN may be the victim here, and that the attack could have been carried out in a new attempt to sabotage their nuclear ambitions. Another scenario suggests that it could be a mercenary operation with the certs being sold to the highest bidder. (In the iran case, the government may have purchased the private key from the hacker)

In the end, we're left with more speculation than facts and a system in crisis. That SSL has been contemplated for electronic voting in Canada -- these events should now underscore the ludicrousness of that idea.

As an update to my CC system vulnerability, after a successful introduction to the issue, I am currently waiting on response from the Canadian Privacy Commissioner's Office and The Ministry of Public Safety to decide how to proceed with the publication process for my additional vulnerability against the SSL system.

More to come.