Arnold,
Thank you very much for your help, I appreciate it.
When talking about performance I also thouth about key "life management"
like new key, key change, key delete. I don't expect it would be very
frequent operation, but even that in multi-milion (10-20M rather than
2-3M) key database can be an issue.
Regards
--
Radoslaw Skorupka
Lodz, Poland
W dniu 2018-06-28 o 19:12, Todd Arnold pisze:
Here are the answers from my friends on the ICSF development team.
1. Is it good idea to have millions of keys in PKDS? Would it be a
problem for ICSF? VSAM limits seem to be not a problem, but maybe ICSF
have some bottlenecks or limitations.
There will be no problem for ICSF to store 2 to 3 million public keys in the
PKDS.
2. Can I keep the keys out of PKDS, for example in DB2 table? Note, we
talk about public key, so there is no big reason to keep it secret.
For example: tell ICSF to check msg using given key value, instead of
given key label. I remeber such solution is feasible for symmetric keys
(the key was encrypted using Master Key).
Yes, you can store the key tokens outside the PKDS. Callable services accept a
label or key token. PKA public keys are in the clear, so there is no security
issues.
To be clear, I would only recommend keeping public keys outside the PKDS.
Private keys should be maintained in the PKDS so they are properly reenciphered
during a master key change.
3. What about performance? While DB2 table can be buffered, what about
PKDS? Does it require I/O for every key use?
During initialization, ICSF copies the PKDS into 64 bit storage. When a label
is passed to a callable service, ICSF retrieves the key token from the in-store
PKDS. No I/O is performed during the retrieval
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
.
======================================================================
--
Treść tej wiadomości może zawierać informacje prawnie chronione Banku
przeznaczone wyłącznie do użytku służbowego adresata. Odbiorcą może być jedynie
jej adresat z wyłączeniem dostępu osób trzecich. Jeżeli nie jesteś adresatem
niniejszej wiadomości lub pracownikiem upoważnionym do jej przekazania
adresatowi, informujemy, że jej rozpowszechnianie, kopiowanie, rozprowadzanie
lub inne działanie o podobnym charakterze jest prawnie zabronione i może być
karalne. Jeżeli otrzymałeś tę wiadomość omyłkowo, prosimy niezwłocznie
zawiadomić nadawcę wysyłając odpowiedź oraz trwale usunąć tę wiadomość
włączając w to wszelkie jej kopie wydrukowane lub zapisane na dysku.
This e-mail may contain legally privileged information of the Bank and is
intended solely for business use of the addressee. This e-mail may only be
received by the addressee and may not be disclosed to any third parties. If you
are not the intended addressee of this e-mail or the employee authorized to
forward it to the addressee, be advised that any dissemination, copying,
distribution or any other similar activity is legally prohibited and may be
punishable. If you received this e-mail by mistake please advise the sender
immediately by using the reply facility in your e-mail software and delete
permanently this e-mail including any copies of it either printed or saved to
hard drive.
mBank S.A. z siedzibą w Warszawie, ul. Senatorska 18, 00-950 Warszawa,
www.mBank.pl, e-mail: [email protected]ąd Rejonowy dla m. st. Warszawy XII
Wydział Gospodarczy Krajowego Rejestru Sądowego, nr rejestru przedsiębiorców
KRS 0000025237, NIP: 526-021-50-88. Według stanu na dzień 01.01.2018 r. kapitał
zakładowy mBanku S.A. (w całości wpłacony) wynosi 169.248.488 złotych.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
