[pkix] PKIX and Revocation - Time to move forward!

"Dr. Pala" <director@openca.org> Mon, 20 November 2017 17:20 UTC

Return-Path: <director@openca.org>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B8EEA12957F for <pkix@ietfa.amsl.com>; Mon, 20 Nov 2017 09:20:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id XzyHuIOa0Umy for <pkix@ietfa.amsl.com>; Mon, 20 Nov 2017 09:20:35 -0800 (PST)
Received: from mail.katezarealty.com (mail.katezarealty.com []) by ietfa.amsl.com (Postfix) with ESMTP id A90A5129C5D for <pkix@ietf.org>; Mon, 20 Nov 2017 09:20:34 -0800 (PST)
Received: from localhost (unknown []) by mail.katezarealty.com (Postfix) with ESMTP id 52A683740FB2 for <pkix@ietf.org>; Mon, 20 Nov 2017 17:20:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([]) by localhost (mail.katezarealty.com []) (amavisd-new, port 10024) with LMTP id bnhw_qX1wA5q for <pkix@ietf.org>; Mon, 20 Nov 2017 12:20:33 -0500 (EST)
Received: from nuc.openca.org (207-38-147-98.s4930.c3-0.avec-ubr2.nyr-avec.ny.cable.rcncustomer.com []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id DE5003740C38 for <pkix@ietf.org>; Mon, 20 Nov 2017 12:20:32 -0500 (EST)
To: pkix@ietf.org
From: "Dr. Pala" <director@openca.org>
Organization: OpenCA Labs
Message-ID: <af3b85eb-7ff5-d010-74ba-c87a41996f81@openca.org>
Date: Mon, 20 Nov 2017 12:20:31 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030200010506070209050201"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/-YC_xUSWmwmCCm72MoDQzYf9Vrg>
Subject: [pkix] PKIX and Revocation - Time to move forward!
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 20 Nov 2017 17:20:38 -0000

Hi all,

although it seems that in the SEC area there is little interest in 
addressing the issue of revocation, we think it is still important to 
address it. Unfortunately, since the PKIX WG was closed, this type of 
work has no house and, as a consequence, there has been NO improvement 
on PKIX in AGES!

We are currently working on a couple of proposals that we are going to 
deploy (independently from IETF's interest in it) in several industry 
segments and related organizations. In particular, we have two different 
proposals. The first is the OCSP over DNS that aims at providing an 
additional transport protocol for OCSP responses (i.e., it is an 
alternative to OCSP over HTTP and not, as some people wrongly focused 
on, as a replacement of OCSP stapling). The draft is currently available 

  * https://datatracker.ietf.org/doc/draft-pala-odin/

For the second proposal, we are not ready to disclose it but it is 
related to improve and simplify revocation information checking.

In order to make a good case around the new design, I wanted to ask the 
PKIX WG few questions that would help confirming or rejecting our 
assumptions related to some PKIX ops (from a CA perspective).

These are my questions:

  * *Does anyone remember why the use of non-sequential random serial
    number for certificates was introduced ?* Initially, I think, it was
    an attempt at masking the number of issued certificates from a CA.
    Then, there was some kind of argument about the "randomness" of data
    within certificates (that did not make sense to me, really, since
    the public key provides plenty of randomness) - maybe this was
    combined with the fear of having "weak" hash algorithms for signing
    certificates ? I.e., SHA-1 ? If that is correct, would the use of
    SHA2 family (or next gen ones) solve the issue and remove the
    alleged need for random serial numbers ?

  * *Why the OCSP protocol behavior was shifted from revocation checking
    to validity checking ?* When the OCSP protocol was first
    standardized, it was meant to provide revocation information (an
    alternative to CRLs) - in particular when no revocation information
    existed related to a requested serial number, the response would
    carry the "valid" response. Following some compromises of CAs, the
    CAB forum (???) decided to mandate for a different interpretation of
    the OCSP: instead of a revocation checking mechanism, they wanted to
    use it as a validation mechanism in the sense that "valid" responses
    were to be returned only for serial numbers of ISSUED certificates
    and not for serial numbers for which no revocation information
    existed (i.e., even if a certificate with the requested serial
    number was never issued). If I am not mistaken, this was an attempt
    at certificate transparency - for which now we have a whole set of
    (overly complicated, IMHO) infrastructure :-( If that is true,
    wouldn't be the original intended usage of OCSP be more appropriate
    today ?

Since in the recent years we developed lots of experience when it comes 
to what and how is actually used for revocation checking, I think we can 
easily provide simpler designs with lower operational costs and, 
consequently, better (more frequent) updates [*] for revocation 
information that take all these considerations into account (in 
particular, the requirements related to the 2nd question above have 
pushed the costs of providing revocation information - probably an 
not-intended consequence/side effect).

Thanks everybody in advance for all your feedback/insights, and please 
let me know if you are interested in collaborating and in which capacity.


[*] Because of this shift in OCSP behavior, CAs now issue OCSP responses 
that have validity of up to 7 days, which is definitely not what OCSP 
was intended for (usually few minutes, hours or maybe one day max was 
initially view

Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo