Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

"Piyush Jain" <piyush@ditenity.com> Tue, 23 October 2012 15:11 UTC

Return-Path: <piyush@ditenity.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8269C21F8644 for <pkix@ietfa.amsl.com>; Tue, 23 Oct 2012 08:11:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.268
X-Spam-Level:
X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8WvNsqi2czO5 for <pkix@ietfa.amsl.com>; Tue, 23 Oct 2012 08:11:12 -0700 (PDT)
Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFA9321F8602 for <pkix@ietf.org>; Tue, 23 Oct 2012 08:11:11 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id o25so3591054iad.31 for <pkix@ietf.org>; Tue, 23 Oct 2012 08:11:11 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=PNQp5z1NHuDlryyT2tYACdsYyoWKW46WakKB2/U6hm8=; b=Mxq5QITSiE1eMEy/HpxMvQ3skcLzYDKdWG7XMyJNDGC6dNkxeAsnhSLWA4C8fuOswU SGFc/J2/dtqbwbezrWs5Ys8MhLQoYAY+WUhVwmq/xmTODNqCznAbZRXMcOajXo3lSQSw sJshnQDtmz2M3BT0Qf8p4SxvKoMKB2Uc+5FjTMTKzqKGBQKNwc/deb6xG7BbKMBeSHNV GwsWZ1PoCPMN6JAvtXrkea7+GGXFmyFO1e+Ort46SfauOtcUXiAiCxiH7XWXrDbYjLCt 1SNd4Vqm5gOAkwU6fr6Uo5wVl1riG1K6azmO4i92fH0H4GQbOW+jqGTSLyKomzJV4717 pxOg==
Received: by 10.50.193.161 with SMTP id hp1mr13222720igc.27.1351005071490; Tue, 23 Oct 2012 08:11:11 -0700 (PDT)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ch4sm25108067igb.2.2012.10.23.08.11.08 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 23 Oct 2012 08:11:10 -0700 (PDT)
From: Piyush Jain <piyush@ditenity.com>
To: mrex@sap.com, 'Erwann Abalea' <eabalea@gmail.com>
References: <CA+i=0E5EjhvqU+4fdtiEMO-gjGqjrSkbZ30S19VvgYie97jG5w@mail.gmail.com> <20121023134121.9FD8D1A2EE@ld9781.wdf.sap.corp>
In-Reply-To: <20121023134121.9FD8D1A2EE@ld9781.wdf.sap.corp>
Date: Tue, 23 Oct 2012 08:11:07 -0700
Message-ID: <02a101cdb130$a21f9de0$e65ed9a0$@ditenity.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQNGNV686hLxHEPm0x+ftXTlG3SOo5TV8p4Q
Content-Language: en-us
X-Gm-Message-State: ALoCoQnGl2AjiZ0kUGsTFUkl7Qu/npA0VF7gBSegxvqFu9uIBiC4lRSsHcpSp1d+VRgaNdC119Y3
Cc: 'Peter Rybar' <peterryb@gmail.com>, pkix@ietf.org, 'Stefan Santesson' <stefan@aaa-sec.com>
Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Oct 2012 15:11:12 -0000

> A well-behaving OCSP responder is one that does not let RPs fall for
> fraudulent certs when it knows pretty damn well that the cert that the RP
is
> requesting the status, for can not possibly be a bona fide
> certificate.   An OCSP responder that lets RPs down so recklessly
> does not count as trustworthy on my scorecard. (Bad dog, no cookie).

This is the unintended consequence that I was talking about earlier. People
will actually start believing that OCSP responders certified by a
compromised CA are trustworthy and authoritative if these responders issue
revoked for fraudulent certificates. 

Martin - If the RP does not check that the payload certificate is bound to
the issuing CA, OCSP response is meaningless. And if the payload certificate
is cryptographically bound to the CA, and CA thinks it is not issued then
the CA and as a result OCSP responder certified by the CA are compromised
and hence not trustworthy.

Not saying that OCSP responder should return revoked in this case, but if it
does the, right reason code should be CACompromised. After all such a
certificate could only be issued (or shall I say non-issued) if the CA is
compromised.

-Piyush