Subject: [TLS] CAs and certificate chains in the SSL/TLS handshake

From: Martin Rex <[email-masked]>
Date: Wed, 7 Nov 2007 20:36:37 +0100 (MET)

I'm finally back at work and investigating a bug in the SSL client
certificate code of our OEM implementation and after reading
the current TLS v1.2 document it appears that the spec is still
unclear what implementations should do for multi-level CA hierarchies.

The description of the "7.4.4. Certificate Request" handshake message
explicitly allows a TLS-Server to announce subordinate CAs
(which I think is useful), but I'm somewhat confused about what
a client is supposed or allowed to send as a certificate_list
(not where it starts, but where it ends), and what the server
is supposed to allow or allowed to / expected to reject.
I would appreciate guidance in the spec here.

Scenario:
PKI with 3-level CA hierarchy for SSL client authentication:
  RootCA, SubCA1, SubCA2, EndEntity(User)

According to 7.4.4. the SSL server can send/include
any one possible subset of (RootCAs,SubCA1,SubCA2) as acceptable
certificate_authorities in the CertificateRequest message.

Which "matching" certification authority the client implementation
depends on the clients search strategy and possibly the order of
the certification_authorities in the CertificateRequest message
of the server.

IMHO, the most sensible approach would be for the server to
send Subordinate CAs names before their issuing CA names,
but for some SSL/TLS (server side) implementations it might
be difficult or impossible to configure a particular ordering,
but the client will always receive a particular order, be
it a side-effect of the server SSL/TLS implementation or
a conscious decision (aka preference list) of the servers admin.

I'm not sure what would be the best approach for the client would
be to (a) search for the "most desirable" certification
authority, and whether it is allowed to send certificates
in the certificate_list of the ClientCertificate message
beyond the "matching" certification authority, in case
that matching certification authority was actually a
subordinate CA.

Personally, I would consider it a client-side bug if the client
would send a CA certificate beyond the matched certification
authority from the CertificateRequest, _unless_ the server
explicitly announced this higher certification authority also
in the certification_authorities list of the CertificateRequest
message.

Conceivable reasons why a client may not want to (or not be able to)
send a full path ending at a self-signed CA certificate
(and appreciate the server to announce subordinate CAs) might be
 - size constraints of a crypto hardware token or device
   (it may not store chain certs),
 - bandwith savings for the ClientCertificate handshake message. 
 - reduced work for the server: it does not need to parse
   and to process (even if processing just means comparing and ignoring)
   CA certs beyond a trusted subordinate CA

>From how I read OpenSSL code (s3_both.c from 0.9.7g) I assume that
OpenSSL will unconditionally send all available path certificates
up to a self-signed (CA) cert.

SSL clients sending unrequested/extra CA certs in the ClientCertificate
message will unnecessarily drain resources from the SSL server
(and preclude this small optimization from the server admin).

Opinions?

-Martin

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 9 Nov 2007 12:33:37 +0100

On Wed, Nov 07, 2007 at 08:36:37PM +0100, Martin Rex wrote:

[...]
> in the certification_authorities list of the CertificateRequest

The preferred client behavior that you describe here certainly makes a
lot of sense.  However, I wouldn't want to strictly require it.
Rather, I think that is a feature that (low-footprint) clients can
treat their own certificate chain as a blob and just send the complete
chain without having to take into account its structure.

(Occasionally there might even be an actual advantage in seeing the
complete chain, beyond those CAs found in the
certification_authorities list: Remember that the list only provides
distinguished names, which need not uniquely denote specific
certificates.  If the client has a certificate chain containing one of
the acceptable distinguished names, the server still might be unable
to verify this chain because none of the certificates in it is
trusted.  In this case, knowing the complete CA chain might turn out
to be useful for analysing the whole mess, even if all the TLS
implementation can do with this is help dump the CA chain information
into a logfile.)

Bodo

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 16 Nov 2007 17:02:15 +0000

As I disagree with the major part of this post, I had to go back to the spec to re-read what it actually states.

There is nothing in the current text that says anything about how long chain the client should return. In fact the text is clearly written as if only one certificate is sent. The terminology in 7.4.6 talks about "certificate" and "the certificate" rather than certificates and certificate chains.

