Subject: Re: [dnsext] WGLC: Elliptic Curve DSA

From: bert hubert <[email-masked]>
Date: Fri, 8 Jul 2011 13:08:28 +0200

On Wed, Jul 6, 2011 at 11:17 PM, Olafur Gudmundsson <[email-masked]> wrote:
> Please review the document and sent a statement that you reviewed the
> document. =A0If the review raises any issues, please note what they are.
> Remember that we need a minimum of 5 reviewers.

I have read this document and also the other reviews. I think this
document should go ahead, with two clarifications, one of which is
new.
The first clarification is moving up the definition of ECDSA, but this
has been noted already and Paul is going to fix it.

The second one is that the document describes a signature as 'r|s'. In
such cases, an implementor is always left wondering where r ends and s
begins. In the case of 'r' and 's' both needing their full amount of
bits, this is easy - the '|' goes exactly down the middle.

But it is possible that either r or s fits in one octet less (or more
even!). The same goes for x and y.

It is helpful therefore to add a sentence that r and s are both
left-padded to their full length or, alternatively, that r and s
occupy the same number of octets in an answer (and the same goes for x
and y).

PowerDNS already includes support for ECDSA in the 3.0 prereleases,
and we use the 'cut down the middle' rule.
http://wiki.powerdns.com/trac/browser/trunk/pdns/pdns/cryptoppsigners.cc#L1=
19

But I'd love to see some text that makes it official. A suggestion
might be as the new third paragraph of section 4:
"Implementations will ensure that when concatenating the halves of a
coordinate, each half takes up the same amount of octets, allowing for
the unambiguous reconstruction of the coordinate on reception".

   Bert

---

From: Miek Gieben <[email-masked]>
Date: Fri, 8 Jul 2011 14:27:27 +0200

[ Quoting bert hubert at 13:08 on July  8 in "Re: [dnsext] WGLC: Elliptic Curve D"... ]

> the unambiguous reconstruction of the coordinate on reception".

I've read the draft and support its publication, but I also like to
see the text propposed by Bert to be included.

Regards,
    Miek

---

From: "W.C.A. Wijngaards" <[email-masked]>
Date: Sat, 09 Jul 2011 12:34:19 +0200

> see the text propposed by Bert to be included.

I have not actually checked this, but the bit length of P256 and P384
are divisible by 8 (divisible by 64 even).  Hence the width of these
variables in octets is a whole number of octets?

Are you proposing some sort of variable length encoding?  I would prefer
simplicity.

Best regards,
   Wouter

---

From: Michael StJohns <[email-masked]>
Date: Sat, 09 Jul 2011 11:01:10 -0400

Note below.

At 06:34 AM 7/9/2011, W.C.A. Wijngaards wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1

I'm pretty sure what Olafur is saying is that one possible encoding for an integer is no leading zeros, or additional leading zeros if the high bit is set.    e.g. 00000056abcd1234.... 56abcd1234).  You want to be clear that the point is encoded as 2N octets, where N is 16 for P256 and 24 for P384.

I'm coming to this late, otherwise I would have strongly recommended using the well-defined point encoding from X9.6 - of 2N+1 where the first octet is 04 to indicate uncompressed.  The saving of one byte seems to be short-sighted as this is yet another form of public key that tools will have to understand - pretty much every tool/library I know of will require the "04" be prepended to the key bytes before the key can be loaded for verification.  (See RFC 5480, section 2.2 for better text on how to do the encoding)

Mike

---

From: Miek Gieben <[email-masked]>
Date: Sat, 9 Jul 2011 19:07:29 +0200

[ Quoting Michael StJohns at 11:01 on July  9 in "Re: [dnsext] WGLC: Elliptic Curve D"... ]
> I'm coming to this late, otherwise I would have strongly recommended
> using the well-defined point encoding from X9.6 - of 2N+1 where the
> first octet is 04 to indicate uncompressed.  The saving of one byte
> seems to be short-sighted as this is yet another form of public key
> that tools will have to understand - pretty much every tool/library
> I know of will require the "04" be prepended to the key bytes before
> the key can be loaded for verification.  (See RFC 5480, section 2.2
> for better text on how to do the encoding)

+1

I now understand why my ecdsa library has Marshal/Unmarshal functions,
and why I could not use them in this case.

Regards,
    Miek