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

[Erwann Abalea <[e-mail]>]

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, <[e-mail]> 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" <[e-mail]>
> > 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 <[e-mail]>
> >
> >     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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/pkix
>
-- 
Erwann.