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

List:       racf-l
Subject:    Re: RACF Certs z/OS 1.13
From:       Nigel Pentland <nigel () NIGELPENTLAND ! NET>
Date:       2013-11-20 23:22:57
Message-ID: 528D4451.8060600 () nigelpentland ! net
[Download RAW message or body]

Wai,

Many thanks, nicely put, I look forward to seeing this when we upgrade
to V1.13 (scheduled in Spring).

Kind regards

Nigel...

On 20/11/2013 20:50, Wai Choi wrote:
> Nigel,
>
> In z/OS v1.13, we restructured the key types in the RACDCERT LIST output
> to make them more comprehensive. RSA was the only key type RACDCERT
> supported at the very beginning. We used the store location to
> differentiate the key type - Non-ICSF, ICSF, PCICC  - these are all RSA
> keys. As we support more key types, there is a need to catagorize the
> types better. Also the keywords used for input and output can be more
> consistent.
>
> RACDCERT GENCERT ... RSA ... ==> generate a cert with RSA key pair, with
> private key stored in RACF
> RACDCERT GENCERT ... RSA(PKDS(...)) ... ==> generate a cert with RSA key
> pair, with private key stored in PKDS
>
> LIST examples:
> 1. Cert with RSA public key, private key is stored in RACF:
> Pre V1.13-
> Private Key Type: Non-ICSF
> Private Key Size: 1024
>
> V1.13 and after -
> Key Type: RSA
> Key Size: 1024
> Private Key: Yes
>
> 2. Cert with RSA public key, private key is stored in PKDS
> Pre V1.13-
> Private Key Type: ICSF
> Private Key Size: 1024
>
> V1.13 and after -
> Key Type: RSA
> Key Size: 1024
> Private Key: Yes
> PKDS Label: xxxxx
>
> 3. Cert with RSA public key, no private key (The old output didn't show
> the key size if there is no private key)
> Pre V1.13-
> Private Key Type: None
>
> V1.13 and after -
> Key Type: RSA
> Key Size: 1024
> Private Key: No
>
> Similar output for other key types - DSA, NISTECC, BPECC
>
> Regards,
> Wai
>
> Wai Choi - RACF/PKI Design and Development
>
>
>
> From:   Nigel Pentland <nigel@NIGELPENTLAND.NET>
> To:     RACF-L@listserv.uga.edu,
> Date:   11/20/2013 08:48 AM
> Subject:        Re: RACF Certs z/OS 1.13
> Sent by:        RACF Discussion List <RACF-L@listserv.uga.edu>
>
>
>
> On Mon, 18 Nov 2013 12:27:03 -0500, Joe Mscisz <Joseph_Mscisz@JBHUNT.COM>
> wrote:
>
>> Hello,
>>
>> We upgraded our z/OS system from 1.12 to 1.13 this weekend. All of our
>> outbound CICS Web services using SSL began failing with connection
> refused
>> errors. We finally determined that we were sending SSL type 1 ciphers
>> which were unsupported by our partner, where we had been sending type 3
> on
>> 1.12. The only thing that I can find that is different between systems is
>> the RACF digital certificate on 1.12 shows as NON-ICSF and in 1.13 it is
>> RSA. I'm thinking this is just presentation verbiage, but I'm at a loss.
>> Any ideas on what the culprit could be here? Please pardon my ignorance
>> here, and I greatly appreciate any insight. Thanks!!
> Hi Joe,
>
> Surpirsed nobody else has tried to answer, so I'll throw in my thoughts to
> see what happens.  I'm essentially a RACF adminsitrator who has moved over
> into doing mainly certificates, and I use RACDCERT a lot, but I'm not too
> knowledgeable when it comes to z/OS specific details out with RACF.
>
> I'm confused by the term SSL type 1 which from a quick Google seems to
> simply mean basic authentication which would typically be a one sided
> SSL.  By that I mean only one side has a private key, namely the server
> side.  The client side will only require the trusted root in order to
> validate the certificate chain.
>
> Then you talk about NON-ICSF and RSA.  NON-ICSF indicates two things.
> First there is a private key present, and second it's held within RACF and
> not in ICSF,  i.e. hardware protected.
>
> e.g. (from a RACDCERT certificate listing)
>
>    Private Key Type: Non-ICSF
>    Private Key Size: 1024
>
> As for RSA, I don't see any references for RSA are within RACDCERT
> listings of certificates.  I am used to seeing them else where for either
> the signature algorithm used to sign the certificate, or on OpenSSL traces
> showing how a certificate is being used rather than how it was generated.
>
> Are you able to share any RACDCERT listings of either certificates or
> keyrings?  If you have the same certificates, I would be more suspicious
> of the keyrings being incorrect, or the cipher suites being defined by the
> applications trying to use the certificates.  Come to that are you able to
> share any info about which applications are trynig to use the
> certificates?
>
> Hope this might in some way help?
>
> Nigel...


--

http://kimtag.com/nigelpentland
[prev in list] [next in list] [prev in thread] [next in thread]