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

[Stefan Santesson <[e-mail]>]

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

 


 

-- 

Erwann.