[prev in list] [next in list] [prev in thread] [next in thread] 

List:       racf-l
Subject:    Re: Who do you trust? (What CA's do you trust?)
From:       Wai Choi <wchoi () US ! IBM ! COM>
Date:       2020-02-21 22:36:41
Message-ID: OF4BEABB79.2F6063AB-ON00258515.007A95B9-85258515.007C35A3 () notes ! na ! collabserv ! com
[Download RAW message or body]

An interesting title: Malware and HTTPS – a growing love affair

https://nakedsecurity.sophos.com/2020/02/18/malware-and-https-a-growing-love-affair/

Hosting your own CA has an advantage.

Regards,
Wai 

Wai Choi - RACF/PKI Design and Development



From:   Wai Choi <wchoi@US.IBM.COM>
To:     RACF-L@LISTSERV.UGA.EDU
Date:   01/31/2020 03:57 PM
Subject:        [EXTERNAL] Re: Who do you trust? (What CA's do you trust?)
Sent by:        RACF Discussion List <RACF-L@LISTSERV.UGA.EDU>



Charles,

Even for those CA certs shipped with RACF, the client side still needs to 
'beg' the RACF people to change the status, create a keyring and connect 
the CA cert to it, if  virtual keyring is not used.

I think if the reason offered for the "we don't want that certificate in 
our ring" objection is not trusting that CA cert according to the 
cooperate policy, the administrator is doing the right thing. Adding a CA 
cert to a keyring is a security consideration, it should be handled 
carefully. As long as the cooperate policy indicates it is a trusted CA, 
the RACF group should not reject to use it. 

It is not up to the application owner or the RACF admin to debate 
personally whether a CA should be trusted. But they can make the 
suggestion to make up the trusted CA list in the cooperate policy which 
everyone has to follow.

Regards,
Wai 

Wai Choi - RACF/PKI Design and Development




From:   Charles Mills <charlesm@MCN.ORG>
To:     RACF-L@LISTSERV.UGA.EDU
Date:   01/31/2020 01:59 PM
Subject:        [EXTERNAL] Re: Who do you trust? (What CA's do you trust?)
Sent by:        RACF Discussion List <RACF-L@LISTSERV.UGA.EDU>



Wai, of course what you say is correct, but having to install a CA
certificate is an obstacle to a POC. The guy or gal who is responsible for
the application has to go and beg the RACF people to install the
certificate.

Plus as you mention there is the "we don't want that certificate in our
ring" objection, which cannot happen if it is already installed.

Charles


-----Original Message-----
From: RACF Discussion List [mailto:RACF-L@LISTSERV.UGA.EDU] On Behalf Of 
Wai
Choi
Sent: Friday, January 31, 2020 10:47 AM
To: RACF-L@LISTSERV.UGA.EDU
Subject: Re: Who do you trust? (What CA's do you trust?)

Charles,

Before v2r3 RACF shipped 26 CA certificates. Most of them are 'well-known' 


CAs.  Two of them are IBM code signing CA's. 

The rationale is to simplify the SSL/TLS set up for the customers who 
happen to trust the CA's on the list. They only need to alter the status 
of the certificate to TRUST since all these certificates are shipped with 
NOTRUST status.

  But there are customers who do not want to have these CA certificates in 


their system even they have the NOTRUST status. Someone may accidentally 
alter the TRUST status. 
 
  From the convenience point of view, it is difficult to maintain a list 
of well known CA's nowadays as the number of CA agencies is growing, and 
there are multiple certificates under each    agency. It is hard to know 
which one will be commonly used by the customers in general. 

IBM does not endorse any CAs. It is not the responsibility of individual 
application owner to decide which CA to trust. This should be in the scope 


of cooperate policy. The one who is responsible for setting up the 
cooperate policy is the one to decide which CA to buy certificates from, 
just like any hardware/software purchases, or even use some in-house CA to 


generate certificates for internal use or for communicating with business 
partners.

The right approach is not to guess what CA is already in the clients' 
keyrings, but send the root CA of the server certificate to the clients 
and request them to install that CA, if they decide to communicate with 
your server, according to their cooperate policy. Before the communication 


can happen, you need to send the information to the client, like the 
domain name / ip address/ port number, right? For secure communication, 
you just need to send the root CA cert also.

Regards,
Wai 

Wai Choi - RACF/PKI Design and Development




From:   Charles Mills <charlesm@MCN.ORG>
To:     RACF-L@LISTSERV.UGA.EDU
Date:   01/30/2020 06:07 PM
Subject:        [EXTERNAL] Who do you trust? (What CA's do you trust?)
Sent by:        RACF Discussion List <RACF-L@LISTSERV.UGA.EDU>



X-posted IBM-MAIN and RACF-L.

 

Who do you trust? What CERTAUTH certificates do you have installed and
trusted?

 

I am contemplating purchasing an FTP server certificate for z/OS client 
FTP
access. I'd like to know which CA's are most likely to already be 
installed
in customers' CERTAUTH keyrings.

 

IBM used to ship certificates for VeriSign, Thawte, Integrion, Entrust,
Equifax and ICP. Are those still popularly-trusted CAs?

 

What about Comodo? They are the largest CA. What about GoDaddy? What about
Let's Encrypt, the no-charge CA?

 

There's been a lot of consolidation. Equifax is GeoTrust is VeriSign. 
Thawte
and Symantec are now DigiCert. 

 

Thanks,

 

Charles

 






[prev in list] [next in list] [prev in thread] [next in thread]