--- a/spec/index-respec.html Mon Jul 29 23:35:54 2013 +0200
+++ b/spec/index-respec.html Thu Aug 08 17:08:23 2013 +0200
@@ -1,7 +1,7 @@
<html>
<head>
<title>Redirect to new WebID Authentication Over TLS spec</title>
- <meta http-equiv="refresh" content="0; url=tls-respec.html">
+ <meta http-equiv="refresh" content="0; url=index.html">
</head>
<body>
<p>The WebID spec was refactored into two specs:</p>
--- a/spec/tls-respec.html Mon Jul 29 23:35:54 2013 +0200
+++ b/spec/tls-respec.html Thu Aug 08 17:08:23 2013 +0200
@@ -521,8 +521,9 @@
<h1>The certificate</h1>
<p>The <tref>Key Store</tref> must have a <tref>Certificate</tref> with a <code>Subject Alternative Name</code> URI entry.
-This URI must be one that dereferences to a document the user controls so that he can publish the
-public key for that <tref>Certificate</tref> at this URI.</p>
+This URI must be one that dereferences to a <tref>WebID Profile</tref> whose graph contains a <code>cert:key</code> relation from the <tref>WebID</tre> to the public key published in the <tref>Certificate</tref> . (see below <a href="#the-webid-profile-document">The WebID Profile Document</a>) </p>
+<section class='informative'>
+<h2>Certificate example</h2>
<p>For example, if a user Bob controls <code>https://bob.example/profile</code>,
then his <tref>WebID</tref> can be <code>https://bob.example/profile#me</code></p>
<p>When creating a certificate it is very important to choose a user friendly Common Name (CN) for the user, that will allow him to distinguish between different certificates he may have, such as a personal or a business certificate, when selecting one from his browser.
@@ -540,11 +541,11 @@
Serial Number:
5f:df:d6:be:2c:73:c1:fb:aa:2a:2d:23:a6:91:3b:5c
Signature Algorithm: sha1WithRSAEncryption
- <span style="color: red">Issuer:</span> O=FOAF+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority
+ <span style="color: red">Issuer:</span> O={}, CN=WebID
Validity
Not Before: Jun 8 14:16:14 2010 GMT
Not After : Jun 8 16:16:14 2010 GMT
- <span style="color: red">Subject:</span> O=FOAF+SSL, OU=The Community Of Self Signers, CN=Bob (Personal)
+ <span style="color: red">Subject:</span> O=bob.example, OU=cert creation, CN=Bob (personal)
Subject Public Key Info:
<span style="color: red"> Public Key Algorithm:</span> rsaEncryption
<span style="color: red">Public-Key:</span> (2048 bit)
@@ -589,17 +590,15 @@
45:0c:b9:48:c0:fd:ac:bc:fb:1b:c9:e0:1c:01:18:5e:44:bb:
d8:b8
</pre>
-<p class="issue">Should we formally require the Issuer to be
-O=FOAF+SSL, OU=The Community of Self Signers, CN=Not a Certification Authority.
-This was discussed on the list as allowing servers to distinguish certificates
-that are FOAF+SSL enabled from others. Will probably need some very deep TLS
-thinking to get this right.</p>
-<p class="issue">The above certificate is no longer valid, as I took an valid
-certificate and change the time and <tref>WebID</tref>. As a result the signature is now
-false. A completely valid certificate should be generated to avoid nit-pickers
-picking nits.</p>
-<section class='normative'>
-<h1>Creating a Certificate</h1>
+<p class="issue">Should we formally require the last issuer of a chain of certificates
+to be <code>O={}, CN=WebID</code>
+This would allow the server to request only WebID enabled certificates, or even WebID enabled
+certificates in addition to CA signed certificates it trusts using the certificate_authorities
+field in the TLS request. </p>
+<p class="issue">The above certificate is no longer valid.</p>
+</section>
+<section class="informative">
+<h2>Certificate creation</h2>
<p>Many tools exist to create Certificates.
Some <tref>Key Store</tref>s allow a user to create the Certificate directly with a friendly User Interface.
But using a <tref>Key Store</tref> on the client still requires the public key to be published on the server as detailed in the next section.
@@ -607,9 +606,8 @@
This element can be placed in an HTML5 form, where on submitting the form, the browser asks the <tref>Key Store</tref> to create a public and private key pair, and on receiving the public part of that key pair, the Client can send a key request as part of the form to the <tref>Service</tref>. The <tref>Service</tref> can then create a <tref>WebID Certificate</tref> and return it to the <tref>Client</tref> to pass onto the <tref>Key Store</tref>. In that way the Server is in the position to best make the decisions of what the <tref>Certificate</tref> should say and what the <tref>WebID</tref> should be without the private key ever leaving the secure <tref>Key Store</tref>. The user experience for this Certificate creation is a one click operation.
</section>
</section>
-
<section class='normative'>
-<h1>Publishing the Certificate data in a WebID Profile Document</h1>
+<h1>The WebID Profile Document</h1>
<!-- Update the image to contain only certificate data -->
<p>The <tref>WebID Profile</tref> document MUST be a [[!WEBID]] document. It MUST also expose the relation between the <tref>WebID</tref> URI and the <tref>Subject</tref>'s <tref>public key</tref>s using the <a href="http://www.w3.org/ns/auth/cert#">cert ontology</a> as well as the standard <code>xsd</code> datatypes.
@@ -823,6 +821,11 @@
<p>TLS allows the server to request a Certificate from the Client using the <code>CertificateRequest</code> message [Section 7.4.4] of TLS v1.1 [[!TLS]]. Since WebID TLS authentication does not rely on CAs signing the certificate to verify the <tref>WebID Claim</tref>s made therein, the Server does not need to restrict the certificate it receives by the CAs they were signed by. It can therefore leave the <code>certificate_authorities</code> field blank in the request. </p>
<p class="note">From our experience leaving the certificate_authorities field empty leads to the correct behavior on all browsers and all TLS versions.</p>
+<p class="issue">Should we formally require the last issuer of a chain of certificates
+to be <code>O={}, CN=WebID</code>
+This would allow the server to request only WebID enabled certificates, or even WebID enabled
+certificates in addition to CA signed certificates it trusts using the certificate_authorities
+field in the TLS request.</p>
<p class="note">A security issue with TLS renegotiation was discovered in 2009, and an IETF fix was proposed in [[!RFC5746]] which is widely implemented.</p>
<p>If the Client does not send a certificate, because either it does not have one or it does not wish to send one, other authentication procedures can be pursued at the application layer with protocols such as OpenID, OAuth, BrowserID, etc... </p>
<p>As much as possible it is important for the server to request the client certificate in <code>WANT</code> mode, not in <code>NEED</code> mode.