7.4.6 does not even make any reference to what structure that is used, even if you can determine from other parts of the document that the structure is "Certificate" which allows a chain of certificates.

What I find strange is the following text in 7.4.6

       -  If the certificate_authorities list in the certificate
          request message was non-empty, the certificate SHOULD be
          issued by one of the listed CAs.

This makes no sense to me at all. If the list of CA DNs in certificate_authorities included a list of root CA names, why "SHOULD" the client certificate be issued directly by one of these roots?

The functionality, as I see it implemented in practice, is simply that the server provides a list of CA names. The client picks a certificate where that CA name is present anywhere in the selected client certificate chain. The client then sends either just the client certificate or the whole chain (with or without the root) to the server according to local policy.

I also found another small nit in 7.4.4

In the following text:

       For
       example, if the server sends dss_fixed_dh certificate type and
       {dss_sha1, rsa_sha1} signature types, the client MAY _to_ reply
       with a certificate containing a static DH key, signed with RSA-
       SHA1.

Remove "to" after MAY

Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: Martin Rex [mailto:[email-masked]]
> Sent: den 7 november 2007 20:37
> To: [email-masked]
> Subject: [TLS] CAs and certificate chains in the SSL/TLS handshake
>

---

From: <[email-masked]>
Date: Mon, 19 Nov 2007 10:59:36 +0200

7.4.6 does not describe the structure, because the structure
has been already described, and it's not repeated there.
The description is pretty clear that a chain be sent:

   certificate_list

       This is a sequence (chain) of certificates. The sender's
       certificate MUST come first in the list. Each following
       certificate MUST directly certify the one preceding
       it. Because certificate validation requires that root keys
       be distributed independently, the self-signed certificate
       that specifies the root certificate authority MAY optionally
       be omitted from the chain, under the assumption that the
       remote end must already possess it in order to validate it
       in any case.

But there is indeed some text in e.g. 7.4.6 that incorrectly
talks about just "the certificate", when it means "the certificate
plus possibly intermediate parts of the chain". I'll see
that these get fixed during WGLC...

Best regards,
Pasi

> From: ext Stefan Santesson [mailto:[email-masked]] 
> Sent: 16 November, 2007 19:02
> To: [email-masked]; [email-masked]
> Subject: RE: [TLS] CAs and certificate chains in the SSL/TLS handshake
> 
> As I disagree with the major part of this post, I had to go 
> back to the spec to re-read what it actually states.
> 
> There is nothing in the current text that says anything about 
> how long chain the client should return. In fact the text is 
> clearly written as if only one certificate is sent. The 
> terminology in 7.4.6 talks about "certificate" and "the 
> certificate" rather than certificates and certificate chains.
> 
> 7.4.6 does not even make any reference to what structure that 
> is used, even if you can determine from other parts of the 
> document that the structure is "Certificate" which allows a 
> chain of certificates.
> 
> This makes no sense to me at all. If the list of CA DNs in 
> certificate_authorities included a list of root CA names, why 
> "SHOULD" the client certificate be issued directly by one of 
> these roots?
> 
> The functionality, as I see it implemented in practice, is 
> simply that the server provides a list of CA names. The 
> client picks a certificate where that CA name is present 
> anywhere in the selected client certificate chain. The client 
> then sends either just the client certificate or the whole 
> chain (with or without the root) to the server according to 
> local policy.
> 
>

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 19 Nov 2007 18:42:24 +0000

Pasi,

I know that the structure for certificates is defined. I was just surprised that this section didn't even mention it. I know that many use standards as dictionaries rather than novels (they don't read them from page 1 to the end). So some kind of hint where the structure is defined would not hurt.

Stefan Santesson
Senior Program Manager

> From: [email-masked] [mailto:[email-masked]]
> Sent: den 19 november 2007 10:00
> To: Stefan Santesson; [email-masked]

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 13:23:34 +0200

Stefan Santesson wrote:
> Pasi,
> 
> I know that the structure for certificates is defined. I was 
> just surprised that this section didn't even mention it. I 
> know that many use standards as dictionaries rather than 
> novels (they don't read them from page 1 to the end). So some 
> kind of hint where the structure is defined would not hurt.

A very reasonable suggestion; I'll propose text to be added 
here during WGLC.

Best regards,
Pasi