Re: [edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var cert name and guid
That's fine. I will create one patch directly:). Thanks. Jiaxin > -Original Message- > From: Palmer, Thomas [mailto:thomas.pal...@hpe.com] > Sent: Tuesday, June 28, 2016 12:51 AM > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > Cc: Zimmer, Vincent <vincent.zim...@intel.com>; Li, Ruth > <ruth...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Ye, Ting > <ting...@intel.com>; Hsiung, Harry L <harry.l.hsi...@intel.com>; Shifflett, > Joseph <joseph.shiffl...@hpe.com> > Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var > cert name and guid > > I can create the patch if you tell me where to put everything. Or if you are > like me, may be easier for you to just code it up. Either way is fine > > Thomas > > -Original Message- > From: Wu, Jiaxin [mailto:jiaxin...@intel.com] > Sent: Sunday, June 26, 2016 8:38 PM > To: Palmer, Thomas <thomas.pal...@hpe.com>; edk2-devel@lists.01.org > Cc: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; Zimmer, > Vincent <vincent.zim...@intel.com>; Li, Ruth <ruth...@intel.com>; Fu, > Siyuan <siyuan...@intel.com>; Ye, Ting <ting...@intel.com>; Hsiung, Harry L > <harry.l.hsi...@intel.com> > Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var > cert name and guid > > > > > -Original Message- > > From: Palmer, Thomas [mailto:thomas.pal...@hpe.com] > > Sent: Saturday, June 25, 2016 12:51 AM > > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > > Cc: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; Zimmer, > > Vincent <vincent.zim...@intel.com>; Li, Ruth <ruth...@intel.com>; Fu, > > Siyuan <siyuan...@intel.com>; Ye, Ting <ting...@intel.com>; Hsiung, > > Harry L <harry.l.hsi...@intel.com> > > Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS > > var cert name and guid > > > > Jiaxin, et al ~ > > > > I noticed while using the TLS feature that the GUID and Variable Name > > define were being re-defined in multiple spots. Currently, if someone > > were to write a UEFI application, there is no single include file that > > would provide the variable name in a define. As a matter of sheer > > better programming practices, the Variable Name define and GUID should > > be put into central locations and not copied all over the codebase. > > Yes, I agree to put it into a single file. I can create another patch to > refine it. If > you would like to provide it, I'm fine:). > > > > > With regards to GlobalVariable.h: I realize now this is not the place to > > put it. > > Because our variable has a unique GUID, we would have to create a new > > MdePkg/Include/Guid/ header file to hold the define, much like > > ImageAuthentication.h which is also used by VarCheckUefiLibNullClass.c. > > > > I put the GUID definition into CryptoPkg.dec because the TlsLib and > > OpenSSL library are there. I can be persuaded to have it in > > NetworkPkg.dec as it's modules are the ultimate consumers of the > > variable. CryptoPkg is simply providing libraries. > > > > With regards to "[TlsCaCertificate is] only a private variable": This > > variable > is > > super critical to secure TLS communication. It is so critical that we > > are even discussing how to protect it in runtime from malicious/careless > modifications. > > We understand that if this variable were compromised that there could > > be severe security implications that follow. This variable must be > > respected properly. > > Actually, I don't have the strong opinion about the security of this variable. > TlsCaCertificate is used to store the public certificate that means everyone > can get and use it. Take windows OS as an example, any login user > can/should have the ability to modify this kind of certificate, we can think > it's > not protected except for the system-level access control. This is the reason > why I put it into plaintext currently. But I also agree that protecting this > variable is also meaningful because we no such access control. As for how to > protect it, it is another question we discussed before. > > > > > For that reason, I'd argue that we should put the TlsCaCertificate > > into the UEFI Spec. When it gets put into the spec I do not know, but > > we should be aiming for that. It is too important to security to not be in > > the > spec. > > In my opinion, TlsCaCertificate variable is just a temporary scenario to hold > the certificate, not the fin
Re: [edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var cert name and guid
I can create the patch if you tell me where to put everything. Or if you are like me, may be easier for you to just code it up. Either way is fine Thomas -Original Message- From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Sunday, June 26, 2016 8:38 PM To: Palmer, Thomas <thomas.pal...@hpe.com>; edk2-devel@lists.01.org Cc: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; Zimmer, Vincent <vincent.zim...@intel.com>; Li, Ruth <ruth...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Ye, Ting <ting...@intel.com>; Hsiung, Harry L <harry.l.hsi...@intel.com> Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var cert name and guid > -Original Message- > From: Palmer, Thomas [mailto:thomas.pal...@hpe.com] > Sent: Saturday, June 25, 2016 12:51 AM > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > Cc: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; Zimmer, > Vincent <vincent.zim...@intel.com>; Li, Ruth <ruth...@intel.com>; Fu, > Siyuan <siyuan...@intel.com>; Ye, Ting <ting...@intel.com>; Hsiung, > Harry L <harry.l.hsi...@intel.com> > Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS > var cert name and guid > > Jiaxin, et al ~ > > I noticed while using the TLS feature that the GUID and Variable Name > define were being re-defined in multiple spots. Currently, if someone > were to write a UEFI application, there is no single include file that > would provide the variable name in a define. As a matter of sheer > better programming practices, the Variable Name define and GUID should > be put into central locations and not copied all over the codebase. Yes, I agree to put it into a single file. I can create another patch to refine it. If you would like to provide it, I'm fine:). > > With regards to GlobalVariable.h: I realize now this is not the place to put > it. > Because our variable has a unique GUID, we would have to create a new > MdePkg/Include/Guid/ header file to hold the define, much like > ImageAuthentication.h which is also used by VarCheckUefiLibNullClass.c. > > I put the GUID definition into CryptoPkg.dec because the TlsLib and > OpenSSL library are there. I can be persuaded to have it in > NetworkPkg.dec as it's modules are the ultimate consumers of the > variable. CryptoPkg is simply providing libraries. > > With regards to "[TlsCaCertificate is] only a private variable": This > variable is > super critical to secure TLS communication. It is so critical that we > are even discussing how to protect it in runtime from malicious/careless > modifications. > We understand that if this variable were compromised that there could > be severe security implications that follow. This variable must be > respected properly. Actually, I don't have the strong opinion about the security of this variable. TlsCaCertificate is used to store the public certificate that means everyone can get and use it. Take windows OS as an example, any login user can/should have the ability to modify this kind of certificate, we can think it's not protected except for the system-level access control. This is the reason why I put it into plaintext currently. But I also agree that protecting this variable is also meaningful because we no such access control. As for how to protect it, it is another question we discussed before. > > For that reason, I'd argue that we should put the TlsCaCertificate > into the UEFI Spec. When it gets put into the spec I do not know, but > we should be aiming for that. It is too important to security to not be in > the spec. In my opinion, TlsCaCertificate variable is just a temporary scenario to hold the certificate, not the finally or general UEFI solution for the certificate management. So, it's pointless to standardize it, keeping it as a private variable is fine currently. > > Not only that, but once this is in the spec it will enable 3rd party > applications to re-use this variable too. I've personally talked with > one such developer who is eagerly awaiting a variable that is a secure > UEFI standard for Certificate Authority storage. > > Thomas > > -Original Message- > From: Wu, Jiaxin [mailto:jiaxin...@intel.com] > Sent: Thursday, June 23, 2016 9:56 PM > To: Palmer, Thomas <thomas.pal...@hpe.com>; edk2-devel@lists.01.org > Cc: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; Zimmer, > Vincent <vincent.zim...@intel.com>; Li, Ruth <ruth...@intel.com>; Fu, > Siyuan <siyuan...@intel.com>; Ye, Ting <ting...@intel.com>; Hsiung, > Harry L <harry.l.hsi...@intel.com> > Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: C
Re: [edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var cert name and guid
> -Original Message- > From: Palmer, Thomas [mailto:thomas.pal...@hpe.com] > Sent: Saturday, June 25, 2016 12:51 AM > To: Wu, Jiaxin <jiaxin...@intel.com>; edk2-devel@lists.01.org > Cc: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; Zimmer, > Vincent <vincent.zim...@intel.com>; Li, Ruth <ruth...@intel.com>; Fu, > Siyuan <siyuan...@intel.com>; Ye, Ting <ting...@intel.com>; Hsiung, Harry L > <harry.l.hsi...@intel.com> > Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var > cert name and guid > > Jiaxin, et al ~ > > I noticed while using the TLS feature that the GUID and Variable Name define > were being re-defined in multiple spots. Currently, if someone were to write > a UEFI application, there is no single include file that would provide the > variable name in a define. As a matter of sheer better programming practices, > the Variable Name define and GUID should be put into central locations and > not copied all over the codebase. Yes, I agree to put it into a single file. I can create another patch to refine it. If you would like to provide it, I'm fine:). > > With regards to GlobalVariable.h: I realize now this is not the place to put > it. > Because our variable has a unique GUID, we would have to create a new > MdePkg/Include/Guid/ header file to hold the define, much like > ImageAuthentication.h which is also used by VarCheckUefiLibNullClass.c. > > I put the GUID definition into CryptoPkg.dec because the TlsLib and OpenSSL > library are there. I can be persuaded to have it in NetworkPkg.dec as it's > modules are the ultimate consumers of the variable. CryptoPkg is simply > providing libraries. > > With regards to "[TlsCaCertificate is] only a private variable": This > variable is > super critical to secure TLS communication. It is so critical that we are > even > discussing how to protect it in runtime from malicious/careless modifications. > We understand that if this variable were compromised that there could be > severe security implications that follow. This variable must be respected > properly. Actually, I don't have the strong opinion about the security of this variable. TlsCaCertificate is used to store the public certificate that means everyone can get and use it. Take windows OS as an example, any login user can/should have the ability to modify this kind of certificate, we can think it's not protected except for the system-level access control. This is the reason why I put it into plaintext currently. But I also agree that protecting this variable is also meaningful because we no such access control. As for how to protect it, it is another question we discussed before. > > For that reason, I'd argue that we should put the TlsCaCertificate into the > UEFI Spec. When it gets put into the spec I do not know, but we should be > aiming for that. It is too important to security to not be in the spec. In my opinion, TlsCaCertificate variable is just a temporary scenario to hold the certificate, not the finally or general UEFI solution for the certificate management. So, it's pointless to standardize it, keeping it as a private variable is fine currently. > > Not only that, but once this is in the spec it will enable 3rd party > applications > to re-use this variable too. I've personally talked with one such developer > who is eagerly awaiting a variable that is a secure UEFI standard for > Certificate Authority storage. > > Thomas > > -Original Message- > From: Wu, Jiaxin [mailto:jiaxin...@intel.com] > Sent: Thursday, June 23, 2016 9:56 PM > To: Palmer, Thomas <thomas.pal...@hpe.com>; edk2-devel@lists.01.org > Cc: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; Zimmer, > Vincent <vincent.zim...@intel.com>; Li, Ruth <ruth...@intel.com>; Fu, > Siyuan <siyuan...@intel.com>; Ye, Ting <ting...@intel.com>; Hsiung, Harry L > <harry.l.hsi...@intel.com> > Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var > cert name and guid > > Hi Thomas, > One point we should know that TLS cert variable is not defined in UEFI Spec, > it's only private variable used to configure the CA certificate. So, we can't > add > this variable check into VarCheckUefiLib. VarCheckUefiLib only contain the > variables defined in UEFI spec, private variable is not allowed. > EDKII_VAR_CHECK_PROTOCOL could be located directly If we truly want to > check one private variable. > > In addition, I think defining TlsCaCertificate in GlobalVariable.h is also > unreasonable. This file should only contain globally defined variables with > gEfiGlobalVariableGuid. What do you think? > > Moreove
Re: [edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var cert name and guid
Jiaxin, et al ~ I noticed while using the TLS feature that the GUID and Variable Name define were being re-defined in multiple spots. Currently, if someone were to write a UEFI application, there is no single include file that would provide the variable name in a define. As a matter of sheer better programming practices, the Variable Name define and GUID should be put into central locations and not copied all over the codebase. With regards to GlobalVariable.h: I realize now this is not the place to put it. Because our variable has a unique GUID, we would have to create a new MdePkg/Include/Guid/ header file to hold the define, much like ImageAuthentication.h which is also used by VarCheckUefiLibNullClass.c. I put the GUID definition into CryptoPkg.dec because the TlsLib and OpenSSL library are there. I can be persuaded to have it in NetworkPkg.dec as it's modules are the ultimate consumers of the variable. CryptoPkg is simply providing libraries. With regards to "[TlsCaCertificate is] only a private variable": This variable is super critical to secure TLS communication. It is so critical that we are even discussing how to protect it in runtime from malicious/careless modifications. We understand that if this variable were compromised that there could be severe security implications that follow. This variable must be respected properly. For that reason, I'd argue that we should put the TlsCaCertificate into the UEFI Spec. When it gets put into the spec I do not know, but we should be aiming for that. It is too important to security to not be in the spec. Not only that, but once this is in the spec it will enable 3rd party applications to re-use this variable too. I've personally talked with one such developer who is eagerly awaiting a variable that is a secure UEFI standard for Certificate Authority storage. Thomas -Original Message- From: Wu, Jiaxin [mailto:jiaxin...@intel.com] Sent: Thursday, June 23, 2016 9:56 PM To: Palmer, Thomas <thomas.pal...@hpe.com>; edk2-devel@lists.01.org Cc: El-Haj-Mahmoud, Samer <samer.el-haj-mahm...@hpe.com>; Zimmer, Vincent <vincent.zim...@intel.com>; Li, Ruth <ruth...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Ye, Ting <ting...@intel.com>; Hsiung, Harry L <harry.l.hsi...@intel.com> Subject: RE: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var cert name and guid Hi Thomas, One point we should know that TLS cert variable is not defined in UEFI Spec, it's only private variable used to configure the CA certificate. So, we can't add this variable check into VarCheckUefiLib. VarCheckUefiLib only contain the variables defined in UEFI spec, private variable is not allowed. EDKII_VAR_CHECK_PROTOCOL could be located directly If we truly want to check one private variable. In addition, I think defining TlsCaCertificate in GlobalVariable.h is also unreasonable. This file should only contain globally defined variables with gEfiGlobalVariableGuid. What do you think? Moreover, Why put the GUID definition in CryptoPkg.dec? It looks so strange. Thanks. Jiaxin > -Original Message- > From: Thomas Palmer [mailto:thomas.pal...@hpe.com] > Sent: Friday, June 24, 2016 2:14 AM > To: edk2-devel@lists.01.org > Cc: samer.el-haj-mahm...@hpe.com; Wu, Jiaxin <jiaxin...@intel.com>; > Zimmer, Vincent <vincent.zim...@intel.com>; Li, Ruth > <ruth...@intel.com>; Fu, Siyuan <siyuan...@intel.com>; Ye, Ting > <ting...@intel.com>; Hsiung, Harry L <harry.l.hsi...@intel.com>; > Thomas Palmer <thomas.pal...@hpe.com> > Subject: [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var > cert name and guid > > Put the TLS cert variable name define into GlobalVariable.h and create > a GUID for it in CryptoPkg.dec. Describe the minimum size and expected > variable attributes in VarCheckUefiLib. > > Contributed-under: TianoCore Contribution Agreement 1.0 > Signed-off-by: Thomas Palmer <thomas.pal...@hpe.com> > --- > CryptoPkg/CryptoPkg.dec| 5 > .../Library/VarCheckUefiLib/VarCheckUefiLib.inf| 3 +++ > .../VarCheckUefiLib/VarCheckUefiLibNullClass.c | 28 > +- > MdePkg/Include/Guid/GlobalVariable.h | 7 ++ > NetworkPkg/HttpDxe/HttpDxe.inf | 7 +- > NetworkPkg/HttpDxe/HttpsSupport.c | 7 +++--- > NetworkPkg/HttpDxe/HttpsSupport.h | 11 + > NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf | 3 +++ > NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c| 11 - > NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h| 11 + > 10 files changed, 61 insertions(+), 32 deletions(-) > > diff --git a/CryptoPkg/Crypt
[edk2] [PATCH] [edk2-staging/HTTPS-TLS][PATCH]: Centralize TLS var cert name and guid
Put the TLS cert variable name define into GlobalVariable.h and create a GUID for it in CryptoPkg.dec. Describe the minimum size and expected variable attributes in VarCheckUefiLib. Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Thomas Palmer--- CryptoPkg/CryptoPkg.dec| 5 .../Library/VarCheckUefiLib/VarCheckUefiLib.inf| 3 +++ .../VarCheckUefiLib/VarCheckUefiLibNullClass.c | 28 +- MdePkg/Include/Guid/GlobalVariable.h | 7 ++ NetworkPkg/HttpDxe/HttpDxe.inf | 7 +- NetworkPkg/HttpDxe/HttpsSupport.c | 7 +++--- NetworkPkg/HttpDxe/HttpsSupport.h | 11 + NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigDxe.inf | 3 +++ NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.c| 11 - NetworkPkg/TlsAuthConfigDxe/TlsAuthConfigImpl.h| 11 + 10 files changed, 61 insertions(+), 32 deletions(-) diff --git a/CryptoPkg/CryptoPkg.dec b/CryptoPkg/CryptoPkg.dec index ea02ad7..fe04b7d 100644 --- a/CryptoPkg/CryptoPkg.dec +++ b/CryptoPkg/CryptoPkg.dec @@ -5,6 +5,7 @@ # It also provides a test application to test libraries. # # Copyright (c) 2009 - 2016, Intel Corporation. All rights reserved. +# (C) Copyright 2016 Hewlett Packard Enterprise Development LP # This program and the accompanying materials # are licensed and made available under the terms and conditions of the BSD License # which accompanies this distribution. The full text of the license may be found at @@ -35,6 +36,10 @@ ## TlsLib|Include/Library/TlsLib.h +[Guids] + ## GUID used for TLS Certificate verification + gEfiTlsCaCertificateGuid = {0xfd2340D0, 0x3dab, 0x4349, {0xa6, 0xc7, 0x3b, 0x4f, 0x12, 0xb4, 0x8e, 0xae}} + [Protocols] ## Include/Protocol/RuntimeCrypt.h gEfiRuntimeCryptProtocolGuid = { 0xe1475e0c, 0x1746, 0x4802, {0x86, 0x2e, 0x1, 0x1c, 0x2c, 0x2d, 0x9d, 0x86 }} diff --git a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf index 128c44d..945397a 100644 --- a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf +++ b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLib.inf @@ -36,6 +36,7 @@ [Packages] MdePkg/MdePkg.dec MdeModulePkg/MdeModulePkg.dec + CryptoPkg/CryptoPkg.dec [LibraryClasses] BaseLib @@ -81,6 +82,8 @@ ## SOMETIMES_CONSUMES ## Variable:L"SysPrep" ## SOMETIMES_CONSUMES ## Variable:L"Key" gEfiGlobalVariableGuid + ## SOMETIMES_CONSUMES ## Variable:L"TlsCaCertificate" + gEfiTlsCaCertificateGuid ## SOMETIMES_CONSUMES ## Variable:L"DB" ## SOMETIMES_CONSUMES ## Variable:L"DBX" ## SOMETIMES_CONSUMES ## Variable:L"DBT" diff --git a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c index 8f7126e..b820659 100644 --- a/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c +++ b/MdeModulePkg/Library/VarCheckUefiLib/VarCheckUefiLibNullClass.c @@ -2,6 +2,7 @@ Implementation functions and structures for var check uefi library. Copyright (c) 2015 - 2016, Intel Corporation. All rights reserved. +(C) Copyright 2016 Hewlett Packard Enterprise Development LP This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License which accompanies this distribution. The full text of the license may be found at @@ -671,10 +672,26 @@ UEFI_DEFINED_VARIABLE_ENTRY mHwErrRecVariable = { NULL }; +// +// EFI_TLS_CA_CERTIFICATE_VARIABLE +// +UEFI_DEFINED_VARIABLE_ENTRY mTlsCaCertificateVariable = { + EFI_TLS_CA_CERTIFICATE_VARIABLE, + { +VAR_CHECK_VARIABLE_PROPERTY_REVISION, +0, +VARIABLE_ATTRIBUTE_NV_BS_RT, +sizeof (EFI_SIGNATURE_LIST), +MAX_UINTN + }, + NULL +}; + EFI_GUID *mUefiDefinedGuid[] = { , , - + , + , }; /** @@ -915,6 +932,15 @@ VariablePropertySetUefiDefined ( , ); + + // + // EFI_TLS_CA_CERTIFICATE_VARIABLE + // + VarCheckLibVariablePropertySet ( +mTlsCaCertificateVariable.Name, +, + +); } /** diff --git a/MdePkg/Include/Guid/GlobalVariable.h b/MdePkg/Include/Guid/GlobalVariable.h index 0804236..aebf56d 100644 --- a/MdePkg/Include/Guid/GlobalVariable.h +++ b/MdePkg/Include/Guid/GlobalVariable.h @@ -2,6 +2,7 @@ GUID for EFI (NVRAM) Variables. Copyright (c) 2006 - 2016, Intel Corporation. All rights reserved. + (C) Copyright 2016 Hewlett Packard Enterprise Development LP This program and the accompanying materials are licensed and made available under the terms and conditions of the BSD License which accompanies this distribution. The full text of the license may be found at @@ -189,4 +190,10 @@ extern EFI_GUID gEfiGlobalVariableGuid; /// #define EFI_VENDOR_KEYS_VARIABLE_NAME