[pkix] Should a CRL be required for an OCSP service provider to assert status.

daniel bryan <danbryan80@gmail.com> Wed, 08 June 2016 20:21 UTC

Return-Path: <danbryan80@gmail.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 B2F1212D0ED for <pkix@ietfa.amsl.com>; Wed, 8 Jun 2016 13:21:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level:
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQ1rSN2wVl4c for <pkix@ietfa.amsl.com>; Wed, 8 Jun 2016 13:21:58 -0700 (PDT)
Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 430CB12B02B for <pkix@ietf.org>; Wed, 8 Jun 2016 13:21:58 -0700 (PDT)
Received: by mail-vk0-x236.google.com with SMTP id e4so27431666vkb.1 for <pkix@ietf.org>; Wed, 08 Jun 2016 13:21:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=mrImpvVFI5LjGVrPMtWBZYCGTF1F327kh8FWfsoslTk=; b=Uolscz306DPM0kNthPf9420dBKh5fVSHStlhKh0m8mIS7iTO/GsAgRBj7AVEDceBfe aXBwOwafC2FpkwVhy1lGhd87zbqySNFiWz4+enQSpSJUvDBYtQQTGhPRdu4qg2g9k6Bl ng9VhieuiQVagzHQQqhCk8FPaIezLdmg+JRC4CTPoXBCgO5qTPKU46yV0963ccH5Dn+L GSM5npRQ/r4HdcEBgo7olJtQrW/mucgVvBLUyUd13DZ/yPWqeHiYrIYqMEACuVeX4ibe 2t2ne/oPFDOWEz/2vegNtnXDf/3HUBb2NQW9d84BpRR+hlFmMyA8eK8UBeE3o2aRP6YP Idxg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=mrImpvVFI5LjGVrPMtWBZYCGTF1F327kh8FWfsoslTk=; b=MsYosYuGf9T8T/JQuV0VnYrq7gZFXdZjArlGAeQbnDgxGfJBsD3QPBBdhePcHqPW/t 6stATPEn8ZFrqu3U374gxbqSMUekT+LZGwOdSvBfCzbekT6sbZLwsqEiDIqvubPm3bxU HuLHeHdwGxRxeOcL0egdkhWXT4AjnditYZbkXM/x+exFzMIVBO6Zh/ju55e38Zhz9eyK 5QtROFZ7w79beuocUiTDTq1vO+2QKK38aX+lFOqI25PaOREWhbS3I8wMWeS1JHEpEoi0 lPtrNxtkklaLXyDMQpUN391p31z0RW1lVgyMwVGPHPqPrrl3QidtKhE5hqgNUzqdNU71 3kjQ==
X-Gm-Message-State: ALyK8tKf1CSPw/MxQgQB9TAAVIcN8MmfzHMOEVrVI2JpH929mLWmKwpNW/Lhyw7Ug8iQJOvLf8/lhTPc1/qeJA==
X-Received: by 10.31.136.194 with SMTP id k185mr3157016vkd.2.1465417317095; Wed, 08 Jun 2016 13:21:57 -0700 (PDT)
MIME-Version: 1.0
From: daniel bryan <danbryan80@gmail.com>
Date: Wed, 08 Jun 2016 20:21:47 +0000
Message-ID: <CAJKvcBQq_uK3H_R4Twa9T7xPO-=ySTT1aS049b9QFYGhjsP+xg@mail.gmail.com>
To: "pkix@ietf.org" <pkix@ietf.org>
Content-Type: multipart/alternative; boundary=001a11441b7ca21df00534ca0e0d
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/uumsQcH6_CLQLKp1wUBc1ZNDchA>
Subject: [pkix] Should a CRL be required for an OCSP service provider to assert status.
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 08 Jun 2016 20:22:00 -0000

So i ran into an interesting situation today that sparked a conversation.
Suppose we have a development CA that has issued 2 certificates.  The first
is a SSL webserver cert, and the second is the OCSP Signing certificate
allowing our OCSP service to assert status. The CA has NOT created or
published a CRL. The software we are researching allows a lot of
flexibility in how the ocsp database is created. One of the configuration
options is to compute the database based on a list of serial numbers that
we know the CA says has/will issue. So for example I know this CA has
issued the server cert (serial 0x12345) so I choose to compute 0x12345 as
good. I also choose to make the OCSP response this update value = to the
response creation time, as well as the validity to be a static 10 days from
the response creation. The vendor tool fails to create a database because a
CRL is not present. During my discussion with the vendor, they said,
although they could technically create a database without the CRL in this
case, they don't feel that they have the authority to do so.  But, on the
contrary, they also allow the OCSP service owner to perform "instant
revocation" which marks a serial as revoked regardless if the CA owner
revokes the serial, or publishes a CRL.  My initial thought is an OCSP
service should be able to assert any status as long as the CA has delegated
authority to the service via the OCSP Signing certificate.

Ok, with that whole semi organized info dump about what I know here are the
official questions.

*Q1: Should an OCSP service provider be able to assert a status of revoked
when the serial is not revoked on the CA.*



*Q2: Should an OCSP service provider be able to assert a status of good for
a truly valid issued certificate when no CRL has been created by the CA*
 I would like to know if their our any standards out there that provide
guidance on this subject.