[openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled

[Blumenthal, Uri - 0553 - MITLL via RT]

Considering emerging attacks against UEFI I'd be hesitant weakening protection mechanisms, even those that *currently* aren't likely to be used.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: David Woodhouse via RT
Sent: Friday, August 7, 2015 10:56
Reply To: rt at openssl.org
Cc: openssl-dev at openssl.org
Subject: Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed	Certificate Timestamps to be disabled

On Fri, 2015-08-07 at 08:58 +0000, Ben Laurie via RT wrote:
> I am curious why you think you don't need CT for UEFI?

The use case for OpenSSL within UEFI is for Secure Boot — checking
PKCs#7 signatures on bootloader / operating system images.

Referring to RFC6962...

Abstract

This document describes an experimental protocol for publicly logging
the existence of Transport Layer Security (TLS) certificates as they
are issued or observed, in a manner that allows anyone to audit
certificate authority (CA) activity and notice the issuance of
suspect certificates as well as to audit the certificate logs
themselves. The intent is that eventually clients would refuse to
honor certificates that do not appear in a log, effectively forcing
CAs to add all issued certificates to the logs.


I don't really see a viable use case for this in the UEFI environment.

We don't have a way to get these (hypothetical) logs of validly issued
certificates into the firmware. We certainly don't normally have the
facility to perform HTTPS requests prior to booting the OS.

I realise that this scheme allows for asynchronous verification, but it
would be utterly pointless to devise a complex scheme for interaction
between the firmware and the booted OS, when the whole point is that
the OS *isn't* trustworthy if that signature wasn't valid. Even aside
from the general rule that *anything* we implement like that, some
idiot will break when they do their "value subtract" to the standard
open source UEFI offering.

-- 
David Woodhouse Open Source Technology Centre
David.Woodhouse at intel.com Intel Corporation



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150807/e39b9a39/attachment.bin>