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
> 4.2.1.2)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): http://www.cosic.esat.kuleuven.be/publications/article-2216.pdf --dkg
signature.asc
Description: OpenPGP digital signature
