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
currently
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
openssl-dev-boun...@openssl.org on behalf of dw...@infradead.org wrote:
UEFI is widely mocked for how bloated it is, given
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, given
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 Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT r...@openssl.org 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
On Thu, 6 Aug 2015 at 14:14 David Woodhouse via RT r...@openssl.org 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
, 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't need CT
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
, 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't need CT
, 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't need CT
, 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't need CT
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
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?
--
] [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 those that *currently* aren't likely
] [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 those that *currently* aren't likely
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
19 matches
Mail list logo
