Difference between revisions of "Project Information:template OpenSign Server Project - Final Review - Second Reviewer - F"

From OWASP
Jump to: navigation, search
Line 19: Line 19:
 
   | colspan="2" style="width:75%; background:#cccccc" align="left"|
 
   | colspan="2" style="width:75%; background:#cccccc" align="left"|
  
At this point the core functionality of the OpenSign project has been developed and tested. This includes the issuing and verifying of certificates within a client server infrastructure. Users must be authenticated and approved by an issuer to use the issuing-service. The issuing is done easily by making use of the client application or online via a web-form. However, OpenSign is not an independent solution for code signing yet. It relies on java-keytool (or an application with the same intention) to generate the client side keys and the certificate sign requests. There is no graphical interface for the client in place. Also the support of .NET code signing was not taken into account yet.
+
* Client tool to generate RSA key pair and request signing certificate by return via a secure connection, secure connection will authenticate user after a dedicated registration process and also use mutual authentication SSL to avoid man-in-the-middle - returning certificate to user in real time. Registered developer can then submit their SPC online to verify the SPC.
 +
 
 +
-> ok
 +
 
 +
* Client tool to download software that will do a proper verification on the software against the code signing service
 +
 
 +
-> code download and verification is not available in the OSSJClient. Verification of the certificate is therefore performed
 +
independently of the signed code (one step is missing in the process).
 +
 
 +
* Website interface for the code signing service
 +
 
 +
-> ok
 +
 
 +
* Set of Admin tools to manage the code signing service, user and certificate repository
 +
 
 +
-> available, but completeness of features should be validated
 +
 
 +
* Documentation
 +
 
 +
-> User documentation has been completed.
 +
 
 +
-> The demonstration could be more explicit related to the integration of the tools in the software deployment process.
 +
The role of entities (certificate, CSR) could be explained more precisely, so as to enable developpers with limited
 +
security knowledge to use the tool. For instance: integrate the documentation (opendsign-concept.doc ...) in the
 +
demo slides.
 +
 
 +
Documentation in the code repository contains the original design doc rather than the current dev/use documentation.
  
 
OK
 
OK
Line 27: Line 53:
 
   | colspan="2" style="width:75%; background:#cccccc" align="left"|
 
   | colspan="2" style="width:75%; background:#cccccc" align="left"|
  
OpenSign Server: 80%
+
'''NOTE''': the deliverables are tagged in the project definition as 'idealized result', and were since the beginning identified
 +
as an ambitious goal. The project delivers running tools and documentation, which do not fullfil these expectations,
 +
but provide developpers with usefull and simple to use tools. The percentage are relative to the original definition.
  
OK
+
* Client tool to generate RSA key pair and request signing certificate by return via a secure connection, secure connection will authenticate user after a dedicated registration process and also use mutual authentication SSL to avoid man-in-the-middle - returning certificate to user in real time. Registered developer can then submit their SPC online to verify the SPC.
  
Client Tools – OSSJClient: 90%
+
100 %
  
OK
+
* Client tool to download software that will do a proper verification on the software against the code signing service
  
Documentation: 30%  
+
50%
  
OK
+
* Website interface for the code signing service
|-  
+
90 %
 +
 
 +
* Set of Admin tools to manage the code signing service, user and certificate repository
 +
 
 +
70 %
 +
 
 +
|-  
 
  | style="width:25%; background:#7B8ABD" align="center"|
 
  | style="width:25%; background:#7B8ABD" align="center"|
 
3. Please do use the right hand side column to provide advice and make work suggestions.
 
3. Please do use the right hand side column to provide advice and make work suggestions.
Line 53: Line 87:
 
* The 'opensign-design' documentation could be completed.
 
* The 'opensign-design' documentation could be completed.
  
 +
'''First comments''':
 +
 +
* it would be nice it it would be possible to simply download and run the code
 +
for the server and the client (I have made some tests under linux, this seems not to be the case for the latter releases available on the project web page)
 +
* available scripts for starting both under MS win & linux, with default config
 +
* available user documentation: what can I do with each tool, how (for instance under the form of a '5 minutes introduction' and reference list of available functions) ?
 +
* is the C# code available for download and execution ?
 +
* it would be nice if the 'trunk' would be documented in a way that let the user know:
 +
- how to compile everything (without needing to install libraries from the web) ?
 +
 +
- how to run the server and clients (a global 'readme' file is missing).
 +
 +
* Moreover, the 'opensign-design' document could be completed. User documentation mqkes this less urgent.
 +
 +
'''Final Review'''
 +
 +
Extending the OSSJClient with code download and verification feature would provide a important added value for
 +
