5 ms·

Without commenting on the merits of this RFC, I saw "[[OPEN ISSUE: Should we just re-encode this directly in CBOR?. That might be easier for people, but I

Without commenting on the merits of this RFC, I saw "[[OPEN ISSUE: Should we just re-encode this directly in CBOR?. That might be easier for people, but I ran out of time.]]" IMO, yes, please. The last thing the world needs is Yet Another Custom Binary format and CBOR is a very good choice (happens to be one of my favorite encodings).

carterschonwald 7y ago
My life would be so much more pleasant if the asn1 stuff in x509 et al was in cbor.
- cryptonector 7y ago
  That's not going to happen. You need an ASN.1 compiler and run-time. I use Heimdal's (which comes with a nice PKIX library with a very nice API).
- tialaramex 7y ago
  Mmm. You obviously wouldn't build anything like X.509 today (not least because the X.500 directory system never ended up building that global directory) but over time I appreciate more and more things that I once thought were mistakes in X.509 and ASN.1. The Distinguished Encoding for example. So easy to build a format that says well you can do X or Y and then you get nasty surprises because which is it? Or OIDs. Sure today you figure we'll let IANA track things in a registry, or we'll do everything with URLs which are inherently namespaced, but OIDs are in many ways a nicer option than either.
  - cryptonector 7y ago
    I would replace OIDs with URNs. Textual identifiers are much nicer than OIDs in any APIs and in any UIs (if they must leak there, which often happens). This goes for things like GSS-API as well. I do NOT like definite-length encoding. It's nice to have the full length of a PDU up front, but inside the PDU you want to use indefinite length encoding for everything as this greatly simplifies encoding. Tag-length-value (TLV) is an anti-optimization that was only ever a crutch. By the time the ITU-T worked on PER this was well understood. I feel that the use of TLV encoding rules held back [open source] compiler creation for ASN.1. Compare to XDR and rpcgen. XDR is a lot like a subset of ASN.1 with PER-/OER-like encoding that uses 4-octet alignment. XDR was long easier to use than ASN.1, but why? Mostly because a) it has C-like syntax and is fairly easy to build parsers for, and b) the encoding rules are very straightforward. Protocol buffers makes some of the same mistakes as DER... It's really difficult to reinvent wheels well. It really helps to not throw the baby out with the bathwater. Specifically, here, there's a lot functionality in ASN.1 the _syntax_ that would be very good to keep. As for encoding rules, XDR is dead simple, so I'd use that for almost anything. It's also good to know what's really missing. For my money, the most commonly missing feature is control over emitted types for the host language, and, specifically, lack of a way to emit private fields that are not to be encoded or decoded but which make it easy to keep state near relevant data. XDR is so simple that as long as you have a decent buffer abstraction and support routines for encoding/decoding scalar types, it's easy enough to do without a compiler. The most promising newish thing here is flatbuffers.
    - pas 7y ago
      What's wrong with TLV? It helps getting rid of end-of terminators, no?
      - cryptonector 7y ago
        For one, the tags aren't necessary -- you know what belongs at any point, and for OPTIONAL/DEFAULT elements all you need to know is whether they are present or absent (that's one bit, or a byte if you're not aiming to be more space efficient). Definite-lengths greatly complicate encoding. The easiest way to encode DER is "backwards", starting the end of a SEQUENCE and working your way backwards. That's a bit of a pain. Definite-lengths add lots of mostly-unnecessary redundancy. For constrained-range integers, the best thing to do is to encode them as whatever number of octets are needed to encode the constrained range. For structures (SEQUENCE) and arrays (SEQUENCE/SET OF) indefinite length encoding is much easier to encode. Decoding is easy because you just decode the fields -- a terminator shouldn't be needed (though I know BER uses terminators, but that's a design flaw in the BER family of encoding rules, not a complete necessity. Definite-length encodings or terminator encodings are mostly only needed for strings and extensibility holes (OCTET STRINGs, extensibility markers), but they can be the exception rather than the rule, and thus simplify things.

carterschonwald 7y ago

My life would be so much more pleasant if the asn1 stuff in x509 et al was in cbor.

cryptonector 7y ago
That's not going to happen. You need an ASN.1 compiler and run-time. I use Heimdal's (which comes with a nice PKIX library with a very nice API).
tialaramex 7y ago
Mmm. You obviously wouldn't build anything like X.509 today (not least because the X.500 directory system never ended up building that global directory) but over time I appreciate more and more things that I once thought were mistakes in X.509 and ASN.1. The Distinguished Encoding for example. So easy to build a format that says well you can do X or Y and then you get nasty surprises because which is it? Or OIDs. Sure today you figure we'll let IANA track things in a registry, or we'll do everything with URLs which are inherently namespaced, but OIDs are in many ways a nicer option than either.
- cryptonector 7y ago
  I would replace OIDs with URNs. Textual identifiers are much nicer than OIDs in any APIs and in any UIs (if they must leak there, which often happens). This goes for things like GSS-API as well. I do NOT like definite-length encoding. It's nice to have the full length of a PDU up front, but inside the PDU you want to use indefinite length encoding for everything as this greatly simplifies encoding. Tag-length-value (TLV) is an anti-optimization that was only ever a crutch. By the time the ITU-T worked on PER this was well understood. I feel that the use of TLV encoding rules held back [open source] compiler creation for ASN.1. Compare to XDR and rpcgen. XDR is a lot like a subset of ASN.1 with PER-/OER-like encoding that uses 4-octet alignment. XDR was long easier to use than ASN.1, but why? Mostly because a) it has C-like syntax and is fairly easy to build parsers for, and b) the encoding rules are very straightforward. Protocol buffers makes some of the same mistakes as DER... It's really difficult to reinvent wheels well. It really helps to not throw the baby out with the bathwater. Specifically, here, there's a lot functionality in ASN.1 the _syntax_ that would be very good to keep. As for encoding rules, XDR is dead simple, so I'd use that for almost anything. It's also good to know what's really missing. For my money, the most commonly missing feature is control over emitted types for the host language, and, specifically, lack of a way to emit private fields that are not to be encoded or decoded but which make it easy to keep state near relevant data. XDR is so simple that as long as you have a decent buffer abstraction and support routines for encoding/decoding scalar types, it's easy enough to do without a compiler. The most promising newish thing here is flatbuffers.
  - pas 7y ago
    What's wrong with TLV? It helps getting rid of end-of terminators, no?
    - cryptonector 7y ago
      For one, the tags aren't necessary -- you know what belongs at any point, and for OPTIONAL/DEFAULT elements all you need to know is whether they are present or absent (that's one bit, or a byte if you're not aiming to be more space efficient). Definite-lengths greatly complicate encoding. The easiest way to encode DER is "backwards", starting the end of a SEQUENCE and working your way backwards. That's a bit of a pain. Definite-lengths add lots of mostly-unnecessary redundancy. For constrained-range integers, the best thing to do is to encode them as whatever number of octets are needed to encode the constrained range. For structures (SEQUENCE) and arrays (SEQUENCE/SET OF) indefinite length encoding is much easier to encode. Decoding is easy because you just decode the fields -- a terminator shouldn't be needed (though I know BER uses terminators, but that's a design flaw in the BER family of encoding rules, not a complete necessity. Definite-length encodings or terminator encodings are mostly only needed for strings and extensibility holes (OCTET STRINGs, extensibility markers), but they can be the exception rather than the rule, and thus simplify things.