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

Stefan Santesson <stefan@aaa-sec.com> Tue, 16 July 2019 13:30 UTC

Return-Path: <stefan@aaa-sec.com>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767C01204DA for <pkix@ietfa.amsl.com>; Tue, 16 Jul 2019 06:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.596
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzhOaYNDlq_m for <pkix@ietfa.amsl.com>; Tue, 16 Jul 2019 06:30:00 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BE661204D6 for <pkix@ietf.org>; Tue, 16 Jul 2019 06:29:54 -0700 (PDT)
Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id E98201F154C5 for <pkix@ietf.org>; Tue, 16 Jul 2019 15:29:51 +0200 (CEST)
Received: from s498.loopia.se (unknown [172.21.200.35]) by s554.loopia.se (Postfix) with ESMTP id CB1237949FB; Tue, 16 Jul 2019 15:29:51 +0200 (CEST)
Received: from s474.loopia.se (unknown [172.22.191.6]) by s498.loopia.se (Postfix) with ESMTP id C6F9C470796; Tue, 16 Jul 2019 15:29:51 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s499.loopia.se ([172.22.191.6]) by s474.loopia.se (s474.loopia.se [172.22.190.14]) (amavisd-new, port 10024) with LMTP id DGRw3bzXlzEX; Tue, 16 Jul 2019 15:29:51 +0200 (CEST)
X-Loopia-Auth: user
X-Loopia-User: mailstore2@aaa-sec.com
X-Loopia-Originating-IP: 85.235.7.89
Received: from [192.168.2.38] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s499.loopia.se (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 <stefan@aaa-sec.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>, Niklas Matthies <pkix@nmhq.net>, "pkix@ietf.org" <pkix@ietf.org>
Message-ID: <218E69B7-036E-45FF-AD3B-9F017FCAF40E@aaa-sec.com>
Thread-Topic: [pkix] Clarification on "zero" hash value in SigPolicyHash (CAdES)
References: <20190712200549.2kgzjqodj5afnxlt@nmhq.net> <0FDBEEC9-0FBA-4C47-BD04-EE7F6053426D@aaa-sec.com> <1563269533626.58560@cs.auckland.ac.nz>
In-Reply-To: <1563269533626.58560@cs.auckland.ac.nz>
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pkix/nLhSYuXoytXhpHtvrff1Am5tJJU>
Subject: Re: [pkix] Clarification on "zero" hash value in SigPolicyHash (CAdES)
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pkix/>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=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" <pgut001@cs.auckland.ac.nz>; wrote:

    Stefan Santesson <stefan@aaa-sec.com>; 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.