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

Stefan Santesson <stefan@aaa-sec.com> Wed, 31 October 2012 18:46 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 CC43B21F888F for <pkix@ietfa.amsl.com>; Wed, 31 Oct 2012 11:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.32
X-Spam-Level:
X-Spam-Status: No, score=-101.32 tagged_above=-999 required=5 tests=[AWL=0.929, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 m1iKvnKMpko9 for <pkix@ietfa.amsl.com>; Wed, 31 Oct 2012 11:46:39 -0700 (PDT)
Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 34ADE21F8864 for <pkix@ietf.org>; Wed, 31 Oct 2012 11:46:38 -0700 (PDT)
Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id B3AD12675A for <pkix@ietf.org>; Wed, 31 Oct 2012 19:46:36 +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 ZwegDlhN5SLA for <pkix@ietf.org>; Wed, 31 Oct 2012 19:46:36 +0100 (CET)
Received: from s331.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 63472229DEBA for <pkix@ietf.org>; Wed, 31 Oct 2012 19:46:36 +0100 (CET)
Received: (qmail 19275 invoked from network); 31 Oct 2012 18:46:35 -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 s331.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for <pkix@ietf.org>; 31 Oct 2012 18:46:35 -0000
User-Agent: Microsoft-MacOutlook/14.2.4.120824
Date: Wed, 31 Oct 2012 19:46:46 +0100
From: Stefan Santesson <stefan@aaa-sec.com>
To: pkix@ietf.org
Message-ID: <CCB72811.5281A%stefan@aaa-sec.com>
Thread-Topic: Proposed resolution to non-issued certificates - 2560bis
In-Reply-To: <CA+i=0E6yVQT3P0Dbqizgvv+Rt-zCbx_FUjAAinW=MNF5nvTmQQ@mail.gmail.com>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: [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 18:46:40 -0000

I didn't put up an end date for the straw-poll, but the trend seems clear.

The results so far (if I counted right)

Supporting #1: 22
Supporting #2: 0
Supporting #3 using "unknown": 6
Supporting #3 using "unauthorised: 2

6 persons supporting #1 has expressed various levels of support/demand for
an explicit declaration that the OCSP responder supports the enhanced
definition of "revoked" to include "no issued".

1 person responded off-line supporting #1.


If the trend reflects the opinion of the WG. This is my proposed
resolution:


1) Extend the "revoked" response to also be allowed for non-issued
certificates. Clearly stating that this is optional if and only if the
OCSP responder knows that the requested serial number has never been
issued.
2) Specify that a "revoked" status for a non-issued certificate serial
number MUST have revocationTime set to Jan 1, 1970 and MUST set the
revocationReason to certificateHold (6).
2) Define a new optional non-critical extension declaring that OCSP
responder returns "revoked" for non-issued certificates according to the
updated standard. This extension MUST be present in all responses where
the "revoked" response is returned as a result of a status request for a
non-issued certificate.


Rationale:
The certificateHold reason feels important for one particular reason. If a
CA is issuing certificates with sequential serial numbers, then it could
be possible to obtain a revoked response for a certificate serial number
that is not yet issued, but soon will be issued. That the certificate
serial number is currently not issued, does not mean that it never will,
thus the certificateHold reason seems more appropriate.

The date 1 Jan, 1970 is appropriate since it is common in programming
languages to express time as milliseconds since jan 1, 1970. Selecting
this time avoids time expression as a negative integer.

This date translates to (java):
Date revocationTime = new Date(0);  //Jan 1st, 1970

The extension would be a simple OID with no data structure and MUST not be
set to critical.


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.

But perhaps this will bee too much to agree on :)

/Stefan