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

[Stefan Santesson <[e-mail]>]

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" <[e-mail]> wrote:

    Stefan Santesson <[e-mail]> 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?
    
    Peter.