--- a/spec/tls-respec.html	Fri Sep 06 18:47:34 2013 +0200
+++ b/spec/tls-respec.html	Mon Sep 09 20:43:04 2013 +0200
@@ -653,23 +653,23 @@
 <section class='normative'>
 <h2>Cryptographic Vocabulary</h2>
 
-<p>The following properties SHOULD be used when conveying the relation between the 
+<p>The following properties MUST be used when conveying the relation between the 
    <tref>Subject</tref> and his or her key, within <tref>WebID Profile</tref> documents:</p>
 <dl>
-  <dt><a href="http://www.w3.org/ns/auth/cert#RSAPublicKey">cert:RSAPublicKey</a></dt>
-  <dd>Refers to the class of RSA public key. The RSAPublicKey MUST specify the
-  cert:modulus and cert:exponent properties.</dd>
   <dt><a href="http://www.w3.org/ns/auth/cert#key">cert:key</a></dt>
   <dd>Used to associate a <tref>WebID</tref> URI with an RSAPublicKey. A <tref>WebID Profile</tref>
   MUST contain at least one RSAPublicKey that is associated with the
   corresponding <tref>WebID</tref> URI.</dd>
+  <dt><a href="http://www.w3.org/ns/auth/cert#RSAPublicKey">cert:RSAPublicKey</a></dt>
+  <dd>Refers to the class of RSA public key. The RSAPublicKey MUST specify the
+  cert:modulus and cert:exponent properties.</dd>
   <dt><a href="http://www.w3.org/ns/auth/cert#modulus">cert:modulus</a></dt>
   <dd>Used to relate an RSAPublic key to its modulus expressed as a hexBinary.
-    An RSA Key must have one and only one modulus. The datatype of a modulus is xsd:hexBinary.
+    An RSA key MUST have one and only one modulus. The datatype of a modulus is xsd:hexBinary.
   </dd>
   <dt><a href="http://www.w3.org/ns/auth/cert#exponent">cert:exponent</a></dt>
   <dd>Used to relate an RSAPublic key to its exponent expressed as an integer.
-     An RSA Key must have one and only  one exponent. The datatype of a modulus is xsd:integer.
+     An RSA key MUST have one and only one exponent. The datatype of a modulus is xsd:integer.
   </dd>
 </dl>
 
@@ -709,7 +709,7 @@
 <p>A <tref>WebID Certificate</tref> identifies the <tref>Subject</tref> alone and no one else, if and only if that <tref>Subject</tref> is the only one to control the corresponding private key. 
 It is very important therefore that the <tref>Subject</tref> take care of keeping the <tref>private key</tref> secure.
 This can be done by keeping it in the <tref>Key Store</tref> of a personal machine in an account that is password protected and free of viruses, or best of all on some physical device where the private key is inaccessible to be read by any software. 
-In the second case having the device implies that the <tref>private key</tref> has not been lost or copied. 
+In the second case, having the device implies that the <tref>private key</tref> has not been lost or copied. 
 In the first case the user has to be more careful for signals of misuse.<p>
 <p>In either situation if the <tref>Subject</tref> is suspicious that his private key has been taken, future authentications for that certificate can be disabled by removing the corresponding <tref>public key</tref> from the <tref>WebID Profile</tref>.
  If the profile contains more than one public key for the <tref>Subject</tref> then it is suggested that each public key contain a label to help the user locate the key. In the examples above an <code>rdfs:label</code> with a creation date was used for this purpose. 
@@ -829,8 +829,8 @@
 
 <section class='informative'>
 <h2>Access Control Check</h2>
-<p>The <tref>Guard</tref> can intercept the request and consult its access control rules for that resource, in order to determine if  some the request type is access controled. 
-If the request is authorized to anyone then server can pass the request straight on to the resource.
+<p>The <tref>Guard</tref> can intercept the request and consult its access control rules for that resource, in order to determine if  some the request type is access controlled. 
+If the request is authorized to anyone, then server can pass the request straight on to the resource.
 If the request requires some authentication the Guard MAY request the client certificate as detailed
 in the next section. </p>
 <p>Because a <tref>WebID</tref> is a global linkable URI, one can  build webs of trust that can be crawled the same way the web can be crawled: by following links from one document to another. 
