done in master.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Mon, 2015-08-10 at 16:11 +, Blumenthal, Uri - 0553 - MITLL wrote:
>
> >You seem to be suggesting that we build in some cryptographic
> >functionality that we admit we have no *idea* how we could sensibly use
> >it, and also build in various extended math library routines that are
> >current
> Yes. But skimping on security features is not a good way to deal with
> software/firmware bloat. And again, attacks on this layer are increasing in
> quantity and sophistication. The current protection mechanisms appear
> insufficient. Draw your own conclusions.
But this isn't a general-purpose
For the sake of brevity I’ll answer to only some of your points (that I
consider relevant to my views or work).
On 8/10/15, 5:44 , "openssl-dev on behalf of David Woodhouse"
wrote:
>UEFI is widely mocked for how bloated it is, given that the job of a sane
>firmware is to boot the operating as qu
Updated patch. fixing a typo that broke the no-rfc3779 support in
util/mkdef.pl
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
>From 03ac2e3a1052c73e030884c2df501c0fe6715e8c Mon Sep 17 00:00:00
On Fri, 2015-08-07 at 15:34 +, Blumenthal, Uri - 0553 - MITLL via
RT wrote:
> Alas, not right now (and here we're in agreement).
>
> However I expect the field to evolve with the threats, and the means
> for using this capability to emerge.
UEFI is widely mocked for how bloated it is, give
, August 7, 2015 10:56
Reply To: r...@openssl.org
Cc: openssl-dev@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 +, Ben Laurie via RT wrote:
> I am curious why you think you don&
, August 7, 2015 10:56
Reply To: r...@openssl.org
Cc: openssl-dev@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 +, Ben Laurie via RT wrote:
> I am curious why you think you don&
, August 7, 2015 10:56
Reply To: r...@openssl.org
Cc: openssl-dev@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 +, Ben Laurie via RT wrote:
> I am curious why you think you don&
e: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed
Certificate Timestamps to be disabled
On Fri, 2015-08-07 at 15:07 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> Considering emerging attacks against UEFI I'd be hesitant weakening
> protection mechanisms, even tho
e: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed
Certificate Timestamps to be disabled
On Fri, 2015-08-07 at 15:07 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> Considering emerging attacks against UEFI I'd be hesitant weakening
> protection mechanisms, even tho
On Fri, 2015-08-07 at 15:07 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> Considering emerging attacks against UEFI I'd be hesitant weakening
> protection mechanisms, even those that *currently* aren't likely to
> be used.
Can you suggest a practicable means by which this *could* be used?
--
On Fri, 2015-08-07 at 15:07 +, Blumenthal, Uri - 0553 - MITLL
wrote:
> Considering emerging attacks against UEFI I'd be hesitant weakening
> protection mechanisms, even those that *currently* aren't likely to
> be used.
Can you suggest a practicable means by which this *could* be used?
--
, August 7, 2015 10:56
Reply To: r...@openssl.org
Cc: openssl-dev@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 +, Ben Laurie via RT wrote:
> I am curious why you think you don&
On Fri, 2015-08-07 at 08:58 +, 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 de
On Fri, 2015-08-07 at 08:58 +, 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 de
On Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT wrote:
> This code does open-coded division on 64-bit quantities and thus when
> building with GCC on 32-bit platforms will require functions such as
> __umoddi3 and __udivdi3 from libgcc.
>
> In constrained environments such as firmware, those f
On Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT wrote:
> This code does open-coded division on 64-bit quantities and thus when
> building with GCC on 32-bit platforms will require functions such as
> __umoddi3 and __udivdi3 from libgcc.
>
> In constrained environments such as firmware, those f
This code does open-coded division on 64-bit quantities and thus when
building with GCC on 32-bit platforms will require functions such as
__umoddi3 and __udivdi3 from libgcc.
In constrained environments such as firmware, those functions may not
be available. So make it possible to compile out SCT
19 matches
Mail list logo