RE: Request change in son-of-rfc2633
Russ Housley <housley@vigilsec.com> Wed, 29 October 2003 05:14 UTC
Received: from above.proper.com (above.proper.com [208.184.76.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA25061 for <smime-archive@lists.ietf.org>; Wed, 29 Oct 2003 00:14:31 -0500 (EST)
Received: from above.proper.com (localhost [127.0.0.1]) by above.proper.com (8.12.10/8.12.8) with ESMTP id h9T4NKI7023619 for <ietf-smime-bks@above.proper.com>; Tue, 28 Oct 2003 20:23:20 -0800 (PST) (envelope-from owner-ietf-smime@mail.imc.org)
Received: (from majordom@localhost) by above.proper.com (8.12.10/8.12.9/Submit) id h9T4NKF7023618 for ietf-smime-bks; Tue, 28 Oct 2003 20:23:20 -0800 (PST)
X-Authentication-Warning: above.proper.com: majordom set sender to owner-ietf-smime@mail.imc.org using -f
Received: from woodstock.binhost.com (woodstock.binhost.com [144.202.240.3]) by above.proper.com (8.12.10/8.12.8) with SMTP id h9T4NJI7023612 for <ietf-smime@imc.org>; Tue, 28 Oct 2003 20:23:19 -0800 (PST) (envelope-from housley@vigilsec.com)
Received: (qmail 4401 invoked by uid 0); 29 Oct 2003 04:20:15 -0000
Received: from unknown (HELO Russ-Laptop.vigilsec.com) (65.222.154.72) by woodstock.binhost.com with SMTP; 29 Oct 2003 04:20:15 -0000
Message-Id: <5.2.0.9.2.20031028231703.03f60b40@mail.binhost.com>
X-Sender: housley@mail.binhost.com
X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9
Date: Tue, 28 Oct 2003 23:20:19 -0500
To: pgut001@cs.auckland.ac.nz, blake@brutesquadlabs.com, jimsch@exmsft.com
From: Russ Housley <housley@vigilsec.com>
Subject: RE: Request change in son-of-rfc2633
Cc: ietf-smime@imc.org
In-Reply-To: <200310290405.h9T45OE08868@cs.auckland.ac.nz>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Sender: owner-ietf-smime@mail.imc.org
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-smime/mail-archive/>
List-ID: <ietf-smime.imc.org>
List-Unsubscribe: <mailto:ietf-smime-request@imc.org?body=unsubscribe>
Peter: > >Further, if there is a collision, an implementation can try the very small > >number of public keys that have the same identifier. > >How does it know when to stop looking for more certs? For example, what if it >can only find one cert and it's the wrong one? If the key identifier is computed from the public key as recommended by RFC 3280, the odds are quite small. So, if the first certificate located is not the right one, search for another. If one is not located, then return an error. Russ
- Request change in son-of-rfc2633 Jim Schaad
- Re: Request change in son-of-rfc2633 Russ Housley
- Re: Request change in son-of-rfc2633 Peter Gutmann
- RE: Request change in son-of-rfc2633 Blake Ramsdell
- RE: Request change in son-of-rfc2633 Peter Gutmann
- RE: Request change in son-of-rfc2633 Blake Ramsdell
- RE: Request change in son-of-rfc2633 Peter Gutmann
- RE: Request change in son-of-rfc2633 Blake Ramsdell
- RE: Request change in son-of-rfc2633 Russ Housley
- RE: Request change in son-of-rfc2633 Blake Ramsdell
- RE: Request change in son-of-rfc2633 Russ Housley
- RE: Request change in son-of-rfc2633 Peter Gutmann
- RE: Request change in son-of-rfc2633 Peter Gutmann
- RE: Request change in son-of-rfc2633 Peter Gutmann
- RE: Request change in son-of-rfc2633 Russ Housley
- RE: Request change in son-of-rfc2633 Peter Gutmann
- Re: Request change in son-of-rfc2633 Steve Hanna
- RE: Request change in son-of-rfc2633 Santosh Chokhani
- Re: Request change in son-of-rfc2633 Peter Gutmann
- Re: Request change in son-of-rfc2633 Peter Gutmann