The way this is supposed to work is by using a timestamp from a trusted
timestamp server to show the certificate was valid at the time the code was
signed.
See the following text from the draft code signing baseline requirements from
the CA/Browser forum:
8.2.1: ... With the exception of
Hi David,
I think that both your proposals will add vulnerabilities. With your
proposal I anticipate that many careless application developers will
disable the date checking forever. As a result, consumers will be blaming
openssl, not these developers.
Current solution for kernels and other
For secure boot (and other services), OpenSSL is built as part of the
Tianocore UEFI firmware. It does not use the normal makefiles; it has
its own build system and provides its own #defines and list of files to
be built:
https://github.com/tianocore/edk2/blob/master/CryptoPkg/Library/Openssl
I'm willing to forward them to you, and if you want to review and rebase, etc.,
that would make it quicker.
--
Senior Architect, Akamai Technologies
IM: richs...@jabber.at Twitter: RichSalz
-Original Message-
From: David Woodhouse [mailto:dw...@infradead.org]
Sent: Wednesday, July
On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote:
The way this is supposed to work is by using a timestamp from a
trusted timestamp server to show the certificate was valid at the
time the code was signed.
That would be great. Unfortunately, if the UEFI firmware were suddenly
to start
On Wed, 2015-07-22 at 16:02 +, Salz, Rich wrote:
To what extent is the OPENSSL_NO_STDIO build expected to actually work?
It seems fairly unloved.
I have a a complete fix sitting in my queue for a few months now.
Is that sitting in a visible git tree somewhere, and/or could you
share,
On Wed, 2015-07-22 at 16:13 +, Salz, Rich wrote:
I'm willing to forward them to you, and if you want to review and
rebase, etc., that would make it quicker.
Please.
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com
To what extent is the OPENSSL_NO_STDIO build expected to actually work?
It seems fairly unloved.
I have a a complete fix sitting in my queue for a few months now.
___
openssl-dev mailing list
To unsubscribe:
Hi David,
I think that both your proposals will add vulnerabilities. With your
proposal I anticipate that many careless application developers will
disable the date checking forever. As a result, consumers will be blaming
openssl, not these developers.
Current solution for kernels and other
On Wed, 2015-07-22 at 14:58 +, Victor Wagner via RT wrote:
Isn't it better to check if certificate was valid at the time of
signing?
Is there a benefit to that which would make it worth the additional
complexity?
Typically compiler somehow puts compilation timestamp into compiled
To what extent is the OPENSSL_NO_STDIO build expected to actually work?
It seems fairly unloved.
The UEFI build (currently on 1.0.2) has a minimal patch¹ which fixes up
OPENSSL_NO_FP for their use case, which obviously it would be nice to
eliminate by merging upstream.
But since
The way this is supposed to work is by using a timestamp from a trusted
timestamp server to show the certificate was valid at the time the code was
signed.
See the following text from the draft code signing baseline requirements from
the CA/Browser forum:
8.2.1: ... With the exception of
On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote:
The way this is supposed to work is by using a timestamp from a
trusted timestamp server to show the certificate was valid at the
time the code was signed.
That would be great. Unfortunately, if the UEFI firmware were suddenly
to start
On Wed, 2015-07-22 at 14:58 +, Victor Wagner via RT wrote:
Isn't it better to check if certificate was valid at the time of
signing?
Is there a benefit to that which would make it worth the additional
complexity?
Typically compiler somehow puts compilation timestamp into compiled
On Wed, Jul 22, 2015 at 03:36:40PM +, David Woodhouse via RT wrote:
FWIW the Linux kernel also specifically avoids checking timestamps
altogether when validating signed modules.
You probably need a dedicated implementation of X509_verify_cert().
When dealing with data at rest (signed
fixed in master.
not needed for 1.0.2 since that code uses inline coding, not calling the
standard routines.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe:
On Wed, Jul 22, 2015 at 04:36:27PM +0100, David Woodhouse wrote:
On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote:
The way this is supposed to work is by using a timestamp from a
trusted timestamp server to show the certificate was valid at the
time the code was signed.
That
On Wed, Jul 22, 2015 at 03:36:40PM +, David Woodhouse via RT wrote:
FWIW the Linux kernel also specifically avoids checking timestamps
altogether when validating signed modules.
What do you mean wit timestamps? The trusted timestamp, or the
validity period?
Any idea why they don't check
On Wed, Jul 22, 2015 at 04:36:27PM +0100, David Woodhouse wrote:
On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote:
The way this is supposed to work is by using a timestamp from a
trusted timestamp server to show the certificate was valid at the
time the code was signed.
That
On Wed, Jul 22, 2015 at 10:23:40AM +, Pascal Cuoq via RT wrote:
Recently, GCC began to assume for optimization purposes that p and q are
non-null pointers when
memcpy(p, q, n); is invoked.
I have to agree that p and q can't be NULL, even when n is 0. The
standard seems to be rather clear
The ciphers documentation page (https://www.openssl.org/docs/apps/ciphers.html)
says:
kRSA, aRSA, RSA
cipher suites using RSA key exchange, authentication or either respectively.
That sounds like RSA should be a superset of kRSA and aRSA, but actually aRSA
includes cipher suites not in RSA,
Hi,
To disable SSLv2 and SSLv3 while compilation used no-ssl2 and no-ssl3 option
for windows platform. But getting the below link error. Without option no-ssl2
no-ssl3 I can compile successfully. Any pointers to resolve this issue? Thanks
in advance.
LINK : warning LNK4001: no object files
Recently, GCC began to assume for optimization purposes that p and q are
non-null pointers when
memcpy(p, q, n); is invoked.
This means that the if is eliminated completely when compiling the following
sequence of instructions:
memcpy(p, q, n);
if (!p) printf(good\n);
And this causes a
From: David Bar david@gmail.com
Subject: [PATCH] RT3674: Fix no-cms build failure
This fixes multiple problems with CMS-related code, including the
RFC2631 DH key derivation which depends on CMS, not being correctly
protected by #ifndef OPENSSL_NO_CMS.
---
Updated version of David Bar's
Maybe it is the time to introduce the 64-bit UNIX time? Anything else looks
like a patch.
Regards,
Alex.
On Wed, Jul 22, 2015 at 2:34 PM, David Woodhouse dw...@infradead.org
wrote:
On Wed, 2015-07-22 at 23:29 +0200, Kurt Roeckx wrote:
On Wed, Jul 22, 2015 at 09:56:24PM +0100, David Woodhouse
On Wed, 2015-07-22 at 22:42 +0200, Kurt Roeckx wrote:
On Wed, Jul 22, 2015 at 03:36:40PM +, David Woodhouse via RT
wrote:
FWIW the Linux kernel also specifically avoids checking timestamps
altogether when validating signed modules.
What do you mean wit timestamps? The trusted
On Wed, 2015-07-22 at 22:40 +0200, Kurt Roeckx wrote:
On Wed, Jul 22, 2015 at 04:36:27PM +0100, David Woodhouse wrote:
On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote:
The way this is supposed to work is by using a timestamp from a
trusted timestamp server to show the certificate
On Wed, 2015-07-22 at 22:40 +0200, Kurt Roeckx wrote:
On Wed, Jul 22, 2015 at 04:36:27PM +0100, David Woodhouse wrote:
On Wed, 2015-07-22 at 14:52 +, Tim Hollebeek wrote:
The way this is supposed to work is by using a timestamp from a
trusted timestamp server to show the certificate
On Wed, 2015-07-22 at 23:29 +0200, Kurt Roeckx wrote:
On Wed, Jul 22, 2015 at 09:56:24PM +0100, David Woodhouse wrote:
The more I look at this 'signed timestamp' scheme, the more pointless
it seems in this situation. We basically don't *care* about the wall
-clock time, *and* we don't
On Thu, 2015-07-23 at 00:29 +0200, Kurt Roeckx wrote:
On Wed, Jul 22, 2015 at 10:34:53PM +0100, David Woodhouse wrote:
On Wed, 2015-07-22 at 23:29 +0200, Kurt Roeckx wrote:
On Wed, Jul 22, 2015 at 09:56:24PM +0100, David Woodhouse wrote:
The whole point of this signed timestamp is
On Wed, Jul 22, 2015 at 07:38:48PM +, Lynch, Paul[E] via RT wrote:
The ciphers documentation page
(https://www.openssl.org/docs/apps/ciphers.html) says:
kRSA, aRSA, RSA
cipher suites using RSA key exchange, authentication or either
respectively.
That sounds like RSA should be a
On Wed, 2015-07-22 at 15:02 -0700, Alexander Gostrer wrote:
Maybe it is the time to introduce the 64-bit UNIX time? Anything else
looks like a patch.
Theoretically, we can already encode notAfter values as a
GeneralizedTime of up to 1231235959Z (i.e. Y10K) in an X.509
certificate.
The
On Wed, Jul 22, 2015 at 08:49:05PM +, Kurt Roeckx via RT wrote:
On Wed, Jul 22, 2015 at 07:38:48PM +, Lynch, Paul[E] via RT wrote:
The ciphers documentation page
(https://www.openssl.org/docs/apps/ciphers.html) says:
kRSA, aRSA, RSA
cipher suites using RSA key exchange,
On Wed, Jul 22, 2015 at 09:56:24PM +0100, David Woodhouse wrote:
The more I look at this 'signed timestamp' scheme, the more pointless
it seems in this situation. We basically don't *care* about the wall
-clock time, *and* we don't really know it. If we're going to trust
anyone to say THIS
On Wed, Jul 22, 2015 at 10:34:53PM +0100, David Woodhouse wrote:
On Wed, 2015-07-22 at 23:29 +0200, Kurt Roeckx wrote:
On Wed, Jul 22, 2015 at 09:56:24PM +0100, David Woodhouse wrote:
The whole point of this signed timestamp is that the signature
doesn't expire and that you don't have to
On Wed, 22 Jul 2015 13:09:48 +
Woodhouse, David via RT r...@openssl.org wrote:
There are various circumstances in which it makes no sense to be
checking the start and end times of a certificate's validity.
When validating OS kernel drivers, or indeed when validating the OS
kernel itself
36 matches
Mail list logo
