[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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 the domain parameters defined in SEC2 or recommended in FIPS 186-2.

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


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