httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kahn Gillmor <>
Subject Re: mod_ssl-2.4.x-certkeyfile and OCSPStapling
Date Sun, 09 Feb 2014 19:55:12 GMT
On 02/05/2014 02:44 AM, Kaspar Brand wrote:
> On 05.02.2014 08:25, Brian Smith wrote:
>> It would be possible for a server to fetch and staple the OCSP
>> response only using the information from the server's end-entity
>> certificate.
> Actually no - you can't properly fill in the CertID for the request
> otherwise. From RFC 6960:
>>    Request         ::=     SEQUENCE {
>>        reqCert                     CertID,
>>        singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }
>>    CertID          ::=     SEQUENCE {
>>        hashAlgorithm       AlgorithmIdentifier,
>>        issuerNameHash      OCTET STRING, -- Hash of issuer's DN
>>        issuerKeyHash       OCTET STRING, -- Hash of issuer's public key
>>        serialNumber        CertificateSerialNumber }
> and
>>    o  issuerKeyHash is the hash of the issuer's public key.  The hash
>>       shall be calculated over the value (excluding tag and length) of
>>       the subject public key field in the issuer's certificate.
> (relying on the end-entity's AKID extension isn't reliable enough - even
> if it is present, it doesn't necessarily have to be a hash over the
> issuer's public key, that's only a recommendation in RFC 5280 section

furthermore, there are good arguments to be made that the recommendation
in RFC 5280 for the Key ID is actually a bad recommendation, since
hashing only the SPK doesn't include the  algorithm identifier itself
(which would be included if the hash was over the full SPKI instead).

I don't have a concrete attack sorted out, but i can imagine two
separate algorithms which use the same octet string for their SPK, which
result in radically OCSP or other behavior, similar to
Mavrogiannopoulos' cross-protocol attack (which misinterpreted data
across different forms of DHE):


View raw message