Abstract: The present invention relates to a method at an issuing authority (111) to anonymously provide an individual (121) with a certificate (C), a method of providing anonymous approval of the individual at a communicating party (101) by means of using the certificate, an issuing authority for anonymously providing an individual with a certificate and an approving device for anonymously approving the individual by means of using the certificate. A basic idea of the invention is to provide an individual anonymously with certificates at an issuing authority, which certificates subsequently can be used by an individual to anonymously prove membership in a group at a communicating party.

Abstract: Establishing a chain of trust in a public key infrastructure can be costly, time consuming and requires nearly constant access to the appropriate network-based authorities. Local trust between devices is established using a combination of a personal identification number (PIN) delivered out-of-band and self-signed certificates. The client may present the PIN to an electronic device such as a projector or printer so the electronic device can trust the client. The electronic device may present a self-signed digital certificate with the electronic device UUID based on a hash of the electronic device public key from the certificate.

Abstract: The present invention provides a method, system, and computer program product for transparent on-demand certificate provisioning for secure email. The method comprises: generating a keypair and a self-signed certificate; requesting a certificate from a certification authority; temporarily securing email using the self-signed certificate; and securing email using the requested certificate, after receipt of the requested certificate from the certification authority. The present inventions uses self-signed certificates as an initial, interim security mechanism, provides automatic submission of certificate requests and renewal requests, provides an administrative policy to specify when keypairs and self-signed certificates are generated by a user's client system, and when certificate requests are submitted, and provides automatic transition from end-user defined trust to delegated trust based upon CA-issued certificates.

Abstract: The access control mechanisms used in traditional security infrastructures have been proven inadequate, inflexible, and difficult to apply to the Internet of today. In this work, we have proposed a general-purpose, application-independent dynamic distributed trust model (DDTM). In DDTM, access rights are directly associated with a trust value. The trust values are further classified into direct trust values, indirect trust values and trust authorization levels. We have calculated and expressed each type of the trust values into explicit numerical numbers. The core of this model is the recommendation-based trust model, organized as a trust delegation tree (TDT), and the authorization delegation realized by delegation certificate chains.

Abstract: In a traditional PKI, the trust associated with a public key is expressed in binary either by 0 or 1. Alternatively, several authors have proposed trust metrics to evaluate the confidence afforded by a public key. However their work has a static point of view and does not take into account the issue of public key revocation. In this paper, we make the first attempt to incorporate the revocation status information into the trust metrics for public key certification. To achieve our goal, we use a tailored form of a vector of trust model recently proposed. This would allow us to reason formally about when there is a need to check revocation status and how reliable the revocation mechanism should be in a given security application.

Abstract: Terms conveyed by means of policy in electronic business have become a common way to express permissions and limitations in online transactions. Doctrine and standards have contributed to determining policy frameworks and making them mandatory in certain areas such as electronic signatures. A typical example of limitations conveyed through policy in electronic signatures includes certificate policies that Certification Authorities (CAs) typically make available to subscribers and relying parties. Trade partners might also use policies to convey limitations to the way electronic signatures are accepted within specific business frameworks. Examples of transaction constraints might include limitations in roles undertaken to carry out an action in a given context, which can be introduced by means of attribute certificates. Relying parties might also use signature policies to denote the conditions for the validation and verification of electronic signatures they accept. Furthermore, signature policies might contain additional transaction-specific limitations in validating an electronic signature addressed to end users. Largescale transactions that involve the processing of electronic signatures in a mass scale within diverse applications rely on policies to convey signature-related information and limitations in a transaction. As legally binding statements, policies are used to convey trust in electronic business. Extending further the use of policy in transaction environments can enhance security, legal safety, and transparency in a transaction. Additional improvements are required, however, in order to render applicable terms that are conveyed through policy and enforce them unambiguously in a transaction. The remainder of this article discusses common concepts of policies and certain applications thereof.

Abstract: This paper presents a watermarking protocol able to solve the well-known "customer's right problem" and "unbinding problem". In particular, the protocol has been purposely designed to be adopted in a web context, where users wanting to buy digital contents are usually neither provided with digital certificates issued by certification authorities (CAs) nor able to autonomously perform specific security actions. Furthermore, the protocol enables users to keep their identities unexposed during web transactions as well as allows guilty buyers, i.e. who are responsible distributors of illegal replicas, to be unambiguously identified. Finally, the protocol has been designed so that web content providers (CPs) can exploit copyright protection services supplied by web service providers (SPs) in a security context. Thus, CPs can take advantage of complex services without having to directly implement them.

