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

"David A. Cooper" <david.cooper@nist.gov> Wed, 31 October 2012 22:23 UTC

Return-Path: <david.cooper@nist.gov>
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 416BC21F868A for <pkix@ietfa.amsl.com>; Wed, 31 Oct 2012 15:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.141
X-Spam-Level:
X-Spam-Status: No, score=-5.141 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4]
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 NcwQrfJ+eMVn for <pkix@ietfa.amsl.com>; Wed, 31 Oct 2012 15:23:27 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 7EE0321F867D for <pkix@ietf.org>; Wed, 31 Oct 2012 15:23:27 -0700 (PDT)
Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.1.421.2; Wed, 31 Oct 2012 18:22:46 -0400
Received: from smtp.nist.gov (129.6.16.226) by smtp-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.1.421.2; Wed, 31 Oct 2012 18:22:28 -0400
Received: from st26.ncsl.nist.gov (st26.ncsl.nist.gov [129.6.54.72]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id q9VMN2CW028766; Wed, 31 Oct 2012 18:23:02 -0400
Message-ID: <5091A4C5.9090609@nist.gov>
Date: Wed, 31 Oct 2012 18:23:01 -0400
From: "David A. Cooper" <david.cooper@nist.gov>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:15.0) Gecko/20120829 Thunderbird/15.0
MIME-Version: 1.0
To: Stefan Santesson <stefan@aaa-sec.com>
References: <CCB753C4.52888%stefan@aaa-sec.com>
In-Reply-To: <CCB753C4.52888%stefan@aaa-sec.com>
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: IETF PKIX <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: Wed, 31 Oct 2012 22:23:28 -0000

Stefan,

Up until now, you have been discussing extending the revoked response as indicated in your current draft of 2560bis:

   The "revoked" state indicates that the certificate has been revoked
   (either permanently or temporarily (on hold)). This state SHOULD also
   be returned if the responder knows that the requested certificate has
   never been issued.

Does your message below mean that you now intend to extend the meaning of "revoked" even further to include certificates that were issued by CA and that were never revoked, but that are now expired?  As I explained before (http://www.ietf.org/mail-archive/web/pkix/current/msg31863.html" rel="nofollow">http://www.ietf.org/mail-archive/web/pkix/current/msg31863.html), I believe that would be a non-backward compatible change.

Dave

On 10/31/2012 05:25 PM, Stefan Santesson wrote:
Here is my own concerns with inclusion of an optional cert hash in the extension.

There might be OCSP responders that do have access to a database of issued certs that are currently valid, but not the history of issued certs (expired).
They could not use this extension to include a cert hash as they can't know if a particular serial number of an expired cert is asked for.

Thus it may be wise to separate these issues and keep it simple and just use an OID to indicate this particular behaviour with regard to "revoked" response.
It may be wise therefore to allow a separate process come up with a separate extension for positive confirmations.
Not that I don't like such functionality.

The alternative is to extend this process long enough that we feel sure we got it right.

/Stefan


From: Tom Ritter <tom@ritter.vg>
Date: Wednesday, October 31, 2012 8:32 PM
To: Stefan Santesson <stefan@aaa-sec.com>
Cc: IETF PKIX <pkix@ietf.org>
Subject: Re: [pkix] Proposed resolution to non-issued certificates - 2560bis

Question:
Would it make sense to require an OCSP responder that adopts the expanded
use of "revoked" to always include the new extension?
It would add the benefit that someone receiving "good" can know that the
OCSP responder has checked that the certificate in fact has been issued by
the CA.
In such case it may be reasonable to add an optional data structure which
MAY contain a hash of the cert.
Such hash would make the positive confirmation even stronger, adding proof
of existence of the certificate.

I'll register my vote for all these items also - I like the idea of providing transparency into the operations of the responders.