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" <[email protected]>
> 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 <[email protected]>
>
> 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
[email protected]
https://www.ietf.org/mailman/listinfo/pkix
lmpx.com only provides a reader for public news (NNTP) servers. It is not
affiliated with the servers or forums shown here and is not responsible for
the content of articles, which is written by their respective authors.