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

From: RFC Errata System <[email-masked]>
Date: Mon, 11 May 2020 05:15:47 -0700 (PDT)

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 <[email-masked]>

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: Stefan Santesson <[email-masked]>
Date: Mon, 11 May 2020 15:59:19 +0200

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" <[email-masked]> wrote:

    Section: 1

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

    Corrected Text
    --------------

    Notes
    -----

    Instructions:
    -------------

---

From: [email-masked]
Date: Mon, 11 May 2020 18:12:51 +0300

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:

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

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:
> 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.
>        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:
>     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:
>     -------------
>     Title               : X.509 Internet Public Key Infrastructure
> Online Certificate Status Protocol - OCSP

---

From: Erwann Abalea <[email-masked]>
Date: Sat, 16 May 2020 03:52:38 +0200

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, <[email-masked]> a écrit :

> _______________________________________________
> pkix mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pkix
>
-- 
Erwann.

---

From: Erwann Abalea <[email-masked]>
Date: Sat, 16 May 2020 14:31:20 +0200

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, <[email-masked]> 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:
>

-- 
Erwann.

---

From: Russ Housley <[email-masked]>
Date: Sat, 16 May 2020 09:26:08 -0400

We are talking about the DER encoding (not the BER encoding)

Russ

> On May 15, 2020, at 9:52 PM, Erwann Abalea <[email-masked]> wrote:
> 
> 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
> 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, <[email-masked] <mailto:yury@strozhevsky..com>> a écrit :
> Hello All,
> 
> > On 2020-05-11, 14:16, "RFC Errata System" <[email-masked] <mailto:[email-masked]>> 
> > wrote:
> > 
> >     https://www.rfc-editor.org/errata/eid6165 <https://www.rfc-editor.org/errata/eid6165>
> > 
> >     Reported by: Yury Strozhevsky <[email-masked] <mailto:[email-masked]>>
> > 
> >     Section: 1
> > 
> >     Original Text
> >     -------------
> >     ---
> > 
> >     Corrected Text
> >     --------------
> >     The difference is in what would be under SHA-1 hash.. In RFC2560
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/pkix <https://www.ietf.org/mailman/listinfo/pkix>
> -- 
> Erwann.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 18 May 2020 11:14:50 +0200

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: <[email-masked]>
Date: Monday, 18 May 2020 at 07:49
To: Erwann Abalea <[email-masked]>
Cc: RFC Errata System <[email-masked]>, Stefan Santesson <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, Stephen Kent <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
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. 

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).

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

03 08 03 00000000000000

03 08 03 00000000000007

Hello All,

Best regards,
Yury Strozhevsky

-- 

Erwann.

-- 

Erwann.

---

From: Russ Housley <[email-masked]>
Date: Mon, 18 May 2020 13:27:13 -0400

+1

> On May 18, 2020, at 5:14 AM, Stefan Santesson <[email-masked]> wrote:
> 
> Yury,
>  
> From: <[email-masked] <mailto:[email-masked]>>
> To: Erwann Abalea <[email-masked] <mailto:[email-masked]>>
> Cc: RFC Errata System <[email-masked] <mailto:[email-masked]>>, Stefan Santesson <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>, Stephen Kent <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>, <[email-masked] <mailto:[email-masked]>>
>> Le sam. 16 mai 2020 à 07:22, <[email-masked] <mailto:yury@strozhevsky..com>> a écrit :
>>> Hello Erwann!
>>>> 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, <[email-masked] <mailto:[email-masked]>> a écrit :
>>>>> Hello All,
>>>>> 
>>>>> >     "X..509 Internet Public Key Infrastructure Online Certificate
>>>>> > Status Protocol - OCSP".
>>>>> >

---

From: [email-masked]
Date: Mon, 18 May 2020 08:49:37 +0300

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.  

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:

> Le jeu. 14 mai 2020 à 19:11, <[email-masked]> a écrit : Hello All,
> 
> https://www.ietf.org/mailman/listinfo/pkix -- 
> Erwann.

  -- 
Erwann.

---

From: [email-masked]
Date: Mon, 18 May 2020 12:39:12 +0300

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. 
> 
> Let's just settle with editorial and put this one to rest. 
> 
> Stefan Santesson 
> 

--

Erwann.