Abstract: The Public Key Certificate (PKC) is an important way to support the secure global WEB applications. The revocation of the PKC, however, remains as one of the most costly problems in the certificate management. In this paper, a new public key certificate revocation scheme based on one-way hash chain is proposed. Specifically, no centralized authority holds responsibility to collect and publish certificate status information. Instead, the individual user takes charge of his own certificate status by periodically releasing an updated secure hash value. The paper concludes with an informal examination of the security, efficiency and scalability of this scheme.

Abstract: Security and privacy top the list of consumers' concerns in e-commerce. If there is concern, trust is unlikely to develop, and trust means money. The American initiative to tackle this issue using electronic quality certificates/seals as easy-to-recognise trustmarks is valuable. However, it is falling short because, among other reasons, the system underlying the certificates is not trustworthy. There is a lesson to learn for Europe since its market is still open for such initiatives. After having analysed the weak points of the American initiative I will discuss ways to set up a reliable quality certification system and possibilities to manage the liability risk related to providing such a service in Europe.

Abstract: In this paper, we present an initial approach to the problem of specifying formally the requirements of the Certification Policy as published by a Certification Authority. The approach uses the XML language to describe the structure of the policy document, and attempts to provide a canonical representation of the document in order to allow the semantics of the policy to be described. The ultimate aim is to permit policies to be compared, thus allowing a degree of trust to be inferred between entities holding certificates issued by otherwise unconnected Certification Authorities. Introduction A common and increasingly popular method of establishing trust between entities in cyberspace is by the use of digital certificates. Digital certificates are electronic documents essentially confirming the identity of the holder, and relating this identity to a set of additional attributes “owned” by the identity. The de facto standard for digital certificates is X.509 [1], of which the current latest version is Version 3. The trust that can be placed in a certificate comes about through the fact that the digital certificate (also called a public-key certificate, or simply a certificate) is issued by a trusted entity known as a Certification Authority (CA). The CA will receive a certificate signing request from a subject, and after making a number of checks to establish the credentials of the applicant, will issue the certificate to an end-entity (e.g., end-user, device, Web server, process, etc.), or another CA, which is essentially a digitally signed copy of the information supplied by the requestor, together with some additional information supplied by the issuer (typically the validity period of the certificate falls into this category). The signature provides the proof that the CA agrees that the information contained in the certificate is correct. With the increasing use of the Internet for transactions between entities who have not previously interacted with one another, the use of certificates to establish trust will also increase, and this creates a problem of when one entity (the relying party)1, can reasonably trust another entity (the target). Trusting certificate (actually, trusting the binding embodied in the certificate) could be examined by the relying party, and the degree of the trust depends on several factors [1]. These 1 As defined in [11] “A user or agent that relies on the data in a certificate in making decisions”. factors include CA practices for authenticating the subject; the CA's operating policy, procedures, security controls, the subject's obligations such as protecting the private key and finally, CA’s legal obligations and the stated undertakings (for example, warranties and limitations on liability). Every CA is required [2] to provide a Certification Policy (CP) and a Certificate Practice Statement (CPS), which define exactly the circumstances under which certificates will be issued, and what reliance can be placed on the certificates issued by that CA. It can be assumed that any entity requesting a certificate will be prepared to accept the terms and conditions laid down by these two documents. In fact, the CA will make it a condition of issuing the certificate that the recipient does so accept them. Clearly, any (non-root) CA can only adopt a CP/CPS for its own use if it also satisfies the terms of the CAs it in the chain from itself to its root CA. (It is possible, however, for a CA to refine the terms of the CP/CPS for its own use, provided it in no way weakens the requirements of the CP/CPS it inherits.) Because the relying party already has a trust relationship with one (or more) of the CAs, and the current situation is that certain world-wide Certification Authorities – Verisign, Thawte, etc. – are almost universally the root CA of every certificate issued. (Why this should be, and why these particular companies should be regarded as the ultimate trusted third party is unclear. Schneier and Ellison [3] address this interesting question in their now infamous “Ten Risks of PKI” paper.) However, we foresee a situation in which a trust relationship between relying party and target cannot be established, because the trust path for the target has no point in common with the trusted entities known to the relying party. One possible approach to this problem is for the relying party to examine the CP/CPS of the target certificate, and try to decide the extent to which the policy of the target’s CA “matches” the policy of the relying party’s own CA. Clearly, study of the target policy by hand would be a feasible, if long-winded, approach, but the ultimate aim of our work is to explore the possibilities of carrying out this task without human intervention. Public-Key Infrastructures The term Public Key Infrastructure (PKI) is usually taken to mean a set of techniques, procedures and policies which all members of the Infrastructure have agreed to follow. A PKI will typically include a number of CAs, together with all the entities to which certificates have been issued. A PKI will normally be expected to include a repository for certificates, and a Certificate Revocation List (CRL). Due to the nature of the PKI, the certificate policy formats the PKI domain in the sense that there are numbers of CAs and end-entities follow a certain CP, and as stated in [4] there are CAs who admitted more than one policies which implies the CA becomes a subordinate to more than one root CA. A Version 3 X.509 certificate may contain a field declaring that one or more specific certificate policies applies to that certificate [1]. A PKI domain is the environment that connects nodes (CAs and end-entities) together. When an authentication request is issued by a relying party to validate a target, the process of attempting to construct a certification path will start. The certification path processing is the mechanism for authentication of any certificate, but this processing is applicable for domains where: 1. The target and relying party reside on the same domain. See Figure 1. 2. The target and relying party reside on different domains, but these domains are connected together directly or indirectly by some previous cross-certification (see Figure 2). This cross-certification may take a number of forms as described in [2]. This paper considers the problem where there is no such certification path exists, i.e. neither of the two situations described above apply [5]. Certificate policy A Certificate Policy (CP) is defined in [1] as: a named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. For example, a particular CP might indicate applicability of a type of certificate to the authentication of electronic data interchange transactions for the trading of goods within a given price range. A certificate may include a field that has a value called Object Identifier (OID) which refers to a specific CP; this helps also to distinguish one CP from another. For better qualification, Certificate Policies certificate extension could have one or more OIDs; for example, RFC3280 suggests two Certificate Policy qualifiers: a User Notice and a pointer to a Certification Practice Statement (CPS) [4]. A CP is a statement of agreement between the certificate issuer and the end-entity of certificate which means both of their certificates should have the same CP. In the cross-certificates domain the Policy Mappings extension will point to equivalent CPs in different domains[4]. In [1] it is stated that a CP is considered as an accreditation of a CA in the way that CA will be accredited against the CP. Moreover the CP has a significant part to play in the crosscertification, where the issuing CA relies on its CP to allow trust to be placed in the target’s CA; an entry in the target’s certificate refers back to the CA and hence to the CP. A relying party may use the CP of a target to decide whether the target’s certificate is trustworthy for a particular application [2]. It is clear from the importance of the Certificate Policy within the PKI, that much care must be taken in creating it. Conversely, the lack of a well-formed CP will have a big influence on security, resulting in possible compromise of electronic transactions and loss of trust. Organizations that fail to provide a CP and a CPS will be unable to be involved in secure communications, and cannot be included in a cross-certification environment [2].

Abstract: This paper presents an agent-based trust building approach developed for the Single Electronic European Market (SEEM). Intelligent agents, embedded in the distributed SEEM registry and repository nodes, SEEM Certification Authority (SCA), Trust Third Parties (TTPs) and external Certification Authorities (CAs) are adopted to collaboratively seek the trust related information of a potential partner such as user certificate and conformance information, as well as registry information.

Abstract: Considering the PKI (public key infrastructure) interoperability problem, we bring out a VBCA (virtual bridge certificate authority) model and detail the construction, maintenance and usage of the model. Two basic tools are used: one is the well-exploited threshold signature technique and the other is a data structure that is called DsCert (double signature certificate). Benefit from these tools, one can use the VBCA to bridge two trust points, and then end entities relying on these points can establish trust relationship. A VBCA model is featured by local CA (certificate authority) autonomy, democratic decision, and efficient path processing. This model overcomes the BCA (bridge certificate authority) compromise problem and removes the cross certificates among trust domains.