[openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
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
Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
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 unneeded but would need a whole bunch of pain for different GCC/MSVC/LLVM toolchains and ABIs... just in case we one day work out how we might use it. All that for just one attribute? Of a certificate that you already have to deal with? I’m missing something, or you’re not correct. Yes, really all that for just one attribute. The real pain point here is the 64-bit division. That's why we disable SCT, instead of just ignoring it like we do various other attributes which are irrelevant to us and will never be seen on certificates we care about. If you do division on a uint64_t in 32-bit mode, GCC will emit out-of -line calls to functions such as __udivdi3(), which are provided by libgcc. Even if you're building with -ffreestanding. Those functions do not exist, because libgcc is not linked into the final UEFI image (and is not even suitable to be so linked). The situation is the same (with slightly different functions) for building with MSVC. I haven't even looked at the clang/llvm build. It would be quite painful to have to provide these functions in the UEFI image. We'd basically end up having to lift copies of those functions (or reimplement them, if necessary for licensing reasons) and copy them into the UEFI package for OpenSSL. And then cope with the fact that we need *different* functions, or different versions of them, depending on which toolchain we build with. And depending on whether we're building with the MS ABI as the default or not. So yes. All that whole bunch of pain, for just one attribute. FWIW the Linux kernel had a similar issue, on the many platforms where libgcc.a is *not* included into the kernel. There we avoid 64-bit division and instead have a 'do_div()' macro which divides a 64-bit integer by a 32-bit one and returns both the dividend and the remainder. OpenSSL just goes ahead and does 64-bit division. The reason I've submitted patches to disable SCRYPT and SCT, which are the two offending locations in OpenSSL, is because the Linux 'do_div()' solution requires inline assembly, and we can't necessary assume that we have inline assembly in OpenSSL. And because we actively do not care about losing those pieces of functionality. -- 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 #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
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 library. It is a boot system embedded into firmware. If the system needs to be updated to address new security concerns, that part of OpenSSL that is also embedded will be updated with the rest of the system. It makes no sense, to me, to add things that aren't being used by this one application. The library and application are tied together. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
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 that the job of a sane firmware is to boot the operating as quickly as possible and then get the hell out of the way. 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. 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 unneeded but would need a whole bunch of pain for different GCC/MSVC/LLVM toolchains and ABIs... just in case we one day work out how we might use it. All that for just one attribute? Of a certificate that you already have to deal with? I’m missing something, or you’re not correct. 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 #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
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 that the job of a sane firmware is to boot the operating as quickly as possible and then get the hell out of the way. 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 unneeded but would need a whole bunch of pain for different GCC/MSVC/LLVM toolchains and ABIs... just in case we one day work out how we might use it. IMHO it would be easier to keep this feature waiting rather than opening a whole new discussion later on. If you come up with a use case, it's hardly difficult for you to check out the open source UEFI implementation from its git tree, build it *without* OPENSSL_NO_SCT, and implement and test your ideas. When you submit that, of course there will be a whole new discussion. about your design and your implementation. But it's largely distinct from this one and will need to happen *anyway* even if we disable SCT in the meantime. Plus, by just being there it might stimulate people to look for ways to use it. It'll stimulate people, I'm sure. But not in a good way. -- 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 #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
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 2001
From: David Woodhouse david.woodho...@intel.com
Date: Thu, 6 Aug 2015 13:54:45 +0100
Subject: [PATCH] RT3992: Allow RFC6962 Signed Certificate Timestamps to be
disabled
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 SCT support, which in
fact (in the case of UEFI) we don't need anyway.
---
crypto/x509v3/ext_dat.h | 2 ++
crypto/x509v3/v3_scts.c | 2 ++
makevms.com | 1 +
util/mkdef.pl | 6 +-
4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/crypto/x509v3/ext_dat.h b/crypto/x509v3/ext_dat.h
index 9c3529b..76be621 100644
--- a/crypto/x509v3/ext_dat.h
+++ b/crypto/x509v3/ext_dat.h
@@ -127,8 +127,10 @@ static const X509V3_EXT_METHOD *standard_exts[] = {
v3_idp,
v3_alt[2],
v3_freshest_crl,
+#ifndef OPENSSL_NO_SCT
v3_ct_scts[0],
v3_ct_scts[1],
+#endif
};
/* Number of standard extensions */
diff --git a/crypto/x509v3/v3_scts.c b/crypto/x509v3/v3_scts.c
index 61e5a83..0ffdfb8 100644
--- a/crypto/x509v3/v3_scts.c
+++ b/crypto/x509v3/v3_scts.c
@@ -61,6 +61,7 @@
#include openssl/asn1.h
#include openssl/x509v3.h
+#ifndef OPENSSL_NO_SCT
/* Signature and hash algorithms from RFC 5246 */
#define TLSEXT_hash_sha256 4
@@ -321,3 +322,4 @@ static int i2r_SCT_LIST(X509V3_EXT_METHOD *method, STACK_OF(SCT) *sct_list,
return 1;
}
+#endif
diff --git a/makevms.com b/makevms.com
index 35c44ec..500b191 100755
--- a/makevms.com
+++ b/makevms.com
@@ -295,6 +295,7 @@ $ CONFIG_LOGICALS := AES,-
RFC3779,-
RMD160,-
RSA,-
+ SCT,-
SCTP,-
SEED,-
SOCK,-
diff --git a/util/mkdef.pl b/util/mkdef.pl
index 26fa209..3147856 100755
--- a/util/mkdef.pl
+++ b/util/mkdef.pl
@@ -80,6 +80,8 @@ my @known_algorithms = ( RC2, RC4, RC5, IDEA, DES, BF,
FP_API, STDIO, SOCK, DGRAM,
# Engines
STATIC_ENGINE, ENGINE, HW, GMP,
+ # X.509v3 Signed Certificate Timestamps
+ SCT,
# RFC3779
RFC3779,
# TLS
@@ -126,7 +128,7 @@ my $no_md2; my $no_md4; my $no_md5; my $no_sha; my $no_ripemd; my $no_mdc2;
my $no_rsa; my $no_dsa; my $no_dh; my $no_aes;
my $no_ec; my $no_ecdsa; my $no_ecdh; my $no_engine; my $no_hw;
my $no_fp_api; my $no_static_engine=1; my $no_gmp; my $no_deprecated;
-my $no_rfc3779; my $no_psk; my $no_cms; my $no_capieng;
+my $no_sct; my $no_rfc3779; my $no_psk; my $no_cms; my $no_capieng;
my $no_jpake; my $no_srp; my $no_ec2m; my $no_nistp_gcc;
my $no_nextprotoneg; my $no_sctp; my $no_srtp; my $no_ssl_trace;
my $no_unit_test; my $no_ssl3_method; my $no_ocb;
@@ -215,6 +217,7 @@ foreach (@ARGV, split(/ /, $options))
elsif (/^no-engine$/) { $no_engine=1; }
elsif (/^no-hw$/) { $no_hw=1; }
elsif (/^no-gmp$/) { $no_gmp=1; }
+ elsif (/^no-sct$/) { $no_sct=1; }
elsif (/^no-rfc3779$/) { $no_rfc3779=1; }
elsif (/^no-cms$/) { $no_cms=1; }
elsif (/^no-ec2m$/) { $no_ec2m=1; }
@@ -1200,6 +1203,7 @@ sub is_valid
if ($keyword eq FP_API $no_fp_api) { return 0; }
if ($keyword eq STATIC_ENGINE $no_static_engine) { return 0; }
if ($keyword eq GMP $no_gmp) { return 0; }
+ if ($keyword eq SCT $no_sct) { return 0; }
if ($keyword eq RFC3779 $no_rfc3779) { return 0; }
if ($keyword eq PSK $no_psk) { return 0; }
if ($keyword eq CMS $no_cms) { return 0; }
--
2.4.3
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 #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
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 firmware, those functions may not be available. So make it possible to compile out SCT support, which in fact (in the case of UEFI) we don't need anyway. I am curious why you think you don't need CT for UEFI? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
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 firmware, those functions may not be available. So make it possible to compile out SCT support, which in fact (in the case of UEFI) we don't need anyway. I am curious why you think you don't need CT for UEFI? ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
Considering emerging attacks against UEFI I'd be hesitant weakening protection mechanisms, even those that *currently* aren't likely to be used. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: David Woodhouse via RT Sent: Friday, August 7, 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 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 describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. I don't really see a viable use case for this in the UEFI environment. We don't have a way to get these (hypothetical) logs of validly issued certificates into the firmware. We certainly don't normally have the facility to perform HTTPS requests prior to booting the OS. I realise that this scheme allows for asynchronous verification, but it would be utterly pointless to devise a complex scheme for interaction between the firmware and the booted OS, when the whole point is that the OS *isn't* trustworthy if that signature wasn't valid. Even aside from the general rule that *anything* we implement like that, some idiot will break when they do their value subtract to the standard open source UEFI offering. -- David Woodhouse Open 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 #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 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 describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. I don't really see a viable use case for this in the UEFI environment. We don't have a way to get these (hypothetical) logs of validly issued certificates into the firmware. We certainly don't normally have the facility to perform HTTPS requests prior to booting the OS. I realise that this scheme allows for asynchronous verification, but it would be utterly pointless to devise a complex scheme for interaction between the firmware and the booted OS, when the whole point is that the OS *isn't* trustworthy if that signature wasn't valid. Even aside from the general rule that *anything* we implement like that, some idiot will break when they do their value subtract to the standard open source UEFI offering. -- 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 #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
Original Message From: Blumenthal, Uri - 0553 - MITLL via RT Sent: Friday, August 7, 2015 11:52 AM To: dw...@infradead.org 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 Considering emerging attacks against UEFI I'd be hesitant weakening protection mechanisms, even those that *currently* aren't likely to be used. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: David Woodhouse via RT Sent: Friday, August 7, 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 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 describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. I don't really see a viable use case for this in the UEFI environment. We don't have a way to get these (hypothetical) logs of validly issued certificates into the firmware. We certainly don't normally have the facility to perform HTTPS requests prior to booting the OS. I realise that this scheme allows for asynchronous verification, but it would be utterly pointless to devise a complex scheme for interaction between the firmware and the booted OS, when the whole point is that the OS *isn't* trustworthy if that signature wasn't valid. Even aside from the general rule that *anything* we implement like that, some idiot will break when they do their value subtract to the standard open source UEFI offering. -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
Original Message From: Blumenthal, Uri - 0553 - MITLL via RT Sent: Friday, August 7, 2015 11:52 AM To: dw...@infradead.org 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 Considering emerging attacks against UEFI I'd be hesitant weakening protection mechanisms, even those that *currently* aren't likely to be used. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: David Woodhouse via RT Sent: Friday, August 7, 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 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 describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. I don't really see a viable use case for this in the UEFI environment. We don't have a way to get these (hypothetical) logs of validly issued certificates into the firmware. We certainly don't normally have the facility to perform HTTPS requests prior to booting the OS. I realise that this scheme allows for asynchronous verification, but it would be utterly pointless to devise a complex scheme for interaction between the firmware and the booted OS, when the whole point is that the OS *isn't* trustworthy if that signature wasn't valid. Even aside from the general rule that *anything* we implement like that, some idiot will break when they do their value subtract to the standard open source UEFI offering. -- David Woodhouse Open Source Technology Centre david.woodho...@intel.com Intel Corporation ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
Considering emerging attacks against UEFI I'd be hesitant weakening protection mechanisms, even those that *currently* aren't likely to be used. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: David Woodhouse via RT Sent: Friday, August 7, 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 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 describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. I don't really see a viable use case for this in the UEFI environment. We don't have a way to get these (hypothetical) logs of validly issued certificates into the firmware. We certainly don't normally have the facility to perform HTTPS requests prior to booting the OS. I realise that this scheme allows for asynchronous verification, but it would be utterly pointless to devise a complex scheme for interaction between the firmware and the booted OS, when the whole point is that the OS *isn't* trustworthy if that signature wasn't valid. Even aside from the general rule that *anything* we implement like that, some idiot will break when they do their value subtract to the standard open source UEFI offering. -- David Woodhouse Open 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 #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 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 describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. I don't really see a viable use case for this in the UEFI environment. We don't have a way to get these (hypothetical) logs of validly issued certificates into the firmware. We certainly don't normally have the facility to perform HTTPS requests prior to booting the OS. I realise that this scheme allows for asynchronous verification, but it would be utterly pointless to devise a complex scheme for interaction between the firmware and the booted OS, when the whole point is that the OS *isn't* trustworthy if that signature wasn't valid. Even aside from the general rule that *anything* we implement like that, some idiot will break when they do their value subtract to the standard open source UEFI offering. -- 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 #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 to be used. Can you suggest a practicable means by which this *could* be used? -- 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 #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 to be used. Can you suggest a practicable means by which this *could* be used? -- 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 #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
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. IMHO it would be easier to keep this feature waiting rather than opening a whole new discussion later on. Plus, by just being there it might stimulate people to look for ways to use it. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: David Woodhouse via RT Sent: Friday, August 7, 2015 11:28 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 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? -- 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 #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
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. IMHO it would be easier to keep this feature waiting rather than opening a whole new discussion later on. Plus, by just being there it might stimulate people to look for ways to use it. Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network. Original Message From: David Woodhouse via RT Sent: Friday, August 7, 2015 11:28 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 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? -- dwmw2 smime.p7s Description: S/MIME cryptographic signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #3992] [PATCH] Allow RFC6962 Signed Certificate Timestamps to be disabled
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 SCT support, which in
fact (in the case of UEFI) we don't need anyway.
---
crypto/x509v3/ext_dat.h | 2 ++
crypto/x509v3/v3_scts.c | 2 ++
makevms.com | 1 +
util/mkdef.pl | 6 +-
4 files changed, 10 insertions(+), 1 deletion(-)
diff --git a/crypto/x509v3/ext_dat.h b/crypto/x509v3/ext_dat.h
index 9c3529b..76be621 100644
--- a/crypto/x509v3/ext_dat.h
+++ b/crypto/x509v3/ext_dat.h
@@ -127,8 +127,10 @@ static const X509V3_EXT_METHOD *standard_exts[] = {
v3_idp,
v3_alt[2],
v3_freshest_crl,
+#ifndef OPENSSL_NO_SCT
v3_ct_scts[0],
v3_ct_scts[1],
+#endif
};
/* Number of standard extensions */
diff --git a/crypto/x509v3/v3_scts.c b/crypto/x509v3/v3_scts.c
index 61e5a83..0ffdfb8 100644
--- a/crypto/x509v3/v3_scts.c
+++ b/crypto/x509v3/v3_scts.c
@@ -61,6 +61,7 @@
#include openssl/asn1.h
#include openssl/x509v3.h
+#ifndef OPENSSL_NO_SCT
/* Signature and hash algorithms from RFC 5246 */
#define TLSEXT_hash_sha256 4
@@ -321,3 +322,4 @@ static int i2r_SCT_LIST(X509V3_EXT_METHOD *method,
STACK_OF(SCT) *sct_list,
return 1;
}
+#endif
diff --git a/makevms.com b/makevms.com
index 35c44ec..500b191 100755
--- a/makevms.com
+++ b/makevms.com
@@ -295,6 +295,7 @@ $ CONFIG_LOGICALS := AES,-
RFC3779,-
RMD160,-
RSA,-
+SCT,-
SCTP,-
SEED,-
SOCK,-
diff --git a/util/mkdef.pl b/util/mkdef.pl
index 26fa209..c5aa99d 100755
--- a/util/mkdef.pl
+++ b/util/mkdef.pl
@@ -80,6 +80,8 @@ my @known_algorithms = ( RC2, RC4, RC5, IDEA, DES,
BF,
FP_API, STDIO, SOCK, DGRAM,
# Engines
STATIC_ENGINE, ENGINE, HW, GMP,
+# X.509v3 Signed Certificate Timestamps
+SCT,
# RFC3779
RFC3779,
# TLS
@@ -126,7 +128,7 @@ my $no_md2; my $no_md4; my $no_md5; my $no_sha; my
$no_ripemd; my $no_mdc2;
my $no_rsa; my $no_dsa; my $no_dh; my $no_aes;
my $no_ec; my $no_ecdsa; my $no_ecdh; my $no_engine; my $no_hw;
my $no_fp_api; my $no_static_engine=1; my $no_gmp; my $no_deprecated;
-my $no_rfc3779; my $no_psk; my $no_cms; my $no_capieng;
+my $no_sct; $no_rfc3779; my $no_psk; my $no_cms; my $no_capieng;
my $no_jpake; my $no_srp; my $no_ec2m; my $no_nistp_gcc;
my $no_nextprotoneg; my $no_sctp; my $no_srtp; my $no_ssl_trace;
my $no_unit_test; my $no_ssl3_method; my $no_ocb;
@@ -215,6 +217,7 @@ foreach (@ARGV, split(/ /, $options))
elsif (/^no-engine$/) { $no_engine=1; }
elsif (/^no-hw$/) { $no_hw=1; }
elsif (/^no-gmp$/) { $no_gmp=1; }
+ elsif (/^no-sct$/) { $no_sct=1; }
elsif (/^no-rfc3779$/) { $no_rfc3779=1; }
elsif (/^no-cms$/) { $no_cms=1; }
elsif (/^no-ec2m$/) { $no_ec2m=1; }
@@ -1200,6 +1203,7 @@ sub is_valid
if ($keyword eq FP_API $no_fp_api) { return 0; }
if ($keyword eq STATIC_ENGINE $no_static_engine) {
return 0; }
if ($keyword eq GMP $no_gmp) { return 0; }
+ if ($keyword eq SCT $no_sct) { return 0; }
if ($keyword eq RFC3779 $no_rfc3779) { return 0; }
if ($keyword eq PSK $no_psk) { return 0; }
if ($keyword eq CMS $no_cms) { return 0; }
--
2.4.3
--
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com Intel Corporation
smime.p7s
Description: S/MIME cryptographic signature
___
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
