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.
- [pkix] Clarification on "zero" hash value in SigP… Niklas Matthies
- Re: [pkix] Clarification on "zero" hash value in … Stefan Santesson
- Re: [pkix] Clarification on "zero" hash value in … Stefan Santesson
- Re: [pkix] Clarification on "zero" hash value in … Peter Gutmann
- Re: [pkix] Clarification on "zero" hash value in … Stefan Santesson
- Re: [pkix] Clarification on "zero" hash value in … Niklas Matthies
- Re: [pkix] Clarification on "zero" hash value in … Andrea Caccia
- Re: [pkix] Clarification on "zero" hash value in … Niklas Matthies
- Re: [pkix] Clarification on "zero" hash value in … Peter Gutmann
- Re: [pkix] Clarification on "zero" hash value in … Peter Gutmann
- Re: [pkix] Clarification on "zero" hash value in … Ernst G Giessmann
- Re: [pkix] Clarification on "zero" hash value in … Stefan Santesson
- Re: [pkix] Clarification on "zero" hash value in … Stefan Santesson
- Re: [pkix] Clarification on "zero" hash value in … Niklas Matthies