Graham,
The PKIX X.509 Certificate and CRL Profile (aka PKIX Part I) contains this
info (ftp://ftp.ietf.org/internet-drafts/draft-ietf-pkix-ipki-part1-07.txt).
The ietf host is down right now, so here are the applicable excerpts from
PKIX Pt 1:
7.2.2 DSA Signature Algorithm
A patent statement regarding the DSA can be found at the end of this
profile.
The Digital Signature Algorithm (DSA) is also called the Digital Sig-
nature Standard (DSS). DSA was developed by the U.S. Government, and
DSA is used in conjunction with the the SHA-1 one-way hash function.
DSA is fully described in FIPS 186 [FIPS 186]. The ASN.1 object
identifiers used to identify this signature algorithm are:
id-dsa-with-sha1 ID ::= {
iso(1) member-body(2) us(840) x9-57 (10040)
x9cm(4) 3 }
The id-dsa-with-sha1 algorithm syntax has NULL parameters. The DSA
parameters in the subjectPublicKeyInfo field of the certificate of
the issuer shall apply to the verification of the signature.
If the subjectPublicKeyInfo AlgorithmIdentifier field has NULL param-
eters and the CA signed the subject certificate using DSA, then the
certificate issuer's parameters apply to the subject's DSA key. If
the subjectPublicKeyInfo AlgorithmIdentifier field has NULL parame-
ters and the CA signed the subject with a signature algorithm other
than DSA, then clients shall not validate the certificate.
When signing, the DSA algorithm generates two values. These values
are commonly referred to as r and s. To easily transfer these two
values as one signature, they shall be ASN.1 encoded using the fol-
lowing ASN.1 structure:
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
7.3 Subject Public Key Algorithms
Certificates described by this standard may convey a public key for
any public key algorithm. The certificate indicates the algorithm
through an algorithmidentifier. This algorithm identfieier is an OID
and optionally associated parameters.
This section identifies preferred OIDs and parameters for the RSA,
DSA, and Diffie-Hellman algorithms. Conforming CAs shall use the
identified OIDs when issuing certificates containing public keys for
these algorithms. Conforming applications supporting any of these
algorithms shall, at a minimum, recognize the OID identified in this
section.
7.3.3 DSA Signature Keys
The object identifier supported by this standard is
id-dsa ID ::= { iso(1) member-body(2) us(840) x9-57(10040)
x9cm(4) 1 }
The id-dsa algorithm syntax includes optional parameters. These
parameters are commonly referred to as p, q, and g. When omitted,
the parameters component shall be present and have the value NULL.
If the DSA algorithm parameters are absent from the subjectPublicKey-
Info AlgorithmIdentifier and the CA signed the subject certificate
using DSA, then the certificate issuer's DSA parameters apply to the
subject's DSA key. If the DSA algorithm parameters are absent from
the subjectPublicKeyInfo AlgorithmIdentifier and the CA signed the
subject certificate using a signature algorithm other than DSA, then
the subject's DSA parameters are distributed by other means. The
parameters are included using the following ASN.1 structure:
Dss-Parms ::= SEQUENCE {
p INTEGER,
q INTEGER,
g INTEGER }
If the subjectPublicKeyInfo AlgorithmIdentifier field has NULL param-
eters and the CA signed the subject certificate using DSA, then the
certificate issuer's parameters apply to the subject's DSA key. If
the subjectPublicKeyInfo AlgorithmIdentifier field has NULL parame-
ters and the CA signed the subject with a signature algorithm other
than DSA, then clients shall not validate the certificate.
When signing, DSA algorithm generates two values. These values are
commonly referred to as r and s. To easily transfer these two values
as one signature, they are ASN.1 encoded using the following ASN.1
structure:
Dss-Sig-Value ::= SEQUENCE {
r INTEGER,
s INTEGER }
The encoded signature is conveyed as the value of the BIT STRING sig-
nature in a Certificate or CertificateList.
The DSA public key shall be ASN.1 encoded as an INTEGER; this encod-
ing shall be used as the contents (i.e., the value) of the sub-
jectPublicKey component (a BIT STRING) of the SubjectPublicKeyInfo
data element.
DSAPublicKey ::= INTEGER -- public key Y
If the keyUsage extension is present in an end entity certificate
which conveys a DSA public key, any combination of the following
values may be present:
digitalSignature; and
nonRepudiation.
If the keyUsage extension is present in an CA certificate which con-
veys a DSA public key, any combination of the following values may be
present:
digitalSignature;
nonRepudiation;
keyCertSign; and
cRLSign.
- John Pawling
At 02:26 PM 5/13/98 +0100, Graham Klyne wrote:
Folks,
Is there a document which describes exactly how DSS signature and
certificate data should be formatted (i.e. the organization of data within
a "SignatureValue", etc.)?
Specifically, in handling signed messages, we have:
To verify the contents of a DSA signed message on the other end you need
three values P, Q, G and the Public Key. The values of P, Q and G must be
the same as those used to sign the message. (where the Public Key is
derived from the P,Q, and G values and the private key).
How are the P, Q and G values communicated? Are they part of the
signature, the public key or something else?
#g
------------
Graham Klyne