Spelling, from Guido Guenther

git-svn-id: svn://svn.h5l.se/heimdal/trunk/heimdal@20208 ec53bebd-3082-4978-b11e-865c3cabbd6b

doc/setup.texi

@@ -1079,12 +1079,12 @@ of the document to see the requirements on the CA sortware.
 There needs to exist a mapping between the certificate and what
 principals that certificate is allowed to use. There are several ways
 to do this. The administrator can use a configuration file, storing
-the principal in SubjectAltName in extensions of certificate, or store
+the principal in the SubjectAltName extension of the certificate, or store the
-the mapping in the principals entry in the kerberos database.
+mapping in the principals entry in the kerberos database.
 
 @section Certificates
 
-This section document the requirements on the KDC and client
+This section documents the requirements on the KDC and client
 certificates and the format used in the id-pkinit-san OtherName
 extention.
 
@@ -1092,10 +1092,10 @@ extention.
 
 The certificate for the KDC have serveral requirements.
 
-First the certificate should have a Extended Key Usage (EKU)
+First the certificate should have an Extended Key Usage (EKU)
 id-pkkdcekuoid (1.3.6.1.5.2.3.5) set. Second there must be a
 subjectAltName otherName using oid id-pkinit-san (1.3.6.1.5.2.2) in
-the type field and and DER encoded KRB5PrincipalName that matches the
+the type field and a DER encoded KRB5PrincipalName that matches the
 name of the TGS of the target realm.
 
 Both of these two requirements are not required by the standard to be
@@ -1103,19 +1103,19 @@ checked by the client if it have external information what the
 certificate the KDC is supposed to be used. So its in the interst of
 minimum amount of configuration on the clients they should be included.
 
-Remember that if client would accept any certificate as the KDC's
+Remember that if the client would accept any certificate as the KDC's
 certificate, the client could be fooled into trusting something that
 isn't a KDC and thus expose the user to giving away information (like
 password or other private information) that it is supposed to secret.
 
-Also, if the certificate have a nameConstraints extention with a
+Also, if the certificate has a nameConstraints extention with a
 Generalname with dNSName or iPAdress it must match the hostname or
 adress of the KDC.
 
 @subsection Client certificate
 
 The client certificate may need to have a EKU id-pkekuoid
-(1.3.6.1.5.2.3.4) depending on set on the certifiate on the KDC.
+(1.3.6.1.5.2.3.4) set depending on the certifiate on the KDC.
 
 It possible to store the principal (if allowed by the KDC) in the
 certificate and thus delegate responsibility to do the mapping between
@@ -1123,7 +1123,7 @@ certificates and principals to the CA.
 
 @subsubsection Using KRB5PrincipalName in id-pkinit-san
 
-OtherName extenetion in the GeneralName is used is used to do the
+OtherName extention in the GeneralName is used to do the
 mapping between certifiate and principal in the certifiate or storing
 the krbtgt principal in the KDC certificate.
 
@@ -1135,7 +1135,7 @@ id-pkinit-san OBJECT IDENTIFIER ::= @{ iso (1) org (3) dod (6)
 internet (1) security (5) kerberosv5 (2) 2 @}
 @end example
 
-In the data part of the OtherName is filled with the following DER
+The data part of the OtherName is filled with the following DER
 encoded ASN.1 structure:
 
 @example
@@ -1145,16 +1145,16 @@ KRB5PrincipalName ::= SEQUENCE @{
 @}
 @end example
 
-where Realm and PrincipalName is defined by Kerberos ASN.1 specification.
+where Realm and PrincipalName is defined by the Kerberos ASN.1 specification.
 
 @section Naming certificate using hx509
 
 hx509 is the X.509 software used in Heimdal to handle
-certificates. hx509 use diffrent syntaxs to specify the diffrent
+certificates. hx509 uses different syntaxes to specify the different
-format the certificate is stored and in what format they exist in.
+formats the certificates are stored in and what formats they exist in.
 
-There are several format that can be used, PEM, embeded into PKCS12
+There are several formats that can be used, PEM, embedded into PKCS12
-files, embeded into PKCS11 devices and raw DER encoded certificates.
+files, embedded into PKCS11 devices and raw DER encoded certificates.
 Below is a list of types to use.
 
 
@@ -1163,12 +1163,12 @@ Below is a list of types to use.
 @item DIR:
 
 DIR is reading all certificates in a directory that is DER or PEM
-formated.
+formatted.
 
 The main feature of DIR is that the directory is read on demand when
-iterating over certificates, that way appliction can for some cases
+iterating over certificates, that way applictions can for some cases
-avoid storeing all certificates in memory. Its very useful for tests
+avoid to store all certificates in memory. It's very useful for tests
-that iterates over larger amount of certificates.
+that iterate over larger amount of certificates.
 
 Syntax is:
 
