Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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.
[dwoodhou@i7 apps]$ ./openssl verify ~/.cert.20100813/certificate.pem
C = US, O = Intel Corporation, CN = Intel Intranet Basic Issuing CA 1B
error 10 at 1 depth lookup:certificate has expired
DC = com, DC = intel, DC = corp, DC = ger, OU = Workers, CN = Woodhouse,
David, emailAddress = david.woodho...@intel.com
error 10 at 0 depth lookup:certificate has expired
/home/dwmw2/.cert.20100813/certificate.pem: OK
[dwoodhou@i7 apps]$ ./openssl verify -no_check_time
~/.cert.20100813/certificate.pem
/home/dwmw2/.cert.20100813/certificate.pem: OK
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
From 782cf323f9a85c9244dc6aceb13d875723253810 Mon Sep 17 00:00:00 2001
From: David Woodhouse david.woodho...@intel.com
Date: Fri, 31 Jul 2015 08:49:50 +0100
Subject: [PATCH] RT3951: Add X509_V_FLAG_NO_CHECK_TIME to suppress time check
In some environments, such as firmware, the current system time is entirely
meaningless. Provide a clean mechanism to suppress the checks against it.
---
apps/apps.h| 8 +---
apps/opt.c | 4
crypto/x509/x509_vfy.c | 4
doc/crypto/X509_VERIFY_PARAM_set_flags.pod | 4
include/openssl/x509_vfy.h | 2 ++
5 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/apps/apps.h b/apps/apps.h
index f2dc812..1781deb 100644
--- a/apps/apps.h
+++ b/apps/apps.h
@@ -179,7 +179,7 @@ void unbuffer(FILE *fp);
OPT_V_X509_STRICT, OPT_V_EXTENDED_CRL, OPT_V_USE_DELTAS, \
OPT_V_POLICY_PRINT, OPT_V_CHECK_SS_SIG, OPT_V_TRUSTED_FIRST, \
OPT_V_SUITEB_128_ONLY, OPT_V_SUITEB_128, OPT_V_SUITEB_192, \
-OPT_V_PARTIAL_CHAIN, OPT_V_NO_ALT_CHAINS, \
+OPT_V_PARTIAL_CHAIN, OPT_V_NO_ALT_CHAINS, OPT_V_NO_CHECK_TIME, \
OPT_V__LAST
# define OPT_V_OPTIONS \
@@ -209,7 +209,8 @@ void unbuffer(FILE *fp);
{ suiteB_128, OPT_V_SUITEB_128, '-' }, \
{ suiteB_192, OPT_V_SUITEB_192, '-' }, \
{ partial_chain, OPT_V_PARTIAL_CHAIN, '-' }, \
-{ no_alt_chains, OPT_V_NO_ALT_CHAINS, '-', Only use the first cert chain found }
+{ no_alt_chains, OPT_V_NO_ALT_CHAINS, '-', Only use the first cert chain found }, \
+{ no_check_time, OPT_V_NO_CHECK_TIME, '-', Do not check validity against current time }
# define OPT_V_CASES \
OPT_V__FIRST: case OPT_V__LAST: break; \
@@ -239,7 +240,8 @@ void unbuffer(FILE *fp);
case OPT_V_SUITEB_128: \
case OPT_V_SUITEB_192: \
case OPT_V_PARTIAL_CHAIN: \
-case OPT_V_NO_ALT_CHAINS
+case OPT_V_NO_ALT_CHAINS: \
+case OPT_V_NO_CHECK_TIME
/*
* Common extended? options.
diff --git a/apps/opt.c b/apps/opt.c
index bfb039e..c7dcc43 100644
--- a/apps/opt.c
+++ b/apps/opt.c
@@ -543,6 +543,10 @@ int opt_verify(int opt, X509_VERIFY_PARAM *vpm)
break;
case OPT_V_NO_ALT_CHAINS:
X509_VERIFY_PARAM_set_flags(vpm, X509_V_FLAG_NO_ALT_CHAINS);
+ break;
+case OPT_V_NO_CHECK_TIME:
+X509_VERIFY_PARAM_set_flags(vpm, X509_V_FLAG_NO_CHECK_TIME);
+ break;
}
return 1;
diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c
index 7062ab2..a1bf0f2 100644
--- a/crypto/x509/x509_vfy.c
+++ b/crypto/x509/x509_vfy.c
@@ -952,6 +952,8 @@ static int check_crl_time(X509_STORE_CTX *ctx, X509_CRL *crl, int notify)
ctx-current_crl = crl;
if (ctx-param-flags X509_V_FLAG_USE_CHECK_TIME)
ptime = ctx-param-check_time;
+else if (ctx-param-flags X509_V_FLAG_NO_CHECK_TIME)
+return 1;
else
ptime = NULL;
@@ -1672,6 +1674,8 @@ int x509_check_cert_time(X509_STORE_CTX *ctx, X509 *x, int quiet)
if (ctx-param-flags X509_V_FLAG_USE_CHECK_TIME)
ptime = ctx-param-check_time;
+else if (ctx-param-flags X509_V_FLAG_NO_CHECK_TIME)
+return 1;
else
ptime = NULL;
diff --git a/doc/crypto/X509_VERIFY_PARAM_set_flags.pod b/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
index 066ce0f..57c7b7b 100644
--- a/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
+++ b/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
@@ -203,6 +203,10 @@ chain found is not trusted, then OpenSSL will continue to check to see if an
alternative chain can be found that is trusted. With this flag set the behaviour
will match that of OpenSSL versions prior to 1.1.0.
+The BX509_V_FLAG_NO_CHECK_TIME flag suppresses checking the validity period
+of certificates and CRLs against the current time. If X509_VERIFY_PARAM_set_time()
+is used to specify a verification time, the check is not suppressed.
+
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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.
[dwoodhou@i7 apps]$ ./openssl verify ~/.cert.20100813/certificate.pem
C = US, O = Intel Corporation, CN = Intel Intranet Basic Issuing CA 1B
error 10 at 1 depth lookup:certificate has expired
DC = com, DC = intel, DC = corp, DC = ger, OU = Workers, CN = Woodhouse,
David, emailAddress = david.woodho...@intel.com
error 10 at 0 depth lookup:certificate has expired
/home/dwmw2/.cert.20100813/certificate.pem: OK
[dwoodhou@i7 apps]$ ./openssl verify -no_check_time
~/.cert.20100813/certificate.pem
/home/dwmw2/.cert.20100813/certificate.pem: OK
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
From 782cf323f9a85c9244dc6aceb13d875723253810 Mon Sep 17 00:00:00 2001
From: David Woodhouse david.woodho...@intel.com
Date: Fri, 31 Jul 2015 08:49:50 +0100
Subject: [PATCH] RT3951: Add X509_V_FLAG_NO_CHECK_TIME to suppress time check
In some environments, such as firmware, the current system time is entirely
meaningless. Provide a clean mechanism to suppress the checks against it.
---
apps/apps.h| 8 +---
apps/opt.c | 4
crypto/x509/x509_vfy.c | 4
doc/crypto/X509_VERIFY_PARAM_set_flags.pod | 4
include/openssl/x509_vfy.h | 2 ++
5 files changed, 19 insertions(+), 3 deletions(-)
diff --git a/apps/apps.h b/apps/apps.h
index f2dc812..1781deb 100644
--- a/apps/apps.h
+++ b/apps/apps.h
@@ -179,7 +179,7 @@ void unbuffer(FILE *fp);
OPT_V_X509_STRICT, OPT_V_EXTENDED_CRL, OPT_V_USE_DELTAS, \
OPT_V_POLICY_PRINT, OPT_V_CHECK_SS_SIG, OPT_V_TRUSTED_FIRST, \
OPT_V_SUITEB_128_ONLY, OPT_V_SUITEB_128, OPT_V_SUITEB_192, \
-OPT_V_PARTIAL_CHAIN, OPT_V_NO_ALT_CHAINS, \
+OPT_V_PARTIAL_CHAIN, OPT_V_NO_ALT_CHAINS, OPT_V_NO_CHECK_TIME, \
OPT_V__LAST
# define OPT_V_OPTIONS \
@@ -209,7 +209,8 @@ void unbuffer(FILE *fp);
{ suiteB_128, OPT_V_SUITEB_128, '-' }, \
{ suiteB_192, OPT_V_SUITEB_192, '-' }, \
{ partial_chain, OPT_V_PARTIAL_CHAIN, '-' }, \
-{ no_alt_chains, OPT_V_NO_ALT_CHAINS, '-', Only use the first cert chain found }
+{ no_alt_chains, OPT_V_NO_ALT_CHAINS, '-', Only use the first cert chain found }, \
+{ no_check_time, OPT_V_NO_CHECK_TIME, '-', Do not check validity against current time }
# define OPT_V_CASES \
OPT_V__FIRST: case OPT_V__LAST: break; \
@@ -239,7 +240,8 @@ void unbuffer(FILE *fp);
case OPT_V_SUITEB_128: \
case OPT_V_SUITEB_192: \
case OPT_V_PARTIAL_CHAIN: \
-case OPT_V_NO_ALT_CHAINS
+case OPT_V_NO_ALT_CHAINS: \
+case OPT_V_NO_CHECK_TIME
/*
* Common extended? options.
diff --git a/apps/opt.c b/apps/opt.c
index bfb039e..c7dcc43 100644
--- a/apps/opt.c
+++ b/apps/opt.c
@@ -543,6 +543,10 @@ int opt_verify(int opt, X509_VERIFY_PARAM *vpm)
break;
case OPT_V_NO_ALT_CHAINS:
X509_VERIFY_PARAM_set_flags(vpm, X509_V_FLAG_NO_ALT_CHAINS);
+ break;
+case OPT_V_NO_CHECK_TIME:
+X509_VERIFY_PARAM_set_flags(vpm, X509_V_FLAG_NO_CHECK_TIME);
+ break;
}
return 1;
diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c
index 7062ab2..a1bf0f2 100644
--- a/crypto/x509/x509_vfy.c
+++ b/crypto/x509/x509_vfy.c
@@ -952,6 +952,8 @@ static int check_crl_time(X509_STORE_CTX *ctx, X509_CRL *crl, int notify)
ctx-current_crl = crl;
if (ctx-param-flags X509_V_FLAG_USE_CHECK_TIME)
ptime = ctx-param-check_time;
+else if (ctx-param-flags X509_V_FLAG_NO_CHECK_TIME)
+return 1;
else
ptime = NULL;
@@ -1672,6 +1674,8 @@ int x509_check_cert_time(X509_STORE_CTX *ctx, X509 *x, int quiet)
if (ctx-param-flags X509_V_FLAG_USE_CHECK_TIME)
ptime = ctx-param-check_time;
+else if (ctx-param-flags X509_V_FLAG_NO_CHECK_TIME)
+return 1;
else
ptime = NULL;
diff --git a/doc/crypto/X509_VERIFY_PARAM_set_flags.pod b/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
index 066ce0f..57c7b7b 100644
--- a/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
+++ b/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
@@ -203,6 +203,10 @@ chain found is not trusted, then OpenSSL will continue to check to see if an
alternative chain can be found that is trusted. With this flag set the behaviour
will match that of OpenSSL versions prior to 1.1.0.
+The BX509_V_FLAG_NO_CHECK_TIME flag suppresses checking the validity period
+of certificates and CRLs against the current time. If X509_VERIFY_PARAM_set_time()
+is used to specify a verification time, the check is not suppressed.
+
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 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 you do that. The final error in the X509_STORE_CTX is the *last* error reported, and other errors may also have been detected earlier. If your callback always returns the ok input except for the two above errors, you're fine. But if returns 1 in additional cases, and then in the end you look at the store error status, you may be in trouble. That's in issue in applications that don't immediately terminate the handshake on authentication errors, and disconnect more gracefully at the application layer when authentication fails. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 you do that. The final error in the X509_STORE_CTX is the *last* error reported, and other errors may also have been detected earlier. If your callback always returns the ok input except for the two above errors, you're fine. But if returns 1 in additional cases, and then in the end you look at the store error status, you may be in trouble. That's in issue in applications that don't immediately terminate the handshake on authentication errors, and disconnect more gracefully at the application layer when authentication fails. Thanks for the warning. I don't believe we're looking at the store error status at all; we only care about the return value from X509_verify_cert() — either directly, or when PKCS7_verify() calls it. (There's no SSL here; only crypto. It's for verifying certificate chains and checking signatures on boot images). So I think it's fine. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 a verify_cb function that just ignores X509_V_ERR_CERT_NOT_YET_VALID and X509_V_ERR_CERT_HAS_EXPIRED. So (for the record) I've submitted patches to EDKII which do precisely that, and I don't depend on this patch any more. Close the RT if you wish. Having said that, if OpenSSL *does* gain this functionality then I'll happily change the EDKII code to make use of it, because I think it's the better approach. 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(). -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 of X509_verify_cert().
When dealing with data at rest (signed email, signed code, ...)
certificate expiration needs to be understood in the context of
time of signature, not time of verification.
Yes, but AFAICT the security model here is entirely bogus.
If we're going to trust a third party to say this is my signature,
oh and trust me, this is when I signed it, then we might as well not
be checking the validity time for that third party's signatures at all.
There is *no* benefit, surely? Just complexity.
Ideally (this generally works for email), the verifier initially
verifies the signed object before the expiration time of the
certificate and then caches this fact in some manner, so that
subsequent verification can ignore the certificate entirely, and
just check the the object has not changed since initially verified.
Except that IMAP deliberately provides a *read-only* message store. You
cannot modify messages in any way, by design. You can only add flags.
I don't even want to contemplate a world in which we just have a
'trust me, message signature was OK' flag on a mailstore and allow that
to bypass the *actual* checking.
Actually, if you look at RFC3851 §2.5.1 you'll see that we include a
signingTime attribute in the S/MIME message. Validation is done using
that.
Which makes it entirely pointless, as I said above. You might as well
just not *check* the validity time at all when validating email,
surely?
Hell, it would make more sense in the case of email to do the check
using the Date: header (or the last Resent-Date: header). At least that
wouldn't be *entirely* redundant. And it wouldn't be possible to
falsely sign a message
If caching results of initial verification is not an option, then
perhaps disabling expiration checks is a last-resort option.
It's not an option. It's not even a good idea.
There are ways (with care) to do this via the verify callback, which
can be made to suppress *only* expiration errors and fail on all
other errors.
Yeah. And it turns out that we have verify callbacks in most cases
*already*, to cope with intermediate CAs being present in our trust
store without the ultimate self-signed root CA also being present.
(Although I'd hope there was a better way to handle that; I'll come
back to that later.)
So for now I can live without the requested feature — although
reluctantly because I think the reasons for refusing are utterly bogus
— and fix it up on the EDK2 side just by ignoring/allowing
X509_V_ERR_CERT_{HAS_EXPIRED,NOT_YET_VALID} thus:
http://git.infradead.org/users/dwmw2/edk2.git/commitdiff/9b89269c
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 revocation checking for time-stamped and expired Certificates, Platforms are expected to validate Code Signatures in accordance with RFC 5280 when first encountered. Subsequent signature validation MAY ignore revocation, especially if rejecting the Code will cause the device to fail to boot. When a Platform encounters a Certificate that fails to validate due to revocation, the Platform should not permit the Code to execute. When a Platform encounters a Certificate that fails to validate for reasons other than revocation, the Platform should treat the Code as unsigned. Ordinarily, a Code Signature created by a Subscriber is only considered valid until expiration of the Certificate. However, the “Timestamp” method and the “Signing Service” methods permit Code to remain valid for longer periods of time. 1. Timestamp Method: In this method, the Subscriber signs the Code, appends its Code Signing Certificate and submits it to a Timestamp Authority to be time-stamped. The resulting package can be considered valid after expiration of the Code Signing Certificate and expiration of the Timestamp Authority certificate if the timestamp is dated prior to the Certificate’s expiration date and any applicable revocation date. (See Section 13.2.) 2. Signing Service Method: In this method, the Subscriber uses the service to sign compiled code, binary, file, app, or similar object. Alternatively, the service MAY sign a digest of the preceding objects. The resulting Code Signature is valid up to the expiration time of the Signing Service’s Code Signing Certificate and any applicable revocation date, whichever comes first. Signing Services MAY also timestamp signed objects. This is much better than simply ignoring all date validation. -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 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 after which the system will no longer function. That would be a bad thing even if we *could* reliably trust the system's real time clock at this stage in the boot sequence. This patch gives us a way to disable the time checks entirely, by using X509_VERIFY_PARAM_set_time() with a time of -1. There is a slight risk here — if anyone was genuinely using the value of -1 to check if a certificate chain was indeed valid in the last second of 1969. I judge that risk to be negligible. And it certainly shouldn't be externally triggerable — if an attacker could influence the value passed to X509_VERIFY_PARAM_set_time() then all bets were off w.r.t. time-based checks anyway. If there are serious concerns, however, I can provide an alternative patch which adds an X509_V_FLAG_NO_CHECK_TIME flag for this purpose instead. I'm happy with anything except the existing version in the UEFI source tree that everyone is shipping, which just disables the time check if OPENSSL_SYS_UEFI is set¹. That one I *don't* like. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://scanmail.trustwave.com/?c=4062d=w5av1VNIDJq7CuEBC-sOxIBHFHbcisoH_n4fAJKpMgs=5u=http%3a%2f%2fgit%2einfradead%2eorg%2fusers%2fdwmw2%2fopenssl%2egit%2fcommitdiff%2f2fb12afc2ceb This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 firmware without a reliable RTC is to issue certificates that are valid from 1969 to 2037. We will have a Y2037 problem similar to Y2000 but this is a wide problem, much wider than openssl can solve at the moment. Regards, Alex Gostrer On Wed, Jul 22, 2015 at 6:09 AM, 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 when the firmware loads it, we *really* don't want to have a built-in obsolescence date after which the system will no longer function. That would be a bad thing even if we *could* reliably trust the system's real time clock at this stage in the boot sequence. This patch gives us a way to disable the time checks entirely, by using X509_VERIFY_PARAM_set_time() with a time of -1. There is a slight risk here — if anyone was genuinely using the value of -1 to check if a certificate chain was indeed valid in the last second of 1969. I judge that risk to be negligible. And it certainly shouldn't be externally triggerable — if an attacker could influence the value passed to X509_VERIFY_PARAM_set_time() then all bets were off w.r.t. time-based checks anyway. If there are serious concerns, however, I can provide an alternative patch which adds an X509_V_FLAG_NO_CHECK_TIME flag for this purpose instead. I'm happy with anything except the existing version in the UEFI source tree that everyone is shipping, which just disables the time check if OPENSSL_SYS_UEFI is set¹. That one I *don't* like. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/2fb12afc2ceb ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 insisting upon that then a lot of operating systems would no longer boot. I don't think it's practical to add this requirement for secure boot at this stage; the UEFI firmware will probably continue to just disable the time check — even if it's a local patch as it is at the moment. But I'm *trying* to eliminate those local patches, to make it easier to keep OpenSSL up to date. It occurs to me that UEFI firmware might be the *largest* deployment of OpenSSL, so it's unfortunate that the patches it needs are out-of-tree :) FWIW the Linux kernel also specifically avoids checking timestamps altogether when validating signed modules. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 firmware without a reliable RTC is to issue certificates that are valid from 1969 to 2037. We will have a Y2037 problem similar to Y2000 but this is a wide problem, much wider than openssl can solve at the moment. Regards, Alex Gostrer On Wed, Jul 22, 2015 at 6:09 AM, 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 when the firmware loads it, we *really* don't want to have a built-in obsolescence date after which the system will no longer function. That would be a bad thing even if we *could* reliably trust the system's real time clock at this stage in the boot sequence. This patch gives us a way to disable the time checks entirely, by using X509_VERIFY_PARAM_set_time() with a time of -1. There is a slight risk here — if anyone was genuinely using the value of -1 to check if a certificate chain was indeed valid in the last second of 1969. I judge that risk to be negligible. And it certainly shouldn't be externally triggerable — if an attacker could influence the value passed to X509_VERIFY_PARAM_set_time() then all bets were off w.r.t. time-based checks anyway. If there are serious concerns, however, I can provide an alternative patch which adds an X509_V_FLAG_NO_CHECK_TIME flag for this purpose instead. I'm happy with anything except the existing version in the UEFI source tree that everyone is shipping, which just disables the time check if OPENSSL_SYS_UEFI is set¹. That one I *don't* like. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/2fb12afc2ceb ___ openssl-bugs-mod mailing list openssl-bugs-...@openssl.org https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 binaries. So, I think, this time should be used as argument to X509_VERIFY_PARAM_set_time instead of wall clock time. For the UEFI build we try to avoid all non-repeatable things like that being included in the binaries. I'm still worrying about how to approach the patch at the end of the list¹ which removes all those instances of __FILE__ and __LINE__... I have a vague recollection of there being a discussion on this list about that, fairly recently, and I need to go back and find it. Or, may be there is something like CMS signing attributes with signing time. Did I not send the patch which fixes the OPENSSL_NO_CMS build yet? :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/b599f07d smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 revocation checking for time-stamped and expired Certificates, Platforms are expected to validate Code Signatures in accordance with RFC 5280 when first encountered. Subsequent signature validation MAY ignore revocation, especially if rejecting the Code will cause the device to fail to boot. When a Platform encounters a Certificate that fails to validate due to revocation, the Platform should not permit the Code to execute. When a Platform encounters a Certificate that fails to validate for reasons other than revocation, the Platform should treat the Code as unsigned. Ordinarily, a Code Signature created by a Subscriber is only considered valid until expiration of the Certificate. However, the “Timestamp” method and the “Signing Service” methods permit Code to remain valid for longer periods of time. 1. Timestamp Method: In this method, the Subscriber signs the Code, appends its Code Signing Certificate and submits it to a Timestamp Authority to be time-stamped. The resulting package can be considered valid after expiration of the Code Signing Certificate and expiration of the Timestamp Authority certificate if the timestamp is dated prior to the Certificate’s expiration date and any applicable revocation date. (See Section 13.2.) 2. Signing Service Method: In this method, the Subscriber uses the service to sign compiled code, binary, file, app, or similar object. Alternatively, the service MAY sign a digest of the preceding objects. The resulting Code Signature is valid up to the expiration time of the Signing Service’s Code Signing Certificate and any applicable revocation date, whichever comes first. Signing Services MAY also timestamp signed objects. This is much better than simply ignoring all date validation. -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 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 after which the system will no longer function. That would be a bad thing even if we *could* reliably trust the system's real time clock at this stage in the boot sequence. This patch gives us a way to disable the time checks entirely, by using X509_VERIFY_PARAM_set_time() with a time of -1. There is a slight risk here — if anyone was genuinely using the value of -1 to check if a certificate chain was indeed valid in the last second of 1969. I judge that risk to be negligible. And it certainly shouldn't be externally triggerable — if an attacker could influence the value passed to X509_VERIFY_PARAM_set_time() then all bets were off w.r.t. time-based checks anyway. If there are serious concerns, however, I can provide an alternative patch which adds an X509_V_FLAG_NO_CHECK_TIME flag for this purpose instead. I'm happy with anything except the existing version in the UEFI source tree that everyone is shipping, which just disables the time check if OPENSSL_SYS_UEFI is set¹. That one I *don't* like. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://scanmail.trustwave.com/?c=4062d=w5av1VNIDJq7CuEBC-sOxIBHFHbcisoH_n4fAJKpMgs=5u=http%3a%2f%2fgit%2einfradead%2eorg%2fusers%2fdwmw2%2fopenssl%2egit%2fcommitdiff%2f2fb12afc2ceb This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 insisting upon that then a lot of operating systems would no longer boot. I don't think it's practical to add this requirement for secure boot at this stage; the UEFI firmware will probably continue to just disable the time check — even if it's a local patch as it is at the moment. But I'm *trying* to eliminate those local patches, to make it easier to keep OpenSSL up to date. It occurs to me that UEFI firmware might be the *largest* deployment of OpenSSL, so it's unfortunate that the patches it needs are out-of-tree :) FWIW the Linux kernel also specifically avoids checking timestamps altogether when validating signed modules. -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 binaries. So, I think, this time should be used as argument to X509_VERIFY_PARAM_set_time instead of wall clock time. For the UEFI build we try to avoid all non-repeatable things like that being included in the binaries. I'm still worrying about how to approach the patch at the end of the list¹ which removes all those instances of __FILE__ and __LINE__... I have a vague recollection of there being a discussion on this list about that, fairly recently, and I need to go back and find it. Or, may be there is something like CMS signing attributes with signing time. Did I not send the patch which fixes the OPENSSL_NO_CMS build yet? :) -- David WoodhouseOpen Source Technology Centre david.woodho...@intel.com Intel Corporation ¹ http://git.infradead.org/users/dwmw2/openssl.git/commitdiff/b599f07d smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 email, signed code, ...) certificate expiration needs to be understood in the context of time of signature, not time of verification. Ideally (this generally works for email), the verifier initially verifies the signed object before the expiration time of the certificate and then caches this fact in some manner, so that subsequent verification can ignore the certificate entirely, and just check the the object has not changed since initially verified. If caching results of initial verification is not an option, then perhaps disabling expiration checks is a last-resort option. There are ways (with care) to do this via the verify callback, which can be made to suppress *only* expiration errors and fail on all other errors. -- Viktor. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 would be great. Unfortunately, if the UEFI firmware were suddenly to start insisting upon that then a lot of operating systems would no longer boot. Which operating systems would that be? As far as I know Windows 7 required this if you wanted to have your drivers stay valid for longer than 2 years and Windows 10 just always requires it. So I would hope that they actually do this for all of their own software. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 it? They're not sure about the time or something at the moment it's checked? Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 would be great. Unfortunately, if the UEFI firmware were suddenly to start insisting upon that then a lot of operating systems would no longer boot. Which operating systems would that be? As far as I know Windows 7 required this if you wanted to have your drivers stay valid for longer than 2 years and Windows 10 just always requires it. So I would hope that they actually do this for all of their own software. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 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 was the time at which the signature was generated, then we might as well forget the whole nonsense about an expiry time and just trust that same third party to provide a signature... or not. The whole point of this signed timestamp is that the signature doesn't expire and that you don't have to care about the wall clock. ... which is much more simply achieved by just not caring about the validity times of the certificate in the first place. -- dwmw2 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 timestamp, or the validity period? Any idea why they don't check it? They're not sure about the time or something at the moment it's checked? It's running on a computer. Of course they're not sure about the time. If after a CMOS battery failure you cannot boot the system in order to log into it and correct the time, because the firmware refuses to load the OS kernel or because the OS kernel refuses to load its disk driver, then there is something very wrong with the design. And if your system is designed to suddenly stop booting in 2037 for no better reason than the fact that *some* systems had bugs which made it seem simpler to set that as the expiry date for a cert even though we didn't really want it to expire *ever*, that's kind of broken too. 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 was the time at which the signature was generated, then we might as well forget the whole nonsense about an expiry time and just trust that same third party to provide a signature... or not. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 was valid at the time the code was signed. That would be great. Unfortunately, if the UEFI firmware were suddenly to start insisting upon that then a lot of operating systems would no longer boot. Which operating systems would that be? As far as I know Windows 7 required this if you wanted to have your drivers stay valid for longer than 2 years and Windows 10 just always requires it. So I would hope that they actually do this for all of their own software. Perhaps they do, although the UEFI bootloader they use is a somewhat different beast. But there are plenty of other OS bootloeders which are signed for so-called secure boot, other than Microsoft's. And I would be utterly shocked if they all have trusted timestamps, given that the UEFI firmware in all current machines does not require such. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 was valid at the time the code was signed. That would be great. Unfortunately, if the UEFI firmware were suddenly to start insisting upon that then a lot of operating systems would no longer boot. Which operating systems would that be? As far as I know Windows 7 required this if you wanted to have your drivers stay valid for longer than 2 years and Windows 10 just always requires it. So I would hope that they actually do this for all of their own software. Perhaps they do, although the UEFI bootloader they use is a somewhat different beast. But there are plenty of other OS bootloeders which are signed for so-called secure boot, other than Microsoft's. And I would be utterly shocked if they all have trusted timestamps, given that the UEFI firmware in all current machines does not require such. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 really know it. If we're going to trust anyone to say was the time at which the signature was generated, then we might as well forget the whole nonsense about an expiry time and just trust that same third party to provide a signature... or not. The whole point of this signed timestamp is that the signature doesn't expire and that you don't have to care about the wall clock. ... which is much more simply achieved by just not caring about the validity times of the certificate in the first place. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 that the signature doesn't expire and that you don't have to care about the wall clock. ... which is much more simply achieved by just not caring about the validity times of the certificate in the first place. In case of a timestamp you can reduce the check to verify that the timestamp was in the validity period of the certificate. Yes. You can. But it's still pointless complexity in a use case where *every* valid signature would need a corresponding timestamp to ensure its validity. I can kind of understand why we might want the timestamp scheme in circumstances where *some* signatures should be infinitely valid, and others not. But in the case where *all* signatures should be infinitely valid, it just seems entirely gratuitous. And retrofitting it into a model where the validity is *already* not being checked is a inviting a whole bunch of breakage for precisely zero benefit. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 limitation is purely an implementation issue — not only is it a fairly safe bet that a lot of software will crap itself on seeing a GeneralizedTime at all (since for dates before we MUST use UTCTime instead), but a lot of 32-bit implementations are known to break even for UTCTime values later than 2038. So certificates which do this are just not going to interoperate very well at all. -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 was the time at which the signature was generated, then we might as well forget the whole nonsense about an expiry time and just trust that same third party to provide a signature... or not. The whole point of this signed timestamp is that the signature doesn't expire and that you don't have to care about the wall clock. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 care about the wall clock. ... which is much more simply achieved by just not caring about the validity times of the certificate in the first place. In case of a timestamp you can reduce the check to verify that the timestamp was in the validity period of the certificate. Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3951] [RFC][PATCH] Allow certificate time checks to be disabled
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 when the firmware loads it, we *really* don't want to have a built-in obsolescence date after which the system will no longer function. That would be a bad thing even if we *could* reliably trust the system's real time clock at this stage in the boot sequence. Isn't it better to check if certificate was valid at the time of signing? Typically compiler somehow puts compilation timestamp into compiled binaries. So, I think, this time should be used as argument to X509_VERIFY_PARAM_set_time instead of wall clock time. Or, may be there is something like CMS signing attributes with signing time. s ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
