TLS - DHE_DSS: How does client know public DSS-server key?

Question

I wonder where the public server key g^x for DSS authentication is communicated to the client when a DHE_DSS cipher suite is used in TLS 1.2. Precisely:

A DSS certificate contains crypto parameters (p_1, q_1, g_1). These values are known to the server (by installation of the certificate) and to the client by the certificate message.

For DHE algorithm, server chooses crypto parameters (p_2, g_2, y_2 = g_2^s). For DSS-authentication of these parameters, the server chooses a random value x and applies the DSA signing algorithm and sends the authenticated data via server key exchange message to the client.

In order to verify the received data, the client needs the server's DSS-public key g_1^x. As far as I can see from TLS 1.2 spec (RFC5246), this DSS-public key is not part of the server key exchange message. So:

Question: How does the client obtain g_1^x ?

Remark: In https://en.wikipedia.org/wiki/Digital_Signature_Algorithm my g_1^x is y = g^x in the section "Per-user keys". And the message m in the wiki-page consists here of the DHE parameters (p_2, g_2, y_2).

**It's in the certificate;** in general the purpose of every SSL/TLS certificate is always to contain a publickey. Remember SubjectPublicKeyInfo includes _both_ algorithm which contains OID and (sometimes, including here) parameters _and_ subjectPublicKey which contains the public key wrapped in BIT STRING. For DSS aka DSA see https://tools.ietf.org/html/rfc3279#section-2.3.2 . Note that the signature _on_ the DHE params&key _under_ the (certified) DSA key is in the ServerKX message. — dave_thompson_085, Nov 04 '17 at 19:50
Thank you very much. This answers my question. In fact, (p_1, q_1, g_1) are the parameters of the algorithmIdentifier und g_1^x is the subject public key. Don't you like to post your comment as an answer ? I'll glad to accept it. — user120513, Nov 07 '17 at 17:08

score 0 · Accepted Answer · edited Oct 07 '21 at 07:34

Expanded from comment for closure, although frankly this feels to me rather like the old poser, "who's buried in Grant's Tomb?"

TLDR: the (static) public-key is in the public-key certificate

SSL/TLS uses X.509 certificates for static public-keys, or to be exact: SSL referenced X.509v3, a standard then recently published by what was then CCITT and has since become ITU-T; the RFCs for TLS reference PKIX which is a subset (formally a profile) of X.509v3 defined by a series of RFCs currently headed by rfc5280.

An X.509/PKIX certificate contains info about the public-key of the subject in a data structure prosaically named SubjectPublicKeyInfo defined in 5280 section 4.1 4.1.1.2 and 4.1.2.7 as:

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

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

which supports a variety of algorithms by specifying both the algorithm itself and algorithm-dependent parameters, as well as the algorithm-dependent public-key 'wrapped' within a BIT STRING.

SPKI (as I call it) is specified in detail for several algorithms including DSA (imprecisely called DSS in the SSL/TLS ciphersuite and keyexchange names) in rfc3279 section 2.3.2. The 'algorithm' part consists of the OID (Object Identifier) for DSA, and parameters normally consisting of p,q,g as an ASN.1 SEQUENCE of INTEGERs -- with an option to omit these parameters from a certificate if they are 'inherited' from the issuer's CA certificate (an option I've never seen used). The 'subjectPublicKey' part is simply the y value (= g^x mod p) as an ASN.1 INTEGER in the BIT STRING wrapper.

The DSA signature (under the privatekey matching the publickey in the cert) on the DHE values (p,g,y) in the ServerKeyExchange message uses a 'random' value conventionally notated k (not x) to produce a pair of integers r,s which are conveyed (in ASN.1) in that same ServerKeyExchange message. (Technically k need not be random as long as it doesn't repeat for different data; see rfc6979 for a deterministic alternative.)

TLS - DHE_DSS: How does client know public DSS-server key?

1 Answers1