106 lines
7.0 KiB
HTML
106 lines
7.0 KiB
HTML
<?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> |