|
Purpose Use the RACDCERT ADD command
to define a digital certificate using a certificate or certificate
package contained in the specified data set.
Each user ID can
be associated with more than one digital certificate but they must
be added individually. The specified data set should contain only
one digital certificate. The command reads the certificate from the
data set, updates the user's profile, and creates the DIGTCERT profile.
If the data set contains a PKCS#7 or PKCS#12 package,
the data set can contain more than one certificate and the processing
will be as described in PKCS #7 and PKCS
#12 processing details.
See UTF-8 and BMP character restrictions for information about how UTF-8 and BMP characters in certificate
names and labels are processed by RACDCERT functions.
Details about DIGTCERT profile names The name of a DIGTCERT profile is derived from the certificate's
serial number and the issuer's distinguished name (IDN). Any character
in either value that would not be valid in a RACF profile name, such
as a blank, is replaced with the ¢ character (X'4A').
The maximum length of a DIGTCERT profile name is 246
characters. The format of the profile name is based on the combined
length of the certificate's serial number and the issuer's distinguished
name (IDN), including the period.
When the combined length of the value of serial-number. issuer's-distinguished-name is 246 characters or less, the name of the DIGTCERT profile
uses the following format: serial-number.issuer's-distinguished-name
When the combined length of the value of serial-number. issuer's-distinguished-name exceeds 246 characters, the name of the DIGTCERT profile
uses the following format, where the certificate-hash value is a hexadecimal representation of the certificate
in a hashed form: serial-number.<first-portion-of-IDN><certificate-hash><last-portion-of-IDN>
When a DIGTCERT profile name contains a certificate hash
value, each occurrence of the equal sign (=) delimiter
is replaced with a colon (:).
For examples
of DIGTCERT profile names, see "DIGTCERT profile
names" in z/OS Security Server RACF Security Administrator's Guide.
Processing details - Re-adding a certificate:
- If the certificate being added already exists in the RACF® database, RACF will accept the certificate and refresh its stored information
if all of the following conditions are true:
- The certificate is being added to the same user ID, SITE, or CERTAUTH
as before.
- The label specified for the certificate matches the old value
or no label is specified.
- The certificate being added has the same public key
as the existing certificate.
Otherwise, an informational message is issued, and the certificate
is not re-added.
- Renewing a certificate:
- The RACDCERT ADD function also supports certificate replacement,
for cases of certificate renewal and fulfillment by an external certificate
authority. When a certificate is replaced, all existing information, including key ring associations, are updated to reflect the new certificate.
In addition, a new certificate label can be specified.
The
certificate in the RACF database
is replaced if the following conditions are true. - If the existing certificate has a private key associated with
it:
- The certificate is being added to the same user ID, SITE, or CERTAUTH
as before.
- The certificate being added is not a duplicate. (You are not re-adding
the certificate.)
- The certificate being added is not expired.
- The certificate being added has the same public key as the existing
certificate.
- If the existing certificate does not have a private key
associated with it:
- The certificate is being added to the same user ID, SITE, or CERTAUTH
as before.
- The certificate being added is not a duplicate. (You are not re-adding
the certificate.)
- The certificate being added is not expired.
- The certificate being added has a later expiration date than that
of the existing certificate.
- The certificate being added has the same subject's distinguished
name, issuer's distinguished name, and public key as the existing
certificate.
- Adding a certificate with an existing key in the PKDS:
-
- If the certificate you are adding has an existing public or private
key in the PKDS, and the key is already associated with this certificate,
the following rules apply:
- If the public key already exists in the PKDS and you add its matching
private key certificate, you must specify the PKDS, ICSF, or PCICC
keyword. This upgrades the PKDS entry to include the new RSA or ECC
private key.
- The PKDS label of the existing public or private key is not changed
when you respecify the label with the PKDS, ICSF, or PCICC keyword.
- If the private key already exists in the PKDS as an RSA Modulus-Exponent
(ME) key token, specifying PKDS or PCICC does not convert the key
to an RSA Chinese Remainder Theorem (CRT) key token.
- If the private key already exists in the PKDS as a CRT key token,
specifying ICSF does not convert the key to an ME key token.
- If the certificate you are adding has an existing public or private
key in the PKDS but the key is not already associated with
this (or another) RACF certificate, RACF associates the key with this
certificate when all of the following conditions are true:
- You specify the PKDS label of the existing key using the PKDS,
ICSF, or PCICC keyword.
- The existing key is either an RSA or ECC private key (an ICSF
internal key token) or an RSA or ECC public key.
- Supported certificate package formats:
- The certificate package must be in one of the following formats:
- A single BER encoded X.509 certificate.
- A single Base64 encoded X.509 certificate.
- A Privacy Enhanced Mail (PEM) encoded X.509 certificate. If the
input is in this format, only the Originator Certificate is used.
- One or more X.509 certificates contained within a PKCS #7 DER
encoding package.
- One or more X.509 certificates and private keys contained within
a PKCS #12 DER encoding package. If the input is in this format, all
certificates are processed but only the first user private key is
used. PKCS #12 is also known as Private Information Exchange (PFX).
The obsolete PFX V0.02 standard is not supported.
- Details about adding new certificates:
- The following are additional details regarding RACDCERT's certificate
processing:
- All fields as defined for X.509 version 1 certificates must be
present and must have a length greater than zero (non-null).
- X.509 certificates with version numbers greater than 3 are not
supported.
- Noncritical extensions are ignored. Critical extensions that are
supported include:
- keyUsage - { 2 5 29 15 }
- basicConstraints - { 2 5
29 19 }
- subjectAltname - { 2 5
29 17 }
- issuerAltName - { 2 5
29 18 }
- certificatePolicies - { 2 5
29 32 }
- policyMappings - { 2 5
29 33 }
- policyConstraints - { 2 5
29 36 }
- nameConstraints - { 2 5
29 30 }
- extKeyUsage - { 2 5 29 37 }
- hostIdMapping - { 1 3
18 0 2 18 1 }
- subjectKeyIdentifier - { 2 5
29 14 }
- authorityKeyIdentifier - { 2 5
29 35 }
- Subject and issuer names can contain only the following string
types:
- UTF8 - TAG 12
- PRINTABLESTRING - TAG 19
- T61STRING - TAG 20
- IA5STRING - TAG 22
- VISIBLESTRING - TAG 26
- GENERALSTRING - TAG 27
- BMPString - TAG 30
- Because certificates can be encoded differently, be aware when
transporting the different certificate encodings to and from z/OS systems.
Both the BER encoded X.509 and PKCS #7 formats are binary formats
and must be transported in their exact binary format. For example,
binary formats, such as BER and X.509, cannot have any ASCII to EBCDIC
translation performed on them, therefore, they must be transported
in their exact binary format. In contrast, text formats, such as PEM
and Base64, must be transported as text. When transporting for an
ASCII system, the ASCII to EBCDIC translation must be performed for
the PEM format and Base64 format certificate.
- PKCS #12 format details:
- PKCS #12 certificate packages can be processed. These certificates
are encrypted with a password when received and must be decrypted
with the same password before being added to the RACF database. For additional information, see
the PASSWORD ('pkcs12-password') keyword.
When
adding a certificate package that contains a private key, if ICSF
is being used to store private keys and no label is specified for
the ICSF key, ADD generates a default label in the format IRR.DIGTCERT.certificate-owner.cvtsname.ebcdic-stck-value, where certificate-owner is the owning user ID, cvtsname is the system name, as taken from the CVT, and ebcdic-stck-value is an EBCDIC version of the current store-clock value. See "PKCS #7 and PKCS #12 processing details" for information
on how the multiple certificates are processed.
- PKCS #7 and PKCS #12 processing details:
- The ADD function of RACDCERT can accept PKCS #7 and PKCS #12 certificate
packages. For PKCS #7, if there is more than one certificate in the
package, the set consisting of the second through last certificate
is the hierarchy of CAs. For PKCS #12, every certificate in the package
other than the first one that has a 'local key ID' that matches the first private key in the package, is considered
to be a CA certificate. If the command issuer is authorized to add
CERTAUTH certificates, the CA certificates will be sorted to determine
the hierarchy chain. The resulting set is then added to the CERTAUTH
category in the hierarchy order (top CA down to lowest CA). Thus each
certificate in the package may be verified using its previously added
parent. If the command issuer is not authorized to add CERTAUTH certificates,
an informational message will be issued. In either case, processing
will then continue with the first certificate in the package (the
end-entity certificate).
Rules: For each CERTAUTH certificate
in the PKCS #7 or PKCS #12 package, the following rules apply in determining
trust status. The rules are listed in priority order. For rules that
conflict, the first matching rule wins.
- If the certificate is already defined to RACF with status HIGHTRUST, the certificate
retains its HIGHTRUST status.
- The trust status specified by the command issuer will apply to
the top CA certificate. This primes the chain with a trust value which
may be inherited down. (See the next rule.) The HIGHTRUST keyword
is ignored if the target user ID on the ADD is not CERTAUTH (irrcerta).
- For all lower CA certificates in the package and for the top CA
certificate when no trust status is specified, the trust status is
determined dynamically as follows:
- If NOTRUST is specified by the command issuer, the certificate
is added with status NOTRUST.
- If the certificate has one or more of the following inconsistencies,
the certificate is added with NOTRUST status:
- The certificate is expired.
- The certificate has an incorrect date range relative to the issuing
CA certificate. (The validity period is not completely contained within
the validity period of the issuing CA certificate).
- The issuer of the certificate is missing from the package and
is not already installed under CERTAUTH.
- The certificate has an unknown signature algorithm
to RACF. The supported signature algorithms are: SHA1RSA,
SHA224RSA, SHA256RSA, SHA384RSA, SHA512RSA, SHA1ECDSA, SHA224ECDSA,
SHA256ECDSA, SHA384ECDSA, SHA512ECDSA, SHA1DSA, MD2RSA and MD5RSA.
- If no inconsistencies are detected, the certificate is added and
inherits the trust status of its parent. If the certificate's parent
has not previously been added (either as a part of this package or
otherwise), the certificate is added with TRUST status if it is self-signed,
NOTRUST status if it is not self-signed. If the self-signed certificate
has already been added, its trust status is not changed.
- HIGHTRUST will be inherited from the parent as per the previous
rule only if the target user ID on the ADD is CERTAUTH (irrcerta) and HIGHTRUST was specified on the command. In all other cases,
HIGHTRUST reverts to TRUST when inheriting from the parent.
- The LABEL value will not be used. The label will be generated.
The authority required to add the CERTAUTH certificates
from a PKCS #7 or PKCS #12 package is the same authority required
to add CERTAUTH certificates directly, either CONTROL authority to
IRR.DIGTCERT.ADD in the FACILITY class or RACF SPECIAL. Note: PKCS #7 and PKCS #12 add
error processing that has no backout support. If a terminating error
is encountered during processing, any CERTAUTH certificates previously
added are not removed. Unless otherwise stated in the error message
description, any error messages issued are relative to the certificate
where the error occurred. This may be the end-entity certificate or
one of the CERTAUTH certificates.
Issuing options The following table identifies
the eligible options for issuing the RACDCERT ADD command: As a RACF TSO command? |
As a RACF operator command? |
With command direction? |
With automatic command direction? |
From the RACF parameter library? |
---|
Yes |
No |
No. (See rules.) |
No. (See rules.) |
No |
Rules: The
following rules apply when issuing this command. - The RACDCERT command cannot be directed to a remote system using
the AT or ONLYAT keyword.
- The updates made to the RACF database by RACDCERT are eligible for propagation with automatic
direction of application updates based on the RRSFDATA profiles AUTODIRECT.target-node.DIGTCERT.APPL and AUTODIRECT.target-node.DIGTRING.APPL, where target-node is the remote node to which the update is to be propagated.
|
Authorization required To issue the RACDCERT ADD command, you must have the following
authorizations: - The SPECIAL attribute, or sufficient authority to the IRR.DIGTCERT.ADD
resource in the FACILITY class for your intended purpose, as shown
in Table 1.
- READ access to the data set that contains the certificate you
are adding.
When your installation controls access to ICSF services
and the CSFSERV class is active, additional access to resources in
the CSFSERV class might be required as follows:
Table 1. Authority required for the
RACDCERT ADD functionIRR.DIGTCERT.ADD |
---|
Access level |
Purpose |
---|
READ |
Add a certificate to your own user ID. |
UPDATE |
Add a certificate for another user ID. |
CONTROL |
Add a SITE or CERTAUTH certificate. |
Activating your changes If the DIGTCERT
or DIGTRING class is RACLISTed, refresh the classes to activate your
changes.
Example: SETROPTS RACLIST(DIGTCERT, DIGTRING) REFRESH
Syntax For the key to
the symbols used in the command syntax diagrams, see Syntax of RACF commands and operands. The complete syntax of the RACDCERT
ADD command is:
|
---|
RACDCERT ADD(data-set-name) |
[ ID(certificate-owner) | SITE | CERTAUTH ]
[ TRUST | NOTRUST | HIGHTRUST ]
[ WITHLABEL('label-name') ]
[ PASSWORD('pkcs12-password') ] [ PKDS[(pkds-label | * )] | PCICC[(pkds-label | * )] | ICSF[(pkds-label | * )] ]
|
If you specify more than one RACDCERT function, only
the last specified function is processed. Extraneous keywords that
are not related to the function being performed are ignored.
If you do not specify a RACDCERT function, LIST is
the default function.
For information on issuing this command
as a RACF TSO command, refer
to RACF TSO commands.
Parameters - ADD(data-set-name)
- Specifies the data set containing one digital certificate or certificate
package. You must specify a cataloged data set, and it may not be
a PDS or a PDS member. The record format (RECFM) expected by RACDCERT
is variable-byte (VB). When you specify the ADD function, RACDCERT
dynamically allocates and opens the specified data set, and reads
the certificate from it as binary data.
If the
certificate package you are adding has an associated ECC private
key, the ICSF subsystem must be operational and configured for PKCS
#11 operations.
To add certificate with
an RSA key that is longer than 1024 bits and is to be stored in the
RACF database, the CP Assist for Cryptographic Function (CPACF) must
be enabled.
Restriction: When ICSF is operating in FIPS
mode, you cannot add a certificate that has a Brainpool ECC key.
- ID(certificate-owner) |
SITE | CERTAUTH
- Specifies that the new certificate is either a user certificate
associated with the specified user ID, a site certificate, or a certificate-authority
certificate. If you do not specify ID, SITE, or CERTAUTH, the default
is ID, and certificate-owner defaults to
the user ID of the command issuer. If more than one keyword is specified,
the last specified keyword is processed and the others are ignored
by TSO command parse processing.
If the new certificate has an ECC private key and keyAgreement is the only key usage, the
certificate cannot be used for signing. Therefore, you cannot add
it as a CERTAUTH certificate.
- TRUST | NOTRUST | HIGHTRUST
- Specifies whether the status of the certificate being
added is trusted, not trusted, or highly trusted. Whether a certificate
is not trusted or trusted depends on whether or not the certificate
is valid and whether the private key has been compromised or not.
Because highly trusted certificates are by definition trusted certificates,
any certificate usage that was enabled by marking the certificate
trusted will also be enabled by marking the certificate highly trusted.
However, only certificate-authority certificates can be highly trusted.
The trust status is stored in the UACC field of the certificate profile: - X'00' indicates the status is trusted
- X'80' indicates the status is not trusted
- X'C0' indicates the status is highly trusted
When a certificate is trusted, it can be used by RACF for its intended purpose (map
to a user ID, or treat as a trusted certificate authority or trusted
site).
For a personal certificate, TRUST indicates that the
certificate can be used to authenticate a user ID.
For a certificate-authority
certificate, a trusted certificate is one that can be used to authenticate
a user's certificate by indicating that the entity identified in the
certificate (for example, the certificate authority) can issue certificates
that this system honors. This implies that a user can gain access
to the system based on the information contained in the certificate
if the user's certificate was signed by a trusted certificate authority.
For site certificates, a trusted certificate is one indicating
that the entity identified in the certificate (for example, the site)
can gain access to the system based on information contained within
the certificate. Because the authority that issued the certificate
might not be defined to the system as a certificate authority, this
certificate information might not be able to be authenticated.
TRUST should only be specified if the command issuer knows: - This is a valid certificate for this user, site, or certificate
authority.
- The private key related to this certificate has not been compromised.
If no trust value is specified on the command, the following
processing will take place to determine the trust status: - If the certificate's signature can be verified, the certificate
has not expired, and the certificate's validity date range is within
the validity date range of the certifying authority's certificate,
the trust status is set to the trust status of the certifying authority's
certificate. For self-signed certificates the certificate being added
is set to TRUST by default. If the self-signed certificate has already
been added, its trust status is not changed.
- If the certificate has expired, has an incorrect validity date
range, or cannot be verified because it either has an unknown encryption
algorithm or RACF cannot locate
its certifying authority's certificate, the status is set to NOTRUST
by default.
- If the trust status is to be set from the status of the certifying
certificate and the certifying certificate is highly trusted, the
status will be trusted.
If the certificate's signature is incorrect, the certificate
is not added.
The TRUST keyword is unrelated to the
TRUSTED attribute as defined for started procedures.
- WITHLABEL('label-name')
- Specifies the label to be associated with the certificate.
Up to 32 characters can be specified. The label-name can contain blanks and mixed-case characters.
This label
is used as a handle instead of the serial number and issuer's
distinguished name. It can be used to store a descriptive text.
If the value specified in WITHLABEL already exists, RACDCERT
returns a message indicating that the label has already been used.
The certificate is not added.
If the user did not specify WITHLABEL,
and the data set being processed is PKCS #12, RACF generates the label based on the certificate's
friendly name, which is extracted from the PKCS #12 package and truncated
to 32 characters if required.
If WITHLABEL is not specified,
or extracted from the PKCS #12 package, RACDCERT generates a label
for the certificate. The generated label is of the form LABELnnnnnnnn, where nnnnnnnn is the first integer value, starting at 00000001 that generates a unique label name.
The label-name is stripped of leading and trailing
blanks. If a single quotation mark is intended to be part of the label-name, use two single quotation marks together
for each single quotation mark within the string, and enclose the
entire string within single quotation marks.
- PASSWORD('pkcs12-password')
- Specifies the password that is associated with the PKCS
#12 certificate package. This keyword is required if the data set
is PKCS #12 and it must not be specified if the data set is not PKCS
#12.
Note: The password specified will be visible on the screen,
so care should be taken to prevent it from being viewed when entered.
Because PKCS #12 passwords do not follow the normal TSO/E rules for
password content, they cannot be suppressed as they normally would
be.
The 'pkcs12-password' can
be up to 255 characters in length, is case-sensitive, and can contain
blanks.
- PKDS | PCICC | ICSF
- Specifies that RACF should attempt to store the RSA or ECC public or private
key associated with this certificate in the ICSF PKA key data set
(PKDS). This applies when the key is introduced to RACF by issuing the ADD function, and when an
existing certificate profile is replaced by issuing the ADD function.
The default action for a new key is for RACF to store it as a software key in the RACF database, not in the ICSF
PKDS. The default action for an existing key is to leave it unchanged.
These keywords cannot be specified when the key already
exists as a secure key in the ICSF token key data set (TKDS).
Guidelines for choosing PKDS, PCICC, or ICSF: When you need hardware protection for the private key, choose the
PKDS, PCICC, or ICSF keyword based on key type, key size, and available
cryptographic hardware. - The PKDS keyword supports both ECC and RSA private keys. For RSA
keys, PKDS is equivalent to PCICC and stores the key as an RSA Chinese
Remainder Theorem (CRT) key token. RACDCERT LIST
will display this key with key type RSA along with a PKDS label.
- The ICSF keyword supports only RSA keys and stores the key as
an RSA Modulus-Exponent (ME) key token. RACDCERT
LIST will display this key with key type RSA Mod-Exp along with a
PKDS label.
- The PKDS and PCICC keywords provide the best performance and support
RSA key sizes up to 4096 bits, but require a PCI-class cryptographic
coprocessor.
- The ICSF keyword can be used on a PCI-class cryptographic coprocessor
or older cryptographic coprocessor. However, the key size is limited
to 1024 bits.
For details about specifying or allowing RACF to generate
the PKDS label, see PKDS label considerations.
For the hardware requirements for storing or accessing
a key in the ICSF PKA key data set (PKDS), see Hardware requirements.
- PKDS[(pkds-label | * )]
- Specifies that RACF should
attempt to store the public or private key associated in the ICSF
PKDS as follows, based on key type.
- For an RSA key:
When you specify a PKDS
label or an asterisk ( *): - If the certificate has a private key, the private key is converted
using a PCI-class cryptographic coprocessor to an RSA Chinese Remainder Theorem (CRT) key token. The
resulting private key is stored in the ICSF PKDS.
- If the certificate has no private key, the public key is stored
as an RSA Modulus-Exponent (ME) key token.
If the data set contains only a certificate, you must
specify a pkds-label value or an asterisk (*). Otherwise, the PKDS keyword is ignored and no PKDS entry is created.
The public key is stored in the ICSF PKDS as an RSA Modulus-Exponent
(ME) key token with the specified label.
If the certificate
has no private key and you specify PKDS without a PKDS label
and without an asterisk (*), the PKDS keyword
is ignored and no PKDS entry is created.
If the data set contains
a PKCS #12 package, the private key is stored in the ICSF PKDS an
RSA Chinese Remainder Theorem (CRT) key token with either a system-generated
label, a label specified by pkds-label, or a label copied from
the certificate label.
Note: If you want to store the
RSA private key in the PKDS as an RSA Modulus-Exponent (ME) key token,
specify ICSF instead of this keyword.
- For an ECC key:
If the data set contains only a certificate,
you must specify a pkds-label value or an asterisk (*). Otherwise, the PKDS keyword is ignored and no PKDS entry
is created. The public key is stored in the ICSF PKDS with the specified
label.
If the certificate has no private key and you specify
PKDS without a PKDS label and without an asterisk (*), the PKDS keyword is ignored and no PKDS entry is created.
If the data set contains a PKCS #12 package, the private key
is stored in the ICSF PKDS with either a system-generated label, a
label specified by pkds-label, or a label copied from the certificate
label.
- For a DSA key: The PKDS keyword is ignored.
- PCICC[(pkds-label | * )]
- Specifies the same option as the PKDS keyword for an RSA key.
See the PKDS keyword of the RACDCERT ADD function for details.
- ICSF[(pkds-label | * )]
- Specifies that the public or private key is to be converted to
an RSA Modulus-Exponent (ME) key token. The resulting key is stored
in the ICSF PKDS.
If the certificate has no private key and you
specify ICSF without a PKDS label and without an asterisk
(*), the ICSF keyword is ignored and no PKDS entry
is created.
Examples
|
|
|
---|
Example 1 |
Operation |
User RACFADM with SPECIAL authority
requests the addition of a digital certificate for user NETB0Y. User
RACFADM has placed the digital certificate in data set 'RACFADM.NETB0Y.CERT' and wants the status of the certificate to be trusted. |
Known |
User RACFADM has SPECIAL authority.
RACFADM has placed the digital certificate in data set 'RACFADM.NETB0Y.CERT'. |
Command |
RACDCERT ADD('RACFADM.NETB0Y.CERT')
ID(NETB0Y)
TRUST WITHLABEL('Savings Account')
|
Output |
IRRD199I Certificate with
label ‘Savings Account’ is added for ’NETB0Y’ |
|
Example 2 |
Operation |
User WENTING exports her new certificate using
the RACDCERT EXPORT command and sends it to her business partner Yun.
When he receives it, Yun adds it to his company's RACF data base as a SITE certificate using the
RACDCERT ADD command and calls it WenTing. |
Known |
The exported certificate does not contain the
private key so the data set Wen Ting transmits to Yun need not
be protected in any way. |
Commands |
Wen Ting's RACDCERT EXPORT command: RACDCERT EXPORT(LABEL('Wen Ting''s certificate')) DSN(FOR.YUN.CRT)
Yun's RACDCERT ADD command: RACDCERT SITE ADD(WENTING.CRT) WITHLABEL('WenTing') ICSF(*)
|
Output |
IRRD199I Certificate with label 'WenTing'
is added for SITE. |
|
Example 3 |
Operation |
User RACFADM wants to add a certificate
for user NETB0Y and protect the ECC private key by storing it in the
ICSF PKDS. User RACFADM has placed the digital certificate in data
set 'RACFADM.NETB0Y.ECC.CERT' and wants the status
of the certificate to be trusted. |
Known |
User RACFADM has SPECIAL authority
and sufficient access to the appropriate resources in the CSFSERV
class. The system contains an operational ICSF subsystem and Crypto
Express3 coprocessor (CEX3C). |
Command |
RACDCERT ADD('RACFADM.NETB0Y.ECC.CERT')
ID(NETB0Y)
TRUST WITHLABEL('Savings Account ECC PKDS')
PKDS(ECC4NETB0Y)
|
Output |
IRRD199I Certificate with
label ‘Savings Account ECC PKDS’ is added for ‘NETB0Y’ |
|