Subject: [ietf-tls] Clarification re: certificates in TLS

From: "Al Arsenault" <[email-masked]>
Date: Mon, 22 Jan 2001 10:19:18 -0500

Folks,

    Could someone please clarify for me the requirements on client and server certificates in TLS?

    I was under the impression that the only certificates supported were X.509v3, and they are "supposed to be" (although mostly aren't for legacy & algorithm reasons) compliant with the PKIX spec, RFC 2459.

    However, looking again at RFC 2246, I found the following:

    Section 7.4.2, Server certificate:  "....The certificate type must be appropriate for the selected cipher
       suite's key exchange algorithm, and is generally an X.509v3 certificate. ..." (bottom of p. 37)

    I could read between the lines there, and think that "is generally" means "isn't always" or "is sometimes not".  Should I?

    Now, later on in the same section (bottom of p. 38) it says:  "...All certificate profiles, key and cryptographic formats are defined
   by the IETF PKIX working group [PKIX]. ..."

    For client certificates, section 7.4.6 refers back to 7.4.2.

    Given the contents of the document as a whole, I believe that the intent was to mandate X.509v3/PKIX certificates for both clients and servers. So, my suggestion is to delete the word "generally" from the line in Section 7.4.2 quoted above, so that people like me won't try to read too much into it. :-)

    If the intent is to support other types of certificates, would somebody like to suggest what types and why?

    Thanks,

                    Al Arsenault
                    Chief Security Architect
                    Diversinet Corp.

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 22 Jan 2001 10:52:45 EST

>     Section 7.4.2, Server certificate:  "....The certificate type must =
> be appropriate for the selected cipher
>        suite's key exchange algorithm, and is generally an X.509v3 =
> certificate. ..." (bottom of p. 37)
> 
>     I could read between the lines there, and think that "is generally" =
> means "isn't always" or "is sometimes not".  Should I?

This opens the door for Kerberos cipher suites and the use of Kerberos
tickets in the server or client certificate messages.

 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.

---

---

From: "Al Arsenault" <[email-masked]>
Date: Mon, 22 Jan 2001 11:37:32 -0500

----- Original Message -----
From: Jeffrey Altman <[email-masked]>
To: IETF Transport Layer Security WG <[email-masked]>
Cc: IETF Transport Layer Security WG <[email-masked]>
Sent: Monday, January 22, 2001 10:52 AM
Subject: [ietf-tls] Re: Clarification re: certificates in TLS

> tickets in the server or client certificate messages.

        Okay, then should the comment about "...All certificate profiles,
key and cryptographic formats are defined
   by the IETF PKIX working group [PKIX]. ..." be removed?  Kerberos stuff
isn't defined by PKIX.

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.

---

---

From: "Al Arsenault" <[email-masked]>
Date: Mon, 22 Jan 2001 11:37:32 -0500

----- Original Message -----
From: Jeffrey Altman <[email-masked]>
To: IETF Transport Layer Security WG <[email-masked]>
Cc: IETF Transport Layer Security WG <[email-masked]>
Sent: Monday, January 22, 2001 10:52 AM
Subject: [ietf-tls] Re: Clarification re: certificates in TLS

            Al Arsenault
            Chief Security Architect
            Diversinet Corp.

---

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 22 Jan 2001 12:54:49 EST

>    by the IETF PKIX working group [PKIX]. ..." be removed?  Kerberos stuff

Are you confusing the difference between what is sent during the
"Server Certificate" message and the format of the Certificate data?
When certificates are used, the profiles, key and crypto formats are
indeed specified by PKIX.

---

---

From: David Hopwood <[email-masked]>
Date: Mon, 22 Jan 2001 21:19:00 +0000

-----BEGIN PGP SIGNED MESSAGE-----

Al Arsenault wrote:
>     Section 7.4.2, Server certificate:  "....The certificate type must
> be appropriate for the selected cipher suite's key exchange algorithm,
> and is generally an X.509v3 certificate. ..." (bottom of p. 37)
> 
>     I could read between the lines there, and think that "is generally"

If new ciphersuites (or possibly extensions) are added, they might allow
other certificate formats. However, for all of the existing ciphersuites
that use certs, they must be X.509v3. This is possibly constrained
further (i.e. to a subset of X.509v3) by an application profile.

>     Given the contents of the document as a whole, I believe that the
> intent was to mandate X.509v3/PKIX certificates for both clients and
> servers.

Only for the currently defined ciphersuites, not for the TLS protocol.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip

---

---

From: Oscar Jacobsson <[email-masked]>
Date: Tue, 23 Jan 2001 14:32:48 +0100

> further (i.e. to a subset of X.509v3) by an application profile.

One question I have is that if the certificate formats, and possibly
profiles of are specified on a per-ciphersuite basis, would the same
logic apply to the verification of said certificates? The TLS
specification, as far as I can tell, only mentions certificate
verification very briefly in section D.3.

If the current set of ciphersuites employ (un-profiled) X.509v3
certificates, would it then follow that verification of said
certificates is to be performed according to the path validation
algorithm of X.509 (1997)? Or is this left to the implementors
discretion?

Cheers,

//oscar

---