RE: [TLS] Updated TLS 1.2 I-D

<> Fri, 30 June 2006 12:38 UTC

Received: from [] ( by with esmtp (Exim 4.43) id 1FwIGC-0001X9-E5; Fri, 30 Jun 2006 08:38:12 -0400
Received: from [] ( by with esmtp (Exim 4.43) id 1FwIGA-0001S5-Mi for; Fri, 30 Jun 2006 08:38:10 -0400
Received: from ([]) by with esmtp (Exim 4.43) id 1FwIG8-0000zO-7q for; Fri, 30 Jun 2006 08:38:10 -0400
Received: from ( []) by (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5UCc39f024977; Fri, 30 Jun 2006 15:38:06 +0300
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 15:38:04 +0300
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Jun 2006 15:38:04 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [TLS] Updated TLS 1.2 I-D
Date: Fri, 30 Jun 2006 15:38:01 +0300
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [TLS] Updated TLS 1.2 I-D
Thread-Index: AcaZ9cActYvbT2tnT3eF2DqCho9d8wCSscDA
From: <>
To: <>, <>
X-OriginalArrivalTime: 30 Jun 2006 12:38:04.0367 (UTC) FILETIME=[080FDDF0:01C69C42]
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

Eric Rescorla wrote:

> > The "Hash" algorithm used in RSA signatures is the same hash
> > algorithm used in the signature of the certificate.  Although this
> > is a simple way to choose the "Hash" algorithm, the chosen hash
> > algorithm really reflects the capability of the CA that issued the
> > certificate as opposed to the capability of the certificate's
> > subject (the server or the client). For example, the CA may sign a
> > server certificate that contains an RSA public key using DSA, and
> > "Hash" would be SHA-1 because the signature of the certificate is
> > a DSA signature.
> Yes. This is a hueristic, but it's the one we have. Since it seems
> like a generally safe assumption that you can verify your own
> cert, I don't think there's a problem here.

I agree with Anyang's concerns to some degree; an explicit negotiation
would be better than a heuristic. But since the draft already has
cert_hash_types extension, couldn't we use it to also specify what
algorithms are supported for the "Signature" construct?

(BTW, it would be useful if the server could also indicate to the
client which hash functions it supports, e.g. for client


> > Any interest in adding SHA-384 to the enumerated HashType defined
> > in The current definition of HashType seems to imply that
> > CAs don't plan to sign certificates with SHA-384 in the signatures.
> I don't personally hear much interest in that. How do other
> WG members feel?

Including SHA-384 would make the list match PKCS#1 (except for MD2,
but I guess that's obsolete)... so maybe it would like nicer?

Best regards,

TLS mailing list