[Cryptography] Is ASN.1 still the thing?

[Henry Baker]

At 11:07 AM 11/17/2017, Watson Ladd wrote:
>On Nov 17, 2017 10:59 AM, "Nico Williams" <nico at cryptonector.com> wrote:
>On Thu, Nov 16, 2017 at 10:05:42PM -0800, Bill Frantz wrote:
>> On 11/15/17 at 4:53 PM, nico at cryptonector.com (Nico Williams) wrote:
>> > As to the issues with Real values not round-tripping, well, x.509 does
>> > not use Real, so I'm not sure what he meant.  Maybe SPKI did??
>>
>> SPKI used S-expressions.
>
>IEEE754 issues are encoding-agnostic.  This kind of thing comes up all
>the time in JSON tooling, in ECMAScript, in RDBMSes, and many other
>things besides.  S-expressions wouldn't be immune.  If you want floating
>point numbers to interop and round-trip then all implementations must
>use arbitrary precision floating point software implementations.
>
>This is not exactly true.  IEEE floats don't come with a wire format but you can serialize and deserialize the fields in the float and that is specified to work.  Formats using other bases can work with the right high precision print routine.

The Common Lisp standard went to a lot of trouble to provide floating point readers & writers that could provide "round trip" assurance for simple S-expressions, even for IEEE floats as an internal representation and decimal external representation.

Thus, unless your floating point numbers are NaN's, Common Lisp provides that read(print(x))=x, bit-for-bit.
Also, print(read(x))=x, as strings, although you need to make sure that the string types are the same.

Yes, I know, this isn't trivial: you need to provide just enough decimal digits to guarantee that it will read correctly, but not so many that the function is no longer 1-1.  Yes, a strict implementation will also work correctly with gradual underflow values.

Yes, the number of decimal digits required is not constant, but varies with the floating point value.