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

[[e-mail]]

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.