ASN.1 definitions drafted
15 May 2019In my first update, I mentioned that I was considering solving the encoding problem by writing ASN.1 definitions for the protocol, and using one of its encoding schemes. Since then, I've been working on writing such definitions, and I've now finished a first draft of them, which you can read at https://code.freespoken.nz/diffusion/1/browse/master/asn.1/
As I suspected it might, ASN.1 has made it easier to specify precisely what data should be used as the input to cryptographic hash and signature functions, without forcing instances to store any of the exact strings of data that they send each other.
ASN.1 has also made it a bit easier to make changes to the protocol without having to rewrite my English prose until I've made a final decision on those changes. But I do now need to do that, so that the PDF specification matches the ASN.1 code. This is the next thing I plan to do.
One thing that ASN.1 did make me think a little harder about was how to allow for permissionless extensibility of the protocol. With JSON, whose objects use strings as keys, I was hoping that people could experiment with, say, demurrage, by using the string "demurrage" as a key in a JSON object. This would be unlikely to clash with someone else's experiment using the key "dividend", for example.
But most of ASN.1's encoding schemes don't use strings that way; they use numerical tags, instead. This would make an experiment with dividends using the next available tag (3) much more likely to clash with someone else's experiment with demurrage that also used tag 3.
My current draft deals with this by reserving tag 0 for experimental uses in certain places where I anticipate people might want to extend the protocol. The idea is that they can use tag 0 while it's experimental, with the understanding that if their experiment later gets standardized, that standardization can involve the allocation of a permanent tag that doesn't clash with anyone else's. This does require a little bit of global coordination, but it shouldn't be too onerous if all you have to do is tell IANA that you want a tag allocated, and give them a link to the document where you specify your standard.
After all that, I still haven't quite decided on the encoding scheme for circulex, but I think the question has been whittled down to whether I write "DER" or "COER" at the relevant point in the specification.
