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