[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Cfrg] Defining inter operable ECC keys in for IETF protocols
Based
on the discussion that Olafur considers unrelated to the subject - I personally
recommend AGAINST using ECC in DNSEXT/DNSSEC. Because in my opinion
the drawbacks outweight the benefits.
Thank
you!
Regards,
Uri
<Standard Disclaimer - I speak for myself
only>
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