[Openvas-commits] r1556 - trunk/doc/website

[scm-commit@wald.intevation.org]

Author: mwiegand
Date: 2008-10-16 11:37:28 +0200 (Thu, 16 Oct 2008)
New Revision: 1556

Modified:
   trunk/doc/website/openvas-cr-17.htm4
Log:
Updated CR #17 with more detailed protocol specification.


Modified: trunk/doc/website/openvas-cr-17.htm4
===================================================================
--- trunk/doc/website/openvas-cr-17.htm4	2008-10-16 09:03:54 UTC (rev 1555)
+++ trunk/doc/website/openvas-cr-17.htm4	2008-10-16 09:37:28 UTC (rev 1556)
@@ -76,15 +76,31 @@
 <h3>Design and Implementation</h3>
 
 <p>
-  The signature information could be included in the PLUGIN_INFO and PLUGIN_LIST
-  message types as a last element; this would probably be the easiest solution.
-  Alternatively, a new message type (like PLUGIN_SIGNATURE) could be introduced.
+  The signature information will be included in the PLUGIN_INFO and PLUGIN_LIST
+  message types as a last element; this is the easiest solution.
+  The current per-NVT response is:<br>
+  <pre>oid &lt;|&gt; name &lt;|&gt; category &lt;|&gt; copyright &lt;|&gt; description &lt;|&gt; summary &lt;|&gt; family &lt;|&gt; plugin_version &lt;|&gt; cve_id &lt;|&gt; bugtraq_id &lt;|&gt; xrefs</pre><br>
+  After the change it would become:<pre>oid &lt;|&gt; name &lt;|&gt; category &lt;|&gt; copyright &lt;|&gt; description &lt;|&gt; summary &lt;|&gt; family &lt;|&gt; plugin_version &lt;|&gt; cve_id &lt;|&gt; bugtraq_id &lt;|&gt; xrefs &lt;|&gt; nvt_sigs</pre><br>
+  "nvt_sigs" will be a list of the IDs of the keys used to sign this NVTs
+  separated by commas (e.g. 0x12345678,0xABCDABCD,0x9ABCDEF0).
 </p>
 
 <p>
-  Before transmitting information regarding the individual NVT signatures, the
-  server should transmit all the certificates (public keys) it knows with a value
-  indicating whether it trusts this certificated or not.
+  The server shall implement a command that allows the client to retrieve all
+  the certificates (public keys) that are known to the server with a value
+  indicating whether the server trusts this certificated or not. This could
+  happen in the following way:<br>
+  Client:<br>
+  <pre>CLIENT &lt;|&gt; CERTIFICATES &lt;|&gt; CLIENT</pre><br>
+  Server:<br>
+  <pre>SERVER &lt;|&gt; CERTIFICATES<br>
+[certificate_data] &lt;|&gt; [1 = trusted/0 = not trusted]<br>
+[certificate_data] &lt;|&gt; [1 = trusted/0 = not trusted]<br>
+[certificate_data] &lt;|&gt; [1 = trusted/0 = not trusted]<br>
+&lt;|&gt; SERVER</pre><br>
+  The format of the [certificate_data] field has yet to be decided. It will be
+  the responsibility of the client to use this field to get the date it needs
+  about the certificate (Key ID, name of issuer etc.)
 </p>
 
 <p>
@@ -96,6 +112,8 @@
 <h3>History</h3>
 
 <ul>
+<li> 2008-10-16 Michael Wiegand &lt;michael.wiegand at intevation.de&gt;:<br>
+     Updated protocol specification.</li>
 <li> 2008-10-13 Michael Wiegand &lt;michael.wiegand at intevation.de&gt;:<br>
      Initial text.</li>
 </ul>