Re: vendor distributes their private key
Fwiw, For client authentication we ask our clients to send us a Certificate Signing Request for the keypair they want to use, and we sign them using our internal Client Authentication CA. We set the CN and other options to what we want for our systems to authorize them correctly, and then send the client the resulting certificate back. We never see their private key, and we have full control of validity of their certificate (revocation and expiration). On Fri, Aug 30, 2019, 10:15 Charles Mills wrote: > Andrew, that's a good thought. I'm not knowledgeable enough to tell > whether it is perfect from a cryptographic point of view or not. > > FWIW though, that is not how X.509 standard client authentication works. > It works the way I described, in accordance with RFC 5246 7.4.6. > > Passwords work, and are obviously THE most common form of client > authentication. I think a primary usage of client certificate > authentication is with unattended processes. (Think z/OS jobs!) There is no > one available to key in a password, and passwords stored in files make the > auditors very cranky. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Andrew Rowley > Sent: Thursday, August 29, 2019 6:38 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: vendor distributes their private key > > On 29/08/2019 9:18 am, Charles Mills wrote: > > > But for certificate-based client authentication, the server admin must > send the client admin a client certificate AND its private key. Why? > Philosophically, because a client certificate signed by a trusted CA does > not prove the authenticity of the client. A man-in-the-middle might have > previously intercepted the certificate and now be sending it out from HIS > client as its own. > > This doesn't sound right somehow. I suspect it is often implemented that > way, but it sounds worse than password authentication with a good password. > > -- > 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: vendor distributes their private key
Andrew, that's a good thought. I'm not knowledgeable enough to tell whether it is perfect from a cryptographic point of view or not. FWIW though, that is not how X.509 standard client authentication works. It works the way I described, in accordance with RFC 5246 7.4.6. Passwords work, and are obviously THE most common form of client authentication. I think a primary usage of client certificate authentication is with unattended processes. (Think z/OS jobs!) There is no one available to key in a password, and passwords stored in files make the auditors very cranky. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Andrew Rowley Sent: Thursday, August 29, 2019 6:38 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key On 29/08/2019 9:18 am, Charles Mills wrote: > But for certificate-based client authentication, the server admin must send > the client admin a client certificate AND its private key. Why? > Philosophically, because a client certificate signed by a trusted CA does not > prove the authenticity of the client. A man-in-the-middle might have > previously intercepted the certificate and now be sending it out from HIS > client as its own. This doesn't sound right somehow. I suspect it is often implemented that way, but it sounds worse than password authentication with a good password. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
On 29/08/2019 9:18 am, Charles Mills wrote: But for certificate-based client authentication, the server admin must send the client admin a client certificate AND its private key. Why? Philosophically, because a client certificate signed by a trusted CA does not prove the authenticity of the client. A man-in-the-middle might have previously intercepted the certificate and now be sending it out from HIS client as its own. This doesn't sound right somehow. I suspect it is often implemented that way, but it sounds worse than password authentication with a good password. With a password: - the server admin supplies a password - you are forced to change the password, the server admin should not know the new password - It's considered bad if the server admin can e.g. run a cracking tool to find out your password With the certificate based client authentication as described - The server admin has your credentials - you can't change them? My understanding of the way client authentication is supposed to work - The client generates a public/private key pair - The public key is incorporated into a certificate, signed by a CA. In this case it is quite valid for the server admin to be the CA. At this point the CA needs to verify the identity of the client. - The client presents the certificate, and uses the private key known only to them to prove that the certificate belongs to them. Like a password, it is up to the client to protect the private key and no-one else, including the server admin should know the private key. It doesn't matter if the man-in-the-middle has the certificate, because they can't use it without the private key. The private key is never transmitted, so no-one in the middle has the opportunity to intercept it. It might be common for the server admin to generate the client certificates and keys because the alternative is hard to implement and manage, but it is roughly equivalent to sending passwords that the client is not allowed to change. -- Andrew Rowley Black Hill Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
> But for certificate-based client authentication, the server admin must send > the client admin a client certificate AND its private key. Yes, he sends the client a key intended to be used only by that client. That's very different from a vendor sending his own private key to customers. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Wednesday, August 28, 2019 7:18 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key I'm sure everyone is tired of this thread but I wanted to jump in here and say that anyone -- including me -- who said "you should never get a private key from the owners of some server you want to connect to" was potentially wrong. Yes, yes, of course, sending out root CA or Intermediate certificate private keys is wrong, wrong, wrong. Horribly wrong. Ditto "regular" server certificate private keys. But for certificate-based client authentication, the server admin must send the client admin a client certificate AND its private key. Why? Philosophically, because a client certificate signed by a trusted CA does not prove the authenticity of the client. A man-in-the-middle might have previously intercepted the certificate and now be sending it out from HIS client as its own. Practically speaking, the client authentication protocol requires the client to send a certificate-signed hash of all of the messages that have come so far on the startup handshake. The server validates that signature with the public key in the certificate. The client must have the private key to be able to do that, preventing the MITM attack I describe above. And the fact that it uses the current session messages as a unique input prevents a replay type attack. Here's a reference: https://blogs.msdn.microsoft.com/kaushal/2015/05/27/client-certificate-authentication-part-1/ Yeah, yeah, it's Microsoft but X.509 is X.509, even when Microsoft does it. Other references say the same thing. This was just more clear and thorough IMHO. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel M Ivey Sent: Thursday, August 22, 2019 5:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: vendor distributes their private key A vendor has an ftps server for us to connect to from a batch job on zos. Similar setups with vendors have required the vendor to provide their server's public cert chain for import into RACF. This vendor insists on providing not just their server public cert chain but also their private key. First, they provided a password-protected p12 file, describing it as containing the "root, intermediate, and private certs". I requested their public certificate chain only, they sent me a DER file -- with both the server cert and its private key. I have asked them to elaborate on their need to distribute their private key to me, their response has essentially been, that's the way we do it. I'm not comfortable accepting anyone's private key. There has been no mention of "client authentication", and I'm still not sure I'd be comfortable with that config, either. Help me understand two things: 1) what I'm missing as to why any vendor would require me to install their private key on my side when installing the public cert on my side should suffice as in many other instances, and 2) arguments for/against client authentication (not password authentication, but client) in case that is why they're sending me their private key. Joel -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
> crypto non-repudiation can show it came from your machine I certainly agree with this, but you can restrict what "your machine" is so that it's a lot better than just "came from a particular PC" or "came from a particular mainframe". For example, the private key may be stored in something you carry and control yourself, like a smart card or cell phone (maybe even the secure enclave in the phone), and digital signatures can be computed in that same device. The smart card can be PIN-protected, and similarly a cell phone can require authentication. This isn't 100% secure, but it's not bad in most cases - there are several possible attack vectors, but they generally aren't easy. On the mainframe, of course, you can use something like RACF to control access to / use of the private key. Again, not perfect by any means, but not bad. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
OH, read this again. I retract my comment - I didn't spot the reference to mutual authentication. There would be an alternative for the server end to trust a client certificate signed by the client's CA by trusting the client's root CA. Mike Wawiorko -Original Message- From: IBM Mainframe Discussion List On Behalf Of Mike Wawiorko Sent: 29 August 2019 10:51 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key This mail originated from outside our organisation - 014ab5cdfb21-dmarc-requ...@listserv.ua.edu Charles sent this "But for certificate-based client authentication, the server admin must send the client admin a client certificate AND its private (???) key." Surely that should say public key. Or am I missing something? Mike Wawiorko I Mainframe Connectivity I Global Technology Infrastructure and Services Tel +44 (0)330 1535515 I Internal 81535515 I Mobile +44 (0)7824 527120 Email mike.wawio...@barclays.com Barclays, Wilson Technology Lab GB12, BTC Radbroke, WA16 9EU (Mail Van 49) barclays.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: 29 August 2019 00:19 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key ... But for certificate-based client authentication, the server admin must send the client admin a client certificate AND its private key. Why? Philosophically, because a client certificate signed by a trusted CA does not prove the authenticity of the client. A man-in-the-middle might have previously intercepted the certificate and now be sending it out from HIS client as its own. ... Charles -- 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: vendor distributes their private key
Charles sent this "But for certificate-based client authentication, the server admin must send the client admin a client certificate AND its private (???) key." Surely that should say public key. Or am I missing something? Mike Wawiorko I Mainframe Connectivity I Global Technology Infrastructure and Services Tel +44 (0)330 1535515 I Internal 81535515 I Mobile +44 (0)7824 527120 Email mike.wawio...@barclays.com Barclays, Wilson Technology Lab GB12, BTC Radbroke, WA16 9EU (Mail Van 49) barclays.com -Original Message- From: IBM Mainframe Discussion List On Behalf Of Charles Mills Sent: 29 August 2019 00:19 To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key ... But for certificate-based client authentication, the server admin must send the client admin a client certificate AND its private key. Why? Philosophically, because a client certificate signed by a trusted CA does not prove the authenticity of the client. A man-in-the-middle might have previously intercepted the certificate and now be sending it out from HIS client as its own. ... Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
I'm sure everyone is tired of this thread but I wanted to jump in here and say that anyone -- including me -- who said "you should never get a private key from the owners of some server you want to connect to" was potentially wrong. Yes, yes, of course, sending out root CA or Intermediate certificate private keys is wrong, wrong, wrong. Horribly wrong. Ditto "regular" server certificate private keys. But for certificate-based client authentication, the server admin must send the client admin a client certificate AND its private key. Why? Philosophically, because a client certificate signed by a trusted CA does not prove the authenticity of the client. A man-in-the-middle might have previously intercepted the certificate and now be sending it out from HIS client as its own. Practically speaking, the client authentication protocol requires the client to send a certificate-signed hash of all of the messages that have come so far on the startup handshake. The server validates that signature with the public key in the certificate. The client must have the private key to be able to do that, preventing the MITM attack I describe above. And the fact that it uses the current session messages as a unique input prevents a replay type attack. Here's a reference: https://blogs.msdn.microsoft.com/kaushal/2015/05/27/client-certificate-authentication-part-1/ Yeah, yeah, it's Microsoft but X.509 is X.509, even when Microsoft does it. Other references say the same thing. This was just more clear and thorough IMHO. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel M Ivey Sent: Thursday, August 22, 2019 5:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: vendor distributes their private key A vendor has an ftps server for us to connect to from a batch job on zos. Similar setups with vendors have required the vendor to provide their server's public cert chain for import into RACF. This vendor insists on providing not just their server public cert chain but also their private key. First, they provided a password-protected p12 file, describing it as containing the "root, intermediate, and private certs". I requested their public certificate chain only, they sent me a DER file -- with both the server cert and its private key. I have asked them to elaborate on their need to distribute their private key to me, their response has essentially been, that's the way we do it. I'm not comfortable accepting anyone's private key. There has been no mention of "client authentication", and I'm still not sure I'd be comfortable with that config, either. Help me understand two things: 1) what I'm missing as to why any vendor would require me to install their private key on my side when installing the public cert on my side should suffice as in many other instances, and 2) arguments for/against client authentication (not password authentication, but client) in case that is why they're sending me their private key. Joel -- 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: vendor distributes their private key
sme...@gmu.edu (Seymour J Metz) writes: > The proper way to provide encryption and non-repudiation is to have > two key pairs. You sign a message using your private key. People > wanting to send you encrypted data encrypt using your public key. So > if foo wants to send bar a signed encrypted document, foo double > encrypts it with foo's private key and bar's publickey. I got into the middle of this in NIST, US and ISO financial standards bodies. crypto non-repudiation can show it came from your machine. The crypto companies wanted to move up the value stream to claim that non-repudiation was in the legal sense of read, understood, agreed, approved, and/or authorized something ... so they could charge more for the crypto ... however showed that those crypto "non-repudation" in no way satisfied the legal/business requirements (just that it was sent from your machine). we were also brought in to help wordsmith some cal. state legislation ... at the time they were working on electronic signature, data breach notification and opt-in personal information sharing. The "digital certificate" companies were lobbying that the electronic signature legislation mandate digital certificates (obtained at high price from them, at the time they were hawking $20B/annum business plans on wallstreet where every person would have a digital certificate at $100/year) ... for use with "digital signatures" ... as someway being equivalent to "human signatures" (and apply to non-repudation). They didn't get their way. -- virtualization experience starting Jan1968, online at home since Mar1970 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
My personal email provider (see below) just recently supported ed25519 for users public/private key pairs. They still support RSA keys of course. Mark Jacobs Sent from ProtonMail, Swiss-based encrypted email. GPG Public Key - https://api.protonmail.ch/pks/lookup?op=get=markjac...@protonmail.com ‐‐‐ Original Message ‐‐‐ On Tuesday, August 27, 2019 12:40 PM, Kirk Wolf wrote: > Keeping with ibm-main tradition, I'll steer this into a different ditch :-) > > "Seriously, stop using RSA" > This is a very interesting writeup/presentation, I've shorted the URL for > obvious reasons > https://tinyurl.com/yxw5xvmv > > IMO, ECDSA (NIST curves) are much better than RSA, although researchers > seem to prefer Curve25519 since the curve wasn't chosen by a government. > > On Tue, Aug 27, 2019 at 7:56 AM Chad Rikansrud < > mainfr...@bigendiansmalls.com> wrote: > > > " Non-repudiation for the message is not guaranteed by a hash. There is > > more than 1 message that could match that hash. " > > The breadth of privacy on the internet as we know it depends upon being > > able to trust that a hashing algo + cryptographic signature verifies the > > non-repudiation of the sender. > > Couple other items on this thread: > > it's true are an infinite number of inputs that would generate any given > > hash, and random inputs can and have created general hash collisions (md5 > > for instance has known random input that creates identical hashes), > > however, creating a meaningful input that (say in this case would be > > similar to what someone would want to say & sign, but slightly different so > > as to alter the message) - is cryptographically infeasible with today's > > compute power / hashes. Great article explaining collisions etc ( > > https://www.sciencedirect.com/topics/computer-science/hash-collision) > > For RSA public key systems - there is only 1 private key for any given > > public key. The keypairs certainly can and have been reused - that all > > depends on how good your entropy in choosing random numbers is (see > > https://www.nytimes.com/2012/02/15/technology/researchers-find-flaw-in-an-online-encryption-method.html > > ) > > There's no requirement outside of p & q being prime (In RSA) , that the > > public exponent or its related private exponent need not be prime, only > > co-prime (having no factors in common) - as was mentioned earlier. That > > said, one of the most common public exponent is prime (65537) > > All in all, to the original point though, sharing the private key by that > > vendor was terrible - you could effectively impersonate them in any / all > > situations that used that keypair/cert if you had a privileged position or > > means. Yikes. > > Chad > > > > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Keeping with ibm-main tradition, I'll steer this into a different ditch :-) "Seriously, stop using RSA" This is a very interesting writeup/presentation, I've shorted the URL for obvious reasons https://tinyurl.com/yxw5xvmv IMO, ECDSA (NIST curves) are much better than RSA, although researchers seem to prefer Curve25519 since the curve wasn't chosen by a government. On Tue, Aug 27, 2019 at 7:56 AM Chad Rikansrud < mainfr...@bigendiansmalls.com> wrote: > " Non-repudiation for the message is not guaranteed by a hash. There is > more than 1 message that could match that hash. " > > The breadth of privacy on the internet as we know it depends upon being > able to trust that a hashing algo + cryptographic signature verifies the > non-repudiation of the sender. > > Couple other items on this thread: > > it's true are an infinite number of inputs that would generate any given > hash, and random inputs can and have created general hash collisions (md5 > for instance has known random input that creates identical hashes), > however, creating a meaningful input that (say in this case would be > similar to what someone would want to say & sign, but slightly different so > as to alter the message) - is cryptographically infeasible with today's > compute power / hashes. Great article explaining collisions etc ( > https://www.sciencedirect.com/topics/computer-science/hash-collision) > > For RSA public key systems - there is only 1 private key for any given > public key. The keypairs certainly can and have been reused - that all > depends on how good your entropy in choosing random numbers is (see > https://www.nytimes.com/2012/02/15/technology/researchers-find-flaw-in-an-online-encryption-method.html > ) > > There's no requirement outside of p & q being prime (In RSA) , that the > public exponent or its related private exponent need not be prime, only > co-prime (having no factors in common) - as was mentioned earlier. That > said, one of the most common public exponent is prime (65537) > > All in all, to the original point though, sharing the private key by that > vendor was terrible - you could effectively impersonate them in any / all > situations that used that keypair/cert if you had a privileged position or > means. Yikes. > > Chad > > -- > 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: vendor distributes their private key
" Non-repudiation for the message is not guaranteed by a hash. There is more than 1 message that could match that hash. " The breadth of privacy on the internet as we know it depends upon being able to trust that a hashing algo + cryptographic signature verifies the non-repudiation of the sender. Couple other items on this thread: it's true are an infinite number of inputs that would generate any given hash, and random inputs can and have created general hash collisions (md5 for instance has known random input that creates identical hashes), however, creating a meaningful input that (say in this case would be similar to what someone would want to say & sign, but slightly different so as to alter the message) - is cryptographically infeasible with today's compute power / hashes. Great article explaining collisions etc (https://www.sciencedirect.com/topics/computer-science/hash-collision) For RSA public key systems - there is only 1 private key for any given public key. The keypairs certainly can and have been reused - that all depends on how good your entropy in choosing random numbers is (see https://www.nytimes.com/2012/02/15/technology/researchers-find-flaw-in-an-online-encryption-method.html) There's no requirement outside of p & q being prime (In RSA) , that the public exponent or its related private exponent need not be prime, only co-prime (having no factors in common) - as was mentioned earlier. That said, one of the most common public exponent is prime (65537) All in all, to the original point though, sharing the private key by that vendor was terrible - you could effectively impersonate them in any / all situations that used that keypair/cert if you had a privileged position or means. Yikes. Chad -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
A few random comments about this discussion: 1. Someone mentioned performance. If that is a concern, use hardware to do the public-key algorithm - for example the Crypto Express HSM. 2. Remember that not all public-key algorithms can directly encrypt data. For example, RSA can, but Elliptic Curve (ECC) and DSA cannot. (For ECC, there is a method called ECIES that essentially creates a symmetric key under the covers and uses that to encrypt the data.) 3. Someone talked about signing and encrypting. Remember that you should never use the same key pairs for both - you should always have separate key pairs for signing and for encrypting. 4. Phil Smith showed how you can send the same content to multiple people by encrypting it with a symmetric key, then encrypting that symmetric key with each of their public keys. The Cryptographic Message Syntax (CMS) standard (RFC 5652, ANSI X9.73) supports exactly this method using something they call "enveloped data". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
I actually might share that with this vendor! They still have not realized/acknowledged their error. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Charles Mills wrote, re hash uniqueness: >https://en.wikipedia.org/wiki/Cryptographic_hash_function >Read the third and fourth bullets. Indeed. Since the odds of a hash collision with any modern hashing algorithm are lower than the odds of a random bit-flip, it's not worth worrying about. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
https://en.wikipedia.org/wiki/Cryptographic_hash_function Read the third and fourth bullets. Read the whole article, for that matter. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jon Perryman Sent: Monday, August 26, 2019 3:20 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key Non-repudiation for the message is not guaranteed by a hash. There is more than 1 message that could match that hash. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Non-repudiation for the message is not guaranteed by a hash. There is more than 1 message that could match that hash. Jon. On Monday, August 26, 2019, 02:42:27 PM PDT, Charles Mills wrote: Yow! Expensive in terms of CPU time. Wouldn't (ideally at least) foo encrypt it with a random secret key and then send it to bar encrypted with bar's public key? To provide non-repudiation -- to sign a document -- it is only necessary for the sender to encrypt a hash of the message with the sender's private key. Much cheaper than two long public key encryptions. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
But much shorter plaintext to encrypt. Around 256 or 512 bits each, rather than whatever the length of the e-mail is. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, August 26, 2019 2:50 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key Those alternatives also involve two pairs of keys. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
That depends on what Phil Smith III meant by "Ah, ok. Reveals my ignorance of how PGP works. Voltage SecureMail uses both, providing that non-repudiation; I guess I assumed everyone did!" -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of zMan Sent: Monday, August 26, 2019 5:27 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key Isn't that what was just discussed? What am I missing here? On Mon, Aug 26, 2019 at 4:42 PM Seymour J Metz wrote: > The proper way to provide encryption and non-repudiation is to have two > key pairs. You sign a message using your private key. People wanting to > send you encrypted data encrypt using your public key. So if foo wants to > send bar a signed encrypted document, foo double encrypts it with foo's > private key and bar's publickey. -- zMan -- "I've got a mainframe and I'm not afraid to use it" -- 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: vendor distributes their private key
Those alternatives also involve two pairs of keys. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Charles Mills Sent: Monday, August 26, 2019 5:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key Yow! Expensive in terms of CPU time. Wouldn't (ideally at least) foo encrypt it with a random secret key and then send it to bar encrypted with bar's public key? To provide non-repudiation -- to sign a document -- it is only necessary for the sender to encrypt a hash of the message with the sender's private key. Much cheaper than two long public key encryptions. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, August 26, 2019 1:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key The proper way to provide encryption and non-repudiation is to have two key pairs. You sign a message using your private key. People wanting to send you encrypted data encrypt using your public key. So if foo wants to send bar a signed encrypted document, foo double encrypts it with foo's private key and bar's publickey. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Monday, August 26, 2019 4:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key CM Poncelet wrote: >Because a sender does not need to have an own public/private key-pair, >but needs only the public keys of the recipients to send encrypted >emails to them. Ah, ok. Reveals my ignorance of how PGP works. Voltage SecureMail uses both, providing that non-repudiation; I guess I assumed everyone did! -- 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 -- 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: vendor distributes their private key
Yow! Expensive in terms of CPU time. Wouldn't (ideally at least) foo encrypt it with a random secret key and then send it to bar encrypted with bar's public key? To provide non-repudiation -- to sign a document -- it is only necessary for the sender to encrypt a hash of the message with the sender's private key. Much cheaper than two long public key encryptions. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Seymour J Metz Sent: Monday, August 26, 2019 1:43 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key The proper way to provide encryption and non-repudiation is to have two key pairs. You sign a message using your private key. People wanting to send you encrypted data encrypt using your public key. So if foo wants to send bar a signed encrypted document, foo double encrypts it with foo's private key and bar's publickey. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Monday, August 26, 2019 4:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key CM Poncelet wrote: >Because a sender does not need to have an own public/private key-pair, >but needs only the public keys of the recipients to send encrypted >emails to them. Ah, ok. Reveals my ignorance of how PGP works. Voltage SecureMail uses both, providing that non-repudiation; I guess I assumed everyone did! -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Isn't that what was just discussed? What am I missing here? On Mon, Aug 26, 2019 at 4:42 PM Seymour J Metz wrote: > The proper way to provide encryption and non-repudiation is to have two > key pairs. You sign a message using your private key. People wanting to > send you encrypted data encrypt using your public key. So if foo wants to > send bar a signed encrypted document, foo double encrypts it with foo's > private key and bar's publickey. -- zMan -- "I've got a mainframe and I'm not afraid to use it" -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
I found the third RSA number that is used to eliminate collisions. I was talking about the exponent which is a coprime to the modulus of the primes. Apparently the exponent does not need to be a prime. wiki page - key generation - step 4 : "Choose an integer e such that 1 < e < λ(n) and gcd(e, λ(n)) = 1; that is, e and λ(n) are coprime.". As long as every CA using this algorithm has a different exponent, then all keys are guaranteed to be unique with the CA's. Jon. On Monday, August 26, 2019, 10:42:44 AM PDT, Seymour J Metz wrote: RSA only involves two primes. See https://en.wikipedia.org/wiki/RSA_(cryptosystem) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Saturday, August 24, 2019 4:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key I vaguely recall that there was a third prime number involved in the algorithm that was static for RSA. Do they still have this third prime? Could it be that they use this to eliminate this possibility? Jon. On Saturday, August 24, 2019, 09:17:22 AM PDT, Mike Schwab wrote: > Well, keys are supposed to be two large prime numbers. Without a > registry of which numbers have been used, it would be possible for two > people to use the same prime number. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
The proper way to provide encryption and non-repudiation is to have two key pairs. You sign a message using your private key. People wanting to send you encrypted data encrypt using your public key. So if foo wants to send bar a signed encrypted document, foo double encrypts it with foo's private key and bar's publickey. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Phil Smith III Sent: Monday, August 26, 2019 4:35 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key CM Poncelet wrote: >Because a sender does not need to have an own public/private key-pair, >but needs only the public keys of the recipients to send encrypted >emails to them. Ah, ok. Reveals my ignorance of how PGP works. Voltage SecureMail uses both, providing that non-repudiation; I guess I assumed everyone did! -- 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: vendor distributes their private key
CM Poncelet wrote: >Because a sender does not need to have an own public/private key-pair, >but needs only the public keys of the recipients to send encrypted >emails to them. Ah, ok. Reveals my ignorance of how PGP works. Voltage SecureMail uses both, providing that non-repudiation; I guess I assumed everyone did! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Because a sender does not need to have an own public/private key-pair, but needs only the public keys of the recipients to send encrypted emails to them. BTW Some links if interested in putting this to the test: [PRZ's website:] https://philzimmermann.com/EN/findpgp/ [free GPG/PGP websites:] https://www.gnupg.org/ https://www.openpgp.org/ [email encryption software for Thunderbird:] https://www.openpgp.org/software/enigmail/ [download my PGP public key (ponce...@logicintegration.com & ponce...@bcs.org.uk) to check sending encrypted emails to me:] http://keyserver.pgp.com/vkd/GetWelcomeScreen.event HTH Cheers, Chris Poncelet (retired sysprog) On 26/08/2019 14:53, Phil Smith III wrote: > CM Poncelet wrote: > >> Possibly - but probably not "encrypted with ... possibly sender's >> private key" > > > ? Why do you say that? Doing so provides both security and non-repudiation. I > may be misunderstanding your point. > > > -- > 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: vendor distributes their private key
On Mon, 26 Aug 2019 17:42:35 +, Seymour J Metz wrote: >RSA only involves two primes. See >https://en.wikipedia.org/wiki/RSA_(cryptosystem) From: Jon Perryman Sent: Saturday, August 24, 2019 4:29 PM I vaguely recall that there was a third prime number involved in the algorithm that was static for RSA. Do they still have this third prime? Could it be that they use this to eliminate this possibility? Are you thinking, perhaps, of Diffie-Hellman? https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange#General_overview -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
RSA only involves two primes. See https://en.wikipedia.org/wiki/RSA_(cryptosystem) -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Jon Perryman Sent: Saturday, August 24, 2019 4:29 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key I vaguely recall that there was a third prime number involved in the algorithm that was static for RSA. Do they still have this third prime? Could it be that they use this to eliminate this possibility? Jon. On Saturday, August 24, 2019, 09:17:22 AM PDT, Mike Schwab wrote: > Well, keys are supposed to be two large prime numbers. Without a > registry of which numbers have been used, it would be possible for two > people to use the same prime number. -- 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: vendor distributes their private key
CM Poncelet wrote: >Possibly - but probably not "encrypted with ... possibly sender's >private key" ? Why do you say that? Doing so provides both security and non-repudiation. I may be misunderstanding your point. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Possibly - but probably not "encrypted with ... possibly sender's private key" On 26/08/2019 02:17, Phil Smith III wrote: > CM Poncelet wrote: > >> PGP allows sending encrypted emails/data to multiple recipients, where >> each recipient has a different private key, and this works AOK (but no >> idea how). > > > Trivial: the actual payload is encrypted with a random symmetric key. Then > THAT key is encrypted with the public key of each > recipient, and the package sent contains a copy for each recipient. So in > pseudo-crypto(!), if the data is being sent to Phil, > Charles, and CM, the package contains: > > > > This is for Phil: < copy of key K, encrypted with Phil's public key and > possibly sender's private key> > > This is for Charles: < copy of key K, encrypted with Charles's public key and > possibly sender's private key> > > This is for CM: < copy of key K, encrypted with CM's public key and possibly > sender's private key> > > > > > > Make sense? > > > > ...phsiii > > > -- > 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: vendor distributes their private key
Very clever. You really want to use symmetric encryption anyway for significant amounts of data because public key is slow. Better to encrypt with a random (relatively short) secret key, and then encrypt that with public key. That's how TLS (SSL) does things. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Phil Smith III Sent: Sunday, August 25, 2019 6:17 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key CM Poncelet wrote: >PGP allows sending encrypted emails/data to multiple recipients, where >each recipient has a different private key, and this works AOK (but no >idea how). Trivial: the actual payload is encrypted with a random symmetric key. Then THAT key is encrypted with the public key of each recipient, and the package sent contains a copy for each recipient. So in pseudo-crypto(!), if the data is being sent to Phil, Charles, and CM, the package contains: This is for Phil: < copy of key K, encrypted with Phil's public key and possibly sender's private key> This is for Charles: < copy of key K, encrypted with Charles's public key and possibly sender's private key> This is for CM: < copy of key K, encrypted with CM's public key and possibly sender's private key> Make sense? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
CM Poncelet wrote: >PGP allows sending encrypted emails/data to multiple recipients, where >each recipient has a different private key, and this works AOK (but no >idea how). Trivial: the actual payload is encrypted with a random symmetric key. Then THAT key is encrypted with the public key of each recipient, and the package sent contains a copy for each recipient. So in pseudo-crypto(!), if the data is being sent to Phil, Charles, and CM, the package contains: This is for Phil: < copy of key K, encrypted with Phil's public key and possibly sender's private key> This is for Charles: < copy of key K, encrypted with Charles's public key and possibly sender's private key> This is for CM: < copy of key K, encrypted with CM's public key and possibly sender's private key> Make sense? ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Vendors should restrict read access to their FTP upload sites in case there is sensitive data included. Dumps are a good example where customers cannot sanitize the file. There are some customers that will not send a dump because they cannot sanitize it. In those situations, you are forced to send diagnostic execs and work remotely. Jon.On Saturday, August 24, 2019, 03:17:30 PM PDT, Arthur wrote: I once had to FTP a dump to a vendor. I saw that the directory was set up to allow read without a password. I refused to send the dump until they fixed the security. It was a long time ago, and I can't remember the outcome, though I know they argued with me. I will admit that it's unusual to require a password for read but not for write/create. -- 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: vendor distributes their private key
On 22 Aug 2019 05:57:37 -0700, in bit.listserv.ibm-main (Message-ID:<0049105969039769.wa.jiveycio.sc@listserv.ua.edu>) ji...@cio.sc.gov (Joel M Ivey) wrote: First, they provided a password-protected p12 file, describing it as containing the "root, intermediate, and private certs". I requested their public certificate chain only, they sent me a DER file -- with both the server cert and its private key. I have asked them to elaborate on their need to distribute their private key to me, their response has essentially been, that's the way we do it. As people have already said, this is incredibly negligent and/or ignorant. I'd hesitate to have any dealings with that company. I once had to FTP a dump to a vendor. I saw that the directory was set up to allow read without a password. I refused to send the dump until they fixed the security. It was a long time ago, and I can't remember the outcome, though I know they argued with me. I will admit that it's unusual to require a password for read but not for write/create. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
No need for a private key registry because verifying the public key is sufficient. There are public key registries but I doubt they validate duplication. Remember this is PGP (Pretty Good Privacy - not perfect), so there are multiple factors that were considered. In this case, duplicate key pairs are a very minor exposure because it's unlikely those few matching private key holders will abuse your key. Jon. On Saturday, August 24, 2019, 10:30:19 AM PDT, Paul Gilmartin <000433f07816-dmarc-requ...@listserv.ua.edu> wrote: On Sat, 24 Aug 2019 11:16:57 -0500, Mike Schwab wrote: >>Well, keys are supposed to be two large prime numbers. Without a >>registry of which numbers have been used, it would be possible for two >>people to use the same prime number. >Such a registry would defeat the purpose, although a registry of public >keys is plausible. Cryptosystems depend on the extreme unlikeliness of a >collision. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
I vaguely recall that there was a third prime number involved in the algorithm that was static for RSA. Do they still have this third prime? Could it be that they use this to eliminate this possibility? Jon. On Saturday, August 24, 2019, 09:17:22 AM PDT, Mike Schwab wrote: > Well, keys are supposed to be two large prime numbers. Without a > registry of which numbers have been used, it would be possible for two > people to use the same prime number. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
We've gone from "not cryptologically proven" to "you've never seen proof". Please don't state fiction as fact. For RSA, the proof has been around for several year's. Back then, it was large prime numbers which appears to be true today but very large. There's a huge difference between "supposed to be" and what you said. "Supposed to be" is where I researched this year's ago but did not know if it was still current. Apparently you don't have any basis for your claims except for a WSAG. Jon. On Saturday, August 24, 2019, 08:47:21 AM PDT, Charles Mills wrote: >> Do you have any basis to guess it's not provable or that they are not >> uniquely paired? > Just that I have never seen a proof and I have learned > in crypto to doubt every unproven assumption. >> They are supposed to be uniquely paired. > "Supposed to be." Is that real different from what I said? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jon Perryman Sent: Saturday, August 24, 2019 7:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key On Friday, August 23, 2019, 04:34:14 PM PDT, Charles Mills wrote: >> I believe a public key can be associated with more than one PGP private key > I don't know PGP at all but for basic asymmetrical or public/private key > encryption, > the public and private keys are basically one to one with each other. You > generate > a pair, both halves at once. Although I guess it is not provable that no two > public > keys have the same private key, that situation is hopefully unlikely. Do you have any basis to guess it's not provable or that they are not uniquely paired? They are supposed to be uniquely paired. Jon. -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
You encrypt with their public key; they decrypt with their private key? That would be pretty "standard." That is "how public key works." Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of CM Poncelet Sent: Saturday, August 24, 2019 11:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key PGP allows sending encrypted emails/data to multiple recipients, where each recipient has a different private key, and this works AOK (but no idea how). I have 'PGP Desktop Whole Disk Encryption (WDE)'. CP -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
On Aug 24, 2019, at 11:16 AM, Mike Schwab wrote: > > Well, keys are supposed to be two large prime numbers. Without a > registry of which numbers have been used, it would be possible for two > people to use the same prime number. RSA keys are *generated* from two large prime numbers, but the keys themselves aren’t prime numbers. And other public key algorithms don’t necessarily involve prime numbers. -- Pew, Curtis G curtis@austin.utexas.edu -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
PGP allows sending encrypted emails/data to multiple recipients, where each recipient has a different private key, and this works AOK (but no idea how). I have 'PGP Desktop Whole Disk Encryption (WDE)'. CP On 24/08/2019 00:34, Charles Mills wrote: >> I believe a public key can be associated with more than one PGP private key > I don't know PGP at all but for basic asymmetrical or public/private key > encryption, the public and private keys are basically one to one with each > other. You generate a pair, both halves at once. Although I guess it is not > provable that no two public keys have the same private key, that situation is > hopefully unlikely. > > Charles > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of CM Poncelet > Sent: Friday, August 23, 2019 8:01 AM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: vendor distributes their private key > > The vendor can revoke his private/public key, generate a new > private/public key pair and - hopefully this time - publish only the > public key. > > BTW I believe a public key can be associated with more than one PGP > private key, although doing so would still not explain the vendor's > publishing a private key that could decrypt his public key encrypted > data - regardless of how many other private keys could do so too. > > Just my ha'penny. > > Chris Poncelet (retired sysprog) > > > On 22/08/2019 20:41, Paul Gilmartin wrote: >> On Thu, 22 Aug 2019 14:13:58 -0500, Joel M Ivey wrote: >> >>> Thanks all for the response. I'm glad I wasn't missing something. I >>> will discuss further with the vendor, hoping they will recognize the risks. >>> >> How can the vendor recover from this without causing great >> disruption, even an indefinite time in the future, to existing >> customers who are rely on the improperly distributed private key? >> >> -- gil >> >> -- >> 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 > > -- > 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: vendor distributes their private key
On Sat, 24 Aug 2019 11:16:57 -0500, Mike Schwab wrote: >Well, keys are supposed to be two large prime numbers. Without a >registry of which numbers have been used, it would be possible for two >people to use the same prime number. > Such a registry would defeat the purpose, although a registry of public keys is plausible. Cryptosystems depend on the extreme unlikeliness of a collision. -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Well, keys are supposed to be two large prime numbers. Without a registry of which numbers have been used, it would be possible for two people to use the same prime number. On Sat, Aug 24, 2019 at 9:40 AM Jon Perryman wrote: > > > > On Friday, August 23, 2019, 04:34:14 PM PDT, Charles Mills > wrote: > >> I believe a public key can be associated with more than one PGP private > key > > > I don't know PGP at all but for basic asymmetrical or public/private key > > encryption, > > the public and private keys are basically one to one with each other. You > > generate > > a pair, both halves at once. Although I guess it is not provable that no > > two public > > keys have the same private key, that situation is hopefully unlikely. > > Do you have any basis to guess it's not provable or that they are not > uniquely paired? They are supposed to be uniquely paired. > > Jon. > > > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
> Do you have any basis to guess it's not provable or that they are not > uniquely paired? Just that I have never seen a proof and I have learned in crypto to doubt every unproven assumption. > They are supposed to be uniquely paired. "Supposed to be." Is that real different from what I said? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jon Perryman Sent: Saturday, August 24, 2019 7:40 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key On Friday, August 23, 2019, 04:34:14 PM PDT, Charles Mills wrote: >> I believe a public key can be associated with more than one PGP private key > I don't know PGP at all but for basic asymmetrical or public/private key > encryption, > the public and private keys are basically one to one with each other. You > generate > a pair, both halves at once. Although I guess it is not provable that no two > public > keys have the same private key, that situation is hopefully unlikely. Do you have any basis to guess it's not provable or that they are not uniquely paired? They are supposed to be uniquely paired. Jon. -- 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: vendor distributes their private key
On Friday, August 23, 2019, 04:34:14 PM PDT, Charles Mills wrote: >> I believe a public key can be associated with more than one PGP private key > I don't know PGP at all but for basic asymmetrical or public/private key > encryption, > the public and private keys are basically one to one with each other. You > generate > a pair, both halves at once. Although I guess it is not provable that no two > public > keys have the same private key, that situation is hopefully unlikely. Do you have any basis to guess it's not provable or that they are not uniquely paired? They are supposed to be uniquely paired. Jon. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
> I believe a public key can be associated with more than one PGP private key I don't know PGP at all but for basic asymmetrical or public/private key encryption, the public and private keys are basically one to one with each other. You generate a pair, both halves at once. Although I guess it is not provable that no two public keys have the same private key, that situation is hopefully unlikely. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of CM Poncelet Sent: Friday, August 23, 2019 8:01 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key The vendor can revoke his private/public key, generate a new private/public key pair and - hopefully this time - publish only the public key. BTW I believe a public key can be associated with more than one PGP private key, although doing so would still not explain the vendor's publishing a private key that could decrypt his public key encrypted data - regardless of how many other private keys could do so too. Just my ha'penny. Chris Poncelet (retired sysprog) On 22/08/2019 20:41, Paul Gilmartin wrote: > On Thu, 22 Aug 2019 14:13:58 -0500, Joel M Ivey wrote: > >> Thanks all for the response. I'm glad I wasn't missing something. I will >> discuss further with the vendor, hoping they will recognize the risks. >> > How can the vendor recover from this without causing great > disruption, even an indefinite time in the future, to existing > customers who are rely on the improperly distributed private key? > > -- gil > > -- > 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
On Thu, 22 Aug 2019 at 22:47, Kirk Wolf wrote: > BUT: if this vendor is giving you its server's private key, then the server > is *not* secure. This is because when you connect to that server you don't > know if you are really talking to the vendor or someone else, since anyone > with the private key could impersonate the server.You should never > trust exchanging information with this server. Friday true story... I had an isomorphic Real World incident back in 1980. Two friends had started a little company, and when I joined them we leased a small office in a mid-sized (10 storey) building that had typically three or four offices per floor, depending on the size. When we moved in the building manager gave us one door key for our little suite, and one building door key for after hours access, and we made a couple of copies of each. Some months later one evening we popped a circuit breaker, and I asked one of the office cleaners who was working on the floor to open the electrical room down the hall so I could reset it, rather than calling the official person and waiting forever. She said "your key will work - all keys are the same". Technopeasant, I said to myself, but indeed my *office* door key did work. We compared her key to mine, and they were identical. Slowly reality dawned... Is this the key you use to open the other offices, I asked? Yes, sure. So with her watching, I was able to open the office next door, and the next one too. They had given us the building master key, and presumably we weren't the only such "lucky" tenants! So of course we complained, but they seemed completely unable to appreciate the significance of what they had done. They offered to change *our* lock, but of course we pointed out that that wasn't the big problem: If *we* are known to have a master key, and *someone else* has a theft, *we* are going to be suspects, and rekeying all the locks in the building is the only solution. Well, we were the tiny startup, and they were the owners of an office building, and they refused to do anything. We wrote them a strongly worded letter disclaiming any responsibility for anything, they ignored it, and we all went on with work. But of course we did add a second lock of our own to address that half of the problem. It's hard to think of that happening in today's world where everyone has alarms and cameras and card access, and there seems to be a more general awareness of security. Or maybe not... Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
The vendor can revoke his private/public key, generate a new private/public key pair and - hopefully this time - publish only the public key. BTW I believe a public key can be associated with more than one PGP private key, although doing so would still not explain the vendor's publishing a private key that could decrypt his public key encrypted data - regardless of how many other private keys could do so too. Just my ha'penny. Chris Poncelet (retired sysprog) On 22/08/2019 20:41, Paul Gilmartin wrote: > On Thu, 22 Aug 2019 14:13:58 -0500, Joel M Ivey wrote: > >> Thanks all for the response. I'm glad I wasn't missing something. I will >> discuss further with the vendor, hoping they will recognize the risks. >> > How can the vendor recover from this without causing great > disruption, even an indefinite time in the future, to existing > customers who are rely on the improperly distributed private key? > > -- gil > > -- > 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: vendor distributes their private key
Agreed - the ftp client has no need for the ftp server's private key. The client only needs the server's certificate or the CA cert. The certs have the public key and a signature of that public key by the CA above it in the chain.Server certs don't contain private keys, and the client doesn't need them. BUT: if this vendor is giving you its server's private key, then the server is *not* secure. This is because when you connect to that server you don't know if you are really talking to the vendor or someone else, since anyone with the private key could impersonate the server.You should never trust exchanging information with this server. On Thu, Aug 22, 2019 at 3:22 PM Charles Mills wrote: > Customers are probably not relying on it. The key has no place in the > protocol flow. It is gratuitous, superfluous information. > > The vendor simply replaces the certificate(s) everywhere, keeping the > private key of the new certificate(s), well, private. > > Then the vendor revokes the compromised certificate(s). > > This process must be applied at whatever level the key applies to. If they > have an in-house CA and are distributing its private key, then they must > start over with a new CA and revoke every unexpired certificate issued by > the old CA. Similar logic if the distributed an Intermediate Certificate > key. > > Charles > > > -Original Message- > From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On > Behalf Of Paul Gilmartin > Sent: Thursday, August 22, 2019 12:42 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: vendor distributes their private key > > On Thu, 22 Aug 2019 14:13:58 -0500, Joel M Ivey wrote: > > >Thanks all for the response. I'm glad I wasn't missing something. I > will discuss further with the vendor, hoping they will recognize the risks. > > > How can the vendor recover from this without causing great > disruption, even an indefinite time in the future, to existing > customers who are rely on the improperly distributed private key? > > -- > 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: vendor distributes their private key
Customers are probably not relying on it. The key has no place in the protocol flow. It is gratuitous, superfluous information. The vendor simply replaces the certificate(s) everywhere, keeping the private key of the new certificate(s), well, private. Then the vendor revokes the compromised certificate(s). This process must be applied at whatever level the key applies to. If they have an in-house CA and are distributing its private key, then they must start over with a new CA and revoke every unexpired certificate issued by the old CA. Similar logic if the distributed an Intermediate Certificate key. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Paul Gilmartin Sent: Thursday, August 22, 2019 12:42 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key On Thu, 22 Aug 2019 14:13:58 -0500, Joel M Ivey wrote: >Thanks all for the response. I'm glad I wasn't missing something. I will >discuss further with the vendor, hoping they will recognize the risks. > How can the vendor recover from this without causing great disruption, even an indefinite time in the future, to existing customers who are rely on the improperly distributed private key? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
> what I'm missing as to why any vendor would require me to install their > private key on my side You don't read Dilbert, do you? If it were me I'd be looking for a different vendor. > their response has essentially been, that's the way we do it. Run, do not walk, to the nearest exit. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Discussion List on behalf of Joel M Ivey Sent: Thursday, August 22, 2019 8:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: vendor distributes their private key A vendor has an ftps server for us to connect to from a batch job on zos. Similar setups with vendors have required the vendor to provide their server's public cert chain for import into RACF. This vendor insists on providing not just their server public cert chain but also their private key. First, they provided a password-protected p12 file, describing it as containing the "root, intermediate, and private certs". I requested their public certificate chain only, they sent me a DER file -- with both the server cert and its private key. I have asked them to elaborate on their need to distribute their private key to me, their response has essentially been, that's the way we do it. I'm not comfortable accepting anyone's private key. There has been no mention of "client authentication", and I'm still not sure I'd be comfortable with that config, either. Help me understand two things: 1) what I'm missing as to why any vendor would require me to install their private key on my side when installing the public cert on my side should suffice as in many other instances, and 2) arguments for/against client authentication (not password authentication, but client) in case that is why they're sending me their private key. Joel -- 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: vendor distributes their private key
On Thu, 22 Aug 2019 14:13:58 -0500, Joel M Ivey wrote: >Thanks all for the response. I'm glad I wasn't missing something. I will >discuss further with the vendor, hoping they will recognize the risks. > How can the vendor recover from this without causing great disruption, even an indefinite time in the future, to existing customers who are rely on the improperly distributed private key? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Thanks all for the response. I'm glad I wasn't missing something. I will discuss further with the vendor, hoping they will recognize the risks. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
> As long as they don't distribute the public key, the data will remain secure. Technically probably true, but not cryptographically verified. But if the distribute the certificate as the OP indicated, they DO distribute the public key. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jon Perryman Sent: Thursday, August 22, 2019 10:19 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key Ask yourself if you can trust a vendor that does not understand basic security concepts. When you complain, will they simply give you the public key or will they request new public / private keys? I personally would be leery because they will be make much worse mistakes. The standard helps with mistakes like this by requiring the use of both keys. Data encrypted with the private key can only be decrypted using the public key. As long as they don't distribute the public key, the data will remain secure. If you move forward, make sure they give you a brand new public key. Jon.On Thursday, August 22, 2019, 05:57:34 AM PDT, Joel M Ivey wrote: A vendor has an ftps server for us to connect to from a batch job on zos. Similar setups with vendors have required the vendor to provide their server's public cert chain for import into RACF. This vendor insists on providing not just their server public cert chain but also their private key. First, they provided a password-protected p12 file, describing it as containing the "root, intermediate, and private certs". I requested their public certificate chain only, they sent me a DER file -- with both the server cert and its private key. I have asked them to elaborate on their need to distribute their private key to me, their response has essentially been, that's the way we do it. I'm not comfortable accepting anyone's private key. There has been no mention of "client authentication", and I'm still not sure I'd be comfortable with that config, either. Help me understand two things: 1) what I'm missing as to why any vendor would require me to install their private key on my side when installing the public cert on my side should suffice as in many other instances, and 2) arguments for/against client authentication (not password authentication, but client) in case that is why they're sending me their private key. Joel -- 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 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Ask yourself if you can trust a vendor that does not understand basic security concepts. When you complain, will they simply give you the public key or will they request new public / private keys? I personally would be leery because they will be make much worse mistakes. The standard helps with mistakes like this by requiring the use of both keys. Data encrypted with the private key can only be decrypted using the public key. As long as they don't distribute the public key, the data will remain secure. If you move forward, make sure they give you a brand new public key. Jon.On Thursday, August 22, 2019, 05:57:34 AM PDT, Joel M Ivey wrote: A vendor has an ftps server for us to connect to from a batch job on zos. Similar setups with vendors have required the vendor to provide their server's public cert chain for import into RACF. This vendor insists on providing not just their server public cert chain but also their private key. First, they provided a password-protected p12 file, describing it as containing the "root, intermediate, and private certs". I requested their public certificate chain only, they sent me a DER file -- with both the server cert and its private key. I have asked them to elaborate on their need to distribute their private key to me, their response has essentially been, that's the way we do it. I'm not comfortable accepting anyone's private key. There has been no mention of "client authentication", and I'm still not sure I'd be comfortable with that config, either. Help me understand two things: 1) what I'm missing as to why any vendor would require me to install their private key on my side when installing the public cert on my side should suffice as in many other instances, and 2) arguments for/against client authentication (not password authentication, but client) in case that is why they're sending me their private key. Joel -- 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: vendor distributes their private key
> the end-user understanding is the weak point And often, specifically, key management. This, however, takes first prize as a key management fail. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tony Harminc Sent: Thursday, August 22, 2019 8:28 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key On Thu, 22 Aug 2019 at 11:06, Charles Mills wrote: > You might ask what part of *private* key they are having trouble > understanding. See "Why Johnny Can't Encrypt" (1999) https://pdfs.semanticscholar.org/389f/55c5c376db4ce1c88161dca98c329614faa8.pdf and "Why Johnny Still Can't Encrypt" (2016) https://arxiv.org/pdf/1510.08555 Youtube seems to have videos on these topics, but I haven't looked at any of them. The above are talking specifically about PGP, but many of the lessons are common to other cryptosystems. The crypto is fine, but the end-user understanding is the weak point. Sure, maybe they should be crypto experts, but not every software developer is. See also Ross Anderson's "Why Cryptosystems Fail". -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Correction: even with Client certificate authentication, there is no distribution of any private key to clients; only a client certificate signed with a private key held at the server end. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Thursday, August 22, 2019 8:06 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: vendor distributes their private key Joel, it's just plain wrong. Others have listed the specifics. It just plain shows they have no clue how certificates work. It would be like if you installed a nice lock on your front door, and then hung the key on a hook outside next to it. You might ask what part of *private* key they are having trouble understanding. Client authentication -- where appropriate -- is goodness. But client authentication requires a separate key for each client (more or less). A client certificate and key "proves" you are the appropriate client. If the key is widely distributed then anyone can "prove" they are you. Client certificates are analogous to passwords. Making the key public would be like making passwords public. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel M Ivey Sent: Thursday, August 22, 2019 5:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: vendor distributes their private key A vendor has an ftps server for us to connect to from a batch job on zos. Similar setups with vendors have required the vendor to provide their server's public cert chain for import into RACF. This vendor insists on providing not just their server public cert chain but also their private key. First, they provided a password-protected p12 file, describing it as containing the "root, intermediate, and private certs". I requested their public certificate chain only, they sent me a DER file -- with both the server cert and its private key. I have asked them to elaborate on their need to distribute their private key to me, their response has essentially been, that's the way we do it. I'm not comfortable accepting anyone's private key. There has been no mention of "client authentication", and I'm still not sure I'd be comfortable with that config, either. Help me understand two things: 1) what I'm missing as to why any vendor would require me to install their private key on my side when installing the public cert on my side should suffice as in many other instances, and 2) arguments for/against client authentication (not password authentication, but client) in case that is why they're sending me their private key. -- 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: vendor distributes their private key
On Thu, 22 Aug 2019 at 11:06, Charles Mills wrote: > You might ask what part of *private* key they are having trouble > understanding. See "Why Johnny Can't Encrypt" (1999) https://pdfs.semanticscholar.org/389f/55c5c376db4ce1c88161dca98c329614faa8.pdf and "Why Johnny Still Can't Encrypt" (2016) https://arxiv.org/pdf/1510.08555 Youtube seems to have videos on these topics, but I haven't looked at any of them. The above are talking specifically about PGP, but many of the lessons are common to other cryptosystems. The crypto is fine, but the end-user understanding is the weak point. Sure, maybe they should be crypto experts, but not every software developer is. See also Ross Anderson's "Why Cryptosystems Fail". Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Joel, it's just plain wrong. Others have listed the specifics. It just plain shows they have no clue how certificates work. It would be like if you installed a nice lock on your front door, and then hung the key on a hook outside next to it. You might ask what part of *private* key they are having trouble understanding. Client authentication -- where appropriate -- is goodness. But client authentication requires a separate key for each client (more or less). A client certificate and key "proves" you are the appropriate client. If the key is widely distributed then anyone can "prove" they are you. Client certificates are analogous to passwords. Making the key public would be like making passwords public. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Joel M Ivey Sent: Thursday, August 22, 2019 5:57 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: vendor distributes their private key A vendor has an ftps server for us to connect to from a batch job on zos. Similar setups with vendors have required the vendor to provide their server's public cert chain for import into RACF. This vendor insists on providing not just their server public cert chain but also their private key. First, they provided a password-protected p12 file, describing it as containing the "root, intermediate, and private certs". I requested their public certificate chain only, they sent me a DER file -- with both the server cert and its private key. I have asked them to elaborate on their need to distribute their private key to me, their response has essentially been, that's the way we do it. I'm not comfortable accepting anyone's private key. There has been no mention of "client authentication", and I'm still not sure I'd be comfortable with that config, either. Help me understand two things: 1) what I'm missing as to why any vendor would require me to install their private key on my side when installing the public cert on my side should suffice as in many other instances, and 2) arguments for/against client authentication (not password authentication, but client) in case that is why they're sending me their private key. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
On Thu, Aug 22, 2019 at 9:03 AM Mike Wawiorko <
014ab5cdfb21-dmarc-requ...@listserv.ua.edu> wrote:
> Private keys should be locked away and treated like the company's crown
> jewels. If you have their private key it is likely many other sites also
> have.
>
I imagine that company also posts all of their employee's social security
numbers, internal memos, and videos of the Christmas parties of years past.
{shudder}
>
> That renders their site completely untrustworthy. I would not send
> anything confidential or, arguably, anything at all to that site.
>
> On the other hand, their public key is exactly what it says, public, and
> no risk.
>
> Mike Wawiorko
>
>
--
I find television very educational. The minute somebody turns it on, I go
into the library and read a good book
-- Groucho Marx
Maranatha! <><
John McKown
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: vendor distributes their private key
Private keys should be locked away and treated like the company's crown jewels. If you have their private key it is likely many other sites also have. That renders their site completely untrustworthy. I would not send anything confidential or, arguably, anything at all to that site. On the other hand, their public key is exactly what it says, public, and no risk. Mike Wawiorko -Original Message- From: IBM Mainframe Discussion List On Behalf Of Joel M Ivey Sent: 22 August 2019 13:57 To: IBM-MAIN@LISTSERV.UA.EDU Subject: vendor distributes their private key This mail originated from outside our organisation - ji...@cio.sc.gov A vendor has an ftps server for us to connect to from a batch job on zos. Similar setups with vendors have required the vendor to provide their server's public cert chain for import into RACF. This vendor insists on providing not just their server public cert chain but also their private key. First, they provided a password-protected p12 file, describing it as containing the "root, intermediate, and private certs". I requested their public certificate chain only, they sent me a DER file -- with both the server cert and its private key. I have asked them to elaborate on their need to distribute their private key to me, their response has essentially been, that's the way we do it. I'm not comfortable accepting anyone's private key. There has been no mention of "client authentication", and I'm still not sure I'd be comfortable with that config, either. Help me understand two things: 1) what I'm missing as to why any vendor would require me to install their private key on my side when installing the public cert on my side should suffice as in many other instances, and 2) arguments for/against client authentication (not password authentication, but client) in case that is why they're sending me their private key. Joel -- 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: vendor distributes their private key
The best argument is impersomating. Anone holding the private ket can present himself like the vendor. The risk is that if you download code form this vendor, you might download agresive code form someone pretending to be the vendor. ITschak On Thu, Aug 22, 2019 at 3:57 PM Joel M Ivey wrote: > A vendor has an ftps server for us to connect to from a batch job on zos. > Similar setups with vendors have required the vendor to provide their > server's public cert chain for import into RACF. This vendor insists on > providing not just their server public cert chain but also their private > key. > > First, they provided a password-protected p12 file, describing it as > containing the "root, intermediate, and private certs". I requested their > public certificate chain only, they sent me a DER file -- with both the > server cert and its private key. I have asked them to elaborate on their > need to distribute their private key to me, their response has essentially > been, that's the way we do it. > > I'm not comfortable accepting anyone's private key. There has been no > mention of "client authentication", and I'm still not sure I'd be > comfortable with that config, either. > > Help me understand two things: 1) what I'm missing as to why any vendor > would require me to install their private key on my side when installing > the public cert on my side should suffice as in many other instances, and > 2) arguments for/against client authentication (not password > authentication, but client) in case that is why they're sending me their > private key. > > Joel > > -- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > -- ITschak Mugzach *|** IronSphere Platform* *|* *Information Security Contiguous Monitoring for Legacy **| * -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
vendor distributes their private key
A vendor has an ftps server for us to connect to from a batch job on zos. Similar setups with vendors have required the vendor to provide their server's public cert chain for import into RACF. This vendor insists on providing not just their server public cert chain but also their private key. First, they provided a password-protected p12 file, describing it as containing the "root, intermediate, and private certs". I requested their public certificate chain only, they sent me a DER file -- with both the server cert and its private key. I have asked them to elaborate on their need to distribute their private key to me, their response has essentially been, that's the way we do it. I'm not comfortable accepting anyone's private key. There has been no mention of "client authentication", and I'm still not sure I'd be comfortable with that config, either. Help me understand two things: 1) what I'm missing as to why any vendor would require me to install their private key on my side when installing the public cert on my side should suffice as in many other instances, and 2) arguments for/against client authentication (not password authentication, but client) in case that is why they're sending me their private key. Joel -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
