Required features of the caNl

The list contains only those requirements that we have already agreed on. In italics are examples, additional explanations or examples.


  • C, Java and (real) C++ versions
  • No static singeltons.
  • Minimal external dependencies.
  • Preferably no exposed library initialization calls. That does not play well with code which is being loaded and unloaded during runtime.
  • No global configuration which affects all calls to library. Use context instead. For example like OpenSSL.
  • Thread-friendly: it must be possible to simultaneously call methods of different of caNl objects from different threads. Also it must be possible to use single caNl object from different threads with external synchronization. It would be nice (but is not strictly required) to make the library thread-safe.


  • Ability to setup sockets to connect/accept in SSL mode with full proxy support regardless of the underlying library. It should also gracefully handle stripping GSI for SSL. The reason for this should be obvious. It is the main feature of the library and the reason for its existence. Both OpenSSL and bouncycastle tend to break API and ABI from version to version.
  • Ability to encapsulate read/write operations (in conjunction with timeouts these are actually quite tricky)
  • Ability to break encapsulation and access the underlying socket/SSL object. Necessary to use the libraries in conjunction with other preexisting software. Example: Allowing software using gsoap to accept proxies in HTTPS connections.
  • Ability to give direct access to remote side credentials (all retrieved even if not directly handled/verified by caNl).
  • Ability to apply all authentication tokens we will agree as supported to the connection.


  • Ability to read credentials (including private key) from files. Formats supported must include: pair of PEM or DER files, concatenated PEM file, JKS keystore, PKCS12 keystore.
  • Ability to read "truststores", i.e. data required to check whether credentials are valid. The formats and sources supported must include: reading trusted CA certs from JKS keystore, from PEM files on disk, CRLs stored on disk, CRL fetching from URLs. This feature must allow for refreshing of the store at runtime.
  • Ability to validate credentials. Both self-test of a credential alone (e.g. is signature is valid, validity timeframe not exceeded) and with respect to truststore (e.g. if issuer is trusted).
  • Ability to set various types of validation and truststore configuration. From full validation to no validation at all. The detailed list of configuration variables will be decided during API designing.
  • Ability to specify more than one validation callback.
  • Ability to influence validation of credentials. The library must be easily extensible, both by providing additional checks/formats in its code and in a code using the library. _See the "callback" mechanism of OpenSSL. However, learn from it and pass the whole chain to the callback rather then just part of it.
  • Ability to generate Proxy certificates.

-- KrzysztofBenedyczak - 11-Oct-2010

Edit | Attach | Watch | Print version | History: r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r2 - 2010-10-11 - unknown
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback