why is GPG_ERR_SEXP_ZERO_PREFIX an error for gcry_sexp_canon_len()?

[Daniel Kahn Gillmor]

Thanks for the response Werner--

On Wed 2019-05-15 08:27:22 +0200, Werner Koch wrote:
> On Tue, 14 May 2019 16:56, dkg at fifthhorseman.net said:
>
>> Can someone who understands S-Expressions better than me point me to
>> documentation that will help me understand why gcry_sexp_canon_len()
>> should treat this as an error?
>
> From the specs: http://theory.lcs.mit.edu/~rivest/sexp.html
>
> | 10. Utilization of S-expressions
> | 
> | This note has described S-expressions in general form.  Application writers
> | may wish to restrict their use of S-expressions in various ways.  Here are
> | some possible restrictions that might be considered:
> | 
> | 	-- no display-hints
> | 	-- no lengths on hexadecimal, quoted-strings, or base-64 encodings
> | 	-- no empty lists
> | 	-- no empty octet-strings

Hm, i don't see this text on that webpage at all.  Can you tell me where
you're getting it from?

Wherever it came from, this doesn't read like an actual justification to
me, though: there is no explanation of why that might be a good or
useful restriction, or what contexts it might be appropriate to do so or
not.  It's just a statement (presumably from an authority) that says
it's ok to constrain in some contexts.

But the choice gcrypt makes is also inconsistent with this list -- why
say "no empty octet-strings" but not "no empty lists", for example?

0 dkg at alice:~$ printf '()' | dumpsexp 
00000000  28 29                                             |()|
0 dkg at alice:~$

Moreover, on:

     https://people.csail.mit.edu/rivest/Sexp.txt

it says:

>>> 4. Octet string representations
>>> 
>>> This section describes in detail the ways in which an octet-string may
>>> be represented.
>>> 
>>> We recall that an octet-string is any finite sequence of octets, and
>>> that the octet-string may have length zero.

So i still don't understand the rationale, and would appreciate a
clearer justification.  what is the benefit here?  what risks would we
see if gcry_sexp_canon_len() *didn't* treat that as an error?  What are
the implications for interoperability with other tools that use
S-expressions that may or may not have chosen the same representations?

        --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gcrypt-devel/attachments/20190517/02792e96/attachment.sig>