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

[Ángel <[e-mail]>]

Thanks gniibe, I think this makes it clearer.

Naming it "the length of the SOS in bits" seems a bit confusing, so
perhaps better to refer differently to that.


> The important point here is: There are multiple interpretations of
> "the length of the SOS in bits".
> 
> This means that canonicalizing SOS representation is not defined by
> the SOS handling itself.

But you *do* need a canonical representation, as notedd by dkg

Seems easy to solve, though. When you a SOS like [00 02 01] or [00 08
01] specify it must be computed as its canonical representation
(i.e. [00 01 01]). Although I would prefer to just reject them as
malformed.

You would still need to support reading a SOS with zero removal and
without, switching between those depending on the algorithm (eek), but
those would be two different representations, not nine.


This specification of SOS would be backwards compatible to MPI in that
values without leading zeroes would have the same representation in MPI
and SOS, and SOS would support reading a MPI-encoded value.


Main problem seem to be the signatures, where you have multiple
MPI/SOS.
Maybe someone can test how the different implementations in the
interoperability test suite behave when seeing signatures by Alice
without zero removal?
Probably most of them will consider it broken, but explicitly knowing
that is probably be an interesting answer nevertheless.


Best regards