FYI: I've been reusing OpenSSL's ASN1 parser code, so, yes, it's doable. (Details are very fuzzy now, sorry. (geriatric brain) + (zero score and 5 years ago) ==> lots of gaps)
Just very recently I've been looking at this stuff again and if you want to use it as a _truely_ _generic_ ASN.1 parser, there's two (three) bits that are lacking: A) OpenSSL ASN.1 code today does not encode nor decode in any way: 1) ASN.1 REAL (floating point values) 2) ASN.1 V_ASN1_EMBEDDED_PDV entities This is not a problem, at least not for 99.99% of applications; I've never personally seen a PDV entity in an ASN.1 stream (wasn't this something new appearing in a later ASN.1 standard?) and that floating point thingy, if I recall the ASN.1 specs correctly (see brain disclaimer above), is just a strict specification of how a floating point value looks as a _string_. With that I mean that ASN.1 encodes these things as strings in all encoding formats (tread beyond IEEE FP Format County and you'll get some serious surprises when you'd take the binary route, anyway. VAX VMS / FORTRAN floating point formats come to mind.) Ergo: ASN.1 REAL ~~ sprintf(output_buf, "%g", fp_value) --> can also be encoded as one of the ASN.1 STRING flavors, which _are_ supported. If you want it (rigorous type checking), it's not too hard to add to the existing code, I guess. Done it 5 years ago, probably even easier today. (1) and (2) are, to the best of my knowledge, nowhere to be found in any public ASN.1 cryptographically related specifications. I had a need/use for (1) in a particular (secure) financial setting. B) [irrelevant except for standards otaku's] no PER support. But you didn't want that anyway. Basta. Conclusion: OpenSSL's ASN.1 was and is a viable alternative for encoding your application data, whether or not wrapped in cryptographic containers, for transfer. So that's 'yes' to your last questions. The first one(s) have been answered already, I think. Ger (There's something stuck in the brain's teeth about converting ASN.1 specs to actual definition trees in the code, but that was 5+ years ago and the ASN.1 code has seen a _major_ overhaul since then (lots of kudos to dr. Henson for that), so that memory sure a heck doesn't match reality any longer.) On Thu, Apr 2, 2009 at 11:39 PM, Randy Turner <rtur...@amalfisystems.com> wrote: > > Hello list, > > Are the ASN.1 functions in OpenSSL "generic" enough to be used for other > purposes besides reading/writing certificates? > > I was curious if the ASN.1 code could encode/decode both BER and DER, > generically, even if the source of the data is NOT associated with > certificates. For instance, can these routines be used to encode/decode a > CMS container. Since CMS is pretty close to PKCS#7, my assumption would be > "yes". But taken to another extreme, could I use the ASN.1 library in > OpenSSL to encode/decode Kerberos traffic, or SNMP traffic (BER), or other > protocols encoded in BER/DER? > > Just curious how "reusable" the OpenSSL ASN.1 was, and if it's not "quite" > as reusable as I am thinking about, is there a generic library available? > I've tried using "asn1c", but this code seems to break when I feed it valid > BER... > > Thanks! > Randy > > -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: g...@hobbelt.com mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
