der: support for the `REAL` type

[ChristopherRabotin]

Hi there,

I'm seriously considering using your library to encode lots of f64 data (cf. https://github.com/anise-toolkit , and specifically this flatbuffer example: https://github.com/anise-toolkit/specs/blob/1-draft-0-0-1/ephemeris.fbs ).

I'm brand new to ASN.1, so please excuse novice questions. According to a copy of some specs I found here, https://www.oss.com/asn1/resources/books-whitepapers-pubs/larmouth-asn1-book.pdf, section 2.4 (page 83) talks about a REAL type. The ASN.1 playground also uses that type in their default example: https://asn1.io/asn1playground/ .

However, I don't see it in the docs as one of the supported type (https://docs.rs/der/latest/der/asn1/index.html).

Is the REAL type not supported in DER encoding? Or has it not yet been implemented in this library because it isn't needed for the crypto algorithms?

Thanks

[tarcieri]

I am not familiar with a DER encoding of ASN.1 REAL.

DER encodings are intended for cryptographic applications and MUST be canonical. Canonicalizing f64 in general seems like a tricky problem.

You likely want BER instead, which this crate purposefully does not support so as to stay laser-focused on DER.

[ChristopherRabotin]

Interesting. What is the reference you're using for DER so I can make sure to adhere to that?

For those who need this, one can rebuild the floating type as per the specs using the following ASN.1 definition, which looks canonical to me, but maybe I'm missing something:

ANISE DEFINITIONS AUTOMATIC TAGS ::= 
BEGIN
  Normal ::= SEQUENCE       
  {                                                     
     mantissa INTEGER DEFAULT 0,
     realbase INTEGER DEFAULT 10,
     exponent INTEGER (-32..32) DEFAULT 0
  }

Subnormal ::= ENUMERATED {
    plus-infinity,
    neg-infinity
}   

Real ::= CHOICE {
    as_normal Normal,
    as_subnormal Subnormal
}                                                                                                 
END

The following works for the encoding of Pi:

realdata Real ::= as_normal : {
mantissa 3141592653589793,
realbase 2,
exponent 14
}

This works in the playground and is oddly slightly more efficient in the encoding of a Real than the default implementation of the playground.

[tarcieri]

DER is defined in ITU X.690

[ChristopherRabotin]

Section 11.3 specifies DER for Real values. Can we reopen this issue?

[tarcieri]

Okay, sorry I guess I missed that.

If you'd like it implemented you'll have to contribute the implementation yourself. Our use cases are all cryptography, and given that floating point support is very much outside our purview.

[ChristopherRabotin]

Hi. Could you give me some tips on how I would go about starting the implementation of that type? Thanks

[tarcieri]

You can look at the other ASN.1 type definitions here for examples: https://github.com/RustCrypto/formats/tree/master/der/src/asn1

You’ll need to implement the same set of traits as the types in those modules.

[ChristopherRabotin]

Hi there,

I've started the decoding implementation and had a design question I was hoping you could provide some guidance on.

As per the specs of the exponent encoding (below), it seems to me that the exponent can be encoded on several octets/bytes. However, the IEEE 754 standard (as implement in Rust as f64) only supports 11 bits of exponent.

Question: how would you prefer this to be designed?

1. One way would be to return an error if the exponent cannot be encoded on the 11bit allowed by IEEE-754. If that's the recommendation, do you know what's the simplest way to rebuild the bytes from the sign bit, the exponent, and the mantissa?
2. Another way would be to convert each component as an f64 and then call powf on that f64 and multiply that result with the other parts of the value. The main problem here is that der is no-std and therefore rustc does not allow me to use powf. Further, off the cuff, this seems like a waste of operations because if the exponent does not fit in the 754 format, then why even go further since, at the very best, we'll have a totally different number stored.

Looking forward to reading your advice, thanks.

[tarcieri]

One way would be to return an error if the exponent cannot be encoded on the 11bit allowed by IEEE-754. If that's the recommendation, do you know what's the simplest way to rebuild the bytes from the sign bit, the exponent, and the mantissa?

You should be able to construct a u64 with the desired bit representation and then use f64::from_bits to safely transmute it to a float.

[ChristopherRabotin]

How do you understand section 8.5.8? The ISO 6093 NR3 format seems to me like a string representation of a floating point value (cf. page 7 of this PDF). I would be immensely surprised if that's what ASN.1 had in mind for a base 10 encoding given how optimized the base 2 encoding is. Further, from section 2.4 of this PDF, the general idea of ASN.1 real encoding is to encode the value on three integers {x, y, z} such that value = x * (y^z), where y is either 2 or 10 in DER.

Thanks for your help

[tarcieri]

There's some discussion of the BER encoding here:

https://stackoverflow.com/questions/4975005/how-should-i-interpret-the-asn-1-ber-standard-for-reals

It indeed does appear to be a string encoding. That's not too far off from the encoding of types like UTCTime and GeneralizedTime.

It appears that 1.0 is encoded as:

[0x09, 0x08, 0x03, '+', '1', '.', '0', 'e', '+', '0']