Changes between Version 38 and Version 39 of CertMgr

Timestamp:

Jun 19, 2007, 3:48:36 PM (17 years ago)

Author:

wehlhard

Comment:

fix terminology

CertMgr

@@ -5 +5 @@
 
 = Branch =
-im.pidgin.soc.2007.certmgr
+im.pidgin.soc.2007.certmgr> gnutls_x509_crt_fmt_t
+
+
 
 = Handy-dandy overview =
 == SSL: The Connection Process ==
- 1. purple_ssl_connect called, and the "tls_peers" CertificateAuthorizer is provided to it as the method to use for cert checking
+ 1. purple_ssl_connect called, and the "tls_peers" CertificateVerifier is provided to it as the method to use for cert checking
  2. ssl_connect looks up the "x509" CertificateScheme, making sure that it is loaded
  3. ssl_connect fetches a the host's certificate 
- 4. ssl_connect asks the "tls_peers" CertificateAuthorizer for verification of the certificate.
- 5. The tls_peers CertificateAuthorizer sees if the get_unique_id(cert) can be found within the pool "tls_servers". If so, the certificate is considered Authenticated, and control returns to ssl_connect, which proceeds to the Hostname Check.
- 6. If the certificate cannot be found in the "tls_servers" pool, the tls_peers Authorizer then checks the "tls_ca" pool to see if the certificate chain (using get_signer_unique_id(cert)) leads to any certificates in the "tls_ca" pool. If it does find such a certificate, it uses the check_signature function to verify the signature chain, and if THAT passes, control returns to ssl_connect, which proceeds to the Hostname Check.
- 7. If the tls_peers CertAuthorizer finds an invalid (apparently attempted forged) signature, the connection fails and the user is given a popup detailing the reason.
- 8. If the tls_peers CertAuthorizer fails to find any appropriate signers in the "tls_ca" or "tls_servers" pool,  the user is prompted with the certificate details given by get_verification_data. If the certificate passes user prompting, tls_peers->bless_certificate is called.
+ 4. ssl_connect asks the "tls_peers" CertificateVerifier for verification of the certificate.
+ 5. The tls_peers CertificateVerifier sees if the get_unique_id(cert) can be found within the pool "tls_servers". If so, the certificate is considered Verified, and control returns to ssl_connect, which proceeds to the Hostname Check.
+ 6. If the certificate cannot be found in the "tls_servers" pool, the tls_peers Verifier then checks the "tls_ca" pool to see if the certificate chain (using get_signer_unique_id(cert)) leads to any certificates in the "tls_ca" pool. If it does find such a certificate, it uses the check_signature function to verify the signature chain, and if THAT passes, control returns to ssl_connect, which proceeds to the Hostname Check.
+ 7. If the tls_peers CertVerifier finds an invalid (apparently attempted forged) signature, the connection fails and the user is given a popup detailing the reason.
+ 8. If the tls_peers CertVerifier fails to find any appropriate signers in the "tls_ca" or "tls_servers" pool,  the user is prompted with the certificate details given by get_verification_data. If the certificate passes user prompting, tls_peers->bless_certificate is called.
  9. If tls_peers finds an expired certificate or any other problem, the connection is aborted with an error.
  10. We shouldn't get to step 10.
@@ -24 +26 @@
  1. ssl_connect checks that the certificate Common Name matches the hostname being connected to. If it matches, it completes the connection initialization. The hostname check may not always work, though, so:
  2. If the hostname check fails, ssl_connect will prompt the user with the certificate data and a warning that the hostname check failed.
- 3. If the user authorizes the certificate anyways, ssl_connect calls bless_certificate in the tls_peers CertificateAuthorizor, which adds it to the "tls_peers" pool. The connection initialization is then completed. (The exact action at this step is not really laid in stone, though)
+ 3. If the user accepts the certificate anyways, ssl_connect calls bless_certificate in the tls_peers CertificateVerifier, which adds it to the "tls_peers" pool. The connection initialization is then completed. (The exact action at this step is not really laid in stone, though)
 
 == CertificateScheme API  ==
@@ -58 +60 @@
  * store_certificate(Certificate) - overwrites previous certificate by unique_id if it exists
 
-=== struct CertificateAuthorizer ===
+=== struct CertificateVerifier ===
  * char * name - unique identifier ("tls_peers", "silc_servers", etc.)
- * CertificateScheme * scheme - certificate type this authorizer works with
- * bless_certificate - forces the certificate's authorization (just calls CertificatePool->store_certificate, most likely)
- * gboolean certificate_is_valid (Certificate) - returns whether a certificate can be verified as usable.
+ * CertificateScheme * scheme - certificate type this Verifier works with
+ * bless_certificate - forces the certificate's verification (just calls CertificatePool->store_certificate, most likely)
+ * gboolean certificate_is_valid (Certificate) - returns whether a certificate can be verified as trustworthy.
   * Perhaps it should also take an expected_values argument of the same form as the return value from get_verification_data(Certificate) to specify some values to check (such as Common Name, which maybe ought to be optional?)