@@ -1179,10 +1179,10 @@ DIR:/path/to/der/files
 @item FILE:
 
 FILE: is used to have the lib pick up a certificate chain and a
-private key. The fil can be either a PEM (openssl) file or a raw DER
+private key. The file can be either a PEM (openssl) file or a raw DER
-encoded certificate. If its a PEM file it can contain several keys and
+encoded certificate. If it's a PEM file it can contain several keys and
 certificates and the code will try to match the private key and
-certificate togehter.
+certificate together.
 
 Its useful to have one PEM file that contains all the trust anchors.
 
@@ -1194,8 +1194,8 @@ FILE:certificate.pem,private-key.key,other-cert.pem,....
 
 @item PKCS11:
 
-PKCS11: is used handle smartcards via PKCS11 drivers, for example
+PKCS11: is used to handle smartcards via PKCS11 drivers, for example
-soft-token opensc, or muscle. Default is to use all slots on the
+soft-token, opensc, or muscle. The default is to use all slots on the
 device/token.
 
 Syntax is:
@@ -1206,7 +1206,7 @@ PKCS11:shared-object.so
 
 @item PKCS12:
 
-PKCS12: is used handle PKCS12 files. PKCS12 files commonly have the
+PKCS12: is used to handle PKCS12 files. PKCS12 files commonly have the
 extension pfx or p12.
 
 Syntax is:
@@ -1221,7 +1221,7 @@ PKCS12:/path/to/file.pfx
 
 First configure the client's trust anchors and what parameters to
 verify, see subsection below how to do that. Now you can use kinit to
-get yourself tickets. One example how that can look it like this:
+get yourself tickets. One example how that can look like is:
 
 @example
 $ kinit -C FILE:$HOME/.certs/lha.crt,$HOME/.certs/lha.key lha@@EXAMPLE.ORG
@@ -1280,7 +1280,7 @@ Write about the kdc.
 
 @subsection Using pki-mapping file
 
-Note that the file this is space sensitive.
+Note that the file name is space sensitive.
 
 @example
 # cat /var/heimdal/pki-mapping
@@ -1289,7 +1289,7 @@ lha@@EXAMPLE.ORG:C=SE,O=Stockholm universitet,CN=Love,UID=lha
 lha@@EXAMPLE.ORG:CN=Love,UID=lha
 @end example
 
-@subsection Using Kerberos database
+@subsection Using the Kerberos database
 
 @section Use hxtool to create certificates
 
@@ -1298,7 +1298,7 @@ lha@@EXAMPLE.ORG:CN=Love,UID=lha
 First you need to generate a CA certificate, change the --subject to
 something appropriate, the CA certificate will be valid for 10 years.
 
-You need to change --subject  in the command below.
+You need to change --subject in the command below.
 
 @example
 hxtool issue-certificate \
@@ -1326,8 +1326,8 @@ hxtool issue-certificate \
     --certificate="FILE:kdc.pem"
 @end example
 
-The users also needs to have a certificates, so generate a certificate
+The users also needs to have a certificate, so generate a certificate
-of the type ``pkinit-client''. Client doesn't need to have the PK-INIT
+of the type ``pkinit-client''. The client doesn't need to have the PK-INIT
 SubjectAltName set, you can have the Subject DN in the ACL file
 (pki-mapping) instead.
 
@@ -1343,10 +1343,10 @@ hxtool issue-certificate \
     --certificate="FILE:user.pem"
 @end example
 
-@subsection Validate certificate
+@subsection Validate the certificate
 
 hxtool also contains a tool that will validate certificates according to
-rules from PKIX document. The checks are not complete, but a good test
+rules from the PKIX document. These checks are not complete, but a good test
 to check if you got all of the basic bits right in your certificates.
 
 @example
@@ -1358,10 +1358,10 @@ hxtool validate FILE:user.pem
 This section tries to give the CA owners hints how to create
 certificates using OpenSSL (or CA software based on OpenSSL).
 
-@subsection Using OpenSSL to create certificate with krb5PrincipalName
+@subsection Using OpenSSL to create certificates with krb5PrincipalName
 
-To make OpenSSL create certificate with krb5PrincipalName use
+To make OpenSSL create certificates with krb5PrincipalName use
-@file{openssl.cnf} as described below. To see an complete example of
+@file{openssl.cnf} as described below. To see a complete example of
 creating client and KDC certificates, see the test-data generation
 script @file{lib/hx509/data/gen-req.sh} in the source-tree. The
 certicates it creates are used to test the PK-INIT functionality in
@@ -1431,7 +1431,7 @@ have to apply a fix from Microsoft.
 
 @subsection Certificates
 
-The client certificates needs to have the extended keyusage ``Microsoft
+The client certificates need to have the extended keyusage ``Microsoft
 Smartcardlogin'' (openssl have the oid shortname msSmartcardLogin).
 
 See Microsoft Knowledge Base Article - 281245 ``Guidelines for Enabling