Re: IBM names new CEO
Just reporting and not my personal opinion (though I do have some IBM shares) but during her tenure IBM was... https://www.cnbc.com/2020/01/31/ibm-was-worst-performing-large-cap-tech-stock-during-romettys-tenure.html On Fri, Jan 31, 2020 at 7:17 PM Edward Finnell < 000248cce9f3-dmarc-requ...@listserv.ua.edu> wrote: > > https://www.bloomberg.com/news/articles/2020-01-30/ibm-names-arvind-krishna-as-ceo-rometty-to-retire-at-year-s-end > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Who do you trust? trivia
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I always thought it interesting that CAs required a driver's license to register... Adam Sent from ProtonMail mobile \ Original Message On Jan 31, 2020, 3:19 PM, Jesse 1 Robinson < jesse1.robin...@sce.com> wrote: > > > > This construction does not bother me nearly as much as the hyper-corrected > inverse: Whom should provide the certificate? Ugh. > > . > . > J.O.Skip Robinson > Southern California Edison Company > Electric Dragon Team Paddler > SHARE MVS Program Co-Manager > 323-715-0595 Mobile > 626-543-6132 Office ⇐=== NEW > robin...@sce.com > > \-Original Message- > From: IBM Mainframe Discussion List On Behalf Of > Charles Mills > Sent: Friday, January 31, 2020 2:52 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: (External):Re: Who do you trust? trivia > > CAUTION EXTERNAL EMAIL > > The allusion was intentional. > > Someone wrote me offline to criticize the use of who rather than whom. I > responded that I doubted Bo Diddley would have had a hit with "Whom Do You > Love"? In his case, I believe there may also have been an allusion to > "hoo-doo." > > Charles > > > \-Original Message- > From: IBM Mainframe Discussion List \[mailto:IBM-MAIN@LISTSERV.UA.EDU\] On > Behalf Of Chris Hoelscher > Sent: Friday, January 31, 2020 1:54 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Who do you trust? trivia > > Trivia: Who do you trust was an American game show primarily from 1957 -> > 1962, hosted by Johnny Carson and his announced Ed McMahon - it was on the > basis of his exposure in this endeavor that he was hired to replace Jack Paar > on The tonight Show > > > \-- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -BEGIN PGP SIGNATURE- Version: ProtonMail wsBmBAEBCAAQBQJeNLaVCRBiYga9B/zq3QAKCRBiYga9B/zq3ax8B/9/FYty i+IoBzIxsUqhWAG4tMG/sgCHsiJkEu+sNs/ROXZYKYh8SAl6K1xhkf214W8o 3wOqAq//hMjFLPyE1/CoA20IgdZtikWNsQUuIJBRWQrsa/okW5xuv+Tn6ViO kA2JNnCw0njIEKfdDtfdNIucNH0LB58N5q7aK3qV58vTPT3y26hyMdmcymj9 Xw2l31BTmJEzudTW4F9NJLTAo4f/+LarSKqr7MMpw/F7Ufw6avWGfTOnuRJi AdVkO/hsqyw900dA4uAPFPnQR9PwV1dRFwWScqhMUqhWxuBx7vtb3S6+ZB/p YWy4fjAeBoJ+lNyAbWmqUH0PW+1JPdzksTqU =LDTj -END PGP SIGNATURE- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Who do you trust? trivia
This construction does not bother me nearly as much as the hyper-corrected inverse: Whom should provide the certificate? Ugh. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: Friday, January 31, 2020 2:52 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: (External):Re: Who do you trust? trivia CAUTION EXTERNAL EMAIL The allusion was intentional. Someone wrote me offline to criticize the use of who rather than whom. I responded that I doubted Bo Diddley would have had a hit with "Whom Do You Love"? In his case, I believe there may also have been an allusion to "hoo-doo." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chris Hoelscher Sent: Friday, January 31, 2020 1:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Who do you trust? trivia Trivia: Who do you trust was an American game show primarily from 1957 -> 1962, hosted by Johnny Carson and his announced Ed McMahon - it was on the basis of his exposure in this endeavor that he was hired to replace Jack Paar on The tonight Show -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Who do you trust? trivia
The allusion was intentional. Someone wrote me offline to criticize the use of who rather than whom. I responded that I doubted Bo Diddley would have had a hit with "Whom Do You Love"? In his case, I believe there may also have been an allusion to "hoo-doo." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Chris Hoelscher Sent: Friday, January 31, 2020 1:54 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Who do you trust? trivia Trivia: Who do you trust was an American game show primarily from 1957 -> 1962, hosted by Johnny Carson and his announced Ed McMahon - it was on the basis of his exposure in this endeavor that he was hired to replace Jack Paar on The tonight Show -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Who do you trust? trivia
Very interesting, to tell the truth. On 1/31/2020 1:54 PM, Chris Hoelscher wrote: Trivia: Who do you trust was an American game show primarily from 1957 -> 1962, hosted by Johnny Carson and his announced Ed McMahon - it was on the basis of his exposure in this endeavor that he was hired to replace Jack Paar on The tonight Show Thank You, Chris Hoelscher| Lead Database Administrator | IBM Global Technical Services| T 502.476.2538 or 502.407.7266 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Who do you trust? trivia
Trivia: Who do you trust was an American game show primarily from 1957 -> 1962, hosted by Johnny Carson and his announced Ed McMahon - it was on the basis of his exposure in this endeavor that he was hired to replace Jack Paar on The tonight Show Thank You, Chris Hoelscher| Lead Database Administrator | IBM Global Technical Services| T 502.476.2538 or 502.407.7266 -Original Message- From: IBM Mainframe Discussion List On Behalf Of Gord Tomlin Sent: Friday, January 31, 2020 10:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: [IBM-MAIN] Who do you trust? (What CA's do you trust?) On 2020-01-30 18:06, Charles Mills wrote: > Who do you trust? What CERTAUTH certificates do you have installed and > trusted? > > > > I am contemplating purchasing an FTP server certificate for z/OS > client FTP access. I'd like to know which CA's are most likely to > already be installed in customers' CERTAUTH keyrings. > > > > IBM used to ship certificates for VeriSign, Thawte, Integrion, > Entrust, Equifax and ICP. Are those still popularly-trusted CAs? > > > > What about Comodo? They are the largest CA. What about GoDaddy? What > about Let's Encrypt, the no-charge CA? > > > > There's been a lot of consolidation. Equifax is GeoTrust is VeriSign. > Thawte and Symantec are now DigiCert. FWIW, from Mozilla: "Most browsers, not just Firefox, do not trust certificates by GeoTrust, RapidSSL, Symantec, Thawte, and VeriSign because these certificate authorities failed to follow security practices in the past." https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsupport.mozilla.org%2Fen-US%2Fkb%2Fwhat-does-your-connection-is-not-secure-meandata=02%7C01%7Cchoelscher%40humana.com%7C242db786a7504ba14cd308d7a666453c%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C0%7C637160830484293588sdata=00dMNUxvGtb5pZlc%2BFjPjN%2Bkbdamrz9sZdJIOkRgTcQ%3Dreserved=0 -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Factionsoftware.com%2Fsupport%2Fdata=02%7C01%7Cchoelscher%40humana.com%7C242db786a7504ba14cd308d7a666453c%7C56c62bbe85984b859e511ca753fa50f2%7C1%7C0%7C637160830484303579sdata=WpGwGGjwknswpjBfoPWd%2FAhVr0VeCBCRaFcWQ4SWvBo%3Dreserved=0 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information transmitted is intended only for the person or entity to which it is addressed and may contain CONFIDENTIAL material. If you receive this material/information in error, please contact the sender and delete or destroy the material/information. Humana Inc. and its subsidiaries comply with applicable Federal civil rights laws and do not discriminate on the basis of race, color, national origin, age, disability, sex, sexual orientation, gender identity, or religion. Humana Inc. and its subsidiaries do not exclude people or treat them differently because of race, color, national origin, age, disability, sex, sexual orientation, gender identity, or religion. English: ATTENTION: If you do not speak English, language assistance services, free of charge, are available to you. Call 1‐877‐320‐1235 (TTY: 711). Español (Spanish): ATENCIÓN: Si habla español, tiene a su disposición servicios gratuitos de asistencia lingüística. Llame al 1‐877‐320‐1235 (TTY: 711). 繁體中文(Chinese)：注意：如果您使用繁體中文，您可以免費獲得語言援助 服務。請致電 1‐877‐320‐1235 (TTY: 711)。 Kreyòl Ayisyen (Haitian Creole): ATANSION: Si w pale Kreyòl Ayisyen, gen sèvis èd pou lang ki disponib gratis pou ou. Rele 1‐877‐320‐1235 (TTY: 711). Polski (Polish): UWAGA: Jeżeli mówisz po polsku, możesz skorzystać z bezpłatnej pomocy językowej. Zadzwoń pod numer 1‐877‐320‐1235 (TTY: 711). 한국어 (Korean): 주의: 한국어를 사용하시는 경우, 언어 지원 서비스를 무료로 이용하실 수 있습니다. 1‐877‐320‐1235 (TTY: 711)번으로 전화해 주십시오. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Connect Direct Secure + - Certificate in use
Your best bet is to use the java keytool utility by connecting to your CD host and port. This will print the cert presented when you connect keytool -printcert -sslserver $host[:$port] Jerry Whitteridge Delivery Manager / Mainframe Architect GTS - Safeway Account 602 527 4871 Mobile jerry.whitteri...@ibm.com IBM Services IBM Mainframe Discussion List wrote on 01/31/2020 10:54:52 AM: > From: Steve David > To: IBM-MAIN@LISTSERV.UA.EDU > Date: 01/31/2020 10:56 AM > Subject: [EXTERNAL] Connect Direct Secure + - Certificate in use > Sent by: IBM Mainframe Discussion List > > Hi All, > We are planning to upgrade CD V4.8 to V5.2, we lost the key to open the key > database which used for secure+ encryption. We have used GSKKYMAN utility > to generate the certificate and signed by third party CA. > > SECURE.SSL.PATH.PREFIX =/usr/lpp/connectd/conn.kdb, > > We have couple of certificates mentioned in above path, out of which one is > expiring in Mar 2020 and other one in Nov 2020, Is there a way to find > which certificate is in use for SSL > Encryption? > > Thanks > Steve > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Connect Direct Secure + - Certificate in use
I think a gsk trace would be a helpful solution. On Fri, Jan 31, 2020 at 1:55 PM Steve David wrote: > Hi All, > We are planning to upgrade CD V4.8 to V5.2, we lost the key to open the key > database which used for secure+ encryption. We have used GSKKYMAN utility > to generate the certificate and signed by third party CA. > > SECURE.SSL.PATH.PREFIX =/usr/lpp/connectd/conn.kdb, > > We have couple of certificates mentioned in above path, out of which one is > expiring in Mar 2020 and other one in Nov 2020, Is there a way to find > which certificate is in use for SSL > Encryption? > > Thanks > Steve > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- Politics: Poli (many) - tics (blood sucking parasites) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Connect Direct Secure + - Certificate in use
Hi All, We are planning to upgrade CD V4.8 to V5.2, we lost the key to open the key database which used for secure+ encryption. We have used GSKKYMAN utility to generate the certificate and signed by third party CA. SECURE.SSL.PATH.PREFIX =/usr/lpp/connectd/conn.kdb, We have couple of certificates mentioned in above path, out of which one is expiring in Mar 2020 and other one in Nov 2020, Is there a way to find which certificate is in use for SSL Encryption? Thanks Steve -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: [External] Re: 3592-E07
Tony, I'm not impressed with the writing in the article. Parts of it are misleading. The picture showing the disaster and the RPO/RTO timelines on it are OK, but this paragraph leaves a bit to be desired: For example, if you have a 4-hour RPO for an application then you will have a maximum 4-hour gap between backup and data loss. Having a 4-hour RPO does not necessarily mean you will lose 4 hours' worth of data. Should a word processing application go down at midnight and come up by 1:15 am, you might not have much (or any) data to lose. But if a busy application goes down at 10 am and isn't restored until 2:00 pm, you will potentially lose 4 hours' worth of highly valuable, perhaps irreplaceable data. In this case, arrange for more frequent backup that will let you hit your application-specific RPO. The example of a busy application going down at 10 and not being restored until 2 has nothing to do with a 4 hour RPO, they're describing a 4 hour RTO. The RPO could still be 5 minutes, if the data had been backed up at 9:55 and the application went down - and trashed the data requiring a data restore - at 10:00. In a nutshell, RPO has to do with how much elapsed time you can handle between the time a backup is done and a data loss occurs, and RTO is after the loss, how long you can handle being down before your applications are back. The example in the article didn't show that. Rex -Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Thigpen Sent: Friday, January 31, 2020 10:44 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: [External] Re: 3592-E07 Radoslaw, I think you don't understand RPO correctly. read: https://www.enterprisestorageforum.com/storage-management/rpo-and-rto-understanding-the-differences.html Tony Thigpen R.S. wrote on 1/31/20 11:24 AM: > W dniu 31.01.2020 o 07:07, Timothy Sipples pisze: >> Radoslaw Skorupka wrote: >>> To complement and clarify: when using physical tapes (* see below) >>> your RPO and RTO may be 36 hours or zero. >> No, your RPO certainly won't be zero. A backup is a (hopefully >> useful) representation of data as it existed historically, at some >> particular past >> >> moment(s) in time. It takes some amount of time to run a backup -- >> let's call that "minutes or longer" for working purposes. Backups run >> at periodic intervals -- let's call that "hourly or less often" for >> working purposes. Your backups, without something else, facilitate a >> best case RPO >> >> that's as long/big as the maximum (worst case) time elapsed since the >> start of your last good backup. That practically always(*) means a >> RPO of "a couple hours or more." >> >> A long/big RPO usually holds RTO back too, but there are a few rare >> exceptions. On the other hand, it's quite possible to have a long/big >> RTO with a RPO of zero. >> >> (*) Why not "always"? Exotic, contrived exceptions might be possible, >> such >> >> as custom software that synchronizes writes directly to local and >> remote tape. > > No, my RPO *is* zero. We do not talk about backup itself, which is > ...the same for VTS, MAGSTAR, USB stick, etc. Despite of backup media > the backup is representation of historical data. > What I'm talking about is time delta between primary and secondary > (local, remote) backup copies. > And again: some (typical?) modes of VTS replication are not > synchronous, so there is time delta between local copy is closed (and > marked as done) and remote copy is also finished. For duplex write in > HSM both tapes are being written simultaneously, so end of backup job > means you have both copies ready. > > Note: Earlier you mentioned that PTAM makes RPO longer. Yes, it *adds* > the time to "historical representation". VTS non-synchronous mode adds > the time also (much less). but HSM duplex write add zero. > -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN The information contained in this message is confidential, protected from disclosure and may be legally privileged. If the reader of this message is not the intended recipient or an employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, distribution, copying, or any action taken or action omitted in reliance on it, is strictly prohibited and may be unlawful. If you have received this communication in error, please notify us immediately by replying to this message and destroy the material in its entirety, whether in electronic or hard copy format. Thank you. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3592-E07
Radoslaw, I think you don't understand RPO correctly. read: https://www.enterprisestorageforum.com/storage-management/rpo-and-rto-understanding-the-differences.html Tony Thigpen R.S. wrote on 1/31/20 11:24 AM: W dniu 31.01.2020 o 07:07, Timothy Sipples pisze: Radoslaw Skorupka wrote: To complement and clarify: when using physical tapes (* see below) your RPO and RTO may be 36 hours or zero. No, your RPO certainly won't be zero. A backup is a (hopefully useful) representation of data as it existed historically, at some particular past moment(s) in time. It takes some amount of time to run a backup -- let's call that "minutes or longer" for working purposes. Backups run at periodic intervals -- let's call that "hourly or less often" for working purposes. Your backups, without something else, facilitate a best case RPO that's as long/big as the maximum (worst case) time elapsed since the start of your last good backup. That practically always(*) means a RPO of "a couple hours or more." A long/big RPO usually holds RTO back too, but there are a few rare exceptions. On the other hand, it's quite possible to have a long/big RTO with a RPO of zero. (*) Why not "always"? Exotic, contrived exceptions might be possible, such as custom software that synchronizes writes directly to local and remote tape. No, my RPO *is* zero. We do not talk about backup itself, which is ...the same for VTS, MAGSTAR, USB stick, etc. Despite of backup media the backup is representation of historical data. What I'm talking about is time delta between primary and secondary (local, remote) backup copies. And again: some (typical?) modes of VTS replication are not synchronous, so there is time delta between local copy is closed (and marked as done) and remote copy is also finished. For duplex write in HSM both tapes are being written simultaneously, so end of backup job means you have both copies ready. Note: Earlier you mentioned that PTAM makes RPO longer. Yes, it *adds* the time to "historical representation". VTS non-synchronous mode adds the time also (much less). but HSM duplex write add zero. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Final Reminder - Next meeting of the GSE UK Security Working Group - 6th February 2020
Greetings, A gentle reminder that the next meeting of the GSE UK Security Working Group, will take place on Thursday 6th February 2020 at the offices of SAS in Bishopsgate, Central London. Registration is still open, which you can access via our Events page > http://www.racf.gse.org.uk/content/content_events.php - the agenda has also been published, which you can download from the same link. Highlights from the agenda include: * Introduction from our host, SAS * New Pen test War Stories * From the CISO’s perspective * The story of an application owners’ quest to clean-up their act * I smell a rat - A Windows Forensic approach * IBM zSecure Update * All hands session to share ideas, problems, best practices etc * Opportunities to network throughout the day with likeminded professionals The agenda is a mixture of technical and non-technical content to cater for a variety of professionals. We also offer the opportunity to earn CPE points for attending the meeting for those of you who are required to maintain professional certifications. We hope that you will be able to join us for the day. For those of you who have already registered, you will receive joining instructions early next week. Regards Mark Wilson and Jamie Pease -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: 3592-E07
W dniu 31.01.2020 o 07:07, Timothy Sipples pisze: Radoslaw Skorupka wrote: To complement and clarify: when using physical tapes (* see below) your RPO and RTO may be 36 hours or zero. No, your RPO certainly won't be zero. A backup is a (hopefully useful) representation of data as it existed historically, at some particular past moment(s) in time. It takes some amount of time to run a backup -- let's call that "minutes or longer" for working purposes. Backups run at periodic intervals -- let's call that "hourly or less often" for working purposes. Your backups, without something else, facilitate a best case RPO that's as long/big as the maximum (worst case) time elapsed since the start of your last good backup. That practically always(*) means a RPO of "a couple hours or more." A long/big RPO usually holds RTO back too, but there are a few rare exceptions. On the other hand, it's quite possible to have a long/big RTO with a RPO of zero. (*) Why not "always"? Exotic, contrived exceptions might be possible, such as custom software that synchronizes writes directly to local and remote tape. No, my RPO *is* zero. We do not talk about backup itself, which is ...the same for VTS, MAGSTAR, USB stick, etc. Despite of backup media the backup is representation of historical data. What I'm talking about is time delta between primary and secondary (local, remote) backup copies. And again: some (typical?) modes of VTS replication are not synchronous, so there is time delta between local copy is closed (and marked as done) and remote copy is also finished. For duplex write in HSM both tapes are being written simultaneously, so end of backup job means you have both copies ready. Note: Earlier you mentioned that PTAM makes RPO longer. Yes, it *adds* the time to "historical representation". VTS non-synchronous mode adds the time also (much less). but HSM duplex write add zero. -- Radoslaw Skorupka Lodz, Poland == Jeśli nie jesteś adresatem tej wiadomości: - powiadom nas o tym w mailu zwrotnym (dziękujemy!), - usuń trwale tę wiadomość (i wszystkie kopie, które wydrukowałeś lub zapisałeś na dysku). Wiadomość ta może zawierać chronione prawem informacje, które może wykorzystać tylko adresat.Przypominamy, że każdy, kto rozpowszechnia (kopiuje, rozprowadza) tę wiadomość lub podejmuje podobne działania, narusza prawo i może podlegać karze. mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. Sąd Rejonowy dla m. st. Warszawy XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS 025237, NIP: 526-021-50-88. Kapitał zakładowy (opłacony w całości) według stanu na 01.01.2019 r. wynosi 169.347.928 złotych. If you are not the addressee of this message: - let us know by replying to this e-mail (thank you!), - delete this message permanently (including all the copies which you have printed out or saved). This message may contain legally protected information, which may be used exclusively by the addressee.Please be reminded that anyone who disseminates (copies, distributes) this message or takes any similar action, violates the law and may be penalised. mBank S.A. with its registered office in Warsaw, ul. Senatorska 18, 00-950 Warszawa,www.mBank.pl, e-mail: kont...@mbank.pl. District Court for the Capital City of Warsaw, 12th Commercial Division of the National Court Register, KRS 025237, NIP: 526-021-50-88. Fully paid-up share capital amounting to PLN 169.347.928 as at 1 January 2019. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Who do you trust? (What CA's do you trust?)
On 2020-01-30 18:06, Charles Mills wrote: Who do you trust? What CERTAUTH certificates do you have installed and trusted? I am contemplating purchasing an FTP server certificate for z/OS client FTP access. I'd like to know which CA's are most likely to already be installed in customers' CERTAUTH keyrings. IBM used to ship certificates for VeriSign, Thawte, Integrion, Entrust, Equifax and ICP. Are those still popularly-trusted CAs? What about Comodo? They are the largest CA. What about GoDaddy? What about Let's Encrypt, the no-charge CA? There's been a lot of consolidation. Equifax is GeoTrust is VeriSign. Thawte and Symantec are now DigiCert. FWIW, from Mozilla: "Most browsers, not just Firefox, do not trust certificates by GeoTrust, RapidSSL, Symantec, Thawte, and VeriSign because these certificate authorities failed to follow security practices in the past." https://support.mozilla.org/en-US/kb/what-does-your-connection-is-not-secure-mean -- Regards, Gord Tomlin Action Software International (a division of Mazda Computer Corporation) Tel: (905) 470-7113, Fax: (905) 470-6507 Support: https://actionsoftware.com/support/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Who do you trust? (What CA's do you trust?)
On 1/30/2020 6:07 PM, Charles Mills wrote: Who do you trust? What CERTAUTH certificates do you have installed and trusted? I am contemplating purchasing an FTP server certificate for z/OS client FTP access. I'd like to know which CA's are most likely to already be installed in customers' CERTAUTH keyrings. I'm not suggesting who anyone should trust, but IBM currently uses Digicert for its software download servers, therefore, I expect most folks already have the Digicert CA cert installed. Kurt Quackenbush -- IBM, SMP/E Development Chuck Norris never uses CHECK when he applies PTFs. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
