Feauture Request for 0.6.1: Parsing DEFAULT with structure

[vanrein]

We're using asn1ate heavily in our Quick DER as a means of using ASN.1 in protocols. We generate C and Python code from it that simplifies parsing and processing of DER (and, in prepartion, JER).

One such application is KIP which takes a surprising new angle on encryption. As part of it I'm designing a document format which makes most sense in DER but which also ought to be as compact as possible. In short, there are many features but most of them have simple defaults. This is where I'm running into the following limitations of the grammar recognised by asn1ate, and I would like to extend that, or see it extended, in the next release.

• SEQUENCE OF ... DEFAULT { } as used here and here
• BIT STRING DEFAULT { } as used here

To motivate the use with a few possible applications of KIP:

• Identity and key access not founded on key ownership but on ability of authentication
• Sending encrypted documents with a key that was generated, rather than looked up and hopefully found for all recipients
• Powerful techniques (AND, OR) to combine rights through keying
• Extremely simple-to-use API (not aimed at cryptographer but programmers)
• Founded on another basis (libk5crypto) than libcrypto -- diversification
• KIP Documents can be references, and may be hashed and/or signed
• KIP Documents can be carried easily in (short) data: URIs and serve as signed references

Please let me know if it is possible to add these DEFAULT parsing forms; their empty forms should make that really easy; if you cannot do it we might, but then we'd like to know ahead of time that you agree with the idea and are willing to integrate it into the Python distributed form of asn1ate.

Thanks! Rick, for the ARPA2 projects

[kimgr]

Hi @vanrein,

I went back to the X.680 spec (available from here: https://www.itu.int/rec/T-REC-X.681) to find this, and it looks like you need better support for BitStringValue and SequenceOfValue for these specific constructs.

More generally, the BuiltinValue production is poorly supported (see https://github.com/kimgr/asn1ate/blob/master/asn1ate/parser.py#L198), so there's plenty of room for improvement there, and it should be pretty straightforward, at least on the parser side. As for a semantic representation of these values in sema, and how to codegen them for pyasn1, I'm not sure, but we can always start with the parser.

I don't have cycles to work on this, I no longer use ASN.1 myself, so if you could sketch out something that works for you, I'd be happy to integrate it.

See also #69, which is tangentially related.