Re: [ANNOUNCE] new release of the ParrotTalk protocol specification, version 3.7

[Robert <[e-mail]>]

Hallo Carsten,

Yes, I wanted to solidify the structure definitions of ParrotTalk with ASN1, which I wrote an encoder for many years ago in Squeak, found in this package (http://www.squeaksource.com/Cryptography/Cryptography-rww.115.mcz). Once I defined Choice, then all my headers became parsable and with Explicit tagging I could decode any header. It actually makes the ProtocolOffered/ProtocolAccepted unneeded, as the first message header decodes to either a v3.6 header (IWant) or a v3.7 header Hello_v3_7, and my protocol selector state machine can determine which version is in use. This is entirely due to using ASN1 DER encoding. I ported my ASN1 encoder to Java to be able to provide identical structure definitions, in code. I like it better than annotation based ASN.1.

https://github.com/CallistoHouseLtd/ASN1

I would ask those interested in implementations to load up my code and see my design. That is the strong suit I have, are the implementations.

Along with IKE I should look at CBOR and COSE.

Cheers,
Robert




‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, November 21, 2018 11:31 AM, Carsten Bormann <[e-mail]> wrote:

> Hi Robert,
>
> maybe adding to all the good comments that Eric Rescorla gave, this one statement stuck out for me:
>
> > On Nov 21, 2018, at 12:34, Robert robert.withers=[e-mail] wrote:
> > strong advantage is that all the headers used in the message flow are defined as ASN1 structures
>
> There are quite a few people who would perceive this as a disadvantage. ASN.1 (or X.409, as it was called then) was a great new idea in 1983, but 35 years later we now know more about its downsides (and, not to forget, those of its dominating set of encoding rules, BER). If you want to stay close to the PKI, it may seem natural to continue to use it, but it seems you count freedom from X.509 certificates as a feature, and that would bring you closer to newer formats such as CBOR and COSE (RFC 8152), which you may want to look at.
>
> Obviously, representation formats are much less important than the security properties of the protocol itself, which I cannot comment on as I haven’t seen it. They still can be an important factor in implementation stability and interoperability, as we have for example experienced when ASN.1 helped sink H.323 some 20 years ago. But there is also a security aspect, which you can gauge by counting the number of CVEs that mention ASN.1 decoder implementations.
>
> Grüße, Carsten