Hi Jim

Jim Starkey wrote:

> A question was raised awhile back about ASN.1 encoding for line
> encoding, internal record encoding or both. Due to circumstances beyond
> my control, I now know more about ASN.1 than I wish (and, not
> incidentally, I take back everything nice I ever said about Crypto++).
>

ASN.1 is like a binary version of XML, although it predates XML.

In fact there is a nice tool that will take an ASN.1 object (like an
X.509 certificate) and make a xml document out of it, or do the reverse
to create an asn.1 blob.

XML unfortunately seems to be taking on all the complications that will
make it as difficult to understand a raw stream of data as ASN.1.

> For use within the
> ODS or in a private line protocol, I think we can do better.
>

I agree, particularly since it's a private internal protocol.

But still the ideas and experience obtained, both successful and the
unsuccessful in the design and use of both ASN.1 (and XML) are good
things to keep in mind while designing a new protocol.

> RSA keys generated by Crypto++ 4.2 are invalid in Crypto++ version 5.
> It isn't fair to say that this is undocumented since nothing about the
> product is documented. The Crypto++ list serve is a ghost town. After
> a week of plowing through gory code (if you want pointers on advanced
> C++ template abuse, study Crypto++), I finally figured out the Crypto++
> 4.2 uses the RSA standard encoding for private keys while Crypt++ 5.2.1
> uses the X.509 encoding which is, in essence, a wrapper around the RSA
> format encoded as an octet-string. This is vastly more than I wanted to
> know about this crud.

Yes, and from quite a few years tinkering with certificates, digital
signatures, pkcs7 and the like, from there the use of ASN.1 rapidly gets
worse.

For some joyful asn.1 bedtime reading try a few documents from:

http://www.rsasecurity.com/rsalabs/pkcs


Cheers

Mark