Re: [pkix] Clarification on "zero" hash value in SigPolicyHash (CAdES)

Stefan Santesson <> Tue, 16 July 2019 13:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 767C01204DA for <>; Tue, 16 Jul 2019 06:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id fzhOaYNDlq_m for <>; Tue, 16 Jul 2019 06:30:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BE661204D6 for <>; Tue, 16 Jul 2019 06:29:54 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id E98201F154C5 for <>; Tue, 16 Jul 2019 15:29:51 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id CB1237949FB; Tue, 16 Jul 2019 15:29:51 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id C6F9C470796; Tue, 16 Jul 2019 15:29:51 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10024) with LMTP id DGRw3bzXlzEX; Tue, 16 Jul 2019 15:29:51 +0200 (CEST)
X-Loopia-Auth: user
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id 617B71CDADDD; Tue, 16 Jul 2019 15:29:51 +0200 (CEST)
User-Agent: Microsoft-MacOutlook/10.1a.0.190609
Date: Tue, 16 Jul 2019 15:29:51 +0200
From: Stefan Santesson <>
To: Peter Gutmann <>, Niklas Matthies <>, "" <>
Message-ID: <>
Thread-Topic: [pkix] Clarification on "zero" hash value in SigPolicyHash (CAdES)
References: <> <> <>
In-Reply-To: <>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <>
Subject: Re: [pkix] Clarification on "zero" hash value in SigPolicyHash (CAdES)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 16 Jul 2019 13:30:02 -0000

To assign a specific meaning to one out of all possible but syntactically valid hash values, is exactly the type of specification work that leads to implementation errors and security vulnerabilities.

Stefan Santesson 

´╗┐On 2019-07-16, 11:32, "Peter Gutmann" <>; wrote:

    Stefan Santesson <>; writes:
    >However, option 3 is the absolute worst from an implementation perspective as
    >it is the hardest to programmatically distinguish from a real hash value.
    I would say it's the best from an implementation perspective, you don't need
    to make any code changes, it's a normal looking hash value that's guaranteed
    not to match anything.  Existing implementations that expect a hash there will
    continue to work as normal.
    >My conclusion is that the standard is so ambiguous that any receiving
    >implementation should be able to handle all 3 alternatives.
    A slightly different interpretation is that since that part of the standard is
    essentially unimplementable, it's likely no-one has ever implemented it, so it
    can be safely dropped.  Given earlier evidence that it's only there for
    backwards compatibility with something no-one can identify, this enhances the
    case for dropping it from the standard.