ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzalz_5.4.0.1/rzalzdigitalsignatures.htm

106 lines
7.0 KiB
HTML
Raw Permalink Normal View History

2024-04-02 14:02:31 +00:00
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en-us" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="security" content="public" />
<meta name="Robots" content="index,follow" />
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
<meta name="DC.Type" content="concept" />
<meta name="DC.Title" content="Digital signatures" />
<meta name="abstract" content="Learn about what digital signatures are and what protection they provide." />
<meta name="description" content="Learn about what digital signatures are and what protection they provide." />
<meta name="DC.Relation" scheme="URI" content="rzalzobjconcepts.htm" />
<meta name="DC.Relation" scheme="URI" content="../rzahu/rzahurazhudigitalcertmngmnt.htm" />
<meta name="DC.Relation" scheme="URI" content="rzalzsignableobjects.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2004, 2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2004, 2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="digitalsignatures" />
<meta name="DC.Language" content="en-us" />
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
<link rel="stylesheet" type="text/css" href="./ic.css" />
<title>Digital signatures</title>
</head>
<body id="digitalsignatures"><a name="digitalsignatures"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Digital signatures</h1>
<div><p>Learn about what digital signatures are and what protection they
provide.</p>
<p>i5/OS™ provides
support for using digital certificates to digitally "sign" objects. A digital
signature on an object is created by using a form of cryptography and is like
a personal signature on a written document. A digital signature provides proof
of the object's origin and a means by which to verify the object's integrity.
A digital certificate owner "signs" an object by using the certificate's private
key. The recipient of the object uses the certificate's corresponding public
key to decrypt the signature, which verifies the integrity of the signed object
and verifies the sender as the source.</p>
<p> Object signing support augments traditional iSeries™ server tools for controlling
who can change objects. Traditional controls cannot protect an object from
unauthorized tampering while the object is in transit across the Internet
or other untrusted network. Because you can detect whether the contents of
an object have been changed since they were signed, you can more easily determine
whether to trust objects that you obtain in cases such as these. </p>
<p>A digital signature is an encrypted mathematical summary of the data in
an object. The object and its contents are not encrypted and made private
by the digital signature; however, the summary itself is encrypted to prevent
unauthorized changes to it. Anyone who wants to ensure that the object has
not been changed in transit and that the object originated from an accepted,
legitimate source can use the signing certificate's public key to verify the
original digital signature. If the signature no longer matches, the data may
have been altered. In such a case, the recipient can avoid using the object
and can instead contact the signer to obtain another copy of the signed object.</p>
<p>The signature on an object represents the system that signed the object,
not a specific user on that system (although the user must have the appropriate
authority to use the certificate for signing objects). </p>
<p>If you decide that using digital signatures fits your security needs and
policies, you need to evaluate whether to use <a href="../rzahu/rzahurzahu4afinternetvsprivcert.htm">public certificates versus issuing local certificates</a>.
If you intend to distribute objects to users in the general public, you need
to consider using certificates from a well-known public Certificate Authority
(CA) to sign objects. Using public certificates ensures that others can easily
and inexpensively verify the signatures that you place on objects that you
distribute to them. If, however, you intend to distribute objects solely within
your organization, you may prefer to use <a href="../rzahu/rzahurazhudigitalcertmngmnt.htm">Digital Certificate Manager</a> (DCM) to operate your own
Local CA to issue certificates for signing objects. Using private certificates
from a Local CA to sign objects is less expensive than purchasing certificates
from a well-known public CA.</p>
<div class="section"><h4 class="sectiontitle">Types of digital signatures</h4><p>Beginning in V5R2, you
can sign command (*CMD) objects; you also can choose one of two types of signatures
for *CMD objects: core object signatures or entire object signatures. </p>
<ul><li><strong>Entire object signatures</strong> This type of signature includes all but
a few nonessential bytes of the object. </li>
<li><strong>Core object signatures</strong> This type of signature includes the essential
bytes of the *CMD object. However, the signature does not include those bytes
that are subject to more frequent changes. This type of signature allows some
changes to be made to the command without invalidating the signature. Which
bytes the core object signature does not include vary based on the specific
*CMD object; core signatures do not include parameter defaults on the *CMD
objects, for example. Examples of changes that will not invalidate a core
object signature include: <ul><li>Changing command defaults.</li>
<li>Adding a validity checking program to a command that does not have one.</li>
<li>Changing the Where allowed to run parameter. </li>
<li>Changing the Allow limited users parameter. </li>
</ul>
</li>
</ul>
</div>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzalzobjconcepts.htm" title="Use this concept and reference information to learn more about digital signatures and the object signing and signature verification processes work.">Object signing concepts</a></div>
</div>
<div class="relconcepts"><strong>Related concepts</strong><br />
<div><a href="rzalzsignableobjects.htm" title="Learn about which objects you can sign and about command (*CMD) object signature options.">Signable objects</a></div>
</div>
<div class="relinfo"><strong>Related information</strong><br />
<div><a href="../rzahu/rzahurazhudigitalcertmngmnt.htm">Digital Certificate Manager (DCM)</a></div>
</div>
</div>
</body>
</html>