At 9:52 AM -0400 7/17/10, Thierry Moreau wrote: >Incidentally, you say you [the design team] had good *documented* reasons for >implementing DURZ *as*you*did*. Did you document why any of >unknown/proprietary/foreign signature algorithm code(s) were not possible >(this was an alternative)? This was my outstanding question.
Thierry, can you say how using one of those alternatives would look different than the DURZ that they used? Should they all be marked as "unverfied" in a compliant DNSSEC resolver? If not, I am interested in how you think the differences would have manifest in the real world. >>Yes, they are - see http://data.iana.org/ksk-ceremony/. If there is anything >>missing, please let me know. >> > >Thanks, great. The two key ceremony scripts are what I wanted to look at. FWIW, this was *widely* publicized, particularly on mailing lists that Thierry is on. It even made the IT trade press. As a side note, I find the IT press part disturbing, given that the key signing ceremonies were just as much security theater as many of the things we like to chide on this list. >I don't have a question. I will trust the DNSSEC root signatures. However, it >seems obvious that formal dual-control rules should have been designed, e.g. a >"Trusted Courier Officer" role with a 3 out of 4 (or 5) separation of duty. >Without this, the key material has been protected only by the tamper-evident >protection in transit from the ECF to the WCF. This role would have been >limited in time. <insert chide about your criticism of the exact shade of red used on the curtains in the theater> --Paul Hoffman, Director --VPN Consortium --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com