@@ -871,8 +871,8 @@
 If the document returned states that the referent of the <tref>WebID</tref> is the agent that controls the private key of the given public key, then this is a  definite description that can be considered to be a definition of the <tref>WebID</tref>: it gives its meaning.
 </p>
 <p>The trust that can be had in that statement is therefore the trust that one can have in one's having received the correct representation of the document that defined that <tref>WebID</tref>. 
-An HTTPS <tref>WebID</tref> will therefore be a lot more trustworthy than an HTTP <tref>WebID</tref> by a factor of the likelihood of man in the middle attacks.</p>
-<p>Once that is proven then the trust one can have in the agent at the end of the TLS connection being the referent of the <tref>WebID</tref> is related to the trust one has in the cryptography, and the likelihood that the private key could have been stolen.</p>
+An HTTPS <tref>WebID</tref> will therefore be a lot more trustworthy than an HTTP <tref>WebID</tref>, as it reduces the likelihood of man-in-the-middle attacks.</p>
+<p>If the authenticity of the server hosting the WebID profile document is proven through the use of HTTPS, then the trust one can have in the agent at the end of the TLS connection being the referent of the <tref>WebID</tref> is related to the trust one has in the cryptography, and the likelihood that the private key could have been stolen.</p>
 <p class="issue">Add explanation for URI with redirect.</p>
 <section class='normative'>
 <h2>Processing the WebID Profile</h2>
@@ -890,7 +890,7 @@
 <h2>Verifying the WebID Claim</h2>
 
 <p>
-To check a <tref>WebID Claim</tref> one has to find if the graph returned by the profile  relates the <tref>WebID</tref> to the <tref>Certificate</tref> <tref>Public Key</tref> with the <code>cert:key</code> relation. In other words one has to check if those statements are present in the graph.</p>
+To check a <tref>WebID Claim</tref> one has to find if the graph returned by the profile  relates the <tref>WebID</tref> to the <tref>Certificate</tref> <tref>Public Key</tref> with the <code>cert:key</code> relation. In other words, one has to check if those statements are present in the graph.</p>
 
 <section class="normative">
 <h2>Verifying the WebID Claim with SPARQL</h2>
@@ -934,7 +934,7 @@
 }
 </pre>
 <p>An ASK query simply returns true or false. If it returns true, then the key was found in the graph with the proper relation and the claim is verified.</p>
-<p>In order to allow the class of queries defined by the template above to return true when asked of graphs where the hexBinary or the exponent contains whitespace characters in initial and final position, the query engine MUST support the D-entailment regime for <code>xsd:hexBinary</code> and <code>xsd:integer</code> as specified in <a href="http://www.w3.org/TR/sparql11-entailment/#DEntRegime">SPARQL 1.1 Entailment Regimes</a>.</p>
+<p>When processing the queries in the above template, unexpected results may appear if the representation of a modulus or exponent contains whitespace characters in the initial and/or final position. For this reason, the query engine MUST support the D-entailment regime for <code>xsd:hexBinary</code> and <code>xsd:integer</code> as specified in <a href="http://www.w3.org/TR/sparql11-entailment/#DEntRegime">SPARQL 1.1 Entailment Regimes</a>.</p>
 <p>For verifiers that do not have access to a SPARQL query engine but can query the RDF data programmatically, it is relatively easy to emulate the above SPARQL query programmatically. There are a number of ways of doing this, some more efficient than others.<p>
 </section>
 <section class="normative">
@@ -948,7 +948,7 @@
 <h2>Authorization</h2>
 
 <p>Once the <tref>Guard</tref> has a <tref>WebID</tref> it can lookup the access control rules for the given resource to see if the agent is allowed the required type of access. 
-Up to this point we are not much more advanced that with a user name and password, except that the user did not have to create an account on Alice's server to identify himself and that the server has some claimed attributes to personalize the site for the requestor.
+Up to this point, we are not much more advanced than with a user name and password, except that the user did not have to create an account on Alice's server to identify himself and that the server has some claimed attributes to personalize the site for the requestor.
 </p>