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

[Hallam-Baker, Phillip]

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.



> -----Original Message-----
> From: ietf-dkim-bounces at mipassoc.org 
> [mailto:ietf-dkim-bounces at mipassoc.org] On Behalf Of Scott Kitterman
> Sent: Thursday, February 23, 2006 12:59 PM
> To: ietf-dkim at mipassoc.org
> Subject: Re: [ietf-dkim] agenda item on upgrading hash algorithms?
> 
> On 02/23/2006 12:16, Douglas Otis wrote:
> > On Feb 22, 2006, at 7:52 PM, Douglas Otis wrote:
> > > On Feb 22, 2006, at 6:47 PM, Hallam-Baker, Phillip wrote:
> > >> In rebuttal to Doug's point about not depending on the DNS 
> > >> supporting longer key sizes, an ECDSA key that gives equivalent 
> > >> strength to a 128 bit symmetric cipher is 256 bits with point 
> > >> compression and 512 bits without. An equivalent ECDSA 
> signature is
> > >> 512 bits in either case. The comparable key size for RSA is 3072 
> > >> bits for key and signature.
> > >
> > > This looks great, but at what price?  From what other companies 
> > > beyond Certicom Inc. would licenses need to be obtained 
> in order to 
> > > support the EC algorithm?  Is there any information with 
> respect to 
> > > existing terms?
> >
> > As a follow-on:
> >
> > Certicom may grant royalty free licenses in some cases.
> >
> > http://www.certicom.com/download/aid-545/IETF.pdf
> >
> > http://www1.ietf.org/ietf/IPR/IETF-2006Jan26-Certicom-IPR.pdf
> >
> > http://www.ietf.org/ietf/IPR/certicom-ipr-rfc3526-rfc2409-ikev2.txt
> >
> > http://www.ietf.org/ietf/IPR/CERTICOM-SMIME
> > http://www.ietf.org/ietf/IPR/certicom_smime_license.pdf
> >
> > http://www.ietf.org/ietf/IPR/CERTICOM-IPSEC-ECC
> >
> > http://www.ietf.org/ietf/IPR/CERTICOM-ECDSA
> >
> 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.
> 
> Scott K
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
>