Thanks for the link, I will read through
it.
My thoughts were to evaluate Cees comments
about ASN.1 needing to be implementation specific, but I have a strong
preference for a general purpose solution. There has been a lot done in
the compiler area that doesn’t apply to Smalltalk. I would at least
like to add as much functionality as the C community is getting from an ASN
complier. I’m still speaking from ignorance here, but my first
impressions are, to allow the building of an ASN structure using ASN specific
classes, and to allow the structure to read from / write to objects through a
TopLink like meta definition attached to classes, with more information like how
to navigate links. That way the structure could translate directly using
some form of root object to gather data. It would seem to me that that
structure would be pretty flexible and general purpose, but it needs more
flushing out.
To say it again:
ASN notation builds ASN Structure of
objects in Squeak.
ASN Structure Traverses a Root Object Meta
Data Structure to retrieve data from itself or other linked objects.
The ANS Structure Class would be responsible
for BER / DER encoding.
The Developer / User would be responsible for
running the notation to create the structure, then defining meta data on domain
objects to get and write data based on some root object (s).
I’m sure you have a lot more experience
with this, and I am still learning. The parser that creates the structure
would do validation which may be the most difficult part (as Cees pointed out
earlier). Having the meta data coordinate encoding on the ANS Structure
should simplify things some, much in the way that TopLink simplifies SQL query
building. What do you think of the potential of the design and its
ability to provide similar value as users currently get form asn compilers?
From: Matthew S.
Hamrick [mailto:mhamrick@cryptonomicon.net]
Sent: Wednesday, November 16, 2005
1:38 PM
To: Ron@USMedRec.com; Cryptography
Team Development List
Subject: Re: [Cryptography Team]
Team Update
Hey...
Are we working on a general purpose ASN.1 compiler / BER codec or just
enough ASN.1 to parse certs and PKCS blobs?
I might recommend we design an interface for the former but simply
implement the latter. BER / DER encoding can be a little ugly at times. I've
written several "highly-focused" BER / DER decoders in Java, and can
tell you that scope creep is NOT your friend. ("Highly focused" in
this context means specific to the ASN.1 for a particular application.)
I think someone mentioned Dubuisson's book on ASN.1, the PDF of which
is available for free download. While I believe that Dubuisson's book is an
excellent read, there's more to ASN.1 than BER/DER encoding, and you might wind
up wasting a little bit of time by trying to implement _everything_. You might
want to check out Burt Kaliski's "Layman's guide to a subset of ASN.1,
BER, and DER". Available in text format at ftp://ftp.rsa.com/pub/pkcs/ascii/layman.asc
.
-Cheers!
-Matt H.
On Nov 15, 2005, at 7:18 PM,
Also once the relationship is settled we
will again approach Cincom about a port of their cryptography code. (Sean have
you heard any new comments from James?) In the mean time I am still working
through ASN.1.