IETF Logo Mail Archive

Re: [pkix] Proposed resolution to non-issued certificates - 2560bis

Stefan Santesson <stefan@aaa-sec.com> Fri, 02 November 2012 15:24 UTC

Return-Path: <stefan@aaa-sec.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 B5D0C21F87C3 for <pkix@ietfa.amsl.com>; Fri, 2 Nov 2012 08:24:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.785
X-Spam-Level:
X-Spam-Status: No, score=-100.785 tagged_above=-999 required=5 tests=[AWL=-0.533, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_31=0.6, MIME_QP_LONG_LINE=1.396, USER_IN_WHITELIST=-100]
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 Q8Ep7FziEMQz for <pkix@ietfa.amsl.com>; Fri, 2 Nov 2012 08:24:26 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC1921F8946 for <pkix@ietf.org>; Fri, 2 Nov 2012 08:24:25 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id DD0ED3629B for <pkix@ietf.org>; Fri, 2 Nov 2012 16:19:41 +0100 (CET)
X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se
Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mSUFuwdKPUhu for <pkix@ietf.org>; Fri, 2 Nov 2012 16:19:39 +0100 (CET)
Received: from s328.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id C2386362BA for <pkix@ietf.org>; Fri, 2 Nov 2012 16:19:28 +0100 (CET)
Received: (qmail 96092 invoked from network); 2 Nov 2012 15:19:28 -0000
Received: from 81-232-51-61-no39.business.telia.com (HELO [192.168.0.113]) (stefan@fiddler.nu@[81.232.51.61]) (envelope-sender <stefan@aaa-sec.com>) by s328.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <simon@tardell.se>; 2 Nov 2012 15:19:28 -0000
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Fri, 02 Nov 2012 16:19:31 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: Simon Tardell <simon@tardell.se>, Peter Rybar <rybar@nbusr.sk>
Message-ID: <CCB9A1ED.52A54%stefan@aaa-sec.com>
Thread-Topic: [pkix] Proposed resolution to non-issued certificates - 2560bis
In-Reply-To: <CANkYYy5TsTajY4hztaHaFeWsUYd+d+7st_yKCcqUAkdWNY6BMw@mail.gmail.com>
Mime-version: 1.0
Content-type: multipart/alternative; boundary="B_3434717976_34724110"
Cc: "pkix@ietf.org" <pkix@ietf.org>
Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis
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: Fri, 02 Nov 2012 15:24:26 -0000

Agree with Simon,

Except on the CRL issue. It is not up to the OCSP standard to limit the use
of other services for revocation status checking.
Just because security of OCSP has been enhanced slightly, does not
necessarily mean that clients must stop using CRL:s.

/Stefan

From:  Simon Tardell <simon@tardell.se>
Date:  Friday, November 2, 2012 1:08 PM
To:  Peter Rybar <rybar@nbusr.sk>
Cc:  Stefan Santesson <stefan@aaa-sec.com>, "pkix@ietf.org" <pkix@ietf.org>
Subject:  Re: [pkix] Proposed resolution to non-issued certificates -
2560bis

> 
> 
> 
> On Fri, Nov 2, 2012 at 11:16 AM, Peter Rybar <rybar@nbusr.sk> wrote:
>> Stefan,
>> 
>>  
>> 
>> I agree with David A. Cooper and Piyush.
>> 
>>  
>> 
>> And also retroactive revocation is not allowed in X.509.
>> 
>> The certificate status "revoked" in OCSP must be consistent with the status
>> in CRL.
>> 
>> In this case it is not consistent because status "revoked" is proposed to be
>> in OCSP but in the same time it is not included in CRL.
>> 
>> Validation will be different by CRL/OCSP!
> 
> So a CA that does answer revoked for never issued MUST NOT use CRLs.
>> Don't forget that also thisUpdate MUST be correctly used and included in OCSP
>> response.
>> 
>>  
>> 
>>    - thisUpdate: The time at which the status being indicated is known to be
>> correct.
>> 
>>  
>> 
>> It mans any new "correct" revocation MUST be with revocation value which is
>> greater than value thisUpdate of any issued CRL/OCSP.
>> 
>> Including revocation date/time before value thisUpdate (of any already issued
>> CRL/OCSP) is destruction of X.509 fundamental rules for validations.
>> 
>> Date and time of revocation MUST be only after value thisUpdate which is
>> included in last issued CRL or OCSP.
>> 
> 
> I don't quite understand. The revocationTime of a RevokedInfo must logically
> be earlier than the thisUpdate of the response, unless we assume that we are
> dealing with a precog OCSP responder. The OCSP responder should try to keep
> the thisUpdate as close to "now" as it can, to limit the window where
> compromised keys can be used.
>  
> /Simon

v2.23.0 | Report a Bug | By Email