On Fri, 2015-07-31 at 03:09 +, Salz, Rich wrote:
If requested, I can still provide a patch with the alternative variant of
using a
X509_V_FLAG_NO_CHECK_TIME flag if that's considered better than using a
'special' time of (time_t)-1 with X509_VERIFY_PARAM_set_time().
Yes, please.
On Fri, 2015-07-31 at 03:09 +, Salz, Rich wrote:
If requested, I can still provide a patch with the alternative variant of
using a
X509_V_FLAG_NO_CHECK_TIME flag if that's considered better than using a
'special' time of (time_t)-1 with X509_VERIFY_PARAM_set_time().
Yes, please.
On Thu, Jul 30, 2015 at 09:55:36PM +, Woodhouse, David via RT wrote:
On Tue, 2015-07-28 at 11:00 +, Salz, Rich via RT wrote:
It seems that the simplest and most obvious thing is to indicate that
you don't care about the dates, which is what this patch does.
Obviously I agree, but
On Thu, 2015-07-30 at 22:08 +, Viktor Dukhovni wrote:
Obviously I agree, but life's too short to argue about it and I *do*
have a viable alternative, with a verify_cb function that just ignores
X509_V_ERR_CERT_NOT_YET_VALID and X509_V_ERR_CERT_HAS_EXPIRED.
You have to be careful how
If requested, I can still provide a patch with the alternative variant of
using a
X509_V_FLAG_NO_CHECK_TIME flag if that's considered better than using a
'special' time of (time_t)-1 with X509_VERIFY_PARAM_set_time().
Yes, please.
___
If requested, I can still provide a patch with the alternative variant of
using a
X509_V_FLAG_NO_CHECK_TIME flag if that's considered better than using a
'special' time of (time_t)-1 with X509_VERIFY_PARAM_set_time().
Yes, please.
___
On Tue, 2015-07-28 at 11:00 +, Salz, Rich via RT wrote:
It seems that the simplest and most obvious thing is to indicate that
you don't care about the dates, which is what this patch does.
Obviously I agree, but life's too short to argue about it and I *do*
have a viable alternative, with
On Wed, 2015-07-22 at 16:47 +, Viktor Dukhovni 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.
You probably need a dedicated implementation
It seems that the simplest and most obvious thing is to indicate that you don't
care about the dates, which is what this patch does.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
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
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
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
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
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
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, 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 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
31 matches
Mail list logo
