[dingosity]

Why are we even talking about ASN.1/DER/BER? We should, like the ancient Egyptian priests who opposed Akhenaten, chisel it's name from every public edifice. Referring to it not as "ASN.1, the platform-independent abstract type system," but "the great heresy, which shall not be named."

[ggm]

Hand in your X.509 certificate at the door. (There was a proposal to do x509 as s-expressions. The road not taken...)

  ANY DEFINED BY ANY -- all following comments

[cryptonector]

ASN.1 is glorified S-expressions.

BER/DER/CER is binary S-expressions.

[ggm]

Anything you can represent in a parse tree is an s-expression the point was during the discussions of SPKI we talked about using canonical s-expression notation rather than ASN.1 to represent the TBS and other structural forms. SPKI used them. It stood in contradistinction to X.509 in ASN.1

If my memory serves me right Kent and others argued for continuance of ASN.1 to keep alignment with the CCITT/ITU on standards docs.

This was a long time ago. Around rfc3270 days so early 2000s. My memory is hazy and my email archive off-line.

All objects in RPKI are in ASN.1 as are SNMP. I only have to deal with the former these days.

[cryptonector]

So, my take is that depending on canonical encodings in security protocols is a mistake. What one ends up doing is something like:

- "hmm, I've a decoded struct here, and a signature of its original encoding, and I have to validate that signature somehow... what do I do??"

- and then "ah, I know! I'll re-encode that struct and then I can validate the signature!!1!",

- but now you need a canonical encoding ruleset, otherwise if the signer had any liberties at all in the encoding, you will have interoperability problems!

And it turns out that specifying and -worse- implementing canonical encodings can be hard. Think of a canonical JSON... Let's say you have a JSON encoder lying around, and now you need to make it emit canonical JSON. You start by eliminating interstitial whitespace and you are ready to declare victory when you notice that you still need a canonical encoding of numbers, and also strings! Ok, now you have less-obvious design choices to make. Worse, adjusting your floating point number printer to emit canonical numbers turns out to be really hard, and there are a lot of traps in doing that. So maybe you decide you're going to limit yourself to integers. And it's all like this.

There is a better answer. The Heimdal ASN.1 compiler has a --preserve-binary=TYPE option where you can say that you want the decoder to preserve the original encoding of the give TYPE(s) so that you can validate signatures later. The way this works is that for each such TYPE, the compiler adds a `_save` field that has a copy of the encoding of that type as it was seen by the decoder.

I'm with Stephen Kent on this. I don't like the OpenSSH certificate format, for example -- it's missing important things and it's not that much simpler than the PKIX certificate format. The OpenSSH certificate format is much less bloaty than the PKIX one because PKIX uses DER and OpenSSH doesn't -- but so what, one could simply use an OER encoding of PKIX certificates and get the same de-bloating benefit with much less churn to existing codebases.