[Q] x.509 encoding of a dsa public key

Martin Kobetic kobetic at rogers.com
Tue Nov 26 01:22:17 UTC 2002


Hi Robert,

> Thanks for the links - I had found the first one in my web searches but not the
> second.  I noticed Booz-Allen seems to have done a lot of beltway consulting in
> this area.  I am scared; that's a lot of work!  pros: you get SNMP and PKI and
> surely some other items with it,  cons: ASN.1 and X509 represent...well a lot
> more work than I have weekends.  If code doesn't appear from a local diety, I
> will proceed to hack TSTTCPW, which is the DSAPublicKeyInfo encoding {id-dsa-
> with-sha1 SEQUENCE<q, p, g, y>} or so, and not the full X509Certificate.  If
> only I knew what those bits were..

Well, if you really need just that particular bit, it shouldn't be too hard. The actual bits likely are a DER encoded instance of
given ASN.1 type. I am not sure where does the definition that you quote come from, because it doesn't quite match what I see in
RFC3279/80 nor the older version RFC2459. The complete definition seems to consist of following types:

SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

AlgorithmIdentifier  ::=  SEQUENCE  {
        algorithm               OBJECT IDENTIFIER,
        parameters              ANY DEFINED BY algorithm OPTIONAL  }

Where in case of DSA:

1) the algorithm of AlgorithmIdentifier takes value of

    id-dsa OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) x9-57(10040) x9cm(4) 1 }

    BTW, the oid that you mention

    id-dsa-with-sha1 OBJECT IDENTIFIER ::=  {iso(1) member-body(2) us(840) x9-57 (10040) x9cm(4) 3 }

    seems to be used for actual DSS signatures, not for DSA public keys. But I may be just misreading things.

2) parameters of the AlgorithmIdentifier optionaly contains

Dss-Parms  ::=  SEQUENCE  {
          p             INTEGER,
          q             INTEGER,
          g             INTEGER  }

3) the subjectPublicKey bitstring is a DER encoding of an INTEGER describe as

    DSAPublicKey ::= INTEGER -- public key, Y

The type definition that you quote, could be a flattened version of the same though, depending on the encoding that is used, I
guess. In any case, translating either of these to/from bits is not that hard even without any ASN.1 infrastructure at hand. If you
need a quick intro to ASN.1 and DER encoding, take a look at 'A Layman's Guide to a Subset of ASN.1, BER, and DER' at
http://www.rsasecurity.com/rsalabs/pkcs/index.html. That should get you up to speed quickly.

> I completely agree that this would be a _very_ useful open-source project.  Any
> chance of Cincom donating your work in X509 and ASN.1?   We could put it in the
> Goodies category of SqueakMap!  ;-)

I don't think anybody on the developement team would mind that, and the thoughts to pursue it  come up from time to time. But it's
not happening for various reasons that I can't get into. I don't think it's completely unlikely to happen, I'm just worried that it
might be too late when it actually comes to that.

On the other hand X509 in VW still needs a lot of work, it has just barely enough to get SSL going. Interestingly we've got 3
independent ASN.1 attempts though. X509 itself uses it's own fairly simplicistic ANS.1/DER decoder, then there's a preview of a
general ASN.1 framework, and finally there's an SNMP optimized framework in Opentalk/SNMP. I hope that we will migrate X509 over to
the generic ASN.1 framework sometimes soon. The SNMP version is likely to live a life of its own for a while, unless we'll suddenly
have copious amounts of spare time to spend distilling the best out of those two implementations.

Regards,

Martin

Martin Kobetic, Cincom Smalltalk Development, http://www.cincom.com/smalltalk




More information about the Squeak-dev mailing list