Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15

"Peter Rybar" <rybar@nbusr.sk> Wed, 03 April 2013 07:58 UTC

Return-Path: <prvs=0805366aec=rybar@nbusr.sk>
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 835BE21F852A for <pkix@ietfa.amsl.com>; Wed, 3 Apr 2013 00:58:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.756
X-Spam-Level: *
X-Spam-Status: No, score=1.756 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, MANGLED_FROM=2.3]
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 06sd6pWVmv8d for <pkix@ietfa.amsl.com>; Wed, 3 Apr 2013 00:58:17 -0700 (PDT)
Received: from mail.nbusr.sk (mail.nbusr.sk [84.245.65.227]) by ietfa.amsl.com (Postfix) with ESMTP id BEE0A21F84E3 for <pkix@ietf.org>; Wed, 3 Apr 2013 00:58:16 -0700 (PDT)
Message-Id: <201304030758.r337wFTY012218@mail.nbusr.sk>
From: Peter Rybar <rybar@nbusr.sk>
To: 'Andris Berzins' <pkix@inbox.lv>, 'Piyush Jain' <piyush@ditenity.com>
Date: Wed, 03 Apr 2013 09:58:14 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook, Build 11.0.6353
In-Reply-To: <1364925043.515b1a73f12b6@mail.inbox.lv>
Thread-Index: Ac4vyqd5laiPaeQ/ScuZxXpfN+UCJAAcPZ7g
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level: ***
X-NAI-Spam-Threshold: 6
X-NAI-Spam-Score: 3.5
X-NAI-Spam-Version: 2.3.0.9362 : core <4537> : streams <933012> : uri <1383621>
Cc: 'Stefan Santesson' <stefan@aaa-sec.com>, sts@aaa-sec.com, pkix@ietf.org
Subject: Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15
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: Wed, 03 Apr 2013 07:58:17 -0000

In this case when response is only about, as proposed by Piyush "Section 2.2 extends the use of the "revoked" response for certificate serial numbers that are not associated with any issued certificates.", such serial number it does not represent certificate and applications MUST not use it for validations, because certificate does not exist.

When applications already have such certificate then applications MUST start appropriate actions to inform users to contact CAs where it will be resolved.

Such additional recommended steps must be included in rfc2560bis note.

When is used the "revoked" response for certificate serial number that is not associated with issued certificate then the OCSP nextUpdate field is not used and OCSP thisUpdate field is better to be set to some strange value or to proposed value of issuer CA cert notBefore.

Probably "the virtual/fake certificate" unknown to CA or OCSP server has expired nearly after or at the time from issuer CA cert notBefore field. :o)

Peter


-----Original Message-----
From: pkix-bounces@ietf.org [mailto:pkix-bounces@ietf.org] On Behalf Of Andris Berzins
Sent: Tuesday, April 02, 2013 7:51 PM
To: Piyush Jain
Cc: 'Stefan Santesson'; sts@aaa-sec.com; pkix@ietf.org
Subject: Re: [pkix] review of draft-ietf-pkix-rfc2560bis-15

Quoting "Piyush Jain" <piyush@ditenity.com>:
>> 
>> That would signal to relying party that relying party has received old
>> information (old thisUpdate) and would query again on nextUpdate and
>> again would get old response with old thisUpdate and so on.
>> 
>> thisUpdate and nextUpdate should be current time IMHO.
> 
> [Piyush] This is the intent.
> The information is correct as of CA start validity time and can change anyti
>me.

That information is correct not only as of CA start of validity, but also on time
requested, and therefore thisUpdate should be set to the current time, i.e.,
to the time that CA knows that certificate is still not issued.

This is what thisUpdate is about. Why to fix it to some useless value?



> 
> In this case the certificate is revoked since the CA came into being.
> The only time when this information gets updates is when the certificate get
>s issued. At that time the response will contain thisUpdate and nextUpdate f
>rom the CRL.

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix