Tom & David,
The NIST OIW Stable Agreements have registered DSA (in June) as:
DSAPublicKey ::= SEQUENCE {
key INTEGER, -- y (public key)
params DSAParameters OPTIONAL }
DSAParameters ::= SEQUENCE {
prime1 [0] INTEGER, -- p
prime2 [1] INTEGER, -- q
base [2] INTEGER } -- g
The BER encoding of the DSAPublicKey is the contents octets of the
subjectPublicKey BIT STRING. The signature itself is a BIT STRING whose
contents octets (as with the ElGamal registration) contain the BER encoding
of:
SEQUENCE {
s INTEGER,
r INTEGER }
The OIDs are:
algorithm OBJECT IDENTIFIER ::=
{ iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) }
dsa OBJECT IDENTIFIER ::= { algorithm 12 }
sha OBJECT IDENTIFIER ::= { algorithm 18 }
dsaWithSHA OBJECT IDENTIFIER ::= { algorithm 13 }
Recall dsaWithSHA would be the signature algorithm ID used in the
"signature" field of the certificate and the "algorithm" field of
subjectPublicKeyInfo (although I would think tolerant implementations
might also accommodate the "dsa" ID). None of the algorithm IDs has
parameters.
This definition will also be used in X9.30-3 (DSA Certificate Management),
which X9F1 is working on.
Burt Kaliski pointed out the use of the algorithm ID to me last week while
reviewing X9.30-3, and I can certainly see the merit to this approach. If
any of you feel strongly about it, I will try to fix the OIW agreements in
September, as a technical errata. This should not be a problem, since none
of the other attendees expressed the slightest interest in registering DSA
in the first place. If we do this, I would suggest the current "dsaWithSHA"
should have the following characteristics:
The subjectPublicKey BIT STRING contains the DSA public key, which is
an integer. It is encoded as described for an INTEGER in ISO 8825,
i.e. two's complement, in the least number of bytes. (Note the BIT
STRING is octet-aligned.)
The algorithm parameter is of type DSAParameters, as described above.
The new algorithm ID would be:
dsaSHAWithCommonParams OBJECT IDENTIFIER ::= { algorithm 20 }
The subjectPublicKey is as described above. The algorithm parameter
is of type NULL.
Any comments or justifications one way or the other are welcome, as are
comments on the proposed changes to the OIW agreements. Please let me
know in the next week or so, so I can update X9.30-3 for the July 20
meeting. There is a (small) chance it will go out for ballot after that
meeting.
Regards,
Rich