Regarding Squeak's support for ASN1 DER, if you load the crypto package and then you can
1) browse implementers of #encodeAsnDer for the marshalling side and browse ASN1Value class>>#fromAsnDer: for the unmarshalling side. I used OrderedCollection to represent the SEQUENCE Der object.
2) Take a look at the ASN1TestCase for tests of Null, Integer, Sequence and BitString.
There is also an implementation of DSAPublicKey>>encodeAsnDer which attaches the subOid for just the Public Subject Key structure out of x509. I use this to exchange the public key for Diffie Hellman in the SqueakElib implementation. This is where things fall of the cliff, since I didn't define any other x509 ASN1 structures, for instance a DSA Certificate, which is a superset structure which includes the DSA Public Subject Key structure. Since SqueakElib (Elib) does not use third party Certificate Servers, I don't need the full blown Certificate structure, but this is what I think of when I read you to say we need to look at the ASN1 implementation and support x509.
Regarding the packaging: I am also confused why we have multiple implementations. I like having an external base crypto module, repackaged as a Monticello package, and remove any in-base-image pieces. If we want to deploy the Crypto module in that base image, that's cool, but it should be maintained and developed as a separate package, so we don't duplicate. I also see the base Crypto module as filled with base algorithms, then have separate Monticello modules for each protocol or for advanced ciphers. Then we can leverage the module dependency mechanism. Is there a server where we could store a primary Monticello repository for crypto packages, base and protocol?
