Re: [certid] section 4.6 rewrite (aka: Bad certificate handling)
"Jim Schaad" <ietf@augustcellars.com> Thu, 30 September 2010 05:18 UTC
Return-Path: <ietf@augustcellars.com>
X-Original-To: certid@core3.amsl.com
Delivered-To: certid@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix)
with ESMTP id 4DFCC3A6B1F for <certid@core3.amsl.com>;
Wed, 29 Sep 2010 22:18:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5
tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com
[127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DzcC14jZM7OJ for
<certid@core3.amsl.com>; Wed, 29 Sep 2010 22:18:42 -0700 (PDT)
Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by
core3.amsl.com (Postfix) with ESMTP id B84653A6B7E for <certid@ietf.org>;
Wed, 29 Sep 2010 22:18:41 -0700 (PDT)
Received: from TITUS (unknown [207.202.179.27]) (using TLSv1 with cipher
AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated
sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTP id
91C2F6A41D; Wed, 29 Sep 2010 22:19:26 -0700 (PDT)
From: "Jim Schaad" <ietf@augustcellars.com>
To: "'Matt McCutchen'" <matt@mattmccutchen.net>,
"'=JeffH'" <Jeff.Hodges@KingsMountain.com>
References: <4CA3AF50.6050101@KingsMountain.com>
<1285808207.1917.28.camel@mattlaptop2.local>
In-Reply-To: <1285808207.1917.28.camel@mattlaptop2.local>
Date: Wed, 29 Sep 2010 22:27:05 -0700
Message-ID: <006c01cb6060$1f213cf0$5d63b6d0$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGpqtf1DBfzG3HdU1/o9iR7FXwOzwIyKBCqk1vZBDA=
Content-Language: en-us
Cc: 'IETF cert-based identity' <certid@ietf.org>
Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling)
X-BeenThere: certid@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Representation and verification of identity in certificates
<certid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/certid>,
<mailto:certid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/certid>
List-Post: <mailto:certid@ietf.org>
List-Help: <mailto:certid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/certid>,
<mailto:certid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Sep 2010 05:18:43 -0000
> -----Original Message----- > From: certid-bounces@ietf.org [mailto:certid-bounces@ietf.org] On Behalf Of > Matt McCutchen > Sent: Wednesday, September 29, 2010 5:57 PM > To: =JeffH > Cc: IETF cert-based identity > Subject: Re: [certid] section 4.6 rewrite (aka: Bad certificate handling) > > On Wed, 2010-09-29 at 14:27 -0700, =JeffH wrote: > > I and PeterSA took a hard look at section "4.6 Outcome" (aka: Bad > > certificate > > handling) and indeed its language needed some semi-major rewriting, > > which we've done. The entire new section "4.6 Outcome" is below. > > > > comments? > > The cases of "no cached certificate" and "different cached certificate" > could probably be combined into "certificate not cached" to simplify things. > I.e.: > > ### > > 4.6. Outcome > ... > 4.6.1. Case #1: Match Found > ... > 4.6.2. Case #2: No Match Found, Certificate Cached > > If the client does not find a presented identifier matching any of the reference > identifiers, but the presented certificate has been designated as acceptable for > this application service (a) by a human user during a previous interaction with > the service or (b) via configuration settings, the server identity check succeeds. > [XXX: What is the validated identity of the server? Should the cached certificate > rather be designated as acceptable for a reference identifier, which can be > taken as the identity of the server?] You cannot take the presented identifier as the identity of the server as it might contain wild cards. > > 4.6.3. Case #3: No Match Found, Certificate Not Cached > > If the client does not find a presented identifier matching any of the reference > identifiers and the presented certificate has not been accepted as described in > section 4.6.2, then the client MUST NOT consider the certificate to include a > validated identity for the application service. Instead, the client MUST proceed > as follows. [...] > > ### > > -- > Matt > > _______________________________________________ > certid mailing list > certid@ietf.org > https://www.ietf.org/mailman/listinfo/certid
- [certid] section 4.6 rewrite (aka: Bad certificat… =JeffH
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Jim Schaad
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Peter Saint-Andre
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Jim Schaad
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Peter Saint-Andre
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Matt McCutchen
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Matt McCutchen
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Martin Rex
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Jim Schaad
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Jim Schaad
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Martin Rex
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Jim Schaad
- Re: [certid] section 4.6 rewrite (aka: Bad certif… =JeffH
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Martin Rex
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Jim Schaad
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Martin Rex
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Peter Saint-Andre
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Jim Schaad
- Re: [certid] section 4.6 rewrite (aka: Bad certif… Peter Saint-Andre