Subject: [Cfrg] Defining inter operable ECC keys in for IETF protocols

From: Ólafur Guðmundsson <[email-masked]>
Date: Wed, 15 Mar 2006 10:04:10 -0500

I apologize for this open ended question but the WG I co-chair DNSEXT
has added security extensions to the base DNS protocol (DNSSEC),
currently RSA/SHA1 is the main signing algorithm. DSA is also
defined. DSA is reaching end of life, safe RSA signatures and keys are
large.

As DNS messages are carried over UDP packets there is interest in being
able ECC due to the fact the keys and signatures are much smaller.
A proposal has been made for a ECC key format.
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-08.txt

Our worry is that the format proposed is open ended and people can
publish/use keys in fields that the rest of the world can not use due
to lack of support in common crypto libraries.

What the DNSEXT working group is looking for is some guidance on how
to create a SHORT list of fields/curves to use by ECC in the DNS context
and/or wider IETF context.

Nice feature: In the DNS world we are more interested in keeping
Verification time down than signing time, RSA with small exponent is quite
nice in this regards. I do not know if the choice of ECC variant has any
impact on the difference between signing and verification time.
If due to the shorter length of ECC key the signature verification times
are on-par with equivalent strength RSA key this is a non issue.

In some environments due to the large number of signatures that need to
generated in short time, hardware implementations might be required.

Any guidance will be greatly appreciated.

	Olafur 

_______________________________________________
Cfrg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/cfrg

---

From: Yvonne Cliff <[email-masked]>
Date: Thu, 23 Mar 2006 12:06:32 +1000 (EST)

> and/or wider IETF context.

Have you looked at the existing standardized NIST and SECG curves?

NIST (National Institute of Standards and Technology), US Department of 
Commerce.  FIPS 186-2, digital signature standard (DSS).  Federal 
Information Processing Standard (FIPS), January 2000. 
http://www.csrc.nist.gov/publications/fips

SEC 2. Recommended Elliptic Curve Domain Parameters. Standards for 
Efficient Cryptography
Group, September, 2000. Working Draft. Available from: 
http://www.secg.org/

> impact on the difference between signing and verification time.

ECCs are based on the discrete logarithm problem (in an EC group), not a 
factorization problem, so one would use EC-DSA for signing, for example. 
This does not have a verification time as fast as RSA.  For timings, see:

http://indigo.ie/~mscott/

Regards,
Yvonne

-------------------------------------------------------------------------------
Dr. Yvonne Cliff
Research Associate
Information Security Institute
Queensland University of Technology
126 Margaret Street
GPO Box 2434
BRISBANE        4001
E-mail: [email-masked]
ABN:  83 791 724 622
CRICOS No 00213J
-------------------------------------------------------------------------------

---

From: Daniel Brown <[email-masked]>
Date: Thu, 23 Mar 2006 11:09:18 -0500

Dear Olafur,

1. The set of 15 different ECC domain parameters in FIPS 186-2 would be a 
good starting point for the short list you're seeking.

2. Formats for ECC public keys and certificates are already defined in 
SEC1, ANSI X9.62/63, and IETF PKIX.  (IEEE P1363, TLS and IKE also have 
extra formatting.) It would make sense to re-use these existing formats, 
especially the ASN.1 syntax, for DNSEXT.   The necessary ASN.1 syntax is 
simple enough to implemented with templates rather than a full ASN.1 
parser, if needed.  If the DER encodings of ASN.1 in these formats is too 
bulky for DNSEXT, then perhaps PER encoding could be used, and failing 
that some custom encoding of the ASN.1 could be used. A significant 
advantage of the existing formats (ASN.1, TLS and IKE) is the ability to 
refer to ECC domain parameters by name (with an OID or integer 
identifier), rather than explicitly defining all the details of the 
elliptic curves.  This helps keeps the key sizes smaller.  The domain 
parameters are namable in this way are usually from a fixed set, such as 
the domain parameters defined in SEC2 or recommended in FIPS 186-2. 

Thanks,

Dan Brown
(905) 501-3857
http://www.certicom.com

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Mon, 27 Mar 2006 14:32:21 -0500

At 11:09 23/03/2006, Daniel Brown wrote:

>Dear Olafur,
>
>1. The set of 15 different ECC domain parameters 
>in FIPS 186-2 would be a good starting point for 
>the short list you're seeking.

Thanks, I was hoping for an even shorter list :-)

>2. Formats for ECC public keys and certificates 
>are already defined in SEC1, ANSI X9.62/63, and 
>IETF PKIX.  (IEEE P1363, TLS and IKE also have 
>extra formatting.) It would make sense to re-use 
>these existing formats, especially the ASN.1 
>syntax, for DNSEXT.   The necessary ASN.1 syntax 
>is simple enough to implemented with templates 
>rather than a full ASN.1 parser, if needed.  If 
>the DER encodings of ASN.1 in these formats is 
>too bulky for DNSEXT, then perhaps PER encoding 
>could be used, and failing that some custom 
>encoding of the ASN.1 could be used. A 
>significant advantage of the existing formats 
>(ASN.1, TLS and IKE) is the ability to refer to 
>ECC domain parameters by name (with an OID or 
>integer identifier), rather than explicitly 
>defining all the details of the elliptic 
>curves.  This helps keeps the key sizes 
>smaller.  The domain parameters are namable in 
>this way are usually from a fixed set, such as 

ASN is a dirty word in the DNS community but we have used ASN identifiers
in some cases (CERT RR).
The current draft 
http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ecc-key-08.txt
has a compact format with lots of flexibility.
What I expect is that ECC keys will be encoded in even more compact way
when defined for use in DNSSEC.

         Olafur