Re: [openpgp] ECC point encoding and "flag byte"

[Ángel <[e-mail]>]

On 2021-03-04 at 09:08 +0100, Werner Koch wrote:
> On Wed,  3 Mar 2021 23:38, Ángel said:
> 
> > > In this situation, it's good to have a data element which can
> > > represent **something in native format** (or anything,
> > > hopefully).
> > 
> > No, you can't. Or rather, I expect it is an issue of terminology :-)
> 
> He meant in the algorithm/protocol/curve native format.  In fact we
> already use the term "Native point format of the curve follows" in
> the ECC point compression flag bytes.
> 
> > On the other hand, if you mean an opaque blob private to the
> > algorithm,
> > that's perfectly fine (and what's already there, I think) *but* you
> > need to define it anyway, it doesn't matter if it's in the OpenPGP
> > spec
> 
> The algorithm/protocol/curve already defines this.

Thanks Werner. I kinda expected that Niibe meant something like that.
But it needs to be stated more clearly.


I think the text should be something like this:

> Algorithm-Specific Part for ECDSA Keys
> The public key is this series of values:
> 
> 
> a variable-length field containing a curve OID, formatted as follows:
> 
> 	a one-octet size of the following field; values 0 and 0xFF are
> reserved for future extensions,
> 
> 	the octets representing a curve OID, defined in {{ecc-curve-oid}};
> 
> a variable length field containing curve-specific octets,
> representing a public key.
> 
> 
> The secret key is this single multiprecision integer:
> 
> a variable length field containing curve-specific octets,
> representing the secret key, which is a scalar of the public EC point.

And then another section like:

#### Curve-specific octets

For Curve25519: a block of 32 bytes which encode a scalar in the way
defined on section 5 of rfc7748.
For Curve448: a block of 56 bytes which encode a scalar in the way
defined on section 5 of rfc7748.

For NIST P-256:
...



(I used the term Curve-specific octets rather than Strange Octet String
in the draft, trying to keep it more obvious, albeit it's probably
still under-specified)


Best regards