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

[David Woodhouse via RT]

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: 5691 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20150807/2c6ac16c/attachment.bin>