top | item 29928341

(no title)

breser | 4 years ago

How excellent the ASN.1 tooling is depends on which subset of ASN.1 you're using. Some of the tooling supports one iteration of ASN.1 or the other. To the degree that the IETF had to write a document on how to deal with this since some of the standards use the older ASN.1 and some use the newer ASN.1: https://tools.ietf.org/id/draft-ietf-pkix-asn1-translation-0...

Interoperability with ASN.1 is very fragile at best.

discuss

order

cryptonector|4 years ago

BTW, that I-D is now RFC 6025 [0].

There's also RFC 5912 [1], which adds x.681/x.682/x.683 constraints to PKIX modules. I use this to great effect in Heimdal[2]. One function call can decode everything in a certificate, and a second can pretty print it in JSON; one command can pretty-print a certificate in all its glory in JSON.

  [0] https://datatracker.ietf.org/doc/html/rfc6025
  [1] https://datatracker.ietf.org/doc/html/rfc5912
  [2] https://github.com/heimdal/heimdal
      https://github.com/heimdal/heimdal/tree/master/lib/asn1

cryptonector|4 years ago

We have tons of interoperable PKIX implementations (OpenSSL and derivatives, NSS, OpenJDK's, GnuTLS, wolfSSL, Heimdal, and many many more), and a bunch of interoperable Kerberos implementations (MIT Kerberos, Heimdal, Windows / AD, OpenJDK's, the IBM Java's, GNU Shishi, there's a python implementation).