Re: [openpgp] patch for EdDSA key packet formats

[Taylor R Campbell <[e-mail]>]

> Date: Tue, 14 Feb 2017 20:30:19 +0900
> From: NIIBE Yutaka <[e-mail]>

Hi, Niibe-san!  Thanks for the review.

> > @@ -1936,8 +1936,9 @@ A version 4 packet contains:
> >             - the octets representing a curve OID, defined in
> >               section NN{FIXME};
> >  
> > -      - a MPI of an EC point representing a public key Q as described
> > -        under EdDSA Point Format below.
> > +      - a MPI, encoded as described under EdDSA Point Format, of an EC
> > +        point A, in the notation of [](#I-D.irtf-cfrg-eddsa),
> > +        Section 3.2 "Keys".
> 
> I think that the expression "an EC point A" would not be good.  In RFC
> 8032, Section 3.1 "Encoding" explains about ENC(), the little-endian
> encoding, and Section 3.2 "Keys" says:
> 
> 	The EdDSA public key is ENC(A).
> 
> ... where A is an EC point.
> 
> We put the prefix 0x40 to ENC(A), it is not entirely same of
> the notation of Section 3.2 "Keys".

Right, but in RFC 8032, the letter `A' does mean a point on the curve.
What my text says is that we encode the point A using the encoding
described below in the Section 13.3 `EdDSA Point Format'.  This is not
the same as storing the RFC 8032 public key, which is the point A
encoded as ENC(A).

It may be that the Section 13.3 `EdDSA Point Format' encoding is
actually 0x40 || ENC(A), but I'm not sure offhand.

> > @@ -2034,8 +2035,8 @@ The packet contains:
> >  
> >      Algorithm-Specific Fields for EdDSA keys:
> >  
> > -      - MPI of an integer representing the secret key, which is a
> > -        scalar of the public EC point.
> > +      - an opaque octet string k, in the notation of
> > +        [](#I-D.irtf-cfrg-eddsa), Section 3.2 "Keys".
> 
> Right.  It's not a scalar of the public EC point.  It is the one
> which generates the scalar.
> 
> In my opinion, "MPI of an integer representing the secret key" is not
> wrong.

You are probably right!  I'm afraid I neglected to write notes when I
prepared the patch, so I forgot where in the code I should have cited
for that.  Do you have a quick reference to the source code in
libgcrypt or gnupg that handles encoding this?