checked into master; thanks! (and thanks for updating the docs as well)
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
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, p
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, p
> 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.
___
openss
> 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.
___
openssl
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 car
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 agre
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
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
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 implemen
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 li
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 times
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
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
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:
> > >
> >
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
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 "
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 cert
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 cert
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 tr
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 che
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.
>
> T
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.
>
> T
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 em
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 star
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 star
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
> bina
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
> bina
ion.
-Tim
-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of
Woodhouse, David via RT
Sent: Wednesday, July 22, 2015 9:10 AM
Cc: openssl-dev@openssl.org
Subject: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time
checks to be disabled
There a
ion.
-Tim
-Original Message-
From: openssl-dev [mailto:openssl-dev-boun...@openssl.org] On Behalf Of
Woodhouse, David via RT
Sent: Wednesday, July 22, 2015 9:10 AM
Cc: openssl-dev@openssl.org
Subject: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time
checks to be disabled
There a
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 firmw
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 firmw
On Wed, 22 Jul 2015 13:09:48 +
"Woodhouse, David via RT" 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 when the
On Wed, 22 Jul 2015 13:09:48 +
"Woodhouse, David via RT" 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 when the
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 when the firmware loads it, we *really* don't want to
have a built-in obsolescence date a
34 matches
Mail list logo
