misc/48940: Typos in developers/pgp.xml

[jlmuir%imca-cat.org@localhost]

>Number:         48940
>Category:       misc
>Synopsis:       Typos in developers/pgp.xml
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    misc-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jun 23 15:45:00 +0000 2014
>Originator:     J. Lewis Muir
>Release:        
>Organization:
>Environment:
>Description:
There are some typos and grammar problems in the PGP Key Management Guide at 
<http://www.netbsd.org/developers/pgp.html>.

(I initially reported this with a patch via email to www%NetBSD.org@localhost, 
but I did not receive a reply.)
>How-To-Repeat:

>Fix:
Index: developers/pgp.xml
===================================================================
RCS file: /cvsroot/htdocs/developers/pgp.xml,v
retrieving revision 1.15
diff -u -r1.15 pgp.xml
--- developers/pgp.xml  20 May 2012 11:19:19 -0000      1.15
+++ developers/pgp.xml  16 Jun 2014 19:18:33 -0000
@@ -55,7 +55,7 @@
     amongst its members.
   </para>
   <para>
-    Typical examples activities requiring this web of trust are:
+    Typical examples of activities requiring this web of trust are:
   </para>
   <itemizedlist>
     <listitem>
@@ -66,8 +66,8 @@
     </listitem>
     <listitem>
       <para>
-      the ability to sign someone else's key (to build a project
-      wide web-of-trust, see below), and to be able to sign an applicants
+      the ability to sign someone else's key (to build a project-wide
+      web-of-trust, see below), and to be able to sign an applicant's
       key
       </para>
     </listitem>
@@ -91,7 +91,7 @@
   <title>Web-of-trust approach</title>
   <para>
     Everyone can create an arbitrary number of keys: any key with any identity;
-    it may not be her/his real identity. He or she may upload these keys to any
+    it may not be her/his real identity. She or he may upload these keys to any
     key server. This implies that a person could pretend to be the key owner
     (who is given as the user-id) although she/he isn't.
   </para>
@@ -150,9 +150,8 @@
     First of all, to ensure maximum security over time, it is advisable to
     choose long key lengths. The key size limitation of a maximum of 1024 bits
     in the current DSA standard may limit the security of DSA. For maximum
-    security it is therefore advisable to use 2048-bit RSA keys for both,
+    security it is therefore advisable to use 2048-bit RSA keys for both
     encrypting and signing.
-    keys).
   </para>
   <note><title/>
     <programlisting>
@@ -213,11 +212,12 @@
     </para>
     <para>
       Another question is whether a key should initially have an expiration
-      date, or not. As the expiration date can set or changed later on (unlike
-      PGP 2.x keys), this question is mostly a matter of personal choice. A
-      good reason to put an expiration date on a key is that people sometimes
-      forget their passphrase or lose the secret key.  With an expiration date,
-      there is a drop-dead date after which the key is not going to be used.
+      date, or not. As the expiration date can be set or changed later on
+      (unlike PGP 2.x keys), this question is mostly a matter of personal
+      choice. A good reason to put an expiration date on a key is that people
+      sometimes forget their passphrase or lose the secret key.  With an
+      expiration date, there is a drop-dead date after which the key is not
+      going to be used.
     </para>
     <para>
       After key creation, uids for all e-mail addresses you use should be added
@@ -349,14 +349,14 @@
       <para>
         If everything matches, make a note on his PGP "business card" that
         the identity check was successful (with date). This does seem an odd
-        thing to do when you meet a single developer, but is really the only
+        thing to do when you meet a single developer, but it is really the only
         way to reliably keep track of things at key signing parties and
         therefore is considered good practice.
       </para>
     </listitem>
     <listitem id="signsteps-pkey-import">
       <para> 
-        When back at your computer, import the other party's public key
+        When back at your computer, import the other person's public key
         (either from a public key server, or from localsrc). With gnupg, this
         is simply done with:
       </para>
@@ -404,12 +404,12 @@
     <listitem id="signsteps-pkey-verify-email">
       <para>
         The remaining task prior to signing is to determine whether the other
-        party has control over the e-mails given in all uids. To check this,
+        person has control over the e-mails given in all uids. To check this,
         generate a random number and send this number, encrypted with his key,
-        to the other party. The task of the other party is to encrypt this
+        to the other person. The task of the other person is to encrypt this
         random number and send it back, this time encrypted with your public
         key (the requirement for the encrypted return channel is to spoil any
-        crypto-analysis attacks).  It is important for the other party
+        crypto-analysis attacks).  It is important for the other person
         to sign the message he sends back, so that you can verify
         his identify in step <xref linkend="signsteps-pkey-verify-signature"/>.
       </para>
@@ -437,7 +437,7 @@
       <para> 
         Once you've received his reply, decrypt it and check his signature.
         If that is successful, that concludes the necessary tests and you can
-        signs his public key.
+        sign his public key.
       </para>
       <para>
         Using GPG, signing a key is done like this: