From nobody Fri May 1 11:45:55 2020 Return-Path: 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 6218C3A19E2 for ; Fri, 1 May 2020 11:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 zTc10iAuDs_j for ; Fri, 1 May 2020 11:44:29 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18E463A19B7 for ; Fri, 1 May 2020 11:44:29 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 931B8300B60 for ; Fri, 1 May 2020 14:44:26 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mwJO9ebv1nRQ for ; Fri, 1 May 2020 14:44:23 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id AECAA300A02; Fri, 1 May 2020 14:44:23 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3AFEA8C0-C3EF-4529-A683-5207066A3363" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Fri, 1 May 2020 14:44:25 -0400 In-Reply-To: Cc: IETF PKIX To: Tom Hans References: <632020ED-4708-4AD7-9F4A-069E294CA5B7@vigilsec.com> <8aaa80ca-9da0-784e-a1fa-9f7ce039abb1@nthpermutation.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: Subject: Re: [pkix] technical question about RFC 6960 X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2020 18:44:45 -0000 --Apple-Mail=_3AFEA8C0-C3EF-4529-A683-5207066A3363 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii So, it sounds like Mike St.Johns gave the right advice. The trust = anchor needs to be in the trust store for it validate. Russ > On Apr 30, 2020, at 6:36 PM, Tom Hans wrote: >=20 > @russ >=20 > Excuse me I forgot to mention that the URLs are used for both CAs, = root A and B. >=20 > Both roots do belong to the same company. >=20 >=20 > Am Donnerstag, 30. April 2020 schrieb Russ Housley = >: > Tom: >=20 > Since these details do not align with the names used in your earlier = message, it is not as helpful as I expected. >=20 > Russ >=20 >=20 >> On Apr 30, 2020, at 2:58 AM, Tom Hans > wrote: >>=20 >> @Russ >> The AIA extension of EndCert A contains: >> [1]Authority Info Access >> Access Method=3DCertification Authority Issuer = (1.3..6.1.5.5.7.48.2) >> Alternative Name: >> URL=3Dhttps://pki.spi-cloud.com/issuer = >> [2]Authority Info Access >> Access Method=3DOn-line Certificate Status Protocol = (1.3.6.1.5.5.7.48.1) >> Alternative Name: >> URL=3Dhttp://ocsp.spi-cloud.com/status/ = >> RI:http://ocsp.spi-cloud.com/status/ = >>=20 >>=20 >> @Peter thank you for your explanation. This helps a lot :) >> So the only "out of band" knowledge I would have is that I saw the = signer through Wireshark nothing else. >> Consequently this is a bad behavior of the CA itself. >>=20 >> Am Mi., 29. Apr. 2020 um 16:56 Uhr schrieb Peter Bowen = >: >> On Tue, Apr 28, 2020 at 11:17 PM Tom Hans > wrote: >> > >> > Hello, >> > >> > thank you for your answers. >> > >> > I know that the OCSP response cannot be validated because I do not = have the Root CA B installed. >> > If I do this the response is validatable. >> > >> > What I like to know is if this is RFC conform? >> > In RFC 6960 section 4.2.2.2. there are mentioned the following = three possibilities: >> > >> > 1. Matches a local configuration of OCSP signing authority for = the >> > certificate in question, or >> > >> > 2. Is the certificate of the CA that issued the certificate in >> > question, or >> > >> > 3. Includes a value of id-kp-OCSPSigning in an extended key = usage >> > extension and is issued by the CA that issued the certificate = in >> > question as stated above. >> > >> > >> > Point 2 and 3 are not used because the certificate in request is = issued by Root CA A and point one is not really clear for me. >>=20 >> There are two different architectures here. Points two and three >> cover "first party" status checking - asking the issuer of the >> certificate or someone authorized by the issuer to tell you the >> status. Point on covers "third party" status checking - asking an >> unrelated party about the certificate. >>=20 >> Comparing this to the process of driver's licenses in the US, you can >> ask the state government department or agency that issues licenses >> about the status of a license. That is point 2. You could also ask = a >> police department about the license and also ask the police for a >> certificate that they are authorized to provide license status. That >> is point 3. However a license is also frequently used as >> identification. A private club could have a membership list. You >> could ask the club secretary whether license matches someone on the >> membership list. It doesn't necessarily tell you that the person is >> authorized to drive a car, but they can tell you if the person is >> authorized to enter the clubhouse. That is point 1. >>=20 >> You hit a OCSP responder that is covered under point 1. Unless you >> have out of band knowledge that the answers it is providing are >> relevant to your use case, then having B tell you about status of >> things A issues probably is not what you want. >>=20 >> Thanks, >> Peter >> _______________________________________________ >> pkix mailing list >> pkix@ietf.org >> https://www.ietf.org/mailman/listinfo/pkix = >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail=_3AFEA8C0-C3EF-4529-A683-5207066A3363 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii So, = it sounds like Mike St.Johns gave the right advice.  The trust = anchor needs to be in the trust store for it validate.

Russ


On Apr 30, 2020, at 6:36 PM, Tom Hans <tomhans18@gmail.com>= wrote:

@russ

Excuse me I forgot to mention that the URLs are used for both = CAs, root A and B.

Both roots do belong to the same company.


Am Donnerstag, 30. April 2020 = schrieb Russ Housley <housley@vigilsec.com>:
Tom:

Since = these details do not align with the names used in your earlier message, = it is not as helpful as I expected.

Russ


On Apr 30, 2020, at 2:58 AM, Tom Hans <tomhans18@gmail.com> wrote:

@Russ
The AIA extension of EndCert A = contains:
[1]Authority Info Access
     Access = Method=3DCertification Authority Issuer = (1.3..6.1.5.5.7.48.2)
     Alternative Name:
      =     URL=3Dhttps://pki.spi-cloud.com/issuer
[2]Authority Info Access
     Access = Method=3DOn-line Certificate Status Protocol = (1.3.6.1.5.5.7.48.1)
     Alternative Name:
      =     URL=3Dhttp://ocsp.spi-cloud.com/status/


@Peter thank you for your explanation. = This helps a lot :)
So the only "out = of band" knowledge I would have is that I saw the signer through = Wireshark nothing else.
Consequently this is a bad = behavior of the CA itself.

Am Mi., 29. Apr. 2020 um 16:56 Uhr schrieb = Peter Bowen <pzbowen@gmail.com>:
On Tue, Apr 28, 2020 at 11:17 = PM Tom Hans <tomhans18@gmail.com> wrote:
>
> Hello,
>
> thank you for your answers.
>
> I know that the OCSP response cannot be validated because I do not = have the Root CA B installed.
> If I do this the response is validatable.
>
> What I like to know is if this is RFC conform?
> In RFC 6960 section 4.2.2.2. there are mentioned the following = three possibilities:
>
>    1. Matches a local configuration of OCSP signing = authority for the
>       certificate in question, or
>
>    2. Is the certificate of the CA that issued the = certificate in
>       question, or
>
>    3. Includes a value of id-kp-OCSPSigning in an = extended key usage
>       extension and is issued by the CA that = issued the certificate in
>       question as stated above.
>
>
> Point 2 and 3 are not used because the certificate in request is = issued by Root CA A and point one is not really clear for me.

There are two different architectures here.  Points two and = three
cover "first party" status checking - asking the issuer of the
certificate or someone authorized by the issuer to tell you the
status.  Point on covers "third party" status checking - asking = an
unrelated party about the certificate.

Comparing this to the process of driver's licenses in the US, you can
ask the state government department or agency that issues licenses
about the status of a license.  That is point 2.  You could = also ask a
police department about the license and also ask the police for a
certificate that they are authorized to provide license status.  = That
is point 3.  However a license is also frequently used as
identification.  A private club could have a membership list.  = You
could ask the club secretary whether license matches someone on the
membership list.  It doesn't necessarily tell you that the person = is
authorized to drive a car, but they can tell you if the person is
authorized to enter the clubhouse.  That is point 1.

You hit a OCSP responder that is covered under point 1.  Unless = you
have out of band knowledge that the answers it is providing are
relevant to your use case, then having B tell you about status of
things A issues probably is not what you want.

Thanks,
Peter
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

_______________________________________________
pkix = mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

= --Apple-Mail=_3AFEA8C0-C3EF-4529-A683-5207066A3363-- From nobody Thu May 14 10:09:33 2020 Return-Path: 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 0A93C3A087B for ; Mon, 11 May 2020 05:16:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 4J0QJR7U8lSg for ; Mon, 11 May 2020 05:16:00 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F77B3A0A3B for ; Mon, 11 May 2020 05:16:00 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 17072F4071E; Mon, 11 May 2020 05:15:47 -0700 (PDT) To: 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, stefan@aaa-sec.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: yury@strozhevsky.com, pkix@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200511121547.17072F4071E@rfc-editor.org> Date: Mon, 11 May 2020 05:15:47 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 14 May 2020 10:09:32 -0700 Subject: [pkix] [Technical Errata Reported] RFC6960 (6165) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 12:16:03 -0000 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 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 From nobody Thu May 14 10:10:06 2020 Return-Path: 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 CA6943A0A47 for ; Mon, 11 May 2020 05:20:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 e4-fTwUJpYNm for ; Mon, 11 May 2020 05:20:45 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E5583A0A43 for ; Mon, 11 May 2020 05:20:45 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 1A7F4F4073C; Mon, 11 May 2020 05:20:32 -0700 (PDT) To: 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, stefan@aaa-sec.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: yury@strozhevsky.com, pkix@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200511122032.1A7F4F4073C@rfc-editor.org> Date: Mon, 11 May 2020 05:20:32 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 14 May 2020 10:10:04 -0700 Subject: [pkix] [Technical Errata Reported] RFC6960 (6167) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 12:20:50 -0000 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/eid6167 -------------------------------------- Type: Technical Reported by: Yury Strozhevsky Section: 4.2.1 Original Text ------------- KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key (excluding the tag and length fields) Corrected Text -------------- 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) Notes ----- Same explanationa as for https://www.rfc-editor.org/errata/eid6166 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 From nobody Thu May 14 10:10:30 2020 Return-Path: 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 51F753A0A43 for ; Mon, 11 May 2020 05:19:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-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 fgqBFzoftr73 for ; Mon, 11 May 2020 05:19:40 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5103F3A0A3B for ; Mon, 11 May 2020 05:19:40 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 13BBEF40739; Mon, 11 May 2020 05:19:27 -0700 (PDT) To: 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, stefan@aaa-sec.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: yury@strozhevsky.com, pkix@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20200511121927.13BBEF40739@rfc-editor.org> Date: Mon, 11 May 2020 05:19:27 -0700 (PDT) Archived-At: X-Mailman-Approved-At: Thu, 14 May 2020 10:10:27 -0700 Subject: [pkix] [Technical Errata Reported] RFC6960 (6166) X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 12:19:42 -0000 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/eid6166 -------------------------------------- Type: Technical Reported by: Yury Strozhevsky Section: Appendix B.2 Original Text ------------- KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key -- (excluding the tag and length fields) Corrected Text -------------- 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) Notes ----- These two descriptions of KeyHash produce different SHA-1 hashes due to different values: one is pure BIT STRING value block, with "unused bits" byte, but other - without "unused byte". Also the Appendix B.2 must be aligned with Appendix B.1 information. 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 From nobody Thu May 14 10:10:45 2020 Return-Path: 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 ; 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 ; 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 ; 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 ; 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 To: RFC Errata System , , , , , , , , , CC: , 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 co= nsolidated 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 wit= h B.1 Please also note that a similar definition exist for the "issuerKeyHash" li= ke: issuerKeyHash OCTET STRING, -- Hash of issuer's public key I think this is editorial Stefan Santesson=20 =EF=BB=BFOn 2020-05-11, 14:16, "RFC Errata System" wr= ote: The following errata report has been submitted for RFC6960, "X.509 Internet Public Key Infrastructure Online Certificate Status Pro= tocol - OCSP". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6165 -------------------------------------- Type: Technical Reported by: Yury Strozhevsky 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 w= ithout tag, length and unused bits. Notes ----- The RFC6960 changes OCSP protocol in part of KeyHash type calculation. = In RFC2560 there is the description: KeyHash ::=3D 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 ::=3D 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 (f= irst 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 =20 can log in to change the status and edit the report, if necessary.=20 -------------------------------------- RFC6960 (draft-ietf-pkix-rfc2560bis-20) -------------------------------------- Title : X.509 Internet Public Key Infrastructure Online C= ertificate 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 From yury@strozhevsky.com Mon May 11 08:13:02 2020 Return-Path: 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 5A06E3A005D for ; Mon, 11 May 2020 08:13:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 RCf-ghW_1aoI for ; Mon, 11 May 2020 08:12:56 -0700 (PDT) Received: from spl3.hosting.reg.ru (spl3.hosting.reg.ru [31.31.196.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C1F3A0044 for ; Mon, 11 May 2020 08:12:55 -0700 (PDT) Received: from webmail.hosting.reg.ru (webmail.hosting.reg.ru [37.140.192.176]) (Authenticated sender: yury@strozhevsky.com) by spl3.hosting.reg.ru (Postfix) with ESMTPA id 49EB017E0702; Mon, 11 May 2020 18:12:51 +0300 (MSK) MIME-Version: 1.0 Date: Mon, 11 May 2020 18:12:51 +0300 From: yury@strozhevsky.com To: Stefan Santesson Cc: RFC Errata System , 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, pkix@ietf.org In-Reply-To: <2013D511-BCF9-4D2C-9331-AA8203235F5F@aaa-sec.com> References: <20200511121547.17072F4071E@rfc-editor.org> <2013D511-BCF9-4D2C-9331-AA8203235F5F@aaa-sec.com> User-Agent: Roundcube Webmail/1.4.3 Message-ID: X-Sender: yury@strozhevsky.com Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-PPP-Message-ID: <20200511151251.12347.55891@spl3.hosting.reg.ru> X-PPP-Vhost: strozhevsky.com Archived-At: X-Mailman-Approved-At: Thu, 14 May 2020 10:10:57 -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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 May 2020 15:14:33 -0000 Hello All, Let me explain some details. Firstly I need to say that I already wrote a couple of mails to RFC6960 authors and discussed it a little. From these discussions I got that before we would start our discussion I need to provide you some technical details. the main problem is that in RFC6960 there are two different description for the same type KeyHash. First description is in 4.2.1 "ASN.1 Specification of the OCSP Response" of RFC6960: KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key (excluding the tag and length fields) And second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of RFC6960: 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) Then I need to clarify why these two descriptions are not the same. Firstly I need to describe ASN.1 type BIT STRING. As all other ASN.1 types BIT STRING consists of three main parts: "Tag", "Length" and "Value" (TLV). But a specific for BIT STRING is that "Value" itself devided on two parts: first byte designates "unused bits" (this value could be 0-7) and the rest is bits describing bits. So, when we are saying "SHA-1 hash of responder's key (excluding the tag and length fields)" we do assume that SHA-1 hash should be for BIT STRING ASN.1 value excluding the "Tag" and "Length" fields (responder's key has type BIT STRING). Thus the SHA-1 hash should be for entire "Value" block of BIT STRING, with "unused bits" byte (the very first byte in BIT STRING "Value" block). In opposite when we are saying " 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" we do assume that SHA-1 hash should be for BIT STRING ASN.1 value excluding Tag, Length and the very first byte from "Value" (unused bits). Do you understand that two SHA-1 hashes made using these two descriptions of KeyHash would be different? Or I would need to provide you a real example with responder's public key values? Feel free to ask me for the example. As a conclusion: the RFC6960 has two descriptions of the same type and a hash produced using these two descriptions would have different values. This is a mistake. I do not really care how you would fix it and what description for KeyHash is correct. But I want to have a correct standard for OCSP. As an addition I found that Appendix B.1 and Appendix B.2 have different description for KeyHash. It is the same ASN.1 description, but different in comment describing the SHA-1 calculation process. The Appendix B.2, in fact, describes KeyHash calculation similar with RFC2560. But Appendix B.1 describes new way of KeyHash calculation. Even if these two appendicies are not aligned allows me to consider the errata change as "technical". Moreover, RFC6960 changes OCSP protocol in part of KeyHash calculation, but it is never stated in any part of RFC6960. So, even if someone says "calculation is obvious" but the problem that for KeyHash there is "specifying comment". And exactly that "specifying comment" clearly specify how to calculate KeyHash. But in RFC6960 there are two different "ways of calculating KeyHash" (two different "specifying comments"). This is also not an "editorial problem", this is clearly a problem in technical description. Best regards, Yury Strozhevsky Stefan Santesson писал 2020-05-11 16:59: > 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" > 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 > > 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 From nobody Fri May 15 18:52:55 2020 Return-Path: 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 C7D733A0848 for ; Fri, 15 May 2020 18:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 ebDjenCq2-LS for ; Fri, 15 May 2020 18:52:51 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2DC03A0843 for ; Fri, 15 May 2020 18:52:50 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id h17so5488892wrc.8 for ; Fri, 15 May 2020 18:52:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=UDWXmf/o/gKB6bLuNYLwYeySIMHfx0l5IbGYFgRQwL8=; b=p9GQiuRWIim9a7diCFIexvXOQe662lPMLAPNLAbyAjotG24+SI5e79GfTzjfwE0GbK huC3Z+Nw5ki7sfW5khSEOwChWHrRqCegpinBVN4z+8iN6zFdfzU+Pv42HMbUA9Tth5PW sKTnR30Lv/HCFiKjfCBOOfcQSKqyK99DfWGHL3RNzLPU9kNeDZECJZBUhAM41lelEJ8T 7Sa38lsW9jvAH4aYCNr5WrpcyJAe+6N6YSZnrPMP+DgnB3o+i2hv2iw5eifEpUceCV6p d4DKhihzrOAeS1iu4xbV7l9nbXYvZ2/UC2j2PHA/tPzcgsY2U6yHGRLvU6waoryRj77K 0JOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=UDWXmf/o/gKB6bLuNYLwYeySIMHfx0l5IbGYFgRQwL8=; b=Dj/IkWi+tCFl597eBngXuaH1uyZARVDd8rgzXmkLcbmK4rgMldnZipnIxS2S95iJKA zL+/tWMR/myGOYU/xJxxUwPKGtH+Hct13GmY2WOT2/CireFXxpc+eSIGi/pbqU3c1XHW ka9Fofm+N0nFvINJVkZVDJmyyY5l0pxO6HNWoxuRoBO+isc5UDfUU6Ziklc4N9cN/Z1I 2CGhi3Kny2RbKPtxhY9bk2QEgCLwQX5K32TKfrInt9/f4ncHNBFOYQobTfz05S0oQW20 x0Wl2GWX/znTZOc7cfeB/6bXnOGWqgYgPfX9uMlSDxzQIsFe8E+7Ar9dQwMzWQohzBZ/ 4k+A== X-Gm-Message-State: AOAM533WCKwwcTn9LpKvD1LikICWUM8mvlaXhE54Yfgz6XHVyMn3t41B hDez5vhPmH/gZdhHHpYVIki+hrMExaGEZsxfimc= X-Google-Smtp-Source: ABdhPJwkuX01xi8KunBOzsENW3EvRwlQBA57CUz5VMSoovUdLOkCrRL/BgQzSKDK8BWddrFt3g6WdHWnYPTpN6sGr3g= X-Received: by 2002:adf:fa4d:: with SMTP id y13mr7453557wrr.263.1589593968886; Fri, 15 May 2020 18:52:48 -0700 (PDT) MIME-Version: 1.0 References: <20200511121547.17072F4071E@rfc-editor.org> <2013D511-BCF9-4D2C-9331-AA8203235F5F@aaa-sec.com> In-Reply-To: From: Erwann Abalea Date: Sat, 16 May 2020 03:52:38 +0200 Message-ID: To: yury@strozhevsky.com Cc: RFC Errata System , Stefan Santesson , ambarish@gmail.com, cadams@eecs.uottawa.ca, kaduk@mit.edu, kent@bbn.com, mmyers@fastq.com, none@rfc-editor.org, pkix@ietf.org, rdd@cert.org, slava.galperin@gmail.com, sts@aaa-sec.com Content-Type: multipart/alternative; boundary="000000000000da48aa05a5ba2fac" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 01:52:54 -0000 --000000000000da48aa05a5ba2fac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I also think the errata is editorial. In a BIT STRING encoding, the first octet (unused bits) is not part of the ASN.1 object, it's only part of its encoding. The following hex strings are all valid BER encodings for a BIT STRING composed of 53 bits set to zero: 03 08 03 00000000000000 03 08 03 00000000000007 23 0D 03 02 00 00 03 07 03 000000000000 23 0D 03 02 00 00 03 07 03 000000000007 23 80 03 05 00 00000000 03 04 03 000000 0000 23 80 03 05 00 00000000 03 04 03 000007 0000 What is hashed is not the different encodings, but the BIT STRING value. In the preceding examples, only the first one is a valid DER encoding. And if you hash the 7 octets after the "unused bits" octet, you'll obtain a wrong hash, because the value is 53 bits long, not 56. Le jeu. 14 mai 2020 =C3=A0 19:11, a =C3=A9crit : > Hello All, > > Let me explain some details. Firstly I need to say that I already wrote > a couple of mails to RFC6960 authors and discussed it a little. From > these discussions I got that before we would start our discussion I need > to provide you some technical details. > > the main problem is that in RFC6960 there are two different description > for the same type KeyHash. First description is in 4.2.1 "ASN.1 > Specification of the OCSP Response" of RFC6960: > > KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key > (excluding the tag and length fields) > > And second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of > RFC6960: > > KeyHash ::=3D 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) > > Then I need to clarify why these two descriptions are not the same. > Firstly I need to describe ASN.1 type BIT STRING. As all other ASN.1 > types BIT STRING consists of three main parts: "Tag", "Length" and > "Value" (TLV). But a specific for BIT STRING is that "Value" itself > devided on two parts: first byte designates "unused bits" (this value > could be 0-7) and the rest is bits describing bits. > So, when we are saying "SHA-1 hash of responder's key (excluding the tag > and length fields)" we do assume that SHA-1 hash should be for BIT > STRING ASN.1 value excluding the "Tag" and "Length" fields (responder's > key has type BIT STRING). Thus the SHA-1 hash should be for entire > "Value" block of BIT STRING, with "unused bits" byte (the very first > byte in BIT STRING "Value" block). > > In opposite when we are saying " 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" we do assume that SHA-1 hash > should be for BIT STRING ASN.1 value excluding Tag, Length and the very > first byte from "Value" (unused bits). > > Do you understand that two SHA-1 hashes made using these two > descriptions of KeyHash would be different? Or I would need to provide > you a real example with responder's public key values? Feel free to ask > me for the example. > > As a conclusion: the RFC6960 has two descriptions of the same type and a > hash produced using these two descriptions would have different values. > This is a mistake. I do not really care how you would fix it and what > description for KeyHash is correct. But I want to have a correct > standard for OCSP. > > As an addition I found that Appendix B.1 and Appendix B.2 have different > description for KeyHash. It is the same ASN.1 description, but different > in comment describing the SHA-1 calculation process. The Appendix B.2, > in fact, describes KeyHash calculation similar with RFC2560. But > Appendix B.1 describes new way of KeyHash calculation. Even if these two > appendicies are not aligned allows me to consider the errata change as > "technical". > > Moreover, RFC6960 changes OCSP protocol in part of KeyHash calculation, > but it is never stated in any part of RFC6960. So, even if someone says > "calculation is obvious" but the problem that for KeyHash there is > "specifying comment". And exactly that "specifying comment" clearly > specify how to calculate KeyHash. But in RFC6960 there are two different > "ways of calculating KeyHash" (two different "specifying comments"). > This is also not an "editorial problem", this is clearly a problem in > technical description. > > Best regards, > Yury Strozhevsky > > > > Stefan Santesson =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-11 16:59: > > 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 > > > > =EF=BB=BFOn 2020-05-11, 14:16, "RFC Errata System" > > 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 > > > > 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 ::=3D OCTET STRING -- SHA-1 hash of responder's public k= ey > > (excluding the tag and length fields) > > > > But in Appendix B.1, which is the major OCSP descriptive module, > > stated: > > KeyHash ::=3D 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 > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > --=20 Erwann. --000000000000da48aa05a5ba2fac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I also think the errata is editorial.

In a BIT STRING encoding, the fi= rst octet (unused bits) is not part of the ASN.1 object, it's only part= of its encoding.

The fo= llowing hex strings are all valid BER encodings for a BIT STRING composed o= f 53 bits set to zero:
03 08 03 00000000000000
=
03 08 03 00000000000007
23 0D 03 0= 2 00 00 03 07 03 000000000000
23 0D 03 02 00 00 03 0= 7 03 000000000007
23 80 03 05 00 00000000 03 04 03 0= 00000 0000
23 80 03 05 00 00000000 03 04 03 000007 0= 000

What is hashed is no= t the different encodings, but the BIT STRING value.
In the preceding examples, only the first one is a valid DER encoding. And= if you hash the 7 octets after the "unused bits" octet, you'= ll obtain a wrong hash, because the value is 53 bits long, not 56.

Le= =C2=A0jeu. 14 mai 2020 =C3=A0 19:11, <yury@strozhevsky.com> a =C3=A9crit=C2=A0:
Hello All,

Let me explain some details. Firstly I need to say that I already wrote a couple of mails to RFC6960 authors and discussed it a little. From
these discussions I got that before we would start our discussion I need to provide you some technical details.

the main problem is that in RFC6960 there are two different description for the same type KeyHash. First description is in 4.2.1 "ASN.1
Specification of the OCSP Response" of RFC6960:

=C2=A0 =C2=A0 KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's p= ublic key
=C2=A0 =C2=A0 (excluding the tag and length fields)

And second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of =
RFC6960:

KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -- (i.e., the SHA-1 hash of the value of the
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -- BIT STRING subjectPublicKey [excluding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -- the tag, length, and number of unused
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 -- bits] in the responder's certificate)

Then I need to clarify why these two descriptions are not the same.
Firstly I need to describe ASN.1 type BIT STRING. As all other ASN.1
types BIT STRING consists of three main parts: "Tag", "Lengt= h" and
"Value" (TLV). But a specific for BIT STRING is that "Value&= quot; itself
devided on two parts: first byte designates "unused bits" (this v= alue
could be 0-7) and the rest is bits describing bits.
So, when we are saying "SHA-1 hash of responder's key (excluding t= he tag
and length fields)" we do assume that SHA-1 hash should be for BIT STRING ASN.1 value excluding the "Tag" and "Length" fie= lds (responder's
key has type BIT STRING). Thus the SHA-1 hash should be for entire
"Value" block of BIT STRING, with "unused bits" byte (t= he very first
byte in BIT STRING "Value" block).

In opposite when we are saying " the SHA-1 hash of the value of the BI= T
STRING subjectPublicKey [excluding the tag, length, and number of unused bits] in the responder's certificate" we do assume that SHA-1 hash=
should be for BIT STRING ASN.1 value excluding Tag, Length and the very first byte from "Value" (unused bits).

Do you understand that two SHA-1 hashes made using these two
descriptions of KeyHash would be different? Or I would need to provide
you a real example with responder's public key values? Feel free to ask=
me for the example.

As a conclusion: the RFC6960 has two descriptions of the same type and a hash produced using these two descriptions would have different values. This is a mistake. I do not really care how you would fix it and what
description for KeyHash is correct. But I want to have a correct
standard for OCSP.

As an addition I found that Appendix B.1 and Appendix B.2 have different description for KeyHash. It is the same ASN.1 description, but different in comment describing the SHA-1 calculation process. The Appendix B.2,
in fact, describes KeyHash calculation similar with RFC2560. But
Appendix B.1 describes new way of KeyHash calculation. Even if these two appendicies are not aligned allows me to consider the errata change as
"technical".

Moreover, RFC6960 changes OCSP protocol in part of KeyHash calculation, but it is never stated in any part of RFC6960. So, even if someone says "calculation is obvious" but the problem that for KeyHash there i= s
"specifying comment". And exactly that "specifying comment&q= uot; clearly
specify how to calculate KeyHash. But in RFC6960 there are two different "ways of calculating KeyHash" (two different "specifying com= ments").
This is also not an "editorial problem", this is clearly a proble= m in
technical description.

Best regards,
Yury Strozhevsky



Stefan Santesson =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-11 16:59:
> I respond to all of these erratas collectivey (which I believe should<= br> > 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.<= br> > 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 compare= d
> with B.1
>
> Please also note that a similar definition exist for the
> "issuerKeyHash" like:
>
> issuerKeyHash=C2=A0 =C2=A0 =C2=A0 OCTET STRING, -- Hash of issuer'= s public key
>
>
> I think this is editorial
>
>
>
> Stefan Santesson
>
> =EF=BB=BFOn 2020-05-11, 14:16, "RFC Errata System" <rfc-editor@rfc-ed= itor.org>
> wrote:
>
>=C2=A0 =C2=A0 =C2=A0The following errata report has been submitted for = RFC6960,
>=C2=A0 =C2=A0 =C2=A0"X.509 Internet Public Key Infrastructure Onli= ne Certificate
> Status Protocol - OCSP".
>
>=C2=A0 =C2=A0 =C2=A0--------------------------------------
>=C2=A0 =C2=A0 =C2=A0You may review the report below and at:
>=C2=A0 =C2=A0 =C2=A0https://www.rfc-editor.org/errata/e= id6165
>
>=C2=A0 =C2=A0 =C2=A0--------------------------------------
>=C2=A0 =C2=A0 =C2=A0Type: Technical
>=C2=A0 =C2=A0 =C2=A0Reported by: Yury Strozhevsky <yury@strozhevsky.com>
>
>=C2=A0 =C2=A0 =C2=A0Section: 1
>
>=C2=A0 =C2=A0 =C2=A0Original Text
>=C2=A0 =C2=A0 =C2=A0-------------
>=C2=A0 =C2=A0 =C2=A0---
>
>=C2=A0 =C2=A0 =C2=A0Corrected Text
>=C2=A0 =C2=A0 =C2=A0--------------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2=A0 Appendix B.1 provides correct KeyHa= sh type processing
> description. Now SHA-1 hash must be calculated for responder's pub= lic
> key ASN.1 value without tag, length and unused bits.
>
>
>=C2=A0 =C2=A0 =C2=A0Notes
>=C2=A0 =C2=A0 =C2=A0-----
>=C2=A0 =C2=A0 =C2=A0The RFC6960 changes OCSP protocol in part of KeyHas= h type
> calculation. In RFC2560 there is the description:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 KeyHash ::=3D OCTET STRING -- SHA-1 hash of= responder's public key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (excluding the tag and length fields)
>
>=C2=A0 =C2=A0 =C2=A0But in Appendix B.1, which is the major OCSP descri= ptive module,
> stated:
>=C2=A0 =C2=A0 =C2=A0KeyHash ::=3D OCTET STRING -- SHA-1 hash of respond= er's public key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- (i.e., the SHA-1 hash of the value of=
> the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- BIT STRING subjectPublicKey [excludin= g
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- the tag, length, and number of unused=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- bits] in the responder's certific= ate)
>
>=C2=A0 =C2=A0 =C2=A0The difference is in what would be under SHA-1 hash= . In RFC2560
> KeyHash would be calculated for entire BIT STRING value, with "un= used
> bits" byte (first byte in BIT STRING value), but Appendix B.1 in<= br> > RFC6960 states that SHA-1 hash must be calculated for BIT STRING value=
> without "unused bits".
>
>=C2=A0 =C2=A0 =C2=A0Instructions:
>=C2=A0 =C2=A0 =C2=A0-------------
>=C2=A0 =C2=A0 =C2=A0This erratum is currently posted as "Reported&= quot;. If necessary,
> please
>=C2=A0 =C2=A0 =C2=A0use "Reply All" to discuss whether it sho= uld be verified or
>=C2=A0 =C2=A0 =C2=A0rejected. When a decision is reached, the verifying= party
>=C2=A0 =C2=A0 =C2=A0can log in to change the status and edit the report= , if necessary.
>
>=C2=A0 =C2=A0 =C2=A0--------------------------------------
>=C2=A0 =C2=A0 =C2=A0RFC6960 (draft-ietf-pkix-rfc2560bis-20)
>=C2=A0 =C2=A0 =C2=A0--------------------------------------
>=C2=A0 =C2=A0 =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0: X.509 Internet Public Key Infrastructure
> Online Certificate Status Protocol - OCSP
>=C2=A0 =C2=A0 =C2=A0Publication Date=C2=A0 =C2=A0 : June 2013
>=C2=A0 =C2=A0 =C2=A0Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= S. Santesson, M. Myers, R. Ankney, A.
> Malpani, S. Galperin, C. Adams
>=C2=A0 =C2=A0 =C2=A0Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := PROPOSED STANDARD
>=C2=A0 =C2=A0 =C2=A0Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : Public-Key Infrastructure (X.509)
>=C2=A0 =C2=A0 =C2=A0Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 : Security
>=C2=A0 =C2=A0 =C2=A0Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 : IETF
>=C2=A0 =C2=A0 =C2=A0Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--
Erwann.
--000000000000da48aa05a5ba2fac-- From nobody Sat May 16 05:31:39 2020 Return-Path: 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 DFCD33A0AFF for ; Sat, 16 May 2020 05:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dvSZZOQwpog4 for ; Sat, 16 May 2020 05:31:33 -0700 (PDT) Received: from mail-wm1-x342.google.com (mail-wm1-x342.google.com [IPv6:2a00:1450:4864:20::342]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41F9B3A0AFD for ; Sat, 16 May 2020 05:31:33 -0700 (PDT) Received: by mail-wm1-x342.google.com with SMTP id h4so4785640wmb.4 for ; Sat, 16 May 2020 05:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LJmwh5hWEYTASwXfKyff3BInFaSnq1FIreHUEE7i//I=; b=dDak0qzZ2mDg4GSIT26jKQ6TiAQaTazgPTzjDlpATgC3eSyPs3GdIFD14vXhH4rJkz a6/pxmLLb7aU1ObBvYssBbbjnsDP8X+5mCPz3m89w5fp0MwpapDZoS3UYY2Kbvpi7zYU 2wrWfeAhg75EXQodSH2IgEX3/SyjKUEIKf2wsq4QxbNL3bKKzfAnBcwxYzdQaHgDXMYj 6kalLr+zXRU566ZWWnkVUtv7Pw67zJThB/qXIP0N//aHGADxvrcyVuDbm/2NAAAId1gE ZGEyoWzeLlvlIE8yiQzHw/uA3vKMJx8QjsSui7ECbo/4KCNNpiA+wHEq4/FbBtwcQAWQ DJ2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LJmwh5hWEYTASwXfKyff3BInFaSnq1FIreHUEE7i//I=; b=BufQ6uvnGgDtsAbS2mDQDdVwHEjvhnB0DDanDCoqYKSnFoJhEwF/mYs/YzJUW2zmGE D/c1ZpKMESv85bZxd+aQyE+eswovFrz22c3mSALFu/kVrk4ADcJarzpO7mHYU2yZJwC1 /7XBNJOgHLlIaXs48qiXN+WPqxoVjpMoi2AP7qWMisAulPv6pW49XGY0IhUeNTehr3Gy hYz6QqU2615I0F3vEXyqLT3xclUSwEkRTcXcRAfk0/BoDPzNeC8Jozbnw35+T+Xa/ZD5 tZgW4fpMPlR6u0DWfPc9VZL5Xe2Auwvyg/roXvFZ4JjB5GtVa62YRa7s2ApK+/5Q0lw/ 8/VA== X-Gm-Message-State: AOAM533GEv3EDlx6jeiFoQyg9cdjcI1eVao1Wbc8mSZp6f3dKW5l0FoK RCnH9h5Z5TNsf7q9Bqj1erP26wLiYFb8dHjgUCM= X-Google-Smtp-Source: ABdhPJz8RBZjN3khYU6nW6PAmaMUTkc/QWwgFbZHjG9YDIUXZUybJrSfkyz6ntbBpCZrpID+rq2o6Y4Xu+Qj/XtIQRI= X-Received: by 2002:a1c:2888:: with SMTP id o130mr8870383wmo.138.1589632291468; Sat, 16 May 2020 05:31:31 -0700 (PDT) MIME-Version: 1.0 References: <20200511121547.17072F4071E@rfc-editor.org> <2013D511-BCF9-4D2C-9331-AA8203235F5F@aaa-sec.com> <56396ec5c59f0f9b372e79612bf0b13b@strozhevsky.com> In-Reply-To: <56396ec5c59f0f9b372e79612bf0b13b@strozhevsky.com> From: Erwann Abalea Date: Sat, 16 May 2020 14:31:20 +0200 Message-ID: To: yury@strozhevsky.com Cc: RFC Errata System , Stefan Santesson , ambarish@gmail.com, cadams@eecs.uottawa.ca, kaduk@mit.edu, Stephen Kent , mmyers@fastq.com, none@rfc-editor.org, "" , rdd@cert.org, slava.galperin@gmail.com, sts@aaa-sec.com Content-Type: multipart/alternative; boundary="0000000000000e788e05a5c31cff" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 12:31:36 -0000 --0000000000000e788e05a5c31cff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Bonjour Yuri, ASN.1 and encoding rules are different but related standards. Therefore, yes, the encoding is not part of the ASN.1 object. If your bit string is of length 0 (i.e. is empty), then its DER encoding will still have this "unused bits" part (and the encoding is then "03 01 00"). Yet, your object is empty, so this octet is not part of it, it's only here to help correctly represent it on the wire because the chosen encoding rules express lengths in octets. See it as an extension to the L field in the TLV triplet. Please refer to X.690 clause 8.6.2 to see the difference between the content octets composing the primitive encoding and the bit string value. If we had used the PER encoding, this "unused bits" element wouldn't exist (because PER encodes the length in bits for this object type). The example given in my first email, encoded in PER, gives "35 00000000000000", and its encoding could lose 3 bits depending on the variant (UNALIGNED vs ALIGNED) and the object encoded right after it. If XER encoding had be chosen, there wouldn't be any L field, and the bits themselves would be encoded as individual characters (0 or 1). Le sam. 16 mai 2020 =C3=A0 07:22, a =C3=A9crit : > Hello Erwann! > > Could you, please, explain "the first octet (unused bits) is not part of > the ASN.1 object, it's only part of its encoding"? Encoding is not a part > of ASN.1 object? > > You are saying "is not part of the ASN.1 object" but right before it said > "the first octet". First octet is not a part of BIT STRING value? > > > Best regards, > > Yury Strozhevsky > > > Erwann Abalea =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-16 04:52: > > I also think the errata is editorial. > > In a BIT STRING encoding, the first octet (unused bits) is not part of th= e > ASN.1 object, it's only part of its encoding. > > The following hex strings are all valid BER encodings for a BIT STRING > composed of 53 bits set to zero: > 03 08 03 00000000000000 > 03 08 03 00000000000007 > 23 0D 03 02 00 00 03 07 03 000000000000 > 23 0D 03 02 00 00 03 07 03 000000000007 > 23 80 03 05 00 00000000 03 04 03 000000 0000 > 23 80 03 05 00 00000000 03 04 03 000007 0000 > > What is hashed is not the different encodings, but the BIT STRING value. > In the preceding examples, only the first one is a valid DER encoding. An= d > if you hash the 7 octets after the "unused bits" octet, you'll obtain a > wrong hash, because the value is 53 bits long, not 56. > > Le jeu. 14 mai 2020 =C3=A0 19:11, a =C3=A9crit : > > Hello All, > > Let me explain some details. Firstly I need to say that I already wrote > a couple of mails to RFC6960 authors and discussed it a little. From > these discussions I got that before we would start our discussion I need > to provide you some technical details. > > the main problem is that in RFC6960 there are two different description > for the same type KeyHash. First description is in 4.2.1 "ASN.1 > Specification of the OCSP Response" of RFC6960: > > KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key > (excluding the tag and length fields) > > And second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of > RFC6960: > > KeyHash ::=3D 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) > > Then I need to clarify why these two descriptions are not the same. > Firstly I need to describe ASN.1 type BIT STRING. As all other ASN.1 > types BIT STRING consists of three main parts: "Tag", "Length" and > "Value" (TLV). But a specific for BIT STRING is that "Value" itself > devided on two parts: first byte designates "unused bits" (this value > could be 0-7) and the rest is bits describing bits. > So, when we are saying "SHA-1 hash of responder's key (excluding the tag > and length fields)" we do assume that SHA-1 hash should be for BIT > STRING ASN.1 value excluding the "Tag" and "Length" fields (responder's > key has type BIT STRING). Thus the SHA-1 hash should be for entire > "Value" block of BIT STRING, with "unused bits" byte (the very first > byte in BIT STRING "Value" block). > > In opposite when we are saying " 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" we do assume that SHA-1 hash > should be for BIT STRING ASN.1 value excluding Tag, Length and the very > first byte from "Value" (unused bits). > > Do you understand that two SHA-1 hashes made using these two > descriptions of KeyHash would be different? Or I would need to provide > you a real example with responder's public key values? Feel free to ask > me for the example. > > As a conclusion: the RFC6960 has two descriptions of the same type and a > hash produced using these two descriptions would have different values. > This is a mistake. I do not really care how you would fix it and what > description for KeyHash is correct. But I want to have a correct > standard for OCSP. > > As an addition I found that Appendix B.1 and Appendix B.2 have different > description for KeyHash. It is the same ASN.1 description, but different > in comment describing the SHA-1 calculation process. The Appendix B.2, > in fact, describes KeyHash calculation similar with RFC2560. But > Appendix B.1 describes new way of KeyHash calculation. Even if these two > appendicies are not aligned allows me to consider the errata change as > "technical". > > Moreover, RFC6960 changes OCSP protocol in part of KeyHash calculation, > but it is never stated in any part of RFC6960. So, even if someone says > "calculation is obvious" but the problem that for KeyHash there is > "specifying comment". And exactly that "specifying comment" clearly > specify how to calculate KeyHash. But in RFC6960 there are two different > "ways of calculating KeyHash" (two different "specifying comments"). > This is also not an "editorial problem", this is clearly a problem in > technical description. > > Best regards, > Yury Strozhevsky > > > > Stefan Santesson =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-11 16:59: > > 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" > > 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 > > > > 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 ::=3D OCTET STRING -- SHA-1 hash of responder's public k= ey > > (excluding the tag and length fields) > > > > But in Appendix B.1, which is the major OCSP descriptive module, > > stated: > > KeyHash ::=3D 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 > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > -- > Erwann. > > > --=20 Erwann. --0000000000000e788e05a5c31cff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Bonjour Yuri,

ASN.1 and encoding rules are different but related standards. Ther= efore, yes, the encoding is not part of the ASN.1 object.

If your bit string is of length 0 (i.e. is empty), then its DER enc= oding will still have this "unused bits" part (and the encoding i= s then "03 01 00"). Yet, your object is empty, so this octet is n= ot part of it, it's only here to help correctly represent it on the wir= e because the chosen encoding rules express lengths in octets. See it as an= extension to the L field in the TLV triplet.
Please refer to X.6= 90 clause 8.6.2 to see the difference between the content octets composing = the primitive encoding and the bit string value.

I= f we had used the PER encoding, this=C2=A0"unused bits" element w= ouldn't exist (because PER encodes the length in bits for this object t= ype). The example given in my first email, encoded in PER, gives "35 0= 0000000000000", and its encoding could lose 3 bits depending on the va= riant (UNALIGNED vs ALIGNED) and the object encoded right after it.

If XER encoding had be chosen, there wo= uldn't be any L field, and the bits themselves would be encoded as indi= vidual characters (0 or 1).

Le=C2=A0sam. 16 mai 2020 =C3=A0=C2=A007:22, <= yury@strozhevsky.com> a =C3= =A9crit=C2=A0:

Hello Erwann!

Could you, please, explain "the first octet (unused bits) is not pa= rt of the ASN.1 object, it's only part of its encoding"? Encoding = is not a part of ASN.1 object?

You are saying "is not part of the ASN.1 object" but right bef= ore it said "the first octet". First octet is not a part of BIT S= TRING value?


Best regards,

Yury Strozhevsky


Erwann Abalea =D0=BF=D0= =B8=D1=81=D0=B0=D0=BB 2020-05-16 04:52:

I also think the errata is editorial.
=C2=A0
In a BIT STRING encoding, the first octet (unused bits) i= s not part of the ASN.1 object, it's only part of its encoding.
=C2=A0
The following hex strings are all valid BER encodings for= a BIT STRING composed of 53 bits set to zero:
03 08 03 00000000000000
03 08 03 00000000000007
23 0D 03 02 00 00 03 07 03 000000000000
23 0D 03 02 00 00 03 07 03 000000000007
23 80 03 05 00 00000000 03 04 03 000000 0000
23 80 03 05 00 00000000 03 04 03 000007 0000
=C2=A0
What is hashed is not the different encodings, but the BI= T STRING value.
In the preceding examples, only the first one is a valid = DER encoding. And if you hash the 7 octets after the "unused bits"= ; octet, you'll obtain a wrong hash, because the value is 53 bits long,= not 56.

Le=C2=A0jeu. 14 mai 2020 =C3=A0 19:11, <yury@strozhev= sky.com> a =C3=A9crit=C2=A0:
Hello= All,

Let me explain some details. Firstly I need to say that I alre= ady wrote
a couple of mails to RFC6960 authors and discussed it a littl= e. From
these discussions I got that before we would start our discussi= on I need
to provide you some technical details.

the main proble= m is that in RFC6960 there are two different description
for the same t= ype KeyHash. First description is in 4.2.1 "ASN.1
Specification of= the OCSP Response" of RFC6960:

=C2=A0 =C2=A0 KeyHash ::=3D OCT= ET STRING -- SHA-1 hash of responder's public key
=C2=A0 =C2=A0 (exc= luding the tag and length fields)

And second is from Appendix B.1 &q= uot;OCSP in ASN.1 - 1998 Syntax" of
RFC6960:

KeyHash ::=3D = OCTET STRING -- SHA-1 hash of responder's public key
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 -- (i.e., the SHA-1 hash of the value of the
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- BI= T STRING subjectPublicKey [excluding
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- the tag, length,= and number of unused
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- bits] in the responder's c= ertificate)

Then I need to clarify why these two descriptions are no= t the same.
Firstly I need to describe ASN.1 type BIT STRING. As all ot= her ASN.1
types BIT STRING consists of three main parts: "Tag"= ;, "Length" and
"Value" (TLV). But a specific for B= IT STRING is that "Value" itself
devided on two parts: first = byte designates "unused bits" (this value
could be 0-7) and t= he rest is bits describing bits.
So, when we are saying "SHA-1 hash= of responder's key (excluding the tag
and length fields)" we = do assume that SHA-1 hash should be for BIT
STRING ASN.1 value excludin= g the "Tag" and "Length" fields (responder's
ke= y has type BIT STRING). Thus the SHA-1 hash should be for entire
"= Value" block of BIT STRING, with "unused bits" byte (the ver= y first
byte in BIT STRING "Value" block).

In opposite= when we are saying " the SHA-1 hash of the value of the BIT
STRIN= G subjectPublicKey [excluding the tag, length, and number of unused
bit= s] in the responder's certificate" we do assume that SHA-1 hash should be for BIT STRING ASN.1 value excluding Tag, Length and the very <= br>first byte from "Value" (unused bits).

Do you understan= d that two SHA-1 hashes made using these two
descriptions of KeyHash wo= uld be different? Or I would need to provide
you a real example with re= sponder's public key values? Feel free to ask
me for the example.
As a conclusion: the RFC6960 has two descriptions of the same type an= d a
hash produced using these two descriptions would have different val= ues.
This is a mistake. I do not really care how you would fix it and w= hat
description for KeyHash is correct. But I want to have a correct standard for OCSP.

As an addition I found that Appendix B.1 and Ap= pendix B.2 have different
description for KeyHash. It is the same ASN.1= description, but different
in comment describing the SHA-1 calculation= process. The Appendix B.2,
in fact, describes KeyHash calculation simi= lar with RFC2560. But
Appendix B.1 describes new way of KeyHash calcula= tion. Even if these two
appendicies are not aligned allows me to consid= er the errata change as
"technical".

Moreover, RFC6960= changes OCSP protocol in part of KeyHash calculation,
but it is never = stated in any part of RFC6960. So, even if someone says
"calculati= on is obvious" but the problem that for KeyHash there is
"spe= cifying comment". And exactly that "specifying comment" clea= rly
specify how to calculate KeyHash. But in RFC6960 there are two diff= erent
"ways of calculating KeyHash" (two different "spec= ifying comments").
This is also not an "editorial problem&quo= t;, this is clearly a problem in
technical description.

Best reg= ards,
Yury Strozhevsky



Stefan Santesson =D0=BF=D0=B8=D1= =81=D0=B0=D0=BB 2020-05-11 16:59:
> 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 normati= ve 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 expla= nations are not wrong, but insufficient compared
> with B.1
> =
> Please also note that a similar definition exist for the
> = "issuerKeyHash" like:
>
> issuerKeyHash=C2=A0 =C2=A0= =C2=A0 OCTET STRING, -- Hash of issuer's public key
>
> <= br>> I think this is editorial
>
>
>
> Stefan= Santesson
>
> On 2020-05-11, 14:16, "RFC Errata System&q= uot; <rfc-editor@rfc-editor.org>
> wrote:
> <= br>>=C2=A0 =C2=A0 =C2=A0The following errata report has been submitted f= or RFC6960,
>=C2=A0 =C2=A0 =C2=A0"X.509 Internet Public Key Infr= astructure Online Certificate
> Status Protocol - OCSP".
>=
>=C2=A0 =C2=A0 =C2=A0--------------------------------------
>= =C2=A0 =C2=A0 =C2=A0You may review the report below and at:
>=C2=A0 = =C2=A0 =C2=A0https://www.rfc-editor.org/errata/eid= 6165
>
>=C2=A0 =C2=A0 =C2=A0------------------------------= --------
>=C2=A0 =C2=A0 =C2=A0Type: Technical
>=C2=A0 =C2=A0 = =C2=A0Reported by: Yury Strozhevsky <yury@strozhevsky.com>
&= gt;
>=C2=A0 =C2=A0 =C2=A0Section: 1
>
>=C2=A0 =C2=A0 = =C2=A0Original Text
>=C2=A0 =C2=A0 =C2=A0-------------
>=C2=A0 = =C2=A0 =C2=A0---
>
>=C2=A0 =C2=A0 =C2=A0Corrected Text
>= =C2=A0 =C2=A0 =C2=A0--------------
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 o=C2= =A0 Appendix B.1 provides correct KeyHash type processing
> descripti= on. Now SHA-1 hash must be calculated for responder's public
> ke= y ASN.1 value without tag, length and unused bits.
>
>
>= ;=C2=A0 =C2=A0 =C2=A0Notes
>=C2=A0 =C2=A0 =C2=A0-----
>=C2=A0 = =C2=A0 =C2=A0The RFC6960 changes OCSP protocol in part of KeyHash type
&= gt; calculation. In RFC2560 there is the description:
>=C2=A0 =C2=A0 = =C2=A0 =C2=A0 KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's p= ublic key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 (excluding the tag and length = fields)
>
>=C2=A0 =C2=A0 =C2=A0But in Appendix B.1, which is t= he major OCSP descriptive module,
> stated:
>=C2=A0 =C2=A0 =C2= =A0KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- (i.e., the SHA-1 hash of the value o= f
> the
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- BIT STRING subjectP= ublicKey [excluding
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- the tag, length= , and number of unused
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 -- bits] in the= responder's certificate)
>
>=C2=A0 =C2=A0 =C2=A0The diffe= rence is in what would be under SHA-1 hash. In RFC2560
> KeyHash woul= d be calculated for entire BIT STRING value, with "unused
> bits= " byte (first byte in BIT STRING value), but Appendix B.1 in
> R= FC6960 states that SHA-1 hash must be calculated for BIT STRING value
&g= t; without "unused bits".
>
>=C2=A0 =C2=A0 =C2=A0Ins= tructions:
>=C2=A0 =C2=A0 =C2=A0-------------
>=C2=A0 =C2=A0 = =C2=A0This erratum is currently posted as "Reported". If necessar= y,
> please
>=C2=A0 =C2=A0 =C2=A0use "Reply All" to = discuss whether it should be verified or
>=C2=A0 =C2=A0 =C2=A0rejecte= d. When a decision is reached, the verifying party
>=C2=A0 =C2=A0 =C2= =A0can log in to change the status and edit the report, if necessary.
&g= t;
>=C2=A0 =C2=A0 =C2=A0--------------------------------------
&g= t;=C2=A0 =C2=A0 =C2=A0RFC6960 (draft-ietf-pkix-rfc2560bis-20)
>=C2=A0= =C2=A0 =C2=A0--------------------------------------
>=C2=A0 =C2=A0 = =C2=A0Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: X.509 I= nternet Public Key Infrastructure
> Online Certificate Status Protoco= l - OCSP
>=C2=A0 =C2=A0 =C2=A0Publication Date=C2=A0 =C2=A0 : June 20= 13
>=C2=A0 =C2=A0 =C2=A0Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0: S. Santesson, M. Myers, R. Ankney, A.
> Malpani, S. Galperin,= C. Adams
>=C2=A0 =C2=A0 =C2=A0Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 : PROPOSED STANDARD
>=C2=A0 =C2=A0 =C2=A0Source=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Public-Key Infrastructure (X.50= 9)
>=C2=A0 =C2=A0 =C2=A0Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 : Security
>=C2=A0 =C2=A0 =C2=A0Stream=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
>=C2=A0 =C2=A0 =C2=A0Verify= ing Party=C2=A0 =C2=A0 =C2=A0: IESG

________________________________= _______________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--
Erwann.




--
Erwann.
--0000000000000e788e05a5c31cff-- From nobody Sat May 16 06:26:27 2020 Return-Path: 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 E41B43A0B5C for ; Sat, 16 May 2020 06:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=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 BuKPpsJwsRHF for ; Sat, 16 May 2020 06:26:23 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48FFB3A0B58 for ; Sat, 16 May 2020 06:26:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 9836D300B5A for ; Sat, 16 May 2020 09:26:20 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SeD3Dj9RoGe8 for ; Sat, 16 May 2020 09:26:07 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 11946300A49; Sat, 16 May 2020 09:26:07 -0400 (EDT) From: Russ Housley Message-Id: <6877A0D0-4B46-4A3D-B26D-85E616B94036@vigilsec.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_C4692EBD-AA5E-49EC-BD91-A9A670440418" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Sat, 16 May 2020 09:26:08 -0400 In-Reply-To: Cc: yury@strozhevsky.com, "Roman D. Danyliw" , ambarish@gmail.com, Mike Myers , slava.galperin@gmail.com, cadams@eecs.uottawa.ca, Stefan Santesson , Ben Kaduk , IETF PKIX To: Erwann Abalea References: <20200511121547.17072F4071E@rfc-editor.org> <2013D511-BCF9-4D2C-9331-AA8203235F5F@aaa-sec.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 May 2020 13:26:26 -0000 --Apple-Mail=_C4692EBD-AA5E-49EC-BD91-A9A670440418 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 We are talking about the DER encoding (not the BER encoding) Russ > On May 15, 2020, at 9:52 PM, Erwann Abalea wrote: >=20 > I also think the errata is editorial. >=20 > In a BIT STRING encoding, the first octet (unused bits) is not part of = the ASN.1 object, it's only part of its encoding. >=20 > The following hex strings are all valid BER encodings for a BIT STRING = composed of 53 bits set to zero: > 03 08 03 00000000000000 > 03 08 03 00000000000007 > 23 0D 03 02 00 00 03 07 03 000000000000 > 23 0D 03 02 00 00 03 07 03 000000000007 > 23 80 03 05 00 00000000 03 04 03 000000 0000 > 23 80 03 05 00 00000000 03 04 03 000007 0000 >=20 > What is hashed is not the different encodings, but the BIT STRING = value. > In the preceding examples, only the first one is a valid DER encoding. = And if you hash the 7 octets after the "unused bits" octet, you'll = obtain a wrong hash, because the value is 53 bits long, not 56. >=20 > Le jeu. 14 mai 2020 =C3=A0 19:11, > a =C3=A9crit : > Hello All, >=20 > Let me explain some details. Firstly I need to say that I already = wrote=20 > a couple of mails to RFC6960 authors and discussed it a little. =46rom=20= > these discussions I got that before we would start our discussion I = need=20 > to provide you some technical details. >=20 > the main problem is that in RFC6960 there are two different = description=20 > for the same type KeyHash. First description is in 4.2.1 "ASN.1=20 > Specification of the OCSP Response" of RFC6960: >=20 > KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key > (excluding the tag and length fields) >=20 > And second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of=20 > RFC6960: >=20 > KeyHash ::=3D 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) >=20 > Then I need to clarify why these two descriptions are not the same.=20 > Firstly I need to describe ASN.1 type BIT STRING. As all other ASN.1=20= > types BIT STRING consists of three main parts: "Tag", "Length" and=20 > "Value" (TLV). But a specific for BIT STRING is that "Value" itself=20 > devided on two parts: first byte designates "unused bits" (this value=20= > could be 0-7) and the rest is bits describing bits. > So, when we are saying "SHA-1 hash of responder's key (excluding the = tag=20 > and length fields)" we do assume that SHA-1 hash should be for BIT=20 > STRING ASN.1 value excluding the "Tag" and "Length" fields = (responder's=20 > key has type BIT STRING). Thus the SHA-1 hash should be for entire=20 > "Value" block of BIT STRING, with "unused bits" byte (the very first=20= > byte in BIT STRING "Value" block). >=20 > In opposite when we are saying " the SHA-1 hash of the value of the = BIT=20 > STRING subjectPublicKey [excluding the tag, length, and number of = unused=20 > bits] in the responder's certificate" we do assume that SHA-1 hash=20 > should be for BIT STRING ASN.1 value excluding Tag, Length and the = very=20 > first byte from "Value" (unused bits). >=20 > Do you understand that two SHA-1 hashes made using these two=20 > descriptions of KeyHash would be different? Or I would need to provide=20= > you a real example with responder's public key values? Feel free to = ask=20 > me for the example. >=20 > As a conclusion: the RFC6960 has two descriptions of the same type and = a=20 > hash produced using these two descriptions would have different = values.=20 > This is a mistake. I do not really care how you would fix it and what=20= > description for KeyHash is correct. But I want to have a correct=20 > standard for OCSP. >=20 > As an addition I found that Appendix B.1 and Appendix B.2 have = different=20 > description for KeyHash. It is the same ASN.1 description, but = different=20 > in comment describing the SHA-1 calculation process. The Appendix B.2,=20= > in fact, describes KeyHash calculation similar with RFC2560. But=20 > Appendix B.1 describes new way of KeyHash calculation. Even if these = two=20 > appendicies are not aligned allows me to consider the errata change as=20= > "technical". >=20 > Moreover, RFC6960 changes OCSP protocol in part of KeyHash = calculation,=20 > but it is never stated in any part of RFC6960. So, even if someone = says=20 > "calculation is obvious" but the problem that for KeyHash there is=20 > "specifying comment". And exactly that "specifying comment" clearly=20 > specify how to calculate KeyHash. But in RFC6960 there are two = different=20 > "ways of calculating KeyHash" (two different "specifying comments").=20= > This is also not an "editorial problem", this is clearly a problem in=20= > technical description. >=20 > Best regards, > Yury Strozhevsky >=20 >=20 >=20 > Stefan Santesson =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-11 16:59: > > I respond to all of these erratas collectivey (which I believe = should > > be consolidated to 1 and not 3 erratas) > >=20 > > I think the observation is correct, but I think it is editorial = rather > > than technical. > >=20 > > 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=20 > > with B.1 > >=20 > > Please also note that a similar definition exist for the=20 > > "issuerKeyHash" like: > >=20 > > issuerKeyHash OCTET STRING, -- Hash of issuer's public key > >=20 > >=20 > > I think this is editorial > >=20 > >=20 > >=20 > > Stefan Santesson > >=20 > > =EF=BB=BFOn 2020-05-11, 14:16, "RFC Errata System" = >=20 > > wrote: > >=20 > > The following errata report has been submitted for RFC6960, > > "X.509 Internet Public Key Infrastructure Online Certificate > > Status Protocol - OCSP". > >=20 > > -------------------------------------- > > You may review the report below and at: > > https://www.rfc-editor.org/errata/eid6165 = > >=20 > > -------------------------------------- > > Type: Technical > > Reported by: Yury Strozhevsky > > >=20 > > Section: 1 > >=20 > > Original Text > > ------------- > > --- > >=20 > > 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. > >=20 > >=20 > > Notes > > ----- > > The RFC6960 changes OCSP protocol in part of KeyHash type > > calculation. In RFC2560 there is the description: > > KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's = public key > > (excluding the tag and length fields) > >=20 > > But in Appendix B.1, which is the major OCSP descriptive module,=20= > > stated: > > KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public = key > > -- (i.e., the SHA-1 hash of the value = of=20 > > the > > -- BIT STRING subjectPublicKey = [excluding > > -- the tag, length, and number of = unused > > -- bits] in the responder's = certificate) > >=20 > > 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". > >=20 > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary,=20 > > 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. > >=20 > > -------------------------------------- > > 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 >=20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = > --=20 > Erwann. > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix --Apple-Mail=_C4692EBD-AA5E-49EC-BD91-A9A670440418 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 We = are talking about the DER encoding (not the BER encoding)

Russ

On May 15, 2020, at 9:52 PM, Erwann Abalea <eabalea@gmail.com> = wrote:

I also think the errata is = editorial.

In a BIT STRING encoding, = the first octet (unused bits) is not part of the ASN.1 object, it's only = part of its encoding.

The following hex strings = are all valid BER encodings for a BIT STRING composed of 53 bits set to = zero:
03 08 03 = 00000000000000
03 08 03 = 00000000000007
23 0D 03 02 00 00 03 07 = 03 000000000000
23 0D 03 02 00 00 03 = 07 03 000000000007
23 80 03 05 00 = 00000000 03 04 03 000000 0000
23 80 03 = 05 00 00000000 03 04 03 000007 0000

What is hashed is not the = different encodings, but the BIT STRING value.
In the preceding examples, only the first one is a valid DER = encoding. And if you hash the 7 octets after the "unused bits" octet, = you'll obtain a wrong hash, because the value is 53 bits long, not = 56.

Le jeu. 14 mai 2020 =C3=A0 19:11, = <yury@strozhevsky.com> a =C3=A9crit :
Hello All,

Let me explain some details. Firstly I need to say that I already wrote =
a couple of mails to RFC6960 authors and discussed it a little. =46rom =
these discussions I got that before we would start our discussion I need =
to provide you some technical details.

the main problem is that in RFC6960 there are two different description =
for the same type KeyHash. First description is in 4.2.1 "ASN.1
Specification of the OCSP Response" of RFC6960:

    KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's = public key
    (excluding the tag and length fields)

And second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of
RFC6960:

KeyHash ::=3D 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)

Then I need to clarify why these two descriptions are not the same.
Firstly I need to describe ASN.1 type BIT STRING. As all other ASN.1
types BIT STRING consists of three main parts: "Tag", "Length" and
"Value" (TLV). But a specific for BIT STRING is that "Value" itself
devided on two parts: first byte designates "unused bits" (this value =
could be 0-7) and the rest is bits describing bits.
So, when we are saying "SHA-1 hash of responder's key (excluding the tag =
and length fields)" we do assume that SHA-1 hash should be for BIT
STRING ASN.1 value excluding the "Tag" and "Length" fields (responder's =
key has type BIT STRING). Thus the SHA-1 hash should be for entire
"Value" block of BIT STRING, with "unused bits" byte (the very first
byte in BIT STRING "Value" block).

In opposite when we are saying " 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" we do assume that SHA-1 hash
should be for BIT STRING ASN.1 value excluding Tag, Length and the very =
first byte from "Value" (unused bits).

Do you understand that two SHA-1 hashes made using these two
descriptions of KeyHash would be different? Or I would need to provide =
you a real example with responder's public key values? Feel free to ask =
me for the example.

As a conclusion: the RFC6960 has two descriptions of the same type and a =
hash produced using these two descriptions would have different values. =
This is a mistake. I do not really care how you would fix it and what =
description for KeyHash is correct. But I want to have a correct
standard for OCSP.

As an addition I found that Appendix B.1 and Appendix B.2 have different =
description for KeyHash. It is the same ASN.1 description, but different =
in comment describing the SHA-1 calculation process. The Appendix B.2, =
in fact, describes KeyHash calculation similar with RFC2560. But
Appendix B.1 describes new way of KeyHash calculation. Even if these two =
appendicies are not aligned allows me to consider the errata change as =
"technical".

Moreover, RFC6960 changes OCSP protocol in part of KeyHash calculation, =
but it is never stated in any part of RFC6960. So, even if someone says =
"calculation is obvious" but the problem that for KeyHash there is
"specifying comment". And exactly that "specifying comment" clearly
specify how to calculate KeyHash. But in RFC6960 there are two different =
"ways of calculating KeyHash" (two different "specifying comments").
This is also not an "editorial problem", this is clearly a problem in =
technical description.

Best regards,
Yury Strozhevsky



Stefan Santesson =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-11 16:59:
> 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
>
> =EF=BB=BFOn 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 ::=3D 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 ::=3D 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

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
--
Erwann.
= _______________________________________________
pkix = mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

