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

"Piyush Jain" <piyush@ditenity.com> Thu, 25 October 2012 03:56 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 1DE3C1F0C7F for <pkix@ietfa.amsl.com>; Wed, 24 Oct 2012 20:56:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.315
X-Spam-Level:
X-Spam-Status: No, score=-3.315 tagged_above=-999 required=5 tests=[AWL=0.284, 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 WqVaIvJ-Kg8e for <pkix@ietfa.amsl.com>; Wed, 24 Oct 2012 20:56:10 -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 7DC981F0C4A for <pkix@ietf.org>; Wed, 24 Oct 2012 20:56:10 -0700 (PDT)
Received: by mail-ia0-f172.google.com with SMTP id o25so1113401iad.31 for <pkix@ietf.org>; Wed, 24 Oct 2012 20:56:10 -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=6v3XlNuJ4VKhx1pyRqaq6J3/Nn8aPSduoRg/XjVXbWQ=; b=YqmIyuEKi9dgEN53T0OU5jfR7+CszA2KP2vTQCrOdM4l5OD2633rdfWs5cmtaEYHHv nH79u4aQ5HTjAEfU0zkkLMZHDD0p5QM2XhfDsaTFyZoTrgcTI4wUWcWoee5AjsCAQhAB aauDvm/XEuXKhI3sEVhOsudPwY/Y0k+iNE1lJMTHk2mUK/beX180DLqPZ1sEIJWmx1Uq zH1GP+cvphHODooGHaWZ5rJTF3dMaHEkMRWXHvFxVaWH4PBJpo3qiBE8KGyZ/FnAnWew qAL4y0mfTDQlMZqPXO0sItREGXyszpd9WXV8GbtJeJk+jJj1L9Xnm0Ks7eGOyCuxLk14 5eRA==
Received: by 10.50.151.172 with SMTP id ur12mr4691078igb.44.1351137369984; Wed, 24 Oct 2012 20:56:09 -0700 (PDT)
Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ex10sm3719378igc.15.2012.10.24.20.56.07 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Oct 2012 20:56:09 -0700 (PDT)
From: Piyush Jain <piyush@ditenity.com>
To: mrex@sap.com
References: <04d801cdb238$2ac3f350$804bd9f0$@ditenity.com> <20121024224721.EE2201A2F3@ld9781.wdf.sap.corp>
In-Reply-To: <20121024224721.EE2201A2F3@ld9781.wdf.sap.corp>
Date: Wed, 24 Oct 2012 20:56:05 -0700
Message-ID: <052d01cdb264$a9a32ed0$fce98c70$@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: AQHfLv9/VJ87pJZQkWKugh6d3aoOXJemZeDw
Content-Language: en-us
X-Gm-Message-State: ALoCoQmIBjah4tVzheg9Vv6x0hEWSX6z54IVZedzDTpHhx5WmwqZaPtzMmjkIC82YEicyblFa68M
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: Thu, 25 Oct 2012 03:56:11 -0000

> -----Original Message-----
> From: Martin Rex [mailto:mrex@sap.com]
> Sent: Wednesday, October 24, 2012 3:47 PM
> To: Piyush Jain
> Cc: mrex@sap.com; 'Peter Rybar'; pkix@ietf.org; 'Stefan Santesson'
> Subject: Re: [pkix] New draft-ietf-pkix-rfc2560bis-06
> 
> Piyush Jain wrote:
> >
> >> The "cert hash" in the OCSP response option protects against
> >> hash-collisions and fraudulently issued without record of certs that
> >> re-use the serial of regular valid certs to appear innocent from not
> >> being detectable.
> >>
> >> So that cert hash should probably use at least SHA-256.  Being a new
> >> protocol feature, that ought to be easy (we skipped SHA-1 in DANE as
> well).
> >
> > [Piyush]  I think you mean appears to protect.
> > I hope people really don't start believing that this extension
> > protects them from a CA compromise scenario.
> 
> 
> You're confusing things.  The reason why this protection currently does
not
> work is not that there is a problem with conveying back the hash, but that
> the current scheme to identify an authorized OCSP responder cert is
fatally
> flawed.
[Piyush] I'm confused but only after your comments. What scheme are you
talking about - CA delegated trust or direct trust dictated by local policy?
> 
> Fixing the authorized OCSP responder issue is by defining a new attribute
> that is hardwired into the CA cert in order to establish an alternative
trust
> path.
> 
[Piyush] We are not talking about overhauling the protocol here. Are you
implying that without this new attribute (whatever it is) the proposed
change of returning revoked for fraudulent cert is not beneficial? If so
then this discussion is moot.
> 
> The other thing you seem to totally discount is that not every breach of
the
> CAs security amounts to a full and thorough compromise, i.e. that the
> attacker can get hold of an carry away the CA private signature key.
> 
[Piyush] If an attacker can issue fraudulent certificate it can issue a
fraudulent certificate that points to a fraudulent OCSP responder also
issued by the compromised CA. Unless you create a trust model where
responder trust is independent of CA trust, these proposals just amount to
hacks.
Intent of OCSP is to address operational issues associated with CRL not to
detect CA compromises. 


> 
> -Martin