Re: [pkix] An alternative proposal Was: Fwd: New Version Notification for draft-hamilton-cmr-00.txt

Rob Stradling <rob.stradling@comodo.com> Thu, 03 November 2011 13:11 UTC

Return-Path: <rob.stradling@comodo.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 37AC011E80F4 for <pkix@ietfa.amsl.com>; Thu, 3 Nov 2011 06:11:07 -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=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6SMFh1BDAPK0 for <pkix@ietfa.amsl.com>; Thu, 3 Nov 2011 06:11:06 -0700 (PDT)
Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id 0D80E21F8D24 for <pkix@ietf.org>; Thu, 3 Nov 2011 06:11:05 -0700 (PDT)
Received: (qmail 24655 invoked from network); 3 Nov 2011 13:11:01 -0000
Received: from ian.bd.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 3 Nov 2011 13:11:01 -0000
Received: (qmail 18027 invoked by uid 1000); 3 Nov 2011 13:11:01 -0000
Received: from nigel.brad.office.comodo.net (HELO nigel.localnet) (192.168.0.58) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (AES256-SHA encrypted) ESMTPS; Thu, 03 Nov 2011 13:11:01 +0000
From: Rob Stradling <rob.stradling@comodo.com>
To: pkix@ietf.org
Date: Thu, 03 Nov 2011 13:10:58 +0000
User-Agent: KMail/1.13.7 (Linux/3.0.6-gentoo; KDE/4.6.5; i686; ; )
References: <CAD7F7D5.2003%tmiller@mitre.org>
In-Reply-To: <CAD7F7D5.2003%tmiller@mitre.org>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-Id: <201111031311.00428.rob.stradling@comodo.com>
Subject: Re: [pkix] An alternative proposal Was: Fwd: New Version Notification for draft-hamilton-cmr-00.txt
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, 03 Nov 2011 13:11:07 -0000

On Thursday 03 Nov 2011 12:57:14 Miller, Timothy J. wrote:
> On 11/3/11 7:37 AM, "Phillip Hallam-Baker" <hallam@gmail.com> wrote:
> >That was the old thinking. It is not the current thinking.
> 
> Maybe not yours, but so far I can't seem to grasp exactly why you think
> that way.
> 
> >In the DigiNotar case, whitelisting could have allowed the issue to be
> >detected much earlier.
> 
> Ok, how?  Give me a scenario.

http://isc.sans.edu/diary.html?storyid=11512

"Some of the CA servers have had parts of their logs deleted, leading to 
DigiNotar not knowing what certificates were issued."

"The OCSP server's working at DigiNotar has been reversed since Sept 1st. 
Normally these servers respond with good to all certificates except those on 
the CRL (a blacklist). The OCSP now operates in whitelist mode: it will call 
all unknown certificates signed by DigiNotar as revoked (a whitelist). 
Hence we need to make sure to use the OCSP server to validate DigiNotar 
certificates -should we want/need to- and not rely on the published CRLs 
anymore."

> >The authoritative source for status information is and always has been
> >the CA certificate database. At present the specs are defective in not
> >supporting disclosure of 'does not exist'.
> 
> DigiNotar and Comodo were attacked through compromised Registration
> Authority account credentials.  The attacker in these cases was acting as
> an authorized RA.  This means that as far as internal processes at the CA
> are concerned, the fraudulent certificates were properly issued and had
> entries in the CA database.

In the Comodo case, yes, the fraudulent certificates did have entries in our CA 
database.  They were detected and revoked within a few hours of being issued.

> Detecting which certificates were frauds required checking the CA database
> against data external to the CA--e.g., paperwork, email, payment records,
> etc.--because the CA database itself was at question.  So where does the
> whitelist fit in again?
> 
> 
> -- T
> 
> _______________________________________________
> pkix mailing list
> pkix@ietf.org
> https://www.ietf.org/mailman/listinfo/pkix

Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
  3rd Floor, 26 Office Village, Exchange Quay,
  Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
If you have received this email in error please notify the sender by replying
to the e-mail containing this attachment. Replies to this email may be
monitored by Comodo for operational or business reasons. Whilst every
endeavour is taken to ensure that e-mails are free from viruses, no liability
can be accepted and the recipient is requested to use their own virus checking
software.