Projekt

Obecné

Profil

Iteration 4 » Historie » Revize 13

Revize 12 (Jan Pašek, 2021-04-08 08:01) → Revize 13/14 (Jan Pašek, 2021-04-08 08:01)

h1. Iteration 4 

 *Target:* CRL/OCSP, certificate detailed view 

 h2. Tasks 

 h3. Implement certificate revocation, add CRL distribution point and OCSP endpoint to certificate extensions 

 * One Rest API endpoint: POST /api/certificates/{id}/revoke body =    { reason: "<reason for revocation>"}  
 with reason: [unspecified, keyCompromise, cACompromise, affiliationChanged, superseded, cessationOfOperation, certificateHold, removeFromCRL, privilegeWithdrawn, aACompromise]. 
 The reason will be optional and if not present, unspecified is used.  
 * Controller will call a method revoke_certificate(id) of CertificateService. 
 * Certificate service will call a CertificateRepository set_certificate_revoked(id, timestamp, reason) to set the certificate revoked. 
 * Database must be extended with the following data: revocation date (Unix timestamp, generated automatically by the CertificateService), bool flag if is revoked, the reason for revocation(may be implemented as a second table with revocation reason values). 
 * CertificateRepository shall expose the following method get_all_revoked_by(id) that returns all certificates that were issued by the given CA and are now revoked. 

 * Extensions of each certificate shall contain CRL and OCSP distribution points. Base URL of the server must be determined from the configuration 

 h3. Implement certificate deletion endpoint 

 * One Rest API endpoint: DELETE /api/certificates/{id} that deletes the certificate 
 * Controller calls CertificateService delete_certificate(id) that must be extended to delete the whole subtree of certificates 
 * To extend delete_certificate(id) a CertificateRepository must implement get_all_issued_by(id) that returns all certificates that were issued by the given CA 

 h3. Implement endpoint for retrieving public/private key for each certificate 

 * Two endpoints GET /api/certificates/{id}/publickey and GET /api/certificates/{id}/privatekey 
 * The first endpoint just queries the certificate using CertificateService, gets a private key ID, queries private key from the KeyService and returns its data. 
 * The second endpoint will do the same, except at the end it calls a new method of KeyService get_public_key(private_key) that utilizes OpenSSL via CryptographyService to get a public key out of the private key provided 

 h3. Implement endpoint for retrieving all certificates issued by a given CA 

 * Extend existing endpoint GET /api/certificates with another filtering option {issuedby: <id>} 
 * Controller can use new function of CertificateService get_certificates_issued_by(id) that calls CertificateRepository -> get_all_issued_by(id) (described previously) 

 h3. Implement creation OpenSSL index file 

 * Probably new service for CRL/OCSP 
 * One method create_revoked_index(ca_id) that queries revoked certificates of the given CA using get_all_revoked_by(id) of the CertificateRepository and creates index file based on the following link  
 https://pki-tutorial.readthedocs.io/en/latest/cadb.html 

 h3. Implement CRL service and corresponding endpoint 

 * application endpoint that will use CRL/OCSP service to get CRL file that will be returned by the endpoint 
 * endpoint will be GET /api/crl/{ca_id} 
 * CRL/OCSP service must first generate the index file with revoked certificates and then call (maybe via cryptography service) OpenSSL to generate the CRL. Then the CRL file will be read in and returned  

 h3. Implement OCSP service and corresponding endpoint 

 * application endpoint that reads the OSCP request from the request (in case of get -> URL parameter, in case of POST request body - see RFC for details) 
 * endpoint will be GET/POST /api/ocsp/{ca_id} 
 * OCSP request will    be passed to CRL/OCSP service 
 * CRL/OCSP service will generate the index file and calls (maybe via cryptography service) OpenSSL to generate OCSP response. The response is then returned to the controller. 
 * Both response and request are DER encoded data, so they are not readable... 
 * For signing OCSP additional certificate issued by the CA corresponding to the OCSP endpoint must be used. (this can be checked in RFC)  


 h3. Logging 

 * Implement logging as specified in requirement specification NR 6 and start using it 
 * Shall not take too much time 
 * Simple rolling file 
 https://docs.python.org/3/library/logging.html 

 h3. Application initialization and DI 

 * Check if OpenSSL exists on the system 
 * DI: https://python-dependency-injector.ets-labs.org/index.html 

 h3. Database initialization 

 * Create a database file 
 * Create database tables 
 * Insert init data 


 h3. Certificate detailed view 

 * Display complete DN + notBefore + notAfter - via GET /api/certificates/{id}/details 
 * Reference to the detailed view page of the issuing CA - from the same data from the previous Rest call 
 * Display link to OCSP/CRL endpoint - only CA id in necessary to generate link - known from the previous Rest call 
 * Download public/private key - endpoints defined previously 
 * Download certificate, a chain of trust, root - endpoints already available 
 * List of issued certificates using GET - /api/certificates with filtering option {issuedby: <id>} 

 * Listing on the main page must be extended with a link to the detailed view 

 h2. Remaining implementation after this one 

 * Validity check endpoint 
 * GUI certificate list filtering and pagination 
 * Creating certificates based on provided private key possibly protected by DES3 
 * Creating certificates based on an automatically generated key with a user-specified passphrase 
 * Automatic GUI tests 
 * GUI design improvement (background unification etc...) 
 * Templating 
 * Tree view certifikátů?