DNSSEC is not designed to address those particular issues. X.509v3 is designed to address them, or at least is capable of doing so if configured in the right way. 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. 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. 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. 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 > -- Website: http://hallambaker.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf