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

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" <[email protected]> wrote:

    Stefan Santesson <[email protected]> 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.
    
    Peter.
    


_______________________________________________
pkix mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/pkix