Trac is being migrated to new services! Issues can be found in our new
YouTrack instance and WIKI pages can be found on our
website.
- Timestamp:
-
May 31, 2007, 2:00:33 AM (17 years ago)
- Author:
-
wehlhard
- Comment:
-
documentation!
Legend:
- Unmodified
- Added
- Removed
- Modified
-
v27
|
v28
|
|
43 | 43 | * char * get_signer_unique_id - returns a unique identifier for the key used to sign the certificate |
44 | 44 | |
| 45 | === struct CertificatePool === |
| 46 | * char * name - the pool identifier |
| 47 | * CertificateScheme * scheme - certificate type this pool is filled with |
| 48 | * gboolean exists_in_pool(unique_id) - checks for the presence of a given cert in the pool (see get_unique_id above) (may take Certificate instead of unique_id?) |
| 49 | * Certificate * retrieve_certificate(unique_id) |
| 50 | * store_certificate(Certificate) - overwrites previous certificate by unique_id if it exists |
| 51 | |
| 52 | === struct CertificateAuthorizer === |
| 53 | * char * name - unique identifier ("tls_peers", "silc_servers", etc.) |
| 54 | * CertificateScheme * scheme - certificate type this authorizer works with |
| 55 | * bless_certificate - forces the certificate's authorization (just calls CertificatePool->store_certificate, most likely) |
| 56 | * gboolean certificate_is_valid (Certificate) - returns whether a certificate can be verified as usable. |
| 57 | * 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?) |
| 58 | |
45 | 59 | == SslOps Additions == |
46 | 60 | * get_peer_certificates - fetches as much of the certificate chain as the peer is willing to provide off of the wire and exports the certificates as several "x509" Certificate instances. |
47 | 61 | |
48 | 62 | == Key Store == |
49 | | The API for this hasn't been decided yet. However, the organization will look something like this: |
50 | | ~/.purple/certificates/cert_scheme_name/cert_unique_id(.pem?) |
| 63 | Managed by a CertificatePool. |
| 64 | |
| 65 | The API for this hasn't been totally decided yet. However, the organization will look something like this: |
| 66 | ~/.purple/certificates/cert_scheme_name/cert_pool/cert_unique_id(.pem?) |
51 | 67 | So an example X.509 certificate might be stored as: |
52 | | ~/.purple/certificates/x509/gmail_com_1234567890abcdef1234567890abcdef.pem |
53 | | Some metadata may be necessary for each certificate. |
| 68 | ~/.purple/certificates/x509/tls_servers/gmail_com_1234567890abcdef1234567890abcdef.pem |
| 69 | The keystore logic will be left mostly up to the relevant CertificatePool; these are only guidelines for how the CertificatePools should run their backends. |
54 | 70 | |
55 | 71 | == Miscellaneous API changes == |
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!