a reasonnable work overhead. It could therefore be done in priority.
 +
 +
Please see other omments for further remarks.
  
 
  |-  
 
  |-  

Revision as of 22:44, 5 March 2009

Clik here to return to the previous page.

FINAL REVIEW
PART I

Project Deliveries & Objectives

OWASP OpenSign Server Project's Deliveries & Objectives

QUESTIONS ANSWERS

1. At what extent have the project deliveries & objectives been accomplished? Having in consideration the assumed ones, please exemplify writing down those of them that haven't been realised.

  • Client tool to generate RSA key pair and request signing certificate by return via a secure connection, secure connection will authenticate user after a dedicated registration process and also use mutual authentication SSL to avoid man-in-the-middle - returning certificate to user in real time. Registered developer can then submit their SPC online to verify the SPC.

-> ok

  • Client tool to download software that will do a proper verification on the software against the code signing service

-> code download and verification is not available in the OSSJClient. Verification of the certificate is therefore performed independently of the signed code (one step is missing in the process).

  • Website interface for the code signing service

-> ok

  • Set of Admin tools to manage the code signing service, user and certificate repository

-> available, but completeness of features should be validated

  • Documentation

-> User documentation has been completed.

-> The demonstration could be more explicit related to the integration of the tools in the software deployment process. The role of entities (certificate, CSR) could be explained more precisely, so as to enable developpers with limited security knowledge to use the tool. For instance: integrate the documentation (opendsign-concept.doc ...) in the demo slides.

Documentation in the code repository contains the original design doc rather than the current dev/use documentation.

OK

2. At what extent have the project deliveries & objectives been accomplished? Having in consideration the assumed ones, please quantify in terms of percentage.

NOTE: the deliverables are tagged in the project definition as 'idealized result', and were since the beginning identified as an ambitious goal. The project delivers running tools and documentation, which do not fullfil these expectations, but provide developpers with usefull and simple to use tools. The percentage are relative to the original definition.

  • Client tool to generate RSA key pair and request signing certificate by return via a secure connection, secure connection will authenticate user after a dedicated registration process and also use mutual authentication SSL to avoid man-in-the-middle - returning certificate to user in real time. Registered developer can then submit their SPC online to verify the SPC.

100 %

  • Client tool to download software that will do a proper verification on the software against the code signing service

50%

  • Website interface for the code signing service

90 %

  • Set of Admin tools to manage the code signing service, user and certificate repository

70 %

3. Please do use the right hand side column to provide advice and make work suggestions.

Second comments:

  • I was able to get this running fine on MS OS with Java/Maven and compile in the Eclipse IDE
  • it would be nice it it would be possible to simply download and run the code

for the server and the client - AGREE

  • available user documentation: what can I do with each tool, how (for instance under the form of a '5 minutes introduction' and reference list of available functions) ? - AGREE
  • I would like to see the C# version as well
  • it would be nice if the 'trunk' would be documented in a way that let the user know:
  • how to run the server and clients (a global 'readme' file is missing).
  • The 'opensign-design' documentation could be completed.

First comments:

  • it would be nice it it would be possible to simply download and run the code

for the server and the client (I have made some tests under linux, this seems not to be the case for the latter releases available on the project web page)

  • available scripts for starting both under MS win & linux, with default config
  • available user documentation: what can I do with each tool, how (for instance under the form of a '5 minutes introduction' and reference list of available functions) ?
  • is the C# code available for download and execution ?
  • it would be nice if the 'trunk' would be documented in a way that let the user know:

- how to compile everything (without needing to install libraries from the web) ?

- how to run the server and clients (a global 'readme' file is missing).

  • Moreover, the 'opensign-design' document could be completed. User documentation mqkes this less urgent.

Final Review

Extending the OSSJClient with code download and verification feature would provide a important added value for a reasonnable work overhead. It could therefore be done in priority.

Please see other omments for further remarks.

PART II

Assessment Criteria

OWASP Project Assessment Criteria

QUESTIONS ANSWERS

1. Having into consideration the OWASP Project Assessment Methodology which criteria, if any, haven’t been fulfilled in terms of Alpha Quality status?

2. Having into consideration the OWASP Project Assessment Methodology which criteria, if any, haven’t been fulfilled in terms of Beta Quality status?

  • Include user documentation in Project's OWASP Wiki page(s)

OK

3. Having into consideration the OWASP Project Assessment Methodology which criteria, if any, haven’t been fulfilled in terms of Release Quality status?

  • Include online documention built into tool (based on required user documentation)
  • Be run through Fortify Software's open source review (if appropriate) and FindBugs

OK

4. Please do use the right hand side column to provide advice and make work suggestions.