[pkix] Should Archive Cutoff be included in all OCSP responses?

Jaime Hablutzel <hablutzel1@gmail.com> Sun, 09 June 2019 23:06 UTC

Return-Path: <hablutzel1@gmail.com>
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 E3284120043 for <pkix@ietfa.amsl.com>; Sun, 9 Jun 2019 16:06:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.748
X-Spam-Status: No, score=-1.748 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8uitGt_E16jP for <pkix@ietfa.amsl.com>; Sun, 9 Jun 2019 16:06:15 -0700 (PDT)
Received: from mail-wm1-x32c.google.com (mail-wm1-x32c.google.com [IPv6:2a00:1450:4864:20::32c]) (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 416DF12000E for <pkix@ietf.org>; Sun, 9 Jun 2019 16:06:15 -0700 (PDT)
Received: by mail-wm1-x32c.google.com with SMTP id v19so6417683wmj.5 for <pkix@ietf.org>; Sun, 09 Jun 2019 16:06:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=twxjnZgSK9GJGWOywdZuw7LNuO4R2XZFG+hzlL9ikmk=; b=jAVX6WqoMTeelEAQnX0lYtJ4l7OV2LZkPc8mICrKCUe8/qYF/4zxvccDU9gVfo3BVw bwhQUQt79O8lwgam7ANAqjAhPiSvft1yE4EN8ZSnfkMLztWGU97fwPKH+RWAHquZSvtt EeS/C+t9Cz+tjrkEn+yT2j06O2qJCngrIAPHBA/NuBXt11KyCX2xTvM6MdJhp9avLTAI Uhkia7d5rOx+RtKco0aifnxVvFv4hVE0JweHOBkLNBnxWX+uuIOwYYd4XxpBc7/koPEn TC+GVJCXdKYblYkvsAP0DemHRBb1k8y3WtJnrl041BqUuQYXPaAn3Kded1x2OThmBgzO Zw7Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=twxjnZgSK9GJGWOywdZuw7LNuO4R2XZFG+hzlL9ikmk=; b=nobIXNcFlmujAfiQWuOoJ6D/yDdsUkAOd440Zu+TWLY6a3x6B++58xY61bV1oKDGM8 73Bx9fPxdyowmT+OLAXn8kUqkrbjdbiOdG+Eo34VcOM6k3B+Wcpu6bmOtZGhWJDjEu1c TBO6B+A/HXl5GsvkUgp4N832x8nZaiiA7bhwqpIS/O/pAg/3bgzAFrD0Mhe1sN/Anfzf Us7ie1E/MbFwmluVaOZ70qTwsS9SIOjQR5C326KVrX23R03VdMPJhW8a+l6Lfw4X0C7m phzo6i012m6sEy5YKVJqW9FN/rxyuMJ6QGyDAHoGH7iECjmLuKyMjx/tudQV0r+0eQ93 sr5g==
X-Gm-Message-State: APjAAAVonXds4w/R8p2+WdAvCqF9fkZyA9hhfidU7Sz6QraBucBbqBLH 4NnIM6ZLMOiBLPISz9REU/sWBJ/fc4388SsWwYS98sdoMAI=
X-Google-Smtp-Source: APXvYqxy18RJCJ1u0FTFEAyeWa/ucEQp9ulNbRx4+wtmiV0xiYhppAPeU9WPoXtXAHF200oLnWYy2gm92S4hQGanaFc=
X-Received: by 2002:a7b:cb01:: with SMTP id u1mr12405678wmj.153.1560121573385; Sun, 09 Jun 2019 16:06:13 -0700 (PDT)
MIME-Version: 1.0
From: Jaime Hablutzel <hablutzel1@gmail.com>
Date: Sun, 9 Jun 2019 18:06:01 -0500
Message-ID: <CAFxNpv9Qab8He40v1h96ovgkifmEiA511ELi5nCC6iG3Vagj0g@mail.gmail.com>
To: IETF PKIX <pkix@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000003032f8058aec1c22"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/rUfHNu-1DjAjMAfaINLd4MZcwhI>
Subject: [pkix] Should Archive Cutoff be included in all OCSP responses?
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
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: Sun, 09 Jun 2019 23:06:17 -0000

Quoting from RFC 6960, "4.4.4. Archive Cutoff":

OCSP servers that provide support for such a historical reference
> SHOULD include an archive cutoff date extension *in responses*.

So for an OCSP server which effectively holds archive revocation
information during a given retention interval, it would be valid to
interpret "in responses" as "in all responses"?, so the extension is
included in all responses instead of only a subset of them (e.g. only for
known expired certificates).

Now, I find important to always include it because status for a given
certificate might not be available anymore, but it could have been "good"
or "revoked" in the past, so including the archive cutoff date in this case
would warn clients of this possibility and this might be specially
important when the server has been configured to return "good" for
non-issued certificates and it could be responding "good" now for a deleted
certificate previously "revoked".

In the other hand, if the certificate is not expired yet, to provide the
archive cutoff would help clients to learn the server retention interval,
so they can realize until when the OCSP server guarantees to keep
certificate status after expiration, e.g. a client might need to validate a
digital signature in the future and knowing the archive cutoff would be
helpful for him to know until when he will be able to fully validate the
certificate status after expiration.

Finally, considering the analogous X.509 ExpiredCertsOnCRL extension which,
being a CRL extension instead of a CRL entry extension, would always be
present and provides archive status information for all possible
certificates that expired after the date it specifies, OCSP's Archive
Cutoff would need to be included in all responses (as a singleExtensions of
course) to produce the same effect, isn't it?.

Jaime Hablutzel -  +51 994690880