[pkix] PKIX and Revocation - Time to move forward!
"Dr. Pala" <firstname.lastname@example.org> Mon, 20 November 2017 17:20 UTC
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8EEA12957F for <email@example.com>; Mon, 20 Nov 2017 09:20:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 ([188.8.131.52]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XzyHuIOa0Umy for <firstname.lastname@example.org>; Mon, 20 Nov 2017 09:20:35 -0800 (PST)
Received: from mail.katezarealty.com (mail.katezarealty.com [184.108.40.206]) by ietfa.amsl.com (Postfix) with ESMTP id A90A5129C5D for <email@example.com>; Mon, 20 Nov 2017 09:20:34 -0800 (PST)
Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 52A683740FB2 for <firstname.lastname@example.org>; Mon, 20 Nov 2017 17:20:34 +0000 (UTC)
X-Virus-Scanned: amavisd-new at katezarealty.com
Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bnhw_qX1wA5q for <email@example.com>; 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 [220.127.116.11]) (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 <firstname.lastname@example.org>; Mon, 20 Nov 2017 12:20:32 -0500 (EST)
From: "Dr. Pala" <email@example.com>
Organization: OpenCA Labs
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
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030200010506070209050201"
Subject: [pkix] PKIX and Revocation - Time to move forward!
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:email@example.com?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 here: * 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. Cheers, Max [*] 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