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

Niklas Matthies <> Tue, 16 July 2019 14:58 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2501120614 for <>; Tue, 16 Jul 2019 07:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EPeaqjBY9gyL for <>; Tue, 16 Jul 2019 07:58:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78EAF1206BB for <>; Tue, 16 Jul 2019 07:58:11 -0700 (PDT)
Received: from matthies by with local (Exim 4.89) (envelope-from <>) id 1hnOu8-0003UF-9I for; Tue, 16 Jul 2019 16:58:08 +0200
Date: Tue, 16 Jul 2019 16:58:08 +0200
From: Niklas Matthies <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <>
X-Clacks-Overhead: GNU Terry Pratchett
X-Editor: VIM - Vi IMproved 8.0
X-Operating-System: Linux 4.4.112 x86_64
User-Agent: NeoMutt/20170113 (1.7.2)
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 14:58:14 -0000

It now occurred to me that sigPolicyHash field being optional in ETSI 
TS 101 733 V1.6.3 (2005-09) probably was discovered to be a mistake 
because (1) it introduces a parsing ambiguity with 
sigPolicyQualifiers, as both are optional SEQUENCEs, and (2) because 
it broke compatibility with existing implementation.

So it would seem that the zero hash value was introduced as a 
workaround to still be able to have an optional hash, syntactically 
masquerading as a real hash, and thus maintaining compatibility with 
the earlier versions at least on the ASN.1 level. Then the note about 
backwards compatibility would not be referring to the support of 
"zero" hash values, but to the fact that keeping the sigPolicyHash 
field mandatory for backwards compatibility reasons leaves no other 
choice than to use a "compatible" encoding for a missing hash value.

This interpretation would favor option 3 (using the length implied by 
the hash algorithm), as this arguably causes the least disruption for 
pre-V1.6.3 (and RFC-3126-based) implementations.


On Fri 2019-07-12 at 22:05h, Niklas Matthies wrote on pkix:
>Dear all,
>I hope that someone can shed some light on the definition and origin 
>of the special-case "zero" hash value for SigPolicyHash in CAdES. The 
>main question is what exactly constitutes a "zero" hash value on the 
>ASN.1 level.
>In the most current CAdES specification, ETSI EN 319 122-1 V1.1.1 
>(2016-04), the zero hash value is described as follows (clause 
>, page 20):        The sigPolicyHash field shall contain the 
>identifier of the hash    algorithm and the hash of the value of the 
>signature policy.
>   The hashValue within the sigPolicyHash may be set to zero to    
>indicate that the policy hash value is not known.
>       NOTE: The use of a zero-sigPolicyHash value is to ensure        
>backwards compatibility with earlier versions of ETSI TS 101 733 [1].
>The ASN.1 definition of SigPolicyHash is as follows:
>   SignaturePolicyId ::= SEQUENCE {
>       sigPolicyId SigPolicyId,
>       sigPolicyHash SigPolicyHash,
>       sigPolicyQualifiers SEQUENCE SIZE (1..MAX) OF            
>SigPolicyQualifierInfo OPTIONAL
>   }
>   SigPolicyHash ::= OtherHashAlgAndValue
>   OtherHashAlgAndValue ::= SEQUENCE {
>       hashAlgorithm   AlgorithmIdentifier,
>       hashValue       OtherHashValue }
>   OtherHashValue ::= OCTET STRING
>The question is what constitutes a "zero" hash value. A zero-length 
>octet string? Any octet string where all octets are zero? Is the 
>length of the octet string relevant, e.g. can or should it match the 
>length implied by the hash algorithm?
>I spent some time going back the history of the standards to find the 
>"earlier version" relevant for the note about backwards compatibility, 
>however that search was inconclusive.
>All versions of ETSI TS 101 733 from the latest V2.2.1 (2013-04) back 
>to V1.7.4 (2008-07) include the following note, which had a second 
>sentence added:
>       NOTE: The use of a zero-sigPolicyHash value is to ensure        
>backwards compatibility with earlier versions of the
>       current document. If sigPolicyHash is zero, then the hash        
>value should not be checked against the calculated hash value        
>of the signature policy.
>Confusingly, this now talks about sigPolicyHash being zero (whatever 
>that would mean), not about the hashValue field within sigPolicyHash.
>The same text appears in RFC 5126 (February 2008).
>The previous version ETSI TS 101 733 V1.7.3 (2007-01) is the first 
>version to talk about a zero hash value, and the note is just one 
>sentence again:
>   The hashValue within the sigPolicyHash max [sic] be set to zero to    
>indicate that the policy hash value is not known.
>       NOTE: The use of zero policy hash value is to ensure backward        
>compatibility with earlier versions of the current document.
>In addition, the annex states the following:
>   Annex K (informative): Changes from the previous version
>       • if the hash of the signature policy is unknown, then, by        
>convention, the sigPolicyHash shall be set to all zero
>Here again, the annex talks about sigPolicyHash being set to zero, not 
>the hashValue within sigPolicyHash.
>On the RFC side, the same note first appears in 
> (May 2007), and 
>the sentence above (without the note) first appears in 
> (April 2006).
>In the previous ETSI TS 101 733 V1.6.3 (2005-09), the sigPolicyHash 
>field is optional (which is mandatory in all previous and all 
>subsequent versions), and the following note is included:
>       NOTE: In the previous version of TS 101 733 (i.e. version 
>1.5.1)        sigPolicyHash was mandatory. Implementations requiring 
>to be        backward compatible with version 1.5.1 and previous 
>versions        of the current document MUST include SigPolicyHash.
>None of the previous versions, from ETSI TS 101 733 V1.5.1 (2003-12) 
>back to ETSI TS 101 733 V1.2.2 (2000-12) (the earliest version 
>available at 
>, as well 
>as RFC 3126 (September 2001), do mention anything about zero hash 
>So it remains unclear to which specification backwards compatiblity is 
>intended. The point where the wording about zero hash values was 
>introduced suggests that this may be about V1.6.3, where the
>sigPolicyHash field was optional. However, it's not clear how a "zero" 
>hash value would achieve compatibility with the case of a missing 
>sigPolicyHash field.
>I would appreciate any clarification on that topic.
>Kind regards,
>pkix mailing list