[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
|