If you are going to do ECC it is much easier to do so by means of the defined ASN.1 encodings which are almost always supported in the crypto toolkits as a matter of course. > -----Original Message----- > From: Ólafur Guðmundsson [mailto:ogud at ogud.com] > Sent: Monday, March 27, 2006 2:32 PM > To: Daniel Brown > Cc: cfrg at ietf.org > Subject: 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 > >
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Cfrg mailing list Cfrg at ietf.org https://www1.ietf.org/mailman/listinfo/cfrg