Re: ANN: Ada/SPARK ASN.1 implementation version 0.0.01

[Shark8 <onewingedshark@gmail.com>]

On Monday, August 1, 2016 at 2:51:56 AM UTC-6, Dmitry A. Kazakov wrote:
> I am interested in the TLS interface outline. Specifically, in how easy 
> it would be to integrate into a non-blocking socket-I/O driven architecture.

There's no outline for the TLS interface, yet. (Even though I did start a TLS project right after Heartbleed, I got stumped on a few points in the RFC [one of which was the ASN.1 OID in certificates] and pretty much abandoned it.)
 
> That means the TLS layer should write no more data than the output 
> buffer length, while keeping its internal state to continue when the 
> buffer becomes available, and the layer is called again.
> 
> Same when reading data from the input buffer, data get available in 
> chunks of arbitrary size. If the layer expects more data, it must return 
> to the caller, again, keeping internal state.

That's a good idea -- a task-type would probably fit the bill nicely, keeping its own state for every instance.

 
> This certainly would have impact on the implementation.

Very much so, but at this point I think outlining the interface would be a bit premature -- at the very least we need the interface for the security certificates, and for that we need an OID type.

> P.S. Simple Components presently use GNUTLS for HTTPS, SMTP, MQTT. It 
> would be great to have a native Ada TLS instead.

*nod* -- I've thought this for literally years, perhaps enough of the community feels the same way as us to actually help implementing it. (And it'll certainly be a good thing if we can make it as SPARK-verifiable as possible.)