= --Apple-Mail=_C4692EBD-AA5E-49EC-BD91-A9A670440418-- From nobody Mon May 18 02:15:05 2020 Return-Path: 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 1CBC83A0A09 for ; Mon, 18 May 2020 02:15:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, 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 pmpflqeszTOL for ; Mon, 18 May 2020 02:15:00 -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 1B4323A09DA for ; Mon, 18 May 2020 02:14:59 -0700 (PDT) Received: from s807.loopia.se (localhost [127.0.0.1]) by s807.loopia.se (Postfix) with ESMTP id 3B4E52F6456C for ; Mon, 18 May 2020 11:14:54 +0200 (CEST) Received: from s645.loopia.se (unknown [172.22.191.5]) by s807.loopia.se (Postfix) with ESMTP id 153262E6FC50; Mon, 18 May 2020 11:14:54 +0200 (CEST) Received: from s473.loopia.se (unknown [172.22.191.6]) by s645.loopia.se (Postfix) with ESMTP id DF7C0156E582; Mon, 18 May 2020 11:14:53 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s645.loopia.se ([172.22.191.5]) by s473.loopia.se (s473.loopia.se [172.22.190.13]) (amavisd-new, port 10024) with LMTP id NrBRNHJWXDfz; Mon, 18 May 2020 11:14:52 +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.54] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s645.loopia.se (Postfix) with ESMTPSA id 78353156E4A3; Mon, 18 May 2020 11:14:51 +0200 (CEST) User-Agent: Microsoft-MacOutlook/16.37.20051002 Date: Mon, 18 May 2020 11:14:50 +0200 From: Stefan Santesson To: , Erwann Abalea CC: RFC Errata System , , , , Stephen Kent , , , , , , Message-ID: <475D361F-8875-445F-96CA-5A4F85477D38@aaa-sec.com> Thread-Topic: [pkix] [Technical Errata Reported] RFC6960 (6165) References: <20200511121547.17072F4071E@rfc-editor.org> <2013D511-BCF9-4D2C-9331-AA8203235F5F@aaa-sec.com> <56396ec5c59f0f9b372e79612bf0b13b@strozhevsky.com> In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3672645291_455865697" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 09:15:04 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3672645291_455865697 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Yury, =20 I don=E2=80=99t believe that you would settle with an even =E2=80=9Cbetter=E2=80=9D explanati= on, so I won=E2=80=99t attempt one. =20 I hope the rest of us can agree that the standard text clearly intends to s= ay that the hash is calculated over the unencoded object and not its encodin= g. This is less perfectly described in the general text and more accurately de= scribed in the normative ASN.1 comment. =20 Let=E2=80=99s just settle with editorial and put this one to rest. =20 Stefan Santesson=20 =20 From: Date: Monday, 18 May 2020 at 07:49 To: Erwann Abalea Cc: RFC Errata System , Stefan Santesson , , , , Stephen Kent , , , = , , , Subject: Re: [pkix] [Technical Errata Reported] RFC6960 (6165) =20 Hello Erwan, The deal it that in case of RFC6960 we have not an abstract "hash something= ", but a direct explanation that should be hashed ASN.1 BIT STRING without t= ag and length.=20 KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key (excluding the tag and length fields) The "responder's public key" is NOT an abstract "bits representing a key", = but a ASN.1 BIT STRING value (having DER encoding, btw, please forget about = other *ERs). And thus we have this definition of KeyHash: KeyHash =3D SHA-1 hash of ASN.1 BIT STRING DER encoded object without tag and= length ASN.1 blocks (=3D> hash of pure ASN.1 BIT STRING DER encoded "Value" b= lock, with "unused bits" byte) Again: the "responder's public key" is NOT an "abstract bits representing a= key", but an ASN.1 BIT STRING DER encoded object. Nowhere in RFC6960 stated= other description of "responder's public key".=20 The RFC6960 (as any other RFC, I do hope so) is a strictly technical docume= ntation. It is not about "guessing" but a technical description. And the RFC= has two different (from technical perspective) descriptions of the same ASN= .1 type KeyHash. =20 Best regards, Yury Strozhevsky =20 Erwann Abalea =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-16 15:31: Bonjour Yuri,=20 =20 ASN.1 and encoding rules are different but related standards. Therefore, ye= s, the encoding is not part of the ASN.1 object. =20 If your bit string is of length 0 (i.e. is empty), then its DER encoding wi= ll still have this "unused bits" part (and the encoding is then "03 01 00").= Yet, your object is empty, so this octet is not part of it, it's only here = to help correctly represent it on the wire because the chosen encoding rules= express lengths in octets. See it as an extension to the L field in the TLV= triplet. Please refer to X.690 clause 8.6.2 to see the difference between the conten= t octets composing the primitive encoding and the bit string value. =20 If we had used the PER encoding, this "unused bits" element wouldn't exist = (because PER encodes the length in bits for this object type). The example g= iven in my first email, encoded in PER, gives "35 00000000000000", and its e= ncoding could lose 3 bits depending on the variant (UNALIGNED vs ALIGNED) an= d the object encoded right after it. =20 If XER encoding had be chosen, there wouldn't be any L field, and the bits = themselves would be encoded as individual characters (0 or 1). =20 Le sam. 16 mai 2020 =C3=A0 07:22, a =C3=A9crit : Hello Erwann! Could you, please, explain "the first octet (unused bits) is not part of th= e ASN.1 object, it's only part of its encoding"? Encoding is not a part of A= SN.1 object? You are saying "is not part of the ASN.1 object" but right before it said "= the first octet". First octet is not a part of BIT STRING value? =20 Best regards, Yury Strozhevsky =20 Erwann Abalea =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-16 04:52: I also think the errata is editorial. =20 In a BIT STRING encoding, the first octet (unused bits) is not part of the = ASN.1 object, it's only part of its encoding. =20 The following hex strings are all valid BER encodings for a BIT STRING comp= osed of 53 bits set to zero: 03 08 03 00000000000000 03 08 03 00000000000007 23 0D 03 02 00 00 03 07 03 000000000000 23 0D 03 02 00 00 03 07 03 000000000007 23 80 03 05 00 00000000 03 04 03 000000 0000 23 80 03 05 00 00000000 03 04 03 000007 0000 =20 What is hashed is not the different encodings, but the BIT STRING value. In the preceding examples, only the first one is a valid DER encoding. And = if you hash the 7 octets after the "unused bits" octet, you'll obtain a wron= g hash, because the value is 53 bits long, not 56. =20 Le jeu. 14 mai 2020 =C3=A0 19:11, a =C3=A9crit : Hello All, Let me explain some details. Firstly I need to say that I already wrote=20 a couple of mails to RFC6960 authors and discussed it a little. From=20 these discussions I got that before we would start our discussion I need=20 to provide you some technical details. the main problem is that in RFC6960 there are two different description=20 for the same type KeyHash. First description is in 4.2.1 "ASN.1=20 Specification of the OCSP Response" of RFC6960: KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key (excluding the tag and length fields) And second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of=20 RFC6960: KeyHash ::=3D 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) Then I need to clarify why these two descriptions are not the same.=20 Firstly I need to describe ASN.1 type BIT STRING. As all other ASN.1=20 types BIT STRING consists of three main parts: "Tag", "Length" and=20 "Value" (TLV). But a specific for BIT STRING is that "Value" itself=20 devided on two parts: first byte designates "unused bits" (this value=20 could be 0-7) and the rest is bits describing bits. So, when we are saying "SHA-1 hash of responder's key (excluding the tag=20 and length fields)" we do assume that SHA-1 hash should be for BIT=20 STRING ASN.1 value excluding the "Tag" and "Length" fields (responder's=20 key has type BIT STRING). Thus the SHA-1 hash should be for entire=20 "Value" block of BIT STRING, with "unused bits" byte (the very first=20 byte in BIT STRING "Value" block). In opposite when we are saying " the SHA-1 hash of the value of the BIT=20 STRING subjectPublicKey [excluding the tag, length, and number of unused=20 bits] in the responder's certificate" we do assume that SHA-1 hash=20 should be for BIT STRING ASN.1 value excluding Tag, Length and the very=20 first byte from "Value" (unused bits). Do you understand that two SHA-1 hashes made using these two=20 descriptions of KeyHash would be different? Or I would need to provide=20 you a real example with responder's public key values? Feel free to ask=20 me for the example. As a conclusion: the RFC6960 has two descriptions of the same type and a=20 hash produced using these two descriptions would have different values.=20 This is a mistake. I do not really care how you would fix it and what=20 description for KeyHash is correct. But I want to have a correct=20 standard for OCSP. As an addition I found that Appendix B.1 and Appendix B.2 have different=20 description for KeyHash. It is the same ASN.1 description, but different=20 in comment describing the SHA-1 calculation process. The Appendix B.2,=20 in fact, describes KeyHash calculation similar with RFC2560. But=20 Appendix B.1 describes new way of KeyHash calculation. Even if these two=20 appendicies are not aligned allows me to consider the errata change as=20 "technical". Moreover, RFC6960 changes OCSP protocol in part of KeyHash calculation,=20 but it is never stated in any part of RFC6960. So, even if someone says=20 "calculation is obvious" but the problem that for KeyHash there is=20 "specifying comment". And exactly that "specifying comment" clearly=20 specify how to calculate KeyHash. But in RFC6960 there are two different=20 "ways of calculating KeyHash" (two different "specifying comments").=20 This is also not an "editorial problem", this is clearly a problem in=20 technical description. Best regards, Yury Strozhevsky Stefan Santesson =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-11 16:59: > I respond to all of these erratas collectivey (which I believe should > be consolidated to 1 and not 3 erratas) >=20 > I think the observation is correct, but I think it is editorial rather > than technical. >=20 > 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=20 > with B.1 >=20 > Please also note that a similar definition exist for the=20 > "issuerKeyHash" like: >=20 > issuerKeyHash OCTET STRING, -- Hash of issuer's public key >=20 >=20 > I think this is editorial >=20 >=20 >=20 > Stefan Santesson >=20 > On 2020-05-11, 14:16, "RFC Errata System" =20 > wrote: >=20 > The following errata report has been submitted for RFC6960, > "X.509 Internet Public Key Infrastructure Online Certificate > Status Protocol - OCSP". >=20 > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6165 >=20 > -------------------------------------- > Type: Technical > Reported by: Yury Strozhevsky >=20 > Section: 1 >=20 > Original Text > ------------- > --- >=20 > 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. >=20 >=20 > Notes > ----- > The RFC6960 changes OCSP protocol in part of KeyHash type > calculation. In RFC2560 there is the description: > KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key > (excluding the tag and length fields) >=20 > But in Appendix B.1, which is the major OCSP descriptive module,=20 > stated: > KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key > -- (i.e., the SHA-1 hash of the value of=20 > the > -- BIT STRING subjectPublicKey [excluding > -- the tag, length, and number of unused > -- bits] in the responder's certificate) >=20 > 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". >=20 > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary,=20 > 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. >=20 > -------------------------------------- > 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 _______________________________________________ pkix mailing list pkix@ietf.org https://www.ietf.org/mailman/listinfo/pkix --=20 Erwann. =20 =20 --=20 Erwann. =20 --B_3672645291_455865697 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Y= ury,

 

I don=E2=80=99t believe that you would se= ttle with an even =E2=80=9Cbetter=E2=80=9D explanation, so I won=E2=80=99t attempt one.

 

I hope the rest of us can agree that the st= andard text clearly intends to say that the hash is calculated over the unen= coded object and not its encoding.

<= span lang=3DEN-US style=3D'mso-fareast-language:EN-US'>This is less perfectly de= scribed in the general text and more accurately described in the normative A= SN.1 comment.

 

Let=E2=80=99s just settle wit= h editorial and put this one to rest.

 

Stefan Santesson

 

From: <yury@strozhevsky.com>
Date: Monday, 18 May 2020 at 07:4= 9
To: Erwann Abalea <eabalea@gmail.com>
Cc: RFC Er= rata System <rfc-editor@rfc-editor.org>, Stefan Santesson <stefan@a= aa-sec.com>, <ambarish@gmail.com>, <cadams@eecs.uottawa.ca>, = <kaduk@mit.edu>, Stephen Kent <kent@bbn.com>, <mmyers@fastq.c= om>, <none@rfc-editor.org>, <pkix@ietf.org>, <rdd@cert.org= >, <slava.galperin@gmail.com>, <sts@aaa-sec.com>
Subjec= t: Re: [pkix] [Technical Errata Reported] RFC6960 (6165)

 

Hello = ;Erwan,

The deal it that in case of RFC6960 we have not an = abstract "hash something", but a direct explanation that should be= hashed ASN.1 BIT STRING without tag and length. 

KeyH= ash ::=3D OCTET STRING -- SHA-1 hash of responder's public key
   = ; (excluding the tag and length fields)

The "responder= 's public key" is NOT an abstract "bits representing a key", = but a ASN.1 BIT STRING value (having DER encoding, btw, please forget about = other *ERs). And thus we have this definition of KeyHash:

K= eyHash =3D SHA-1 hash of ASN.1 BIT STRING DER encoded object without tag and l= ength ASN.1 blocks (=3D> hash of pure ASN.1 BIT STRING DER encoded "Va= lue" block, with "unused bits" byte)

Again: = the "responder's public key" is NOT an "abstract bits represe= nting a key", but an ASN.1 BIT STRING DER encoded object. Nowhere in RF= C6960 stated other description of "responder's public key". <= o:p>

The RFC6960 (as any other RFC, I do hope so) is a strictly = technical documentation. It is not about "guessing" but a technica= l description. And the RFC has two different (from technical perspective) de= scriptions of the same ASN.1 type KeyHash.

 

Best regards,

Yury Strozhevsky

 

Erwann Abalea =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-16 15:3= 1:

Bonjour Yuri,

<= p class=3DMsoNormal> 

ASN.1 a= nd encoding rules are different but related standards. Therefore, yes, the e= ncoding is not part of the ASN.1 object.

 

If your bit stri= ng is of length 0 (i.e. is empty), then its DER encoding will still have thi= s "unused bits" part (and the encoding is then "03 01 00"= ;). Yet, your object is empty, so this octet is not part of it, it's only he= re to help correctly represent it on the wire because the chosen encoding ru= les express lengths in octets. See it as an extension to the L field in the = TLV triplet.

Please refer to X.6= 90 clause 8.6.2 to see the difference between the content octets composing t= he primitive encoding and the bit string value.

 

If we had= used the PER encoding, this "unused bits" element wouldn't e= xist (because PER encodes the length in bits for this object type). The exam= ple given in my first email, encoded in PER, gives "35 00000000000000&q= uot;, and its encoding could lose 3 bits depending on the variant (UNALIGNED= vs ALIGNED) and the object encoded right after it.

 

If XER encoding had be chosen, there wouldn't be any L field, and the bits = themselves would be encoded as individual characters (0 or 1).

 

= Le sam. 16 mai 2020 =C3=A0 07:22, <yury@strozhevsky.com> a =C3=A9crit :

Hello Erwann!

<= p>Could you,= please, explain "the first octet (unused bits) is not part of the ASN.= 1 object, it's only part of its encoding"? Encoding is not a part of AS= N.1 object?

You are saying "is not part of the ASN.1 object= " but right before it said "the first octet". First octet is = not a part of BIT STRING value?

 

<= span style=3D'font-size:10.0pt;font-family:"Verdana",sans-serif'>Best regards,=

Yury Strozhevsky

 

Erwann Abalea =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-16 04:52:

I also think the = errata is editorial.

 

In a BIT STRING encoding, the first octe= t (unused bits) is not part of the ASN.1 object, it's only part of its encod= ing.

 

The following hex strings are all valid BER encodings for a BI= T STRING composed of 53 bits set to zero:

03 08 03 00000000000000

03 08 03= 00000000000007

23 0D 03 02 00 00 03 = 07 03 000000000000

23 0D 03 02 00 00 = 03 07 03 000000000007

23 80 03 05 00 = 00000000 03 04 03 000000 0000

23 80 0= 3 05 00 00000000 03 04 03 000007 0000

 

What is hashed is not the dif= ferent encodings, but the BIT STRING value.

=

In the preceding examples, only the first one is a valid DER encoding= . And if you hash the 7 octets after the "unused bits" octet, you'= ll obtain a wrong hash, because the value is 53 bits long, not 56.

 

L= e jeu. 14 mai 2020 =C3=A0 19:11, <= yury@strozhevsky.com> a =C3=A9crit :

Hello All,

Let me= explain some details. Firstly I need to say that I already wrote
a coup= le of mails to RFC6960 authors and discussed it a little. From
these dis= cussions I got that before we would start our discussion I need
to provi= de you some technical details.

the main problem is that in RFC6960 th= ere are two different description
for the same type KeyHash. First descr= iption is in 4.2.1 "ASN.1
Specification of the OCSP Response" = of RFC6960:

    KeyHash ::=3D OCTET STRING -- SHA-1 hash of r= esponder's public key
    (excluding the tag and length fields)=

And second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax&qu= ot; of
RFC6960:

KeyHash ::=3D OCTET STRING -- SHA-1 hash of respond= er's public key
                &= nbsp;         -- (i.e., the SHA-1 hash of the value of t= he
                    =       -- BIT STRING subjectPublicKey [excluding
  &nb= sp;                     &n= bsp; -- the tag, length, and number of unused
       =                   -- bits] in = the responder's certificate)

Then I need to clarify why these two des= criptions are not the same.
Firstly I need to describe ASN.1 type BIT ST= RING. As all other ASN.1
types BIT STRING consists of three main parts: = "Tag", "Length" and
"Value" (TLV). But a s= pecific for BIT STRING is that "Value" itself
devided on two p= arts: first byte designates "unused bits" (this value
could be= 0-7) and the rest is bits describing bits.
So, when we are saying "= SHA-1 hash of responder's key (excluding the tag
and length fields)"= ; we do assume that SHA-1 hash should be for BIT
STRING ASN.1 value excl= uding the "Tag" and "Length" fields (responder's
key= has type BIT STRING). Thus the SHA-1 hash should be for entire
"Va= lue" block of BIT STRING, with "unused bits" byte (the very f= irst
byte in BIT STRING "Value" block).

In opposite whe= n we are saying " the SHA-1 hash of the value of the BIT
STRING sub= jectPublicKey [excluding the tag, length, and number of unused
bits] in = the responder's certificate" we do assume that SHA-1 hash
should be= for BIT STRING ASN.1 value excluding Tag, Length and the very
first byt= e from "Value" (unused bits).

Do you understand that two SH= A-1 hashes made using these two
descriptions of KeyHash would be differe= nt? Or I would need to provide
you a real example with responder's publi= c key values? Feel free to ask
me for the example.

As a conclusio= n: the RFC6960 has two descriptions of the same type and a
hash produced= using these two descriptions would have different values.
This is a mis= take. I do not really care how you would fix it and what
description for= KeyHash is correct. But I want to have a correct
standard for OCSP.
=
As an addition I found that Appendix B.1 and Appendix B.2 have different=
description for KeyHash. It is the same ASN.1 description, but differen= t
in comment describing the SHA-1 calculation process. The Appendix B.2,=
in fact, describes KeyHash calculation similar with RFC2560. But
Ap= pendix B.1 describes new way of KeyHash calculation. Even if these two
a= ppendicies are not aligned allows me to consider the errata change as
&q= uot;technical".

Moreover, RFC6960 changes OCSP protocol in part = of KeyHash calculation,
but it is never stated in any part of RFC6960. S= o, even if someone says
"calculation is obvious" but the probl= em that for KeyHash there is
"specifying comment". And exactly= that "specifying comment" clearly
specify how to calculate Ke= yHash. But in RFC6960 there are two different
"ways of calculating = KeyHash" (two different "specifying comments").
This is a= lso not an "editorial problem", this is clearly a problem in
t= echnical description.

Best regards,
Yury Strozhevsky


Stefan Santesson =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-11 16:59:
> 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, b= ut I think it is editorial rather
> than technical.
>
> T= he normative text is that the KeyHash is the hash of the public key.
>= This is in itself clear an unambiguous.
> The imperfection here is no= t in the normative text, but in the
> explanation where the explanatio= n 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
&= gt; "issuerKeyHash" like:
>
> issuerKeyHash  &nb= sp;   OCTET STRING, -- Hash of issuer's public key
>
> > I think this is editorial
>
>
>
> Stefan Sa= ntesson
>
> On 2020-05-11, 14:16, "RFC Errata System"= <rfc-editor@rfc-editor.org>
> wrote:
>
>     The following erra= ta report has been submitted for RFC6960,
>     "X= .509 Internet Public Key Infrastructure Online Certificate
> Status Pr= otocol - OCSP".
>
>     -------------------= -------------------
>     You may review the report bel= ow and at:
>     
https://www.rfc-editor.org/errata/eid6165<= br>>
>     -------------------------------------->     Type: Technical
>     Reporte= d by: Yury Strozhevsky <yury@strozh= evsky.com>
>
>     Section: 1
> >     Original Text
>     ----------= ---
>     ---
>
>     Corre= cted Text
>     --------------
>    &nb= sp;   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
>     -----
>&= nbsp;    The RFC6960 changes OCSP protocol in part of KeyHash type=
> calculation. In RFC2560 there is the description:
>  &nb= sp;     KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's publ= ic key
>        (excluding the tag and length fiel= ds)
>
>     But in Appendix B.1, which is the ma= jor OCSP descriptive module,
> stated:
>     Key= Hash ::=3D OCTET STRING -- SHA-1 hash of responder's public key
>  =                      =       -- (i.e., the SHA-1 hash of the value of
> the<= br>>                   =           -- BIT STRING subjectPublicKey [excludin= g
>                  &nbs= p;           -- the tag, length, and number of unus= ed
>                  &nb= sp;           -- bits] in the responder's certifica= te)
>
>     The difference is in what would be u= nder SHA-1 hash. In RFC2560
> KeyHash would be calculated for entire B= IT STRING value, with "unused
> bits" byte (first byte in BI= T STRING value), but Appendix B.1 in
> RFC6960 states that SHA-1 hash = must be calculated for BIT STRING value
> without "unused bits&qu= ot;.
>
>     Instructions:
>    =  -------------
>     This erratum is currently pos= ted as "Reported". If necessary,
> please
>  &nb= sp;  use "Reply All" to discuss whether it should be verified= or
>     rejected. When a decision is reached, the ver= ifying 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
> Onl= ine Certificate Status Protocol - OCSP
>     Publicatio= n Date    : June 2013
>     Author(s)  &= nbsp;        : S. Santesson, M. Myers, R. Ankney, A.
= > Malpani, S. Galperin, C. Adams
>     Category = ;           : PROPOSED STANDARD
>   = ;  Source              : Public-Key = Infrastructure (X.509)
>     Area      &= nbsp;         : Security
>     Stre= am              : IETF
>  &nbs= p;  Verifying Party     : IESG

__________________= _____________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

--

Erwann.

 


 

-- <= o:p>

Erwann.

 

--B_3672645291_455865697-- From nobody Mon May 18 10:27:41 2020 Return-Path: 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 E5D183A09AB for ; Mon, 18 May 2020 10:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.004 X-Spam-Level: X-Spam-Status: No, score=0.004 tagged_above=-999 required=5 tests=[HTML_MESSAGE=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 NYsIQ-3TV9GT for ; Mon, 18 May 2020 10:27:33 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447B13A0962 for ; Mon, 18 May 2020 10:27:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 99DF0300B7C for ; Mon, 18 May 2020 13:27:30 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id y7DA8L7vwaJo for ; Mon, 18 May 2020 13:27:13 -0400 (EDT) Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 9610D300A26; Mon, 18 May 2020 13:27:12 -0400 (EDT) From: Russ Housley Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_2B64102B-D9D9-4EA5-9F15-3AECFD98AF02" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.14\)) Date: Mon, 18 May 2020 13:27:13 -0400 In-Reply-To: <475D361F-8875-445F-96CA-5A4F85477D38@aaa-sec.com> Cc: yury@strozhevsky.com, Erwann Abalea , "Roman D. Danyliw" , ambarish@gmail.com, Mike Myers , Stephen Kent , slava.galperin@gmail.com, cadams@eecs.uottawa.ca, sts@aaa-sec.com, Ben Kaduk , none@rfc-editor.org, IETF PKIX , RFC Editor To: Stefan Santesson References: <20200511121547.17072F4071E@rfc-editor.org> <2013D511-BCF9-4D2C-9331-AA8203235F5F@aaa-sec.com> <56396ec5c59f0f9b372e79612bf0b13b@strozhevsky.com> <475D361F-8875-445F-96CA-5A4F85477D38@aaa-sec.com> X-Mailer: Apple Mail (2.3445.104.14) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 17:27:40 -0000 --Apple-Mail=_2B64102B-D9D9-4EA5-9F15-3AECFD98AF02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 > On May 18, 2020, at 5:14 AM, Stefan Santesson = wrote: >=20 > Yury, > =20 > I don=E2=80=99t believe that you would settle with an even = =E2=80=9Cbetter=E2=80=9D explanation, so I won=E2=80=99t attempt one. > =20 > I hope the rest of us can agree that the standard text clearly intends = to say that the hash is calculated over the unencoded object and not its = encoding. > This is less perfectly described in the general text and more = accurately described in the normative ASN.1 comment. > =20 > Let=E2=80=99s just settle with editorial and put this one to rest. > =20 > Stefan Santesson=20 > =20 > From: > > Date: Monday, 18 May 2020 at 07:49 > To: Erwann Abalea > > Cc: RFC Errata System >, Stefan Santesson = >, >, >, >, Stephen Kent >, >, = >, >, >, = >, = > > Subject: Re: [pkix] [Technical Errata Reported] RFC6960 (6165) > =20 > Hello Erwan, > The deal it that in case of RFC6960 we have not an abstract "hash = something", but a direct explanation that should be hashed ASN.1 BIT = STRING without tag and length.=20 > KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key > (excluding the tag and length fields) > The "responder's public key" is NOT an abstract "bits representing a = key", but a ASN.1 BIT STRING value (having DER encoding, btw, please = forget about other *ERs). And thus we have this definition of KeyHash: > KeyHash =3D SHA-1 hash of ASN.1 BIT STRING DER encoded object without = tag and length ASN.1 blocks (=3D> hash of pure ASN.1 BIT STRING DER = encoded "Value" block, with "unused bits" byte) > Again: the "responder's public key" is NOT an "abstract bits = representing a key", but an ASN.1 BIT STRING DER encoded object. Nowhere = in RFC6960 stated other description of "responder's public key".=20 > The RFC6960 (as any other RFC, I do hope so) is a strictly technical = documentation. It is not about "guessing" but a technical description. = And the RFC has two different (from technical perspective) descriptions = of the same ASN.1 type KeyHash. > =20 > Best regards, > Yury Strozhevsky > =20 > Erwann Abalea =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-16 15:31: >> Bonjour Yuri,=20 >> =20 >> ASN.1 and encoding rules are different but related standards. = Therefore, yes, the encoding is not part of the ASN.1 object. >> =20 >> If your bit string is of length 0 (i.e. is empty), then its DER = encoding will still have this "unused bits" part (and the encoding is = then "03 01 00"). Yet, your object is empty, so this octet is not part = of it, it's only here to help correctly represent it on the wire because = the chosen encoding rules express lengths in octets. See it as an = extension to the L field in the TLV triplet. >> Please refer to X.690 clause 8.6.2 to see the difference between the = content octets composing the primitive encoding and the bit string = value. >> =20 >> If we had used the PER encoding, this "unused bits" element wouldn't = exist (because PER encodes the length in bits for this object type). The = example given in my first email, encoded in PER, gives "35 = 00000000000000", and its encoding could lose 3 bits depending on the = variant (UNALIGNED vs ALIGNED) and the object encoded right after it. >> =20 >> If XER encoding had be chosen, there wouldn't be any L field, and the = bits themselves would be encoded as individual characters (0 or 1). >> =20 >> Le sam. 16 mai 2020 =C3=A0 07:22, > a =C3=A9crit : >>> Hello Erwann! >>> Could you, please, explain "the first octet (unused bits) is not = part of the ASN.1 object, it's only part of its encoding"? Encoding is = not a part of ASN.1 object? >>> You are saying "is not part of the ASN.1 object" but right before it = said "the first octet". First octet is not a part of BIT STRING value? >>> =20 >>> Best regards, >>> Yury Strozhevsky >>> =20 >>> Erwann Abalea =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-16 04:52: >>>> I also think the errata is editorial. >>>> =20 >>>> In a BIT STRING encoding, the first octet (unused bits) is not part = of the ASN.1 object, it's only part of its encoding. >>>> =20 >>>> The following hex strings are all valid BER encodings for a BIT = STRING composed of 53 bits set to zero: >>>> 03 08 03 00000000000000 >>>> 03 08 03 00000000000007 >>>> 23 0D 03 02 00 00 03 07 03 000000000000 >>>> 23 0D 03 02 00 00 03 07 03 000000000007 >>>> 23 80 03 05 00 00000000 03 04 03 000000 0000 >>>> 23 80 03 05 00 00000000 03 04 03 000007 0000 >>>> =20 >>>> What is hashed is not the different encodings, but the BIT STRING = value. >>>> In the preceding examples, only the first one is a valid DER = encoding.. And if you hash the 7 octets after the "unused bits" octet, = you'll obtain a wrong hash, because the value is 53 bits long, not 56. >>>> =20 >>>> Le jeu. 14 mai 2020 =C3=A0 19:11, > a =C3=A9crit : >>>>> Hello All, >>>>>=20 >>>>> Let me explain some details. Firstly I need to say that I already = wrote=20 >>>>> a couple of mails to RFC6960 authors and discussed it a little. = =46rom=20 >>>>> these discussions I got that before we would start our discussion = I need=20 >>>>> to provide you some technical details. >>>>>=20 >>>>> the main problem is that in RFC6960 there are two different = description=20 >>>>> for the same type KeyHash. First description is in 4.2.1 "ASN.1=20 >>>>> Specification of the OCSP Response" of RFC6960: >>>>>=20 >>>>> KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public = key >>>>> (excluding the tag and length fields) >>>>>=20 >>>>> And second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of=20= >>>>> RFC6960: >>>>>=20 >>>>> KeyHash ::=3D 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) >>>>>=20 >>>>> Then I need to clarify why these two descriptions are not the = same.=20 >>>>> Firstly I need to describe ASN.1 type BIT STRING. As all other = ASN.1=20 >>>>> types BIT STRING consists of three main parts: "Tag", "Length" and=20= >>>>> "Value" (TLV). But a specific for BIT STRING is that "Value" = itself=20 >>>>> devided on two parts: first byte designates "unused bits" (this = value=20 >>>>> could be 0-7) and the rest is bits describing bits. >>>>> So, when we are saying "SHA-1 hash of responder's key (excluding = the tag=20 >>>>> and length fields)" we do assume that SHA-1 hash should be for BIT=20= >>>>> STRING ASN.1 value excluding the "Tag" and "Length" fields = (responder's=20 >>>>> key has type BIT STRING). Thus the SHA-1 hash should be for entire=20= >>>>> "Value" block of BIT STRING, with "unused bits" byte (the very = first=20 >>>>> byte in BIT STRING "Value" block). >>>>>=20 >>>>> In opposite when we are saying " the SHA-1 hash of the value of = the BIT=20 >>>>> STRING subjectPublicKey [excluding the tag, length, and number of = unused=20 >>>>> bits] in the responder's certificate" we do assume that SHA-1 hash=20= >>>>> should be for BIT STRING ASN.1 value excluding Tag, Length and the = very=20 >>>>> first byte from "Value" (unused bits). >>>>>=20 >>>>> Do you understand that two SHA-1 hashes made using these two=20 >>>>> descriptions of KeyHash would be different? Or I would need to = provide=20 >>>>> you a real example with responder's public key values? Feel free = to ask=20 >>>>> me for the example. >>>>>=20 >>>>> As a conclusion: the RFC6960 has two descriptions of the same type = and a=20 >>>>> hash produced using these two descriptions would have different = values.=20 >>>>> This is a mistake. I do not really care how you would fix it and = what=20 >>>>> description for KeyHash is correct. But I want to have a correct=20= >>>>> standard for OCSP. >>>>>=20 >>>>> As an addition I found that Appendix B.1 and Appendix B.2 have = different=20 >>>>> description for KeyHash. It is the same ASN.1 description, but = different=20 >>>>> in comment describing the SHA-1 calculation process. The Appendix = B.2,=20 >>>>> in fact, describes KeyHash calculation similar with RFC2560. But=20= >>>>> Appendix B.1 describes new way of KeyHash calculation. Even if = these two=20 >>>>> appendicies are not aligned allows me to consider the errata = change as=20 >>>>> "technical". >>>>>=20 >>>>> Moreover, RFC6960 changes OCSP protocol in part of KeyHash = calculation,=20 >>>>> but it is never stated in any part of RFC6960. So, even if someone = says=20 >>>>> "calculation is obvious" but the problem that for KeyHash there is=20= >>>>> "specifying comment". And exactly that "specifying comment" = clearly=20 >>>>> specify how to calculate KeyHash. But in RFC6960 there are two = different=20 >>>>> "ways of calculating KeyHash" (two different "specifying = comments").=20 >>>>> This is also not an "editorial problem", this is clearly a problem = in=20 >>>>> technical description. >>>>>=20 >>>>> Best regards, >>>>> Yury Strozhevsky >>>>>=20 >>>>>=20 >>>>>=20 >>>>> Stefan Santesson =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-11 16:59: >>>>> > I respond to all of these erratas collectivey (which I believe = should >>>>> > be consolidated to 1 and not 3 erratas) >>>>> >=20 >>>>> > I think the observation is correct, but I think it is editorial = rather >>>>> > than technical. >>>>> >=20 >>>>> > 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=20 >>>>> > with B.1 >>>>> >=20 >>>>> > Please also note that a similar definition exist for the=20 >>>>> > "issuerKeyHash" like: >>>>> >=20 >>>>> > issuerKeyHash OCTET STRING, -- Hash of issuer's public key >>>>> >=20 >>>>> >=20 >>>>> > I think this is editorial >>>>> >=20 >>>>> >=20 >>>>> >=20 >>>>> > Stefan Santesson >>>>> >=20 >>>>> > On 2020-05-11, 14:16, "RFC Errata System" = >=20 >>>>> > wrote: >>>>> >=20 >>>>> > The following errata report has been submitted for RFC6960, >>>>> > "X..509 Internet Public Key Infrastructure Online = Certificate >>>>> > Status Protocol - OCSP". >>>>> >=20 >>>>> > -------------------------------------- >>>>> > You may review the report below and at: >>>>> > https://www.rfc-editor.org/errata/eid6165 = >>>>> >=20 >>>>> > -------------------------------------- >>>>> > Type: Technical >>>>> > Reported by: Yury Strozhevsky > >>>>> >=20 >>>>> > Section: 1 >>>>> >=20 >>>>> > Original Text >>>>> > ------------- >>>>> > --- >>>>> >=20 >>>>> > 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. >>>>> >=20 >>>>> >=20 >>>>> > Notes >>>>> > ----- >>>>> > The RFC6960 changes OCSP protocol in part of KeyHash type >>>>> > calculation. In RFC2560 there is the description: >>>>> > KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's = public key >>>>> > (excluding the tag and length fields) >>>>> >=20 >>>>> > But in Appendix B.1, which is the major OCSP descriptive = module,=20 >>>>> > stated: >>>>> > KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's = public key >>>>> > -- (i.e., the SHA-1 hash of the = value of=20 >>>>> > the >>>>> > -- BIT STRING subjectPublicKey = [excluding >>>>> > -- the tag, length, and number of = unused >>>>> > -- bits] in the responder's = certificate) >>>>> >=20 >>>>> > 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". >>>>> >=20 >>>>> > Instructions: >>>>> > ------------- >>>>> > This erratum is currently posted as "Reported". If = necessary,=20 >>>>> > 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. >>>>> >=20 >>>>> > -------------------------------------- >>>>> > 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 >>>>>=20 >>>>> _______________________________________________ >>>>> pkix mailing list >>>>> pkix@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/pkix = >>>> --=20 >>>> Erwann. >>> =20 >>=20 >>=20 >> =20 >> --=20 >> Erwann. > =20 > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix = --Apple-Mail=_2B64102B-D9D9-4EA5-9F15-3AECFD98AF02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 +1

On May 18, 2020, at 5:14 AM, Stefan Santesson <stefan@aaa-sec.com> = wrote:

Yury,
 
I don=E2=80=99t believe that = you would settle with an even =E2=80=9Cbetter=E2=80=9D explanation, so I = won=E2=80=99t attempt one.
 
I hope the rest of us can = agree that the standard text clearly intends to say that the hash is = calculated over the unencoded object and not its encoding.
This is less perfectly described in the = general text and more accurately described in the normative ASN.1 = comment.
 
Let=E2=80=99s just settle = with editorial and put this one to rest.
 
Stefan = Santesson 
 
From: <yury@strozhevsky.com>
Date: Monday, 18 May 2020 at = 07:49
To: Erwann Abalea <eabalea@gmail.com>
Cc: RFC = Errata System <rfc-editor@rfc-editor.org>, Stefan Santesson <stefan@aaa-sec.com>, = <ambarish@gmail.com>, = <cadams@eecs.uottawa.ca>, = <kaduk@mit.edu>, Stephen = Kent <kent@bbn.com>, <mmyers@fastq.com>, <none@rfc-editor.org>, = <pkix@ietf.org>, <rdd@cert.org>, <slava.galperin@gmail.com>, = <sts@aaa-sec.com>
Subject: Re: [pkix] [Technical = Errata Reported] RFC6960 (6165)
 
Hello Erwan,
The deal it that in case of RFC6960 we have not an abstract = "hash something", but a direct explanation that should be hashed ASN.1 = BIT STRING without tag and length. 
KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's = public key
    (excluding the tag and length = fields)
The "responder's = public key" is NOT an abstract "bits representing a key", but a ASN.1 = BIT STRING value (having DER encoding, btw, please forget about other = *ERs). And thus we have this definition of KeyHash:
KeyHash =3D SHA-1 hash of ASN.1 = BIT STRING DER encoded object without tag and length ASN.1 blocks (=3D>= hash of pure ASN.1 BIT STRING DER encoded "Value" block, with "unused = bits" byte)
Again: the = "responder's public key" is NOT an "abstract bits representing a key", = but an ASN.1 BIT STRING DER encoded object. Nowhere in RFC6960 stated = other description of "responder's public key". 
The RFC6960 (as any other RFC, I = do hope so) is a strictly technical documentation. It is not about = "guessing" but a technical description. And the RFC has two different = (from technical perspective) descriptions of the same ASN.1 type = KeyHash.
 
Best regards,
Yury Strozhevsky
 
Erwann = Abalea =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-16 15:31:
Bonjour = Yuri, 
 
ASN.1 and encoding rules are different = but related standards. Therefore, yes, the encoding is not part of the = ASN.1 object.
 
If your bit string is of length 0 (i.e. is empty), then its = DER encoding will still have this "unused bits" part (and the encoding = is then "03 01 00"). Yet, your object is empty, so this octet is not = part of it, it's only here to help correctly represent it on the wire = because the chosen encoding rules express lengths in octets. See it as = an extension to the L field in the TLV triplet.
Please refer to X.690 clause 8.6.2 to see the difference = between the content octets composing the primitive encoding and the bit = string value.
 
If we had used the PER encoding, this "unused bits" = element wouldn't exist (because PER encodes the length in bits for this = object type). The example given in my first email, encoded in PER, gives = "35 00000000000000", and its encoding could lose 3 bits depending on the = variant (UNALIGNED vs ALIGNED) and the object encoded right after = it.
 
If XER encoding had be chosen, there wouldn't be any L field, = and the bits themselves would be encoded as individual characters (0 or = 1).
 
Le sam. 16 mai 2020 = =C3=A0 07:22, <yury@strozhevsky.com> a =C3=A9crit :
Hello Erwann!
Could you, please, explain "the first octet = (unused bits) is not part of the ASN.1 object, it's only part of its = encoding"? Encoding is not a part of ASN.1 object?
You are saying "is = not part of the ASN.1 object" but right before it said "the first = octet". First octet is not a part of BIT STRING value?
 
Best regards,
Yury Strozhevsky
 
Erwann Abalea =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-16 = 04:52:
I = also think the errata is editorial.
 
In a BIT STRING encoding, the first octet = (unused bits) is not part of the ASN.1 object, it's only part of its = encoding.
 
The following hex strings are all valid BER = encodings for a BIT STRING composed of 53 bits set to zero:
03 08 03 00000000000000
03 08 03 00000000000007
23 0D 03 02 00 00 03 07 03 000000000000
23 0D 03 02 00 00 03 07 03 000000000007
23 80 03 05 00 00000000 03 04 03 000000 0000
23 80 03 05 00 00000000 03 04 03 000007 0000
 
What is hashed is not the different encodings, = but the BIT STRING value.
In the preceding = examples, only the first one is a valid DER encoding.. And if you hash = the 7 octets after the "unused bits" octet, you'll obtain a wrong hash, = because the value is 53 bits long, not 56.
 
Le jeu. 14 mai 2020 =C3=A0 19:11, <yury@strozhevsky.com> a = =C3=A9crit :
Hello All,
Let me explain some details. Firstly I need to say that I = already wrote 
a couple of mails to RFC6960 authors and discussed it a = little. From 
these discussions I got that before we would start our = discussion I need 
to provide you some technical details.

the main problem is that in RFC6960 there are two different = description 
for the same type KeyHash. First description is in 4.2.1 = "ASN.1 
Specification of the OCSP Response" of RFC6960:

    KeyHash ::=3D OCTET STRING -- = SHA-1 hash of responder's public key
    = (excluding the tag and length fields)

And = second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of 
RFC6960:

KeyHash ::=3D 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)

Then = I need to clarify why these two descriptions are not the same. 
Firstly I = need to describe ASN.1 type BIT STRING. As all other ASN.1 
types BIT = STRING consists of three main parts: "Tag", "Length" and 
"Value" = (TLV). But a specific for BIT STRING is that "Value" itself 
devided on = two parts: first byte designates "unused bits" (this value 
could be = 0-7) and the rest is bits describing bits.
So, when we are = saying "SHA-1 hash of responder's key (excluding the tag 
and length = fields)" we do assume that SHA-1 hash should be for BIT 
STRING ASN.1 = value excluding the "Tag" and "Length" fields (responder's 
key has type = BIT STRING). Thus the SHA-1 hash should be for entire 
"Value" = block of BIT STRING, with "unused bits" byte (the very first 
byte in BIT = STRING "Value" block).

In opposite when we = are saying " 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" we do assume that SHA-1 hash 
should be = for BIT STRING ASN.1 value excluding Tag, Length and the very 
first byte = from "Value" (unused bits).

Do you = understand that two SHA-1 hashes made using these two 
descriptions = of KeyHash would be different? Or I would need to provide 
you a real = example with responder's public key values? Feel free to ask 
me for the = example.

As a conclusion: the RFC6960 has = two descriptions of the same type and a 
hash = produced using these two descriptions would have different values. 
This is a = mistake. I do not really care how you would fix it and what 
description = for KeyHash is correct. But I want to have a correct 
standard for = OCSP.

As an addition I found that Appendix = B.1 and Appendix B.2 have different 
description = for KeyHash. It is the same ASN.1 description, but different 
in comment = describing the SHA-1 calculation process. The Appendix B.2, 
in fact, = describes KeyHash calculation similar with RFC2560. But 
Appendix B.1 = describes new way of KeyHash calculation. Even if these two 
appendicies = are not aligned allows me to consider the errata change as 
"technical".

Moreover, RFC6960 = changes OCSP protocol in part of KeyHash calculation, 
but it is = never stated in any part of RFC6960. So, even if someone says 
"calculation = is obvious" but the problem that for KeyHash there is 
"specifying = comment". And exactly that "specifying comment" clearly 
specify how = to calculate KeyHash. But in RFC6960 there are two different 
"ways of = calculating KeyHash" (two different "specifying comments"). 
This is also = not an "editorial problem", this is clearly a problem in 
technical = description.

Best regards,
Yury= Strozhevsky



Stefan Santesson =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-11 = 16:59:
> 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 = ::=3D 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 = ::=3D 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

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix
-- 
Erwann.
 

 
-- 
Erwann.
 
_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix

= --Apple-Mail=_2B64102B-D9D9-4EA5-9F15-3AECFD98AF02-- From james.reilly@kone.com Fri May 22 03:55:13 2020 Return-Path: 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 B5F833A0AF5 for ; Fri, 22 May 2020 03:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=kone.com 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 8d7eXD-fVrwg for ; Fri, 22 May 2020 03:55:11 -0700 (PDT) Received: from EUR05-DB8-obe.outbound.protection.outlook.com (mail-db8eur05on2102.outbound.protection.outlook.com [40.107.20.102]) (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 9C2593A0AF3 for ; Fri, 22 May 2020 03:55:11 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SB3sk/4XT2uTkGViHdKHMFGa+n9nMX0ks1XDujbQUfLEbvQ09EMLeQrxjk8qOaphvxa1DIK/o1dBwp+BYAB8ZZ9i/yn35vJg6tCTc/KmRMgbyg8WW3dq7+pN2Q90YwMnd6wDVYlGEUCP0t6frMSAgtU+jf8I4RBSPnfDdpWU4cYcfhMRJQlk3pj4rrCn86NjiPjB9NdWkhqbTImVXaGHdQO8bFo8C8UXx00xC0bScWJ7++cdOiAcQdq6OPYtjHIGSJvpLLb12vimY9ayuIt0gEkXNIeqgwlkXp/KT/UXbmC71JU0JOljnZdvc/JxqgwQP9A1fOYohtxCpdMvJhTn8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gmfjQ5T0AvICdIP3d4UFrVjzkwb2RoWFo5PMM06fOo4=; b=Rp338HLR1GUNrVPmROyD0bd2PIFMqa4Bcu76AFeNNL/gzKQhYXRIq6xhazTp4+BXHpMtyn+FyRZx9fDJp1waz/tj7LMME0IMxZmmGBlhyf6vmFz1DleV4Kb7wu09fZDZUF4G4AvniQRuZfchJc2GXgObVx0nvy71O3x2aod0COvQ/d9xrrxrpPZMXgk2i3e+QFQWMpplkC8YCwkidEGvzONCzAUKM/BV8d3UV3ooFOvWTbfMZia/E/jzC12ewhjMSDia5MbMWWY2CKEzM8+sx1Iy5Y1pR4fFxfr9gA4wnRdTZQrguyYXw3PrEpSVLWjHJFnute+ZoZrZ/+V8bIIiBA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=kone.com; dmarc=pass action=none header.from=kone.com; dkim=pass header.d=kone.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kone.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gmfjQ5T0AvICdIP3d4UFrVjzkwb2RoWFo5PMM06fOo4=; b=RKUlS1A4vqRM3UkVu3czhDsDeLFudzOc3D3/++A11wgufwAIin5h09xBOzDJr4MM0u1J75rq3HXxM0beOKYdzGxvDGZ66ep0YeloJdKDNNcFpOIWsTnMivY0mnihqH3hJT+nUUvc40qdKlLt5sSbEeUoHwivSehuge0paQnUNo4= Received: from AM6PR07MB5493.eurprd07.prod.outlook.com (2603:10a6:20b:86::22) by AM6PR07MB5432.eurprd07.prod.outlook.com (2603:10a6:20b:8f::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3045.9; Fri, 22 May 2020 10:55:08 +0000 Received: from AM6PR07MB5493.eurprd07.prod.outlook.com ([fe80::5009:eadf:67bb:a130]) by AM6PR07MB5493.eurprd07.prod.outlook.com ([fe80::5009:eadf:67bb:a130%4]) with mapi id 15.20.3021.019; Fri, 22 May 2020 10:55:08 +0000 From: Reilly James To: "pkix@ietf.org" Thread-Topic: Question about RFC 7030 - Enrollment over Secure Transport Thread-Index: AdYwJ3Ts9+DsbQVQS4+mKlif4+ckrQ== Date: Fri, 22 May 2020 10:55:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=kone.com; x-originating-ip: [85.156.182.228] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 110b5cb0-6190-4c1c-d1a6-08d7fe3e9808 x-ms-traffictypediagnostic: AM6PR07MB5432: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 04111BAC64 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: MoPyQIqPejhP67iat+HTcc1wDh18RdlYK3PrH5AC7xgxehg/dKTNOD2MWgeGEjcjYSdEGygHGagwDHDRRGiJXQYRIW6vXGTkgktZDwAtN9Rd6uFyuYEgVfISzK1QArXk4N4dAJ74d29qBGO1smNMs3aygWcHknd7dI5lQOsJ1fCiCMNLNq3tDCSG1hOtK4/ugNHJGbbiUoWCc1UK4Hhdf5Ij10JO0HLeLSF+Yof4RHHZDImy9yNTMk+E7iPQxRhUgkNP9/HQCI3eqUT5SEYq2Zk0Y1FaK/YeBv9pHHRhuRIF1Bp0QZVWPlEehcCM5gM5maJUXBjKDbYAmz6foWN+qg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM6PR07MB5493.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(136003)(366004)(376002)(396003)(346002)(5660300002)(86362001)(6506007)(478600001)(8676002)(8936002)(26005)(33656002)(186003)(55016002)(9686003)(6916009)(2906002)(316002)(52536014)(7696005)(66476007)(66946007)(64756008)(66446008)(66556008)(4744005)(76116006)(71200400001); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata: PyIK53Ha7KV5b3R1ElvTuOKMoIqTOjZL74L/TBmLoKLx12W0xCzTcUYS5D2feQBzHgjFS1BrVCqbQE4y2TriNGrwvAZxBgFMwwcgw6qvMOFwK6xUoEr906HLRTBW224HsBI/cNXZzVE0SvnM59Y2C6/J5j4MIdYU79chLeP02EA93lm4/edEDk9spmSz7G6+7Y1z1+PohfVhDnG4jF0/aAL9tT1UV92+aYsJHPlinRxPhC+R4R3yjhMm5E3vs0ynV2gBSrIms918DkbMgycueAkedQ73YOixlgJOE4DeFNt6KEvIHdZgYUtvqtaWlB/6d4m1EEIORs3v2IoWnel+RzSaFjltahpShtr3SqFUJFuG76StGpWMASa3yu0bXDeeiMhdK/qjyvDd3LI2NL2pvZ2NaMQ1dEDYQEapdJD0D/X6CVAURQOs3jHSfrXGt4M8CIge+SQ4zpB5DaSvgFKjKgCfWl9ZEtbhVVNWtWnphn9OVchiH14BVaucmquOvQal x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AM6PR07MB5493360C958292A80FB88E53E3B40AM6PR07MB5493eurp_" MIME-Version: 1.0 X-OriginatorOrg: kone.com X-MS-Exchange-CrossTenant-Network-Message-Id: 110b5cb0-6190-4c1c-d1a6-08d7fe3e9808 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 May 2020 10:55:08.7887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2bb82c64-2eb1-43f7-8862-fdc1d2333b50 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vKuXlLXINM6J8RMb6dYismf92uRjLcKND17Zm9dlGPYTVXaVMK9zNMux1pRnUfm4mff9/vREJFwVm3qFHeFIdg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR07MB5432 Archived-At: X-Mailman-Approved-At: Sun, 31 May 2020 22:21:36 -0700 Subject: [pkix] Question about RFC 7030 - Enrollment over Secure Transport X-BeenThere: pkix@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: PKIX Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 May 2020 11:13:37 -0000 --_000_AM6PR07MB5493360C958292A80FB88E53E3B40AM6PR07MB5493eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello We are looking at RFC 7030 - Enrollment over Secure Transport. Is there a reason or thought process in section '4.1.3 CA Certificates Resp= onse' 'The EST server SHOULD include the three "Root CA Key Update" certificates OldWithOld, OldWithNew, and NewWithOld in the response chain. These are defined in Section 4.4 of CMP [RFC4210].' why SHOULD rather than example MUST was used in the specification by the au= thors? James --_000_AM6PR07MB5493360C958292A80FB88E53E3B40AM6PR07MB5493eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello

 

We are looking at RFC 7030 R= 11; Enrollment over Secure Transport.

 

Is there a reason or thought pr= ocess in section ‘4.1.3 CA Certificates Response’

   ‘T=
he EST server SHOULD include the three "Root CA Key Update"<=
/o:p>

 &= nbsp; certificates OldWithOld, OldWithNew, and NewWithOld in the response

 &= nbsp; chain.  These are defined in Section 4.4 of CMP [RFC4210].’= ;

 

why SHOULD rather than example = MUST was used in the specification by the authors?

James

--_000_AM6PR07MB5493360C958292A80FB88E53E3B40AM6PR07MB5493eurp_-- From nobody Sun May 31 22:22:01 2020 Return-Path: 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 9D0333A07EC for ; Sun, 17 May 2020 22:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 b_cgG29wYUhu for ; Sun, 17 May 2020 22:49:42 -0700 (PDT) Received: from spl3.hosting.reg.ru (spl3.hosting.reg.ru [31.31.196.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E41633A07D8 for ; Sun, 17 May 2020 22:49:41 -0700 (PDT) Received: from webmail.hosting.reg.ru (webmail.hosting.reg.ru [37.140.192.176]) (Authenticated sender: yury@strozhevsky.com) by spl3.hosting.reg.ru (Postfix) with ESMTPA id 397FA17E0743; Mon, 18 May 2020 08:49:37 +0300 (MSK) MIME-Version: 1.0 Date: Mon, 18 May 2020 08:49:37 +0300 From: yury@strozhevsky.com To: Erwann Abalea Cc: RFC Errata System , Stefan Santesson , ambarish@gmail.com, cadams@eecs.uottawa.ca, kaduk@mit.edu, Stephen Kent , mmyers@fastq.com, none@rfc-editor.org, , rdd@cert.org, slava.galperin@gmail.com, sts@aaa-sec.com In-Reply-To: References: <20200511121547.17072F4071E@rfc-editor.org> <2013D511-BCF9-4D2C-9331-AA8203235F5F@aaa-sec.com> <56396ec5c59f0f9b372e79612bf0b13b@strozhevsky.com> User-Agent: Roundcube Webmail/1.4.3 Message-ID: X-Sender: yury@strozhevsky.com Content-Type: multipart/alternative; boundary="=_3a6860d0207719b91904541887c99128" X-PPP-Message-ID: <20200518054937.21016.75642@spl3.hosting.reg.ru> X-PPP-Vhost: strozhevsky.com Archived-At: X-Mailman-Approved-At: Sun, 31 May 2020 22:21:59 -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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 05:49:46 -0000 --=_3a6860d0207719b91904541887c99128 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Hello Erwan, The deal it that in case of RFC6960 we have not an abstract "hash something", but a direct explanation that should be hashed ASN.1 BIT STRING without tag and length. KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key (excluding the tag and length fields) The "responder's public key" is NOT an abstract "bits representing a key", but a ASN.1 BIT STRING value (having DER encoding, btw, please forget about other *ERs). And thus we have this definition of KeyHash: KeyHash = SHA-1 hash of ASN.1 BIT STRING DER encoded object without tag and length ASN.1 blocks (=> hash of pure ASN.1 BIT STRING DER encoded "Value" block, with "unused bits" byte) Again: the "responder's public key" is NOT an "abstract bits representing a key", but an ASN.1 BIT STRING DER encoded object. Nowhere in RFC6960 stated other description of "responder's public key". The RFC6960 (as any other RFC, I do hope so) is a strictly technical documentation. It is not about "guessing" but a technical description. And the RFC has two different (from technical perspective) descriptions of the same ASN.1 type KeyHash. Best regards, Yury Strozhevsky Erwann Abalea писал 2020-05-16 15:31: > Bonjour Yuri, > > ASN.1 and encoding rules are different but related standards. Therefore, yes, the encoding is not part of the ASN.1 object. > > If your bit string is of length 0 (i.e. is empty), then its DER encoding will still have this "unused bits" part (and the encoding is then "03 01 00"). Yet, your object is empty, so this octet is not part of it, it's only here to help correctly represent it on the wire because the chosen encoding rules express lengths in octets. See it as an extension to the L field in the TLV triplet. > Please refer to X.690 clause 8.6.2 to see the difference between the content octets composing the primitive encoding and the bit string value. > > If we had used the PER encoding, this "unused bits" element wouldn't exist (because PER encodes the length in bits for this object type). The example given in my first email, encoded in PER, gives "35 00000000000000", and its encoding could lose 3 bits depending on the variant (UNALIGNED vs ALIGNED) and the object encoded right after it. > > If XER encoding had be chosen, there wouldn't be any L field, and the bits themselves would be encoded as individual characters (0 or 1). > > Le sam. 16 mai 2020 à 07:22, a écrit : > > Hello Erwann! > > Could you, please, explain "the first octet (unused bits) is not part of the ASN.1 object, it's only part of its encoding"? Encoding is not a part of ASN.1 object? > > You are saying "is not part of the ASN.1 object" but right before it said "the first octet". First octet is not a part of BIT STRING value? > > Best regards, > > Yury Strozhevsky > > Erwann Abalea писал 2020-05-16 04:52: > > I also think the errata is editorial. > > In a BIT STRING encoding, the first octet (unused bits) is not part of the ASN.1 object, it's only part of its encoding. > > The following hex strings are all valid BER encodings for a BIT STRING composed of 53 bits set to zero: > 03 08 03 00000000000000 > 03 08 03 00000000000007 > 23 0D 03 02 00 00 03 07 03 000000000000 > 23 0D 03 02 00 00 03 07 03 000000000007 > 23 80 03 05 00 00000000 03 04 03 000000 0000 > 23 80 03 05 00 00000000 03 04 03 000007 0000 > > What is hashed is not the different encodings, but the BIT STRING value. > In the preceding examples, only the first one is a valid DER encoding. And if you hash the 7 octets after the "unused bits" octet, you'll obtain a wrong hash, because the value is 53 bits long, not 56. > > Le jeu. 14 mai 2020 à 19:11, a écrit : Hello All, > > Let me explain some details. Firstly I need to say that I already wrote > a couple of mails to RFC6960 authors and discussed it a little. From > these discussions I got that before we would start our discussion I need > to provide you some technical details. > > the main problem is that in RFC6960 there are two different description > for the same type KeyHash. First description is in 4.2.1 "ASN.1 > Specification of the OCSP Response" of RFC6960: > > KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key > (excluding the tag and length fields) > > And second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of > RFC6960: > > 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) > > Then I need to clarify why these two descriptions are not the same. > Firstly I need to describe ASN.1 type BIT STRING. As all other ASN.1 > types BIT STRING consists of three main parts: "Tag", "Length" and > "Value" (TLV). But a specific for BIT STRING is that "Value" itself > devided on two parts: first byte designates "unused bits" (this value > could be 0-7) and the rest is bits describing bits. > So, when we are saying "SHA-1 hash of responder's key (excluding the tag > and length fields)" we do assume that SHA-1 hash should be for BIT > STRING ASN.1 value excluding the "Tag" and "Length" fields (responder's > key has type BIT STRING). Thus the SHA-1 hash should be for entire > "Value" block of BIT STRING, with "unused bits" byte (the very first > byte in BIT STRING "Value" block). > > In opposite when we are saying " 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" we do assume that SHA-1 hash > should be for BIT STRING ASN.1 value excluding Tag, Length and the very > first byte from "Value" (unused bits). > > Do you understand that two SHA-1 hashes made using these two > descriptions of KeyHash would be different? Or I would need to provide > you a real example with responder's public key values? Feel free to ask > me for the example. > > As a conclusion: the RFC6960 has two descriptions of the same type and a > hash produced using these two descriptions would have different values. > This is a mistake. I do not really care how you would fix it and what > description for KeyHash is correct. But I want to have a correct > standard for OCSP. > > As an addition I found that Appendix B.1 and Appendix B.2 have different > description for KeyHash. It is the same ASN.1 description, but different > in comment describing the SHA-1 calculation process. The Appendix B.2, > in fact, describes KeyHash calculation similar with RFC2560. But > Appendix B.1 describes new way of KeyHash calculation. Even if these two > appendicies are not aligned allows me to consider the errata change as > "technical". > > Moreover, RFC6960 changes OCSP protocol in part of KeyHash calculation, > but it is never stated in any part of RFC6960. So, even if someone says > "calculation is obvious" but the problem that for KeyHash there is > "specifying comment". And exactly that "specifying comment" clearly > specify how to calculate KeyHash. But in RFC6960 there are two different > "ways of calculating KeyHash" (two different "specifying comments"). > This is also not an "editorial problem", this is clearly a problem in > technical description. > > Best regards, > Yury Strozhevsky > > Stefan Santesson писал 2020-05-11 16:59: >> 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" >> 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 >> >> 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 > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix -- > Erwann. -- Erwann. --=_3a6860d0207719b91904541887c99128 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Hello Erwan,

The deal it that in case of RFC6960 we have not an abstract "hash someth= ing", but a direct explanation that should be hashed ASN.1 BIT STRING witho= ut tag and length. 

KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key
=     (excluding the tag and length fields)

The "responder's public key" is NOT an abstract "bits representing a key= ", but a ASN.1 BIT STRING value (having DER encoding, btw, please forget ab= out other *ERs). And thus we have this definition of KeyHash:

KeyHash =3D SHA-1 hash of ASN.1 BIT STRING DER encoded object without ta= g and length ASN.1 blocks (=3D> hash of pure ASN.1 BIT STRING DER encode= d "Value" block, with "unused bits" byte)

Again: the "responder's public key" is NOT an "abstract bits representin= g a key", but an ASN.1 BIT STRING DER encoded object. Nowhere in RFC6960 st= ated other description of "responder's public key". 

The RFC6960 (as any other RFC, I do hope so) is a strictly technical doc= umentation. It is not about "guessing" but a technical description. And the= RFC has two different (from technical perspective) descriptions of the sam= e ASN.1 type KeyHash.


Best regards,

Yury Strozhevsky


Erwann Abalea =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-= 16 15:31:

Bonjour Yuri,
 
ASN.1 and encoding rules are different but related standards. Therefor= e, yes, the encoding is not part of the ASN.1 object.
 
If your bit string is of length 0 (i.e. is empty), then its DER encodi= ng will still have this "unused bits" part (and the encoding is then "03 01= 00"). Yet, your object is empty, so this octet is not part of it, it's onl= y here to help correctly represent it on the wire because the chosen encodi= ng rules express lengths in octets. See it as an extension to the L field i= n the TLV triplet.
Please refer to X.690 clause 8.6.2 to see the difference between the c= ontent octets composing the primitive encoding and the bit string value.
 
If we had used the PER encoding, this "unused bits" element would= n't exist (because PER encodes the length in bits for this object type). Th= e example given in my first email, encoded in PER, gives "35 00000000000000= ", and its encoding could lose 3 bits depending on the variant (UNALIGNED v= s ALIGNED) and the object encoded right after it.
 
If XER encoding had be chosen, there wouldn't be any L field, and the = bits themselves would be encoded as individual characters (0 or 1).

Le sam. 16 mai 2020 à&n= bsp;07:22, <y= ury@strozhevsky.com> a écrit :

Hello Erwann!

Could you, please, explain "the first octet (unused bits) is not part of= the ASN.1 object, it's only part of its encoding"? Encoding is not a part = of ASN.1 object?

You are saying "is not part of the ASN.1 object" but right before it sai= d "the first octet". First octet is not a part of BIT STRING value?


Best regards,

Yury Strozhevsky


Erwann Abalea =D0=BF=D0= =B8=D1=81=D0=B0=D0=BB 2020-05-16 04:52:

I also think the errata is editorial.
 
In a BIT STRING encoding, the first octet (unused bits) i= s not part of the ASN.1 object, it's only part of its encoding.
 
The following hex strings are all valid BER encodings for= a BIT STRING composed of 53 bits set to zero:
03 08 03 00000000000000
03 08 03 00000000000007
23 0D 03 02 00 00 03 07 03 000000000000
23 0D 03 02 00 00 03 07 03 000000000007
23 80 03 05 00 00000000 03 04 03 000000 0000
23 80 03 05 00 00000000 03 04 03 000007 0000
 
What is hashed is not the different encodings, but the BI= T STRING value.
In the preceding examples, only the first one is a valid = DER encoding. And if you hash the 7 octets after the "unused bits" octet, y= ou'll obtain a wrong hash, because the value is 53 bits long, not 56.

Le jeu. 14 mai 2020 à 19:11, <yury@strozhevsky.com> = a écrit :
Hell= o All,

Let me explain some details. Firstly I need to say that I= already wrote
a couple of mails to RFC6960 authors and discussed it = a little. From
these discussions I got that before we would start our= discussion I need
to provide you some technical details.

= the main problem is that in RFC6960 there are two different description for the same type KeyHash. First description is in 4.2.1 "ASN.1
Sp= ecification of the OCSP Response" of RFC6960:

    KeyH= ash ::=3D OCTET STRING -- SHA-1 hash of responder's public key
  =   (excluding the tag and length fields)

And second is from = Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of
RFC6960:

Key= Hash ::=3D OCTET STRING -- SHA-1 hash of responder's public key
 =                     &nbs= p;   -- (i.e., the SHA-1 hash of the value of the
    &= nbsp;                    = -- BIT STRING subjectPublicKey [excluding
       =                   -- the tag,= length, and number of unused
           = ;               -- bits] in the responde= r's certificate)

Then I need to clarify why these two descriptio= ns are not the same.
Firstly I need to describe ASN.1 type BIT STRING= =2E As all other ASN.1
types BIT STRING consists of three main parts:= "Tag", "Length" and
"Value" (TLV). But a specific for BIT STRING is = that "Value" itself
devided on two parts: first byte designates "unus= ed bits" (this value
could be 0-7) and the rest is bits describing bi= ts.
So, when we are saying "SHA-1 hash of responder's key (excluding t= he tag
and length fields)" we do assume that SHA-1 hash should be for= BIT
STRING ASN.1 value excluding the "Tag" and "Length" fields (resp= onder's
key has type BIT STRING). Thus the SHA-1 hash should be for e= ntire
"Value" block of BIT STRING, with "unused bits" byte (the very = first
byte in BIT STRING "Value" block).

In opposite when = we are saying " the SHA-1 hash of the value of the BIT
STRING subject= PublicKey [excluding the tag, length, and number of unused
bits] in t= he responder's certificate" we do assume that SHA-1 hash
should be fo= r BIT STRING ASN.1 value excluding Tag, Length and the very
first byt= e from "Value" (unused bits).

Do you understand that two SHA-1 h= ashes made using these two
descriptions of KeyHash would be different= ? Or I would need to provide
you a real example with responder's publ= ic key values? Feel free to ask
me for the example.

As a c= onclusion: the RFC6960 has two descriptions of the same type and a
ha= sh produced using these two descriptions would have different values.
This is a mistake. I do not really care how you would fix it and what
description for KeyHash is correct. But I want to have a correct
st= andard for OCSP.

As an addition I found that Appendix B.1 and Ap= pendix B.2 have different
description for KeyHash. It is the same ASN= =2E1 description, but different
in comment describing the SHA-1 calcu= lation process. The Appendix B.2,
in fact, describes KeyHash calculat= ion similar with RFC2560. But
Appendix B.1 describes new way of KeyHa= sh calculation. Even if these two
appendicies are not aligned allows = me to consider the errata change as
"technical".

Moreover,= RFC6960 changes OCSP protocol in part of KeyHash calculation,
but it= is never stated in any part of RFC6960. So, even if someone says
"ca= lculation is obvious" but the problem that for KeyHash there is
"spec= ifying comment". And exactly that "specifying comment" clearly
specif= y how to calculate KeyHash. But in RFC6960 there are two different
"w= ays of calculating KeyHash" (two different "specifying comments").
Th= is is also not an "editorial problem", this is clearly a problem in
t= echnical description.

Best regards,
Yury Strozhevsky
<= br />

Stefan Santesson =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-05-11= 16:59:
> I respond to all of these erratas collectivey (which I be= lieve should
> be consolidated to 1 and not 3 erratas)
> > I think the observation is correct, but I think it is editorial ra= ther
> than technical.
>
> The normative text is t= hat the KeyHash is the hash of the public key.
> This is in itself = clear an unambiguous.
> The imperfection here is not in the normati= ve text, but in the
> explanation where the explanation in B.1 is t= he most accurate and
> detaild.
> The other shorter explana= tions 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
>
> <= br />> I think this is editorial
>
>
>
&= gt; Stefan Santesson
>
> On 2020-05-11, 14:16, "RFC Errata= System" <rfc-editor@rfc-editor.org>
> wrote:
>
>&= nbsp;    The following errata report has been submitted for RFC69= 60,
>     "X.509 Internet Public Key Infrastructure = Online Certificate
> Status Protocol - OCSP".
>
>&= nbsp;    --------------------------------------
>  &= nbsp;  You may review the report below and at:
>    =  https://www.rfc-editor.org/errata/eid6165
>
>     ---------------------------------= -----
>     Type: Technical
>    &= nbsp;Reported by: Yury Strozhevsky <
yury@strozhevsky.com>
>
>= ;     Section: 1
>
>     Ori= ginal Text
>     -------------
>   = ;  ---
>
>     Corrected Text
>= ;     --------------
>        o&= nbsp; Appendix B.1 provides correct KeyHash type processing
> descr= iption. Now SHA-1 hash must be calculated for responder's public
> = key ASN.1 value without tag, length and unused bits.
>
> <= br />>     Notes
>     -----
= >     The RFC6960 changes OCSP protocol in part of KeyHas= h type
> calculation. In RFC2560 there is the description:
>= ;        KeyHash ::=3D OCTET STRING -- SHA-1 hash of re= sponder's public key
>        (excluding the ta= g and length fields)
>
>     But in Appendi= x B.1, which is the major OCSP descriptive module,
> stated:
= >     KeyHash ::=3D OCTET STRING -- SHA-1 hash of respond= er's public key
>              &= nbsp;               -- (i.e., the SHA-1 = hash of the value of
> the
>        &n= bsp;                     = -- BIT STRING subjectPublicKey [excluding
>      &nb= sp;                     &= nbsp; -- the tag, length, and number of unused
>     = ;                     &nb= sp;   -- bits] in the responder's certificate)
>
>&nb= sp;    The difference is in what would be under SHA-1 hash. In RF= C2560
> KeyHash would be calculated for entire BIT STRING value, wi= th "unused
> bits" byte (first byte in BIT STRING value), but Appen= dix 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". I= f necessary,
> please
>     use "Reply All"= to discuss whether it should be verified or
>     r= ejected. When a decision is reached, the verifying party
>  &n= bsp;  can log in to change the status and edit the report, if necessar= y.
>
>     --------------------------------= ------
>     RFC6960 (draft-ietf-pkix-rfc2560bis-20)=
>     --------------------------------------
&= gt;     Title             = ;  : X.509 Internet Public Key Infrastructure
> Online Certifi= cate Status Protocol - OCSP
>     Publication Date&n= bsp;   : June 2013
>     Author(s)   =        : S. Santesson, M. Myers, R. Ankney, A.
&g= t; Malpani, S. Galperin, C. Adams
>     Category&nbs= p;           : PROPOSED STANDARD
>  &= nbsp;  Source              : Public= -Key Infrastructure (X.509)
>     Area    =             : Security
>   =  Stream              : IETF
&= gt;     Verifying Party     : IESG

_______________________________________________
pkix mailing list
pkix@ietf.org
https://www.ietf.org/mailman/listinfo/pkix<= /blockquote>
--
Erwann.



 
--
Erwann.


--=_3a6860d0207719b91904541887c99128-- From nobody Sun May 31 22:22:05 2020 Return-Path: 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 22C143A0A35 for ; Mon, 18 May 2020 02:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 hxmFXaP7wnqd for ; Mon, 18 May 2020 02:39:17 -0700 (PDT) Received: from spl3.hosting.reg.ru (spl3.hosting.reg.ru [31.31.196.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D4FF3A0A32 for ; Mon, 18 May 2020 02:39:16 -0700 (PDT) Received: from webmail.hosting.reg.ru (webmail.hosting.reg.ru [37.140.192.176]) (Authenticated sender: yury@strozhevsky.com) by spl3.hosting.reg.ru (Postfix) with ESMTPA id F2BAE17E0817; Mon, 18 May 2020 12:39:12 +0300 (MSK) MIME-Version: 1.0 Date: Mon, 18 May 2020 12:39:12 +0300 From: yury@strozhevsky.com To: Stefan Santesson Cc: Erwann Abalea , RFC Errata System , ambarish@gmail.com, cadams@eecs.uottawa.ca, kaduk@mit.edu, Stephen Kent , mmyers@fastq.com, none@rfc-editor.org, pkix@ietf.org, rdd@cert.org, slava.galperin@gmail.com, sts@aaa-sec.com In-Reply-To: <475D361F-8875-445F-96CA-5A4F85477D38@aaa-sec.com> References: <20200511121547.17072F4071E@rfc-editor.org> <2013D511-BCF9-4D2C-9331-AA8203235F5F@aaa-sec.com> <56396ec5c59f0f9b372e79612bf0b13b@strozhevsky.com> <475D361F-8875-445F-96CA-5A4F85477D38@aaa-sec.com> User-Agent: Roundcube Webmail/1.4.3 Message-ID: X-Sender: yury@strozhevsky.com Content-Type: multipart/alternative; boundary="=_98c02852bc4a94812e3563f855f43ac0" X-PPP-Message-ID: <20200518093913.19485.57958@spl3.hosting.reg.ru> X-PPP-Vhost: strozhevsky.com Archived-At: X-Mailman-Approved-At: Sun, 31 May 2020 22:21:59 -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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 May 2020 09:39:21 -0000 --=_98c02852bc4a94812e3563f855f43ac0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8; format=flowed Stefan, 1) Responder's public key is a pure ASN.1 object having type BIT STRING using DER encoding rules; 2) Calculation for KeyHash initially was described as " SHA-1 hash of responder's public key (excluding the tag and length fields)"; 3) Then having item 1 in mind we have calculation for KeyHash as "SHA-1 hash of ASN.1 BIT STRING using DER encoding rules (excluding the tag and length fields)"; 4) ASN.1 BIT STRING without tag and length fields has only "value" field (with "unused bits" byte at the beginning); 5) Having items 3 and 4 in mind have calculation for KeyHash as "SHA-1 hash of ASN.1 BIT STRING "value" field" (with "unused bits" byte at the beginning); Please do not say me a word about "encoding is not a part of ASN.1 object" - it is a part of ASN.1 object. If you do believe that "encoding is not a part of ASN.1 object" then imagine a situation when any standard says "hash entire BIT STRING ASN.1 object" (with all these "tag", "length" and "value" blocks). Then what you would hash? All but "unused bits" octet, which is "not a part of ASN.1 object"? Or imagine in a standard has a sentences like "BER encoding allowed" and in BIT STRING there has contructed encoding for TAG block? What you would hash? All except specific bytes in tag encoding? Or anything else? Standard should be very clear from technical perspective. If I am wrong then show me an errors in my conclusions. At the moment I have not heard any from anyone. Best regards, Yury Strozhevsky Stefan Santesson писал 2020-05-18 12:14: > Yury, > > I don't believe that you would settle with an even "better" explanation, so I won't attempt one. > > I hope the rest of us can agree that the standard text clearly intends to say that the hash is calculated over the unencoded object and not its encoding. > > This is less perfectly described in the general text and more accurately described in the normative ASN.1 comment. > > Let's just settle with editorial and put this one to rest. > > Stefan Santesson > > From: > Date: Monday, 18 May 2020 at 07:49 > To: Erwann Abalea > Cc: RFC Errata System , Stefan Santesson , , , , Stephen Kent , , , , , , > Subject: Re: [pkix] [Technical Errata Reported] RFC6960 (6165) > > Hello Erwan, > > The deal it that in case of RFC6960 we have not an abstract "hash something", but a direct explanation that should be hashed ASN.1 BIT STRING without tag and length. > > KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key > (excluding the tag and length fields) > > The "responder's public key" is NOT an abstract "bits representing a key", but a ASN.1 BIT STRING value (having DER encoding, btw, please forget about other *ERs). And thus we have this definition of KeyHash: > > KeyHash = SHA-1 hash of ASN.1 BIT STRING DER encoded object without tag and length ASN.1 blocks (=> hash of pure ASN.1 BIT STRING DER encoded "Value" block, with "unused bits" byte) > > Again: the "responder's public key" is NOT an "abstract bits representing a key", but an ASN.1 BIT STRING DER encoded object. Nowhere in RFC6960 stated other description of "responder's public key". > > The RFC6960 (as any other RFC, I do hope so) is a strictly technical documentation. It is not about "guessing" but a technical description. And the RFC has two different (from technical perspective) descriptions of the same ASN.1 type KeyHash. > > Best regards, > > Yury Strozhevsky > > Erwann Abalea писал 2020-05-16 15:31: > > Bonjour Yuri, > > ASN.1 and encoding rules are different but related standards. Therefore, yes, the encoding is not part of the ASN.1 object. > > If your bit string is of length 0 (i.e. is empty), then its DER encoding will still have this "unused bits" part (and the encoding is then "03 01 00"). Yet, your object is empty, so this octet is not part of it, it's only here to help correctly represent it on the wire because the chosen encoding rules express lengths in octets. See it as an extension to the L field in the TLV triplet. > > Please refer to X.690 clause 8.6.2 to see the difference between the content octets composing the primitive encoding and the bit string value. > > If we had used the PER encoding, this "unused bits" element wouldn't exist (because PER encodes the length in bits for this object type). The example given in my first email, encoded in PER, gives "35 00000000000000", and its encoding could lose 3 bits depending on the variant (UNALIGNED vs ALIGNED) and the object encoded right after it. > > If XER encoding had be chosen, there wouldn't be any L field, and the bits themselves would be encoded as individual characters (0 or 1). > > Le sam. 16 mai 2020 à 07:22, a écrit : > > Hello Erwann! > > Could you, please, explain "the first octet (unused bits) is not part of the ASN.1 object, it's only part of its encoding"? Encoding is not a part of ASN.1 object? > > You are saying "is not part of the ASN.1 object" but right before it said "the first octet". First octet is not a part of BIT STRING value? > > Best regards, > > Yury Strozhevsky > > Erwann Abalea писал 2020-05-16 04:52: > > I also think the errata is editorial. > > In a BIT STRING encoding, the first octet (unused bits) is not part of the ASN.1 object, it's only part of its encoding. > > The following hex strings are all valid BER encodings for a BIT STRING composed of 53 bits set to zero: > > 03 08 03 00000000000000 > > 03 08 03 00000000000007 > > 23 0D 03 02 00 00 03 07 03 000000000000 > > 23 0D 03 02 00 00 03 07 03 000000000007 > > 23 80 03 05 00 00000000 03 04 03 000000 0000 > > 23 80 03 05 00 00000000 03 04 03 000007 0000 > > What is hashed is not the different encodings, but the BIT STRING value. > > In the preceding examples, only the first one is a valid DER encoding. And if you hash the 7 octets after the "unused bits" octet, you'll obtain a wrong hash, because the value is 53 bits long, not 56. > > Le jeu. 14 mai 2020 à 19:11, a écrit : > > Hello All, > > Let me explain some details. Firstly I need to say that I already wrote > a couple of mails to RFC6960 authors and discussed it a little. From > these discussions I got that before we would start our discussion I need > to provide you some technical details. > > the main problem is that in RFC6960 there are two different description > for the same type KeyHash. First description is in 4.2.1 "ASN.1 > Specification of the OCSP Response" of RFC6960: > > KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key > (excluding the tag and length fields) > > And second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of > RFC6960: > > 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) > > Then I need to clarify why these two descriptions are not the same. > Firstly I need to describe ASN.1 type BIT STRING. As all other ASN.1 > types BIT STRING consists of three main parts: "Tag", "Length" and > "Value" (TLV). But a specific for BIT STRING is that "Value" itself > devided on two parts: first byte designates "unused bits" (this value > could be 0-7) and the rest is bits describing bits. > So, when we are saying "SHA-1 hash of responder's key (excluding the tag > and length fields)" we do assume that SHA-1 hash should be for BIT > STRING ASN.1 value excluding the "Tag" and "Length" fields (responder's > key has type BIT STRING). Thus the SHA-1 hash should be for entire > "Value" block of BIT STRING, with "unused bits" byte (the very first > byte in BIT STRING "Value" block). > > In opposite when we are saying " 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" we do assume that SHA-1 hash > should be for BIT STRING ASN.1 value excluding Tag, Length and the very > first byte from "Value" (unused bits). > > Do you understand that two SHA-1 hashes made using these two > descriptions of KeyHash would be different? Or I would need to provide > you a real example with responder's public key values? Feel free to ask > me for the example. > > As a conclusion: the RFC6960 has two descriptions of the same type and a > hash produced using these two descriptions would have different values. > This is a mistake. I do not really care how you would fix it and what > description for KeyHash is correct. But I want to have a correct > standard for OCSP. > > As an addition I found that Appendix B.1 and Appendix B.2 have different > description for KeyHash. It is the same ASN.1 description, but different > in comment describing the SHA-1 calculation process. The Appendix B.2, > in fact, describes KeyHash calculation similar with RFC2560. But > Appendix B.1 describes new way of KeyHash calculation. Even if these two > appendicies are not aligned allows me to consider the errata change as > "technical". > > Moreover, RFC6960 changes OCSP protocol in part of KeyHash calculation, > but it is never stated in any part of RFC6960. So, even if someone says > "calculation is obvious" but the problem that for KeyHash there is > "specifying comment". And exactly that "specifying comment" clearly > specify how to calculate KeyHash. But in RFC6960 there are two different > "ways of calculating KeyHash" (two different "specifying comments"). > This is also not an "editorial problem", this is clearly a problem in > technical description. > > Best regards, > Yury Strozhevsky > > Stefan Santesson писал 2020-05-11 16:59: >> 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" >> 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 >> >> 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 > > _______________________________________________ > pkix mailing list > pkix@ietf.org > https://www.ietf.org/mailman/listinfo/pkix > > -- > > Erwann. -- Erwann. --=_98c02852bc4a94812e3563f855f43ac0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Stefan,

1) Responder's public key is a pure ASN.1 object having type BIT STRING = using DER encoding rules;

2) Calculation for KeyHash initially was described as " SHA-1 hash of re= sponder's public key (excluding the tag and length fields)";

3) Then having item 1 in mind we have calculation for KeyHash as "SHA-1 = hash of ASN.1 BIT STRING using DER encoding rules (excluding the tag and le= ngth fields)";

4) ASN.1 BIT STRING without tag and length fields has only "value" field= (with "unused bits" byte at the beginning);

5) Having items 3 and 4 in mind have calculation for KeyHash as "SHA-1 h= ash of ASN.1 BIT STRING "value" field" (with "unused bits" byte at the begi= nning);


Please do not say me a word about "encoding is not a part of ASN.1 objec= t" - it is a part of ASN.1 object. If you do believe that "encoding is not = a part of ASN.1 object" then imagine a situation when any standard says "ha= sh entire BIT STRING ASN.1 object" (with all these "tag", "length" and "val= ue" blocks). 

Then what you would hash? All but "unused bits" octet, which is "not a p= art of ASN.1 object"? 

Or imagine in a standard has a sentences like "BER encoding allowed" and= in BIT STRING there has contructed encoding for TAG block? What you would = hash? All except specific bytes in tag encoding? Or anything else?

Standard should be very clear from technical perspective. If I am wrong = then show me an errors in my conclusions. At the moment I have not heard an= y from anyone.


Best regards,

Yury Strozhevsky



Stefan Santesson =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-= 05-18 12:14:

Yury,=

 = ;

I don= 't believe that you would settle with an even "better" explanation, so I wo= n't attempt one.

 = ;

I hop= e the rest of us can agree that the standard text clearly intends to say th= at the hash is calculated over the unencoded object and not its encoding.

This = is less perfectly described in the general text and more accurately describ= ed in the normative ASN.1 comment.

 = ;

Let's= just settle with editorial and put this one to rest.

 = ;

Stefan Santesson

 = ;

From: <yury@strozhevsky.com>
Date: Monday, 18 May = 2020 at 07:49
To: Erwann Abalea <eabalea@gmail.com= >
Cc: RFC Errata System <rfc-editor@rfc-editor= =2Eorg>, Stefan Santesson <stefan@aaa-sec.com>, <ambarish@gmail= =2Ecom>, <cadams@eecs.uottawa.ca>, <kaduk@mit.edu>, Stephen = Kent <kent@bbn.com>, <mmyers@fastq.com>, <none@rfc-editor.or= g>, <pkix@ietf.org>, <rdd@cert.org>, <slava.galperin@gmai= l.com>, <sts@aaa-sec.com>
Subject: Re: [pkix= ] [Technical Errata Reported] RFC6960 (6165)

 

Hello Erwan,

The deal it that in case of RFC6960 we have not an abstract "hash someth= ing", but a direct explanation that should be hashed ASN.1 BIT STRING witho= ut tag and length. 

KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's public key
=     (excluding the tag and length fields)

The "responder's public key" is NOT an abstract "bits representing a key= ", but a ASN.1 BIT STRING value (having DER encoding, btw, please forget ab= out other *ERs). And thus we have this definition of KeyHash:

KeyHash =3D SHA-1 hash of ASN.1 BIT STRING DER encoded object without ta= g and length ASN.1 blocks (=3D> hash of pure ASN.1 BIT STRING DER encode= d "Value" block, with "unused bits" byte)

Again: the "responder's public key" is NOT an "abstract bits representin= g a key", but an ASN.1 BIT STRING DER encoded object. Nowhere in RFC6960 st= ated other description of "responder's public key". 

The RFC6960 (as any other RFC, I do hope so) is a strictly technical doc= umentation. It is not about "guessing" but a technical description. And the= RFC has two different (from technical perspective) descriptions of the sam= e ASN.1 type KeyHash.


Best regards,

Yury Strozhevsky


Erwann Abalea =D0=BF=D0=B8=D1=81=D0=B0=D0=BB 2020-0= 5-16 15:31:

Bonjour Yuri,

 

ASN.1 and encoding rules are different but related= standards. Therefore, yes, the encoding is not part of the ASN.1 object.

 

If your bit string is of length 0 (i.e. is empty),= then its DER encoding will still have this "unused bits" part (and the enc= oding is then "03 01 00"). Yet, your object is empty, so this octet is not = part of it, it's only here to help correctly represent it on the wire becau= se the chosen encoding rules express lengths in octets. See it as an extens= ion to the L field in the TLV triplet.

Please refer to X.690 clause 8.6.2 to see the diff= erence between the content octets composing the primitive encoding and the = bit string value.

 

If we had used the PER encoding, this "unused= bits" element wouldn't exist (because PER encodes the length in bits for t= his object type). The example given in my first email, encoded in PER, give= s "35 00000000000000", and its encoding could lose 3 bits depending on the = variant (UNALIGNED vs ALIGNED) and the object encoded right after it.

 

If XER encoding had be chosen, there wouldn't be a= ny L field, and the bits themselves would be encoded as individual characte= rs (0 or 1).

 

Le sam. 16 mai 2020 à 07:22, <= yury@strozhevsky= =2Ecom> a écrit :

He= llo Erwann!

Co= uld you, please, explain "the first octet (unused bits) is not part of the = ASN.1 object, it's only part of its encoding"? Encoding is not a part of AS= N.1 object?

Yo= u are saying "is not part of the ASN.1 object" but right before it said "th= e first octet". First octet is not a part of BIT STRING value?

&n= bsp;

Be= st regards,

Yu= ry Strozhevsky

&n= bsp;

Erwann Abalea =D0=BF=D0=B8= =D1=81=D0=B0=D0=BB 2020-05-16 04:52:

I also think the errata is editorial.

 

In a BIT STRING encoding, the first octet (unused bits)= is not part of the ASN.1 object, it's only part of its encoding.

 

The following hex strings are all valid BER encodings f= or a BIT STRING composed of 53 bits set to zero:

03 08 03 00000000000000

03 08 03 00000000000007

23 0D 03 02 00 00 03 07 03 000000000000

23 0D 03 02 00 00 03 07 03 000000000007

23 80 03 05 00 00000000 03 04 03 000000 0000

23 80 03 05 00 00000000 03 04 03 000007 0000

 

What is hashed is not the different encodings, but the = BIT STRING value.

In the preceding examples, only the first one is a vali= d DER encoding. And if you hash the 7 octets after the "unused bits" octet,= you'll obtain a wrong hash, because the value is 53 bits long, not 56.

 

Le jeu. 14 mai 2020 à 19:11, <yury@strozhevsky.com&g= t; a écrit :

Hello All,

Let me explain some details. Firs= tly I need to say that I already wrote
a couple of mails to RFC6960 a= uthors and discussed it a little. From
these discussions I got that b= efore we would start our discussion I need
to provide you some techni= cal details.

the main problem is that in RFC6960 there are two d= ifferent description
for the same type KeyHash. First description is = in 4.2.1 "ASN.1
Specification of the OCSP Response" of RFC6960:
=
    KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder's= public key
    (excluding the tag and length fields)
<= br />And second is from Appendix B.1 "OCSP in ASN.1 - 1998 Syntax" of
RFC6960:

KeyHash ::=3D OCTET STRING -- SHA-1 hash of responder'= s public key
                &= nbsp;         -- (i.e., the SHA-1 hash of the value of = the
                  &nb= sp;       -- BIT STRING subjectPublicKey [excluding
&nb= sp;                     &= nbsp;   -- the tag, length, and number of unused
    &n= bsp;                     = -- bits] in the responder's certificate)

Then I need to clarify = why these two descriptions are not the same.
Firstly I need to descri= be ASN.1 type BIT STRING. As all other ASN.1
types BIT STRING consist= s of three main parts: "Tag", "Length" and
"Value" (TLV). But a speci= fic for BIT STRING is that "Value" itself
devided on two parts: first= byte designates "unused bits" (this value
could be 0-7) and the rest= is bits describing bits.
So, when we are saying "SHA-1 hash of respon= der's key (excluding the tag
and length fields)" we do assume that SH= A-1 hash should be for BIT
STRING ASN.1 value excluding the "Tag" and= "Length" fields (responder's
key has type BIT STRING). Thus the SHA-= 1 hash should be for entire
"Value" block of BIT STRING, with "unused= bits" byte (the very first
byte in BIT STRING "Value" block).
<= br />In opposite when we are saying " the SHA-1 hash of the value of the BI= T
STRING subjectPublicKey [excluding the tag, length, and number of u= nused
bits] in the responder's certificate" we do assume that SHA-1 h= ash
should be for BIT STRING ASN.1 value excluding Tag, Length and th= e very
first byte from "Value" (unused bits).

Do you under= stand that two SHA-1 hashes made using these two
descriptions of KeyH= ash would be different? Or I would need to provide
you a real example= with responder's public key values? Feel free to ask
me for the exam= ple.

As a conclusion: the RFC6960 has two descriptions of the sa= me type and a
hash produced using these two descriptions would have d= ifferent values.
This is a mistake. I do not really care how you woul= d fix it and what
description for KeyHash is correct. But I want to h= ave a correct
standard for OCSP.

As an addition I found th= at Appendix B.1 and Appendix B.2 have different
description for KeyHa= sh. It is the same ASN.1 description, but different
in comment descri= bing the SHA-1 calculation process. The Appendix B.2,
in fact, descri= bes KeyHash calculation similar with RFC2560. But
Appendix B.1 descri= bes new way of KeyHash calculation. Even if these two
appendicies are= not aligned allows me to consider the errata change as
"technical"= =2E

Moreover, RFC6960 changes OCSP protocol in part of KeyHash c= alculation,
but it is never stated in any part of RFC6960. So, even i= f someone says
"calculation is obvious" but the problem that for KeyH= ash there is
"specifying comment". And exactly that "specifying comme= nt" clearly
specify how to calculate KeyHash. But in RFC6960 there ar= e two different
"ways of calculating KeyHash" (two different "specify= ing comments").
This is also not an "editorial problem", this is clea= rly a problem in
technical description.

Best regards,
Yury Strozhevsky



Stefan Santesson =D0=BF=D0=B8=D1= =81=D0=B0=D0=BB 2020-05-11 16:59:
> I respond to all of these errat= as collectivey (which I believe should
> be consolidated to 1 and n= ot 3 erratas)
>
> I think the observation is correct, but = I think it is editorial rather
> than technical.
>
&g= t; 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 t= he 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 defi= nition 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>
> wr= ote:
>
>     The following errata report ha= s been submitted for RFC6960,
>     "X.509 Internet = Public Key Infrastructure Online Certificate
> Status Protocol - OC= SP".
>
>     ------------------------------= --------
>     You may review the report below and a= t:
>     https://www.rfc-ed= itor.org/errata/eid6165
>
>     -------= -------------------------------
>     Type: Technica= l
>     Reported by: Yury Strozhevsky <yury@strozhevsky.com&g= t;
>
>     Section: 1
>
>&= nbsp;    Original Text
>     -------------=
>     ---
>
>     C= orrected Text
>     --------------
>  &= nbsp;     o  Appendix B.1 provides correct KeyHash type proc= essing
> description. Now SHA-1 hash must be calculated for respond= er's public
> key ASN.1 value without tag, length and unused bits= =2E
>
>
>     Notes
> = ;    -----
>     The RFC6960 changes OCSP = protocol in part of KeyHash type
> calculation. In RFC2560 there is= the description:
>        KeyHash ::=3D OCTET = STRING -- SHA-1 hash of responder's public key
>     = ;   (excluding the tag and length fields)
>
>  &= nbsp;  But in Appendix B.1, which is the major OCSP descriptive module= ,
> stated:
>     KeyHash ::=3D OCTET STRIN= G -- SHA-1 hash of responder's public key
>      &nb= sp;                     &= nbsp; -- (i.e., the SHA-1 hash of the value of
> the
>&nbs= p;                     &n= bsp;       -- BIT STRING subjectPublicKey [excluding
&g= t;                    &nb= sp;         -- the tag, length, and number of unused>                   = ;           -- bits] in the responder's certificat= e)
>
>     The difference is in what would = be under SHA-1 hash. In RFC2560
> KeyHash would be calculated for e= ntire BIT STRING value, with "unused
> bits" byte (first byte in BI= T STRING value), but Appendix B.1 in
> RFC6960 states that SHA-1 ha= sh must be calculated for BIT STRING value
> without "unused bits"= =2E
>
>     Instructions:
>  &= nbsp;  -------------
>     This erratum is curr= ently posted as "Reported". If necessary,
> please
> =    use "Reply All" to discuss whether it should be verified or>     rejected. When a decision is reached, the verif= ying party
>     can log in to change the status and= edit the report, if necessary.
>
>     ---= -----------------------------------
>     RFC6960 (d= raft-ietf-pkix-rfc2560bis-20)
>     ----------------= ----------------------
>     Title    &nbs= p;          : X.509 Internet Public Key Infrastruc= ture
> Online Certificate Status Protocol - OCSP
>  &n= bsp;  Publication Date    : June 2013
>   =  Author(s)           : S. Santesson, M= =2E Myers, R. Ankney, A.
> Malpani, S. Galperin, C. Adams
>=      Category            : PRO= POSED STANDARD
>     Source      &nbs= p;       : Public-Key Infrastructure (X.509)
> =    Area                := Security
>     Stream        &n= bsp;     : IETF
>     Verifying Party = ;    : IESG

__________________________________________= _____
pkix mailing list
pkix@ietf.org
https://www.iet= f.org/mailman/listinfo/pkix

--

Erwann.

&n= bsp;

 

 

--

Erwann.



--=_98c02852bc4a94812e3563f855f43ac0--