Re: [pkix] [Technical Errata Reported] RFC6960 (6165)

Stefan Santesson <stefan@aaa-sec.com> Mon, 11 May 2020 13:59 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 9C00F3A0B1D for <pkix@ietfa.amsl.com>; Mon, 11 May 2020 06:59:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_MSPIKE_H2=-0.001, 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 Sj_sIzTSnHdd for <pkix@ietfa.amsl.com>; Mon, 11 May 2020 06:59:27 -0700 (PDT)
Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [93.188.3.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FFC3A0B0F for <pkix@ietf.org>; Mon, 11 May 2020 06:59:27 -0700 (PDT)
Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 359F72ECE24B for <pkix@ietf.org>; Mon, 11 May 2020 15:59:22 +0200 (CEST)
Received: from s498.loopia.se (unknown [172.22.191.6]) by s807.loopia.se (Postfix) with ESMTP id 1323B2E3528E; Mon, 11 May 2020 15:59:22 +0200 (CEST)
Received: from s474.loopia.se (unknown [172.22.191.6]) by s498.loopia.se (Postfix) with ESMTP id F073B47086F; Mon, 11 May 2020 15:59:21 +0200 (CEST)
X-Virus-Scanned: amavisd-new at amavis.loopia.se
Received: from s645.loopia.se ([172.22.191.6]) by s474.loopia.se (s474.loopia.se [172.22.190.14]) (amavisd-new, port 10024) with LMTP id EpLmE06vdX1j; Mon, 11 May 2020 15:59:21 +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.1.217] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s645.loopia.se (Postfix) with ESMTPSA id B857D156E49C; Mon, 11 May 2020 15:59:20 +0200 (CEST)
User-Agent: Microsoft-MacOutlook/16.36.20041300
Date: Mon, 11 May 2020 15:59:19 +0200
From: Stefan Santesson <stefan@aaa-sec.com>
To: RFC Errata System <rfc-editor@rfc-editor.org>, sts@aaa-sec.com, mmyers@fastq.com, none@rfc-editor.org, ambarish@gmail.com, slava.galperin@gmail.com, cadams@eecs.uottawa.ca, rdd@cert.org, kaduk@mit.edu, kent@bbn.com
CC: yury@strozhevsky.com, pkix@ietf.org
Message-ID: <2013D511-BCF9-4D2C-9331-AA8203235F5F@aaa-sec.com>
Thread-Topic: [Technical Errata Reported] RFC6960 (6165)
References: <20200511121547.17072F4071E@rfc-editor.org>
In-Reply-To: <20200511121547.17072F4071E@rfc-editor.org>
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/8YRtRO4b6gXphcRihg90420y4jA>
X-Mailman-Approved-At: Thu, 14 May 2020 10:10:44 -0700
Subject: Re: [pkix] [Technical Errata Reported] RFC6960 (6165)
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: Mon, 11 May 2020 13:59:37 -0000

I respond to all of these erratas collectivey (which I believe should be consolidated to 1 and not 3 erratas)

I think the observation is correct, but I think it is editorial rather than technical.

The normative text is that the KeyHash is the hash of the public key. This is in itself clear an unambiguous.
The imperfection here is not in the normative text, but in the explanation where the explanation in B.1 is the most accurate and detaild.
The other shorter explanations are not wrong, but insufficient compared with B.1

Please also note that a similar definition exist for the "issuerKeyHash" like:

issuerKeyHash      OCTET STRING, -- Hash of issuer's public key


I think this is editorial



Stefan Santesson 

On 2020-05-11, 14:16, "RFC Errata System" <rfc-editor@rfc-editor.org> wrote:

    The following errata report has been submitted for RFC6960,
    "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP".

    --------------------------------------
    You may review the report below and at:
    https://www.rfc-editor.org/errata/eid6165

    --------------------------------------
    Type: Technical
    Reported by: Yury Strozhevsky <yury@strozhevsky.com>

    Section: 1

    Original Text
    -------------
    ---

    Corrected Text
    --------------
       o  Appendix B.1 provides correct KeyHash type processing description. Now SHA-1 hash must be calculated for responder's public key ASN.1 value without tag, length and unused bits.


    Notes
    -----
    The RFC6960 changes OCSP protocol in part of KeyHash type calculation. In RFC2560 there is the description:
       KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
       (excluding the tag and length fields)

    But in Appendix B.1, which is the major OCSP descriptive module, stated:
    KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
                             -- (i.e., the SHA-1 hash of the value of the
                             -- BIT STRING subjectPublicKey [excluding
                             -- the tag, length, and number of unused
                             -- bits] in the responder's certificate)

    The difference is in what would be under SHA-1 hash. In RFC2560 KeyHash would be calculated for entire BIT STRING value, with "unused bits" byte (first byte in BIT STRING value), but Appendix B.1 in RFC6960 states that SHA-1 hash must be calculated for BIT STRING value without "unused bits".

    Instructions:
    -------------
    This erratum is currently posted as "Reported". If necessary, please
    use "Reply All" to discuss whether it should be verified or
    rejected. When a decision is reached, the verifying party  
    can log in to change the status and edit the report, if necessary. 

    --------------------------------------
    RFC6960 (draft-ietf-pkix-rfc2560bis-20)
    --------------------------------------
    Title               : X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP
    Publication Date    : June 2013
    Author(s)           : S. Santesson, M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams
    Category            : PROPOSED STANDARD
    Source              : Public-Key Infrastructure (X.509)
    Area                : Security
    Stream              : IETF
    Verifying Party     : IESG