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

[Daniel Brown <DBrown at certicom.com>]

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

Ólafur Guðmundsson <ogud at ogud.com> wrote on
03/15/2006 10:04:10 AM:

> 
> 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
> Cfrg at ietf.org
> https://www1.ietf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg