ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] agenda item on upgrading hash algorithms?

2006-02-23 14:14:51

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:dotis(_at_)mail-abuse(_dot_)org] Sent: Thursday, February 23, 2006 3:16 PM
To: Hallam-Baker, Phillip
Cc: ietf-dkim(_at_)mipassoc(_dot_)org
Subject: Re: [ietf-dkim] agenda item on upgrading hash algorithms?


On Feb 23, 2006, at 10:31 AM, Hallam-Baker, Phillip wrote:
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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

<Prev in Thread] Current Thread [Next in Thread>