My point is not that we should try to implement ECC in v1 of the spec, or even in v2.
The possibility of using 256 bit ECC in place of 4096 bit RSA does have a very significant effect on the choices we might make for extension though and we should certainly bear them in mind. Another option we should probably consider as a low cost, low tech solution would be some sort of multiple record solution similar to the one proposed in Caller-ID. > -----Original Message----- > From: Stephen Farrell [mailto:[EMAIL PROTECTED] > Sent: Thursday, February 23, 2006 4:13 PM > To: Hallam-Baker, Phillip > Cc: Douglas Otis; [email protected] > Subject: Re: [ietf-dkim] agenda item on upgrading hash algorithms? > > > This is a long thread! > > My take is that DKIM doesn't need ECC now, and I absolutely > don't want to put it on the critical path, not that anyone's > suggesting that I hope. > > But if someone wants to go write a separate draft, later on > in the year, then the wg could consider taking that on, say > after the base is through wg last call. > > Stephen. > > PS: I would not like us to be the 1st wg to try work around > ECC encumbrances, even though I agree its probably do-able. > Getting PKIX or S/MIME or PGP or KITTEN to figure that out > first would be better IMO. > > Hallam-Baker, Phillip wrote: > > I think that we are all aware that IP owners have a duty to their > > shareholders to promote the value of their IP in the best possible > > light. > > > > We do not need point compression for our purposes. Nor is > efficiency a > > critical issue. The only crucial criteria is a bit length > of 1024 bits > > or less. > > > >> -----Original Message----- > >> From: Douglas Otis [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, February 23, 2006 3:16 PM > >> To: Hallam-Baker, Phillip > >> Cc: [email protected] > >> Subject: Re: [ietf-dkim] agenda item on upgrading hash algorithms? > >> > >> > >> On Feb 23, 2006, at 10:31 AM, Hallam-Baker, Phillip wrote: > >>>> [mailto:[EMAIL PROTECTED] On Behalf Of Scott > >> Kitterman > >>>> One of the points that DKIM currently has in its favor is > >> that it can > >>>> be implemented in all major MTAs without conflicting with the > >>>> existing licensing of those programs (both proprietary and open, > >>>> including GPL). > >>>> > >>>> I think that if DKIM were to be dependent on crypto > >> technology with > >>>> more restrictive licensing terms, it would represent a > substantial > >>>> impediment to adoption. IANAL, so I have no idea if the > >>>> representations above would present a problem or not, but > >> I do think > >>>> that we should understand the impacts of these patents on > >> the ability > >>>> of DKIM to be implemented everywhere before we proceed to > >> far towards > >>>> a solution with additional licensing considerations. > >>> The point I was making here is that we do not need CertiCom > >> to do ECC. > >>> Certicom have a number of patents relating to ECC, the > earliest of > >>> which was filed in 1997. Practical means of performing ECC were > >>> published in 1985. > >> ECC is attractive from a performance standpoint, but not without > >> problems. > >> > >> Quote from Certicom Inc. > >> http://www.certicom.com/index.php?action=ip,keygen > >> --- > >> The security of public-key systems rests on keeping the > private keys > >> secret. Recent discoveries have revealed that the presence > of a bias > >> in the process of generating private keys may leak > information about > >> the private key into the public key. As an example, a > recent attack > >> on a system with a biased key-generation process obtained > information > >> about the private key by examining a number of signatures. The > >> attacks work against such discrete-log-based signature > schemes as the > >> DSA and the ECDSA. One patent protects against this attack by > >> teaching methods of eliminating bias in the generation of private > >> keys or per-message secrets. One such method comprises testing the > >> hashed output of a random-number generator against preset criteria > >> (determined by the order of the group underlying the cryptosystem). > >> If the output fails the test, the pre-hashed value is > modified by a > >> deterministic amount, hashed, and retested until the output passes > >> the test. > >> --- > >> > >> There is a good papers at: > >> http://www.secg.org/?action=secg,docs_draft > >> > >> Certicom's extensive portfolio of patents related to > elliptic-curve > >> cryptography, and the extensive IPR claims affecting IETF > protocols > >> using the elliptic-curve algorithms seems to suggest avoiding > >> Certicom may not be that easy. > >> Their royalty-free license, if granted for DKIM, does not > seem overly > >> problematic. Certicom also provides a developers kit. Is > there safe > >> elliptic-curve cryptography code available known to be free of any > >> IPR restrictions? > >> > >> -Doug > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > > > _______________________________________________ > > NOTE WELL: This list operates according to > > http://mipassoc.org/dkim/ietf-list-rules.html > > > > > _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
