IETF Logo Mail Archive

Re: [certid] user overrides

"Thomson, Martin" <Martin.Thomson@andrew.com> Mon, 14 June 2010 23:39 UTC

Return-Path: <Martin.Thomson@andrew.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 870F928C0DC for <certid@core3.amsl.com>; Mon, 14 Jun 2010 16:39:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.082
X-Spam-Level:
X-Spam-Status: No, score=-3.082 tagged_above=-999 required=5 tests=[AWL=-3.083, BAYES_50=0.001]
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 CiSFgaAVttnc for <certid@core3.amsl.com>; Mon, 14 Jun 2010 16:39:08 -0700 (PDT)
Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 824FF3A659A for <certid@ietf.org>; Mon, 14 Jun 2010 16:39:08 -0700 (PDT)
Received: from [10.86.20.103] ([10.86.20.103]:60988 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S24814684Ab0FNXjL (ORCPT <rfc822; certid@ietf.org>); Mon, 14 Jun 2010 18:39:11 -0500
Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 14 Jun 2010 18:39:11 -0500
Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 15 Jun 2010 07:39:09 +0800
From: "Thomson, Martin" <Martin.Thomson@andrew.com>
To: Peter Saint-Andre <stpeter@stpeter.im>
Date: Tue, 15 Jun 2010 07:41:04 +0800
Thread-Topic: user overrides
Thread-Index: AcsJqsF9CoMvlKZrQNybtk6BZ9bfXwCbgxEw
Message-ID: <8B0A9FCBB9832F43971E38010638454F03E7F987C5@SISPE7MB1.commscope.com>
References: <4C104CC3.8070602@stpeter.im> <4C10516B.1000400@stpeter.im> <8B0A9FCBB9832F43971E38010638454F03E7F1FAC4@SISPE7MB1.commscope.com> <4C12A6A5.9060404@stpeter.im>
In-Reply-To: <4C12A6A5.9060404@stpeter.im>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com
X-BCN-Sender: Martin.Thomson@andrew.com
Cc: IETF cert-based identity <certid@ietf.org>
Subject: Re: [certid] user overrides
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: Mon, 14 Jun 2010 23:39:09 -0000

From: Peter Saint-Andre [mailto:stpeter@stpeter.im]
> > What concerns me
> > is that a) the implications of the override are not articulated; and
> > b) this "pinning" or override function applies to certificates
> > regardless of their RFC5280-determined validity;
> 
> That sounds too broad. I don't think we want to let a "pinned"
> certificate off the hook regarding all aspects of PKIX-validity. All
> we're saying is that the user has explicitly approved this certificate
> as acceptable for this application server, despite an identity mismatch.

I might be convinced that you are limiting scope to "server identity" and so you want to enumerate the faults that "pinning" can be used for.  

If you do so, you run the risk of becoming irrelevant.  I can pin a cert in my browser for a number of reasons.   Why is an identity mismatch any more forgivable than an unknown CA?

> > A cached or "pinned" certificate need not be valid according to
> > [PKIX].  A server that presents a pinned certificate is found to
> > match based solely on its ability to prove that it possesses the
> > private key that corresponds to the public key in the certificate.
> 
> Again, I think that's probably too lenient.

Yes, very.  But the alternative (enumeration) seems both hard and counterproductive.

> Peter Saint-Andre

v2.8.7 | Report a Bug | By Email