Re: [dnsext] draft-hoffman-dnssec-ecdsa-04

[Miek Gieben <[e-mail]>]

[ Quoting <[e-mail]> in "Re: [dnsext] draft-hoffman-dnssec-e..." ]
> 
> => in fact they can get leading zeros so not the length you expect.
> IMHO the critical thing is (quoting the I-D):
>    For P-256, each integer MUST be encoded as 32 octets; for
>    P-384, each integer MUST each be encoded as 48 octets.

Ah, I completely missed that and now I know way: browser caching :(
Thanks.

> >  * Section 6: In the examples the privatekey file is shown. I
> >    haven't seen (or can't remember) this in any previous RFC
> >    specifing new algorithms for DNSKEYs. Also all other (DSA/RSA)
> >    .priv key files (as generated by BIND) put the public key info
> >    in the .priv file, this one is an exception. Why?
> 
> => RFC 5933 (about GOST for DNSSEC, which is BTW another EC stuff).

Ok, so we are stuck with that.

> PS: as far as I can see the example is hard to use to test code:
> the only thing you can do is to validate old/expired signatures...
> PPS: the crypto answer is Q = dG so the public key Q is trivial to
> compute from the private key d and the curve parameters (which
> includes the generator G).

Thanks for you answers.

 Regards,

-- 
    Miek Gieben