Olafur, the advantage of Brainpool curves is the fact that all parameters are generated in a verifiably pseudo-random way. This topic has already been an issue in other WGs, see e.g. https://www.ietf.org/mail-archive/web/tls/current/msg10054.html
>Why are you defining 3 curves ? Again, I'm looking at it from a security perspective: 256/384 bit ECC is fine for the next couple of years (NSA requires using 384 bit for "top secret" data today, see http://www.nsa.gov/ia/programs/suiteb_cryptography/index.shtml). In my opinion, having an additional curve with a security margin ready for use is worth sacrificing one out of 230 code points. >Defining more algorithms decreases interoperability as code bases need to pick >up all algorithms. >While you talk about German regulations wanting some curve, that does not mean >that they can mandate any domain to use it. Thus the issue of what german >regulations use for health care cards is orthogonal to what is used by DNSSEC. >If all you want is to publish German health Insurance Card keys in DNS then >ask for a "Gesundheit" record to publish the keys, and then the consumption of >these records only affects the those that need to process the keys. True, the German regulations cannot mandate anything to this WG and it's also true that they could have a special "Gesundheit" standard/extension that has to be used within the German infrastructure. However, I don't think it would help the interoperability issue to add a parallel definition for signatures. Further, I believe that having a comprehensible set of curve parameters might be a welcome option for others. Best, Jörn _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
