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

Stefan Santesson <> Wed, 17 July 2019 07:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 55074120111 for <>; Wed, 17 Jul 2019 00:46:36 -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 SQ_oUClCG9yT for <>; Wed, 17 Jul 2019 00:46:34 -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 DD5D312009C for <>; Wed, 17 Jul 2019 00:46:33 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 9A3F01F165EE for <>; Wed, 17 Jul 2019 09:46:30 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id 7BD6779537F; Wed, 17 Jul 2019 09:46:30 +0200 (CEST)
Received: from (unknown []) by (Postfix) with ESMTP id 77F424707A3; Wed, 17 Jul 2019 09:46:30 +0200 (CEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by ( []) (amavisd-new, port 10024) with LMTP id jqW8S1vylBbT; Wed, 17 Jul 2019 09:46:29 +0200 (CEST)
X-Loopia-Auth: user
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id B414A1E1462B; Wed, 17 Jul 2019 09:46:29 +0200 (CEST)
User-Agent: Microsoft-MacOutlook/10.1a.0.190609
Date: Wed, 17 Jul 2019 09:46:28 +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: Wed, 17 Jul 2019 07:46:36 -0000

The spec says: Don't match hash to a real document if the hash value is A, but ignore matching for any hash values other than A.
(A = all zero in this case).

That (quite obviously) may lead to security vulnerabilities if matching is important for security and implementers don't get it right.
Example: An implementer gets this wrong and only test if the first byte of the hash (he forgot to increment the index counter). I can then cause this implementation to skip matching if I produce a hash with first byte set to 0x00.

All I'm saying is that a safer design is to say "Don't match if value is absent". Implementers are more likely to get that right, but there are no guarantees.

Stefan Santesson 

On 2019-07-17, 05:28, "Peter Gutmann" <> wrote:

    Stefan Santesson <> writes:
    >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.
    How would it lead to implementation errors and security vulns?  It's a value
    that's guaranteed to not match anything while requiring zero changes to
    existing code, what sort of implementation error would it lead to?