Re: [TLS] Record layer corner cases

Mike <mike-list@pobox.com> Mon, 27 November 2006 23:06 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GopYd-0000vq-5p; Mon, 27 Nov 2006 18:06:39 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GopYc-0000vb-6A for tls@ietf.org; Mon, 27 Nov 2006 18:06:38 -0500
Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GopYZ-00040a-Vo for tls@ietf.org; Mon, 27 Nov 2006 18:06:38 -0500
Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 2AEFB9783D for <tls@ietf.org>; Mon, 27 Nov 2006 18:06:53 -0500 (EST)
Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 810CF975E2 for <tls@ietf.org>; Mon, 27 Nov 2006 18:06:52 -0500 (EST)
Message-ID: <456B6FE6.7030108@pobox.com>
Date: Mon, 27 Nov 2006 15:08:22 -0800
From: Mike <mike-list@pobox.com>
User-Agent: Thunderbird 1.5.0.8 (Windows/20061025)
MIME-Version: 1.0
To: tls@ietf.org
Subject: Re: [TLS] Record layer corner cases
References: <200611272239.XAA17494@uw1048.wdf.sap.corp>
In-Reply-To: <200611272239.XAA17494@uw1048.wdf.sap.corp>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581
Cc:
X-BeenThere: tls@lists.ietf.org
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." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org

>> You argue that a TLS receiver should go out of its way to
>> build a second, longer path that contains the root certificate:
>>
>>    2) TA -> Root -> CA -> EE
> 
> Correct.  SSLv3 (and probably TLS as well) supports only a straight
> forward certification path, and if the local trust anchor happens
> to be the rootCA cert, then I think it is correct to check that
> rootCA cert during path validation in case the peer sends it.

My certificate store (which contains all the trusted certificates)
is indexed based on the DER encoding of the certificates, so if a
server includes a root certificate in its certification path, it
is easily determined to be a trust anchor.  So in my case TA ==
Root and you are left with TA -> CA -> EE.

However, this discussion pointed out that I was checking the
expiration date of the trust anchor, which apparently is not the
right thing to do, so I just eliminated that check.

Mike

_______________________________________________
TLS mailing list
TLS@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls