A security service provision application could be used for other services that are usually provided by trusted third parties (TTPs). Internally they can act as a trusted party and as an intermediary to external TTPs. Consider the following situation. A subject from inside the organization ``Fish Ltd.'' needs to communicate with a subject from ``Chips Inc.'' and non-repudiation is required. To guarantee the genuineness of the public keys, certificates are needed. We assume that they both use compatible certificates for an asymmetric key system like RSA, let us say X.509 certificates. The security service provision application cannot be seen as a true TTP as this would require the subject from ``Chips Inc.'' to trust ``Fish Ltd.'' and strictly speaking there would be no need for a non-repudiation service in that case. The security service application can however simplify certificate management within ``Fish Ltd.''. The central security service is in a good place to act as a registration authority (RA). It can check the identity of its clients that submit public keys for certification and also see whether they are in possession of the corresponding private key. We assume that our internal certification authority (CA) has a public key that is certified by a ``higher'' instance like Verisign or Belsign. The internal CA can now generate a certificate for its clients with the private key of its own certified keypair. These certificates and the internal CA's own certificate are published in a directory that can be referred to by external subjects. The subject from ``Chips Inc.'' gets the appropriate public key certificate from the directory and checks the signature generated by Fish's CA. It does so by retrieving the public key of this CA from the directory. It can in turn check this certificate if it has an authentic copy of the top CA's public key, in this case from Verisign or Belsign. If the subject from ``Fish'' wants to be sure about the public key it obtained from the subject from ``Chips'', it can ask its CA to verify the certificate chain. Alternatively it could have asked the CA to get and verify this public key in the first place. Non-repudiation of origin can now be obtained by the sender signing the message, and non-repudiation of delivery by the receiver replying with the same message (or a digest thereof), signed by the receiver. The internal CAs can also create and routinely update certificate revocation lists for compromised and/or expired keys of their clients. The certificates could internally be used for other purposes than non-repudiation, such as authentication or access control. Other functions that an ``internal TTP'' could provide are timestamping, digital archiving and data recovery. It can also have a function in the settlement of internal disputes that involve the use of public keys.