Re: [openpgp] Algorithm-specific data: problems with Simple Octet Strings, and possible alternatives

[Daniel Kahn Gillmor <[e-mail]>]

Thanks for responding, gniibe--

On Fri 2021-03-26 15:24:00 +0900, NIIBE Yutaka wrote:
> In the implementation of SOS in GnuPG 2.3-beta, it is mixture of two;
> One case is with bit-count and another case is with 8*octet-count.
> Former is used when there is no problem of leading-zero removal.  Latter
> is used to ensure no removal of leading zeros.

I think you're saying that GnuPG 2.3-beta will select between these two
choices based on the algorithm in use -- whether that's a first-order
algorithm as selected from the public-key algorithms registry, or a
distinct curve OID within a EdDSA/ECDSA/ECDH pubkey selection.

Is that right?  which choices are made in what cases?

> My (not-so-strong) proposal is to introduce SOS data type, and apply it
> for ECC (pubkey or ephemeral key, signature, and secret), so that we can
> explicitly require no removal of leading zeros to allow fixed-size data.

If we have fixed-sized data for all three of these elements for a
particular algorithm (which i expect to be the case with new elliptic
curves) then why do we need a prefix length indicator at all?

> Implementations will have to handle new representation with leading
> zeros (when interpreted as an MPI).

Are you saying that there are certificates, private keys, or signatures
in the wild that provide MPIs for existing, specified algorithms, which
have leading zero bytes, or have the MPI length specified in such a way
that it counts leading zero bits?  If so, which implementations are
producing them?

> Actually, many already do when reading data.

How do they cope with multiple representations and fingerprints of the
same key material?  I've opened
https://gitlab.com/sequoia-pgp/openpgp-interoperability-test-suite/-/issues/45
to try to gather data on how different implementations would cope with
encountering something like this in the wild (but i haven't written any
test yet, i'm hoping other folks will step up and write those tests, but
if you have code that is producing these things already, please point ot
it)

>     Minimum impact to the specification and implementations.
>
>     Compatibility, possibly encouraging better interoperability for
>     existing corner-cases (of Ed25519 and ECDH with Curve25519).

My worry is that we actually get *worse* interoperability with existing
corner cases, if we have two distinct ways to represent exactly the same
public key, and two distinct fingerprints for the same public key
material + date.

>     Flexibility, for new curves, no extra definition will be needed.

But if the octet strings for each new curve are going to use a "native"
format for that curve, then we need a definition per curve anyway.  Why
isn't it easier to just include the size in the curve-specific
definition, and not put it directly on the wire at all?

> But, I know that describing existing data of Ed25519 as weird MPI
> representation acculately ... would be difficult in a specification.

I think our current draft actually *underspecifies* a lot of what is
currently expected of an implementation.  I'm hoping we can improve
that, even if it's difficult.

> So, I don't insist much for applying SOS idea in the specification.  For
> some implementers, it would work as a technical guidance for
> interoperability to interpret existing OpenPGP data with Ed25519.

i'd love to see some concrete guidance for implementers, and some of
that could be in the spec (even if just in an "implementation guidance"
section).  But I'm worried about the impact of recommending handling of
these variant forms.

> Well, nevertheless, I believe that it's good to introduce a new distinct
> data type (if not SOS) for opaque octet string, if possible.  It will be
> useful to be friendly to not-yet-standardized things.

If we have not-yet-standardized things that ultimately do need a new
abstraction, I agree we should consider a common abstraction.  But if
this abstraction isn't going to work directly for any existing piece,
and if the main new things that we contemplate don't need any
abstraction at all (they can just be well-documented fixed-length
fields), then i'm not convinced that this particular abstraction is
useful.  Why do we need such an abstraction?

        --dkg