On 7/21/2010 8:12 PM, Phillip Hallam-Baker wrote: > DNSSEC is not designed to address those particular issues.\ AMEN > X.509v3 is designed to address them, or at least is capable of doing > so if configured in the right way. True - if its used correctly. > Now the question I think we should consider is what is going to happen > when all the people who read ICANN press releases that essentially > tell them that DNSSEC is capable of serving these security needs start > relying on the assumptions. They will see ICANN's commentary and simply bring suit in California Court now that Khaled opens that can of worms where the IETF refused to allow those issues to be resolved. If the DNSSEC model doesnt pass muster there it's toast and I think we all know what would happen... > My strong belief is that the Internet needs one PKI not two and that > we should start looking about how to use the combination of DNSSEC and > X.509 so that we get the best from both. When people suggest using > DNSSEC for the type of purposes that they have previously used self > signed certs I do not get worried. But when they start suggesting > using DNSSEC as a replacement for cases where you need non-repudiation > or accountability, I get very worried. So in Khaled is Redflex is trying to 'have the ruling unpublished' claiming that they could have meet these requirements if they had been given the chance, but the real issue here is whether the Court has an obligation to hear claims about the process from third parties with a financial interest in the matter. Also Redflex was the party who captured that photo so it was aware of the whole court process for that matter and chose not to attend. As such it was Redflex's issue about not being there. So assume DNSSEC is attacked in a California District Court as 'non-functional from an evidence perspective' which is something very possibly and probable today. You realize that Khaled affects all of the Businesses everywhere in the 4th District's sphere of influence and Jurisdiction? > > I would strongly suggest that anyone who is interested in the legal > side of technology take a look at the case whether they consider it > relevant to DNSSEC or not. > > http://www.thenewspaper.com/rlc/docs/2010/ca-khaled.pdf > > My reading of the case is that the appeals court knows that there are > much better processes and technical means that could have been used to > protect the chain of custody for the evidence in that case and they > want to ensure that their concerns are urgently attended to. Meaning if DNSSEC is flawed - there are now precedents which can be used easily in California Courts to make DNSSEC a nightmare come true... I think the application of the ruling is dead on which is why I posted it and I am also sure it will seriously annoy many Sr. Professional IETF Standards people since it totally rains on their parade but since they refused to address these issues or even allow the discussion of these issues long ago - the IETF is once again standing waste deep in its own sh*t. Sorry folks but reality is what it is and it that is that it's law that shapes technology not the reverse. Todd > > On Wed, Jul 21, 2010 at 8:09 PM, todd glassey <tglassey@xxxxxxxxxxxxx> wrote: >> On 7/21/2010 1:41 PM, Peter DeVries wrote: >>> Todd, I just read the ruling on this and am confused as to why you >>> would think this applies to DNSSEC rather than DNS (or other >>> information systems). >> Because I read the opinion and looked at what the idea of trustworthy >> meant to the court. Something that is really really different than what >> technical people think trustworthy meets. >>> The reason this case was unable to proceed and >>> the evidence was rejected seems to be because of the police handling >>> of the system and witness. The ruling specifically states that >>> video/evidence capture devices are still admissible (See section II >>> "analysis") as long as timeline and/or "reasonable representation of >>> what it is alleged to portray." is available. >> So then the time-service and sequence of events would need to be >> provable... I totally get that. >>> The problem is that the officer made available to the court had no >>> firsthand knowledge of the incident, no understanding of the system, >>> no knowledge of the time of information handling, and no internal >>> knowledge of the development / testing of the system >> Yep... >>> Either this applies everywhere and DNSSEC is not unique or it applies >>> nowhere as the data path will be further confirmed by >>> administrator/operator knowledge. >> Bingo - it applies everywhere. But the idea of DNSSEC being a solution >> to the issue of evidence capture regarding any and all processes >>> Can you explain in more detail with specific references as to how this >>> applies to DNSSEC or IS systems as a whole. I fail to see your >>> concern. >> It applies to everything that creates data which could come to be >> reviewed by a court. >>> Also, operations is separate from prosecution. DNSSEC has >>> other purposes than prosecution and can most certainly be operated >>> within this ruling. I don't personally see issues with prosecution as >>> long as the witnesses understand and explain how the situation was >>> handled. >> The problem is the integrity of the data model and whether it produces >>> BTW, the appeals case number I read is: 30-2009-00304893. Please let >>> me know if there is another case you are referencing. >> No that's it. >>> Peter >>> >>> On Wed, Jul 21, 2010 at 3:56 PM, todd glassey <tglassey@xxxxxxxxxxxxx> wrote: >>>> Folks - there is a Court Ruling from the 4th Appellate District which >>>> is turning off Red Light Camera's everywhere and there is a question as >>>> to whether that ruling would also effect how Secure DNS Services are run >>>> and if so what would it do. >>>> >>>> The ruling is called California v Khaled and is getting significant >>>> traction here in the State of California in all courts. >>>> >>>> Todd >>>> >>>> _______________________________________________ >>>> Ietf mailing list >>>> Ietf@xxxxxxxx >>>> https://www.ietf.org/mailman/listinfo/ietf >>>> >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf >> > > _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf