Read also: 1997-98 Report: Technical Summary of Developments
The Meta-Certificate Standard FAQ -- MCS FAQ
This FAQ represents work-in-progress
Copyright © 1997, All Rights Reserved
by E. Gerck

Table of Contents

General Information

Section 1 - An Overview of the Meta-Certificate Project

Section 2 - What is a Meta-Certificate and how is it used? Section 3 - MC Communication and Meta-Objects Section 4 - What is a MCC? Section 5 - What is a Public-MC? Section 6 - What is a Private-MC? Section 7 - Green and Certified Private-MCs Section 8 - Basic Definitions Section 9- Authentication Channels

Section 10- Projection

Section 11 - Life-Line

Section 12 - Certification Methods

Section 13 - Examples Section 14 - General Questions

Section 15 - References


General Information

This document contains both general and technical information about Meta-Certificates, proposal status, what it is and what it does, the MCG and more. Please read this FAQ before you post questions about these subjects to the mcg-talk list, to see if your question is already answered here first.

Another source of reference is the "MCG-Threads", which is an attempt to catch the dialogs on different threads of discussion in the mcg-talk list. The MCG-Threads contains pros, cons and comments on several issues related to Meta-Certificates, sometimes with very different sides being presented. A must read.

The plain-text version of this MC FAQ will be available by anonymous ftp at other sites. Mirrors are welcome, both for the html version as well as the text version.


SECTION 1:
An Overview of the Meta-Certificate Project

1.1: What is the MCG?

MCG stands for "Meta-Certificate Group". The MCG is a non-profit, open, international group that represents a technical development forum for today's security needs. For a statement of objectives, participants, how to participate, the mcg-talk listserver, etc., see the MCG Home-Page.

1.2: What is the purpose of a Meta-Certificate?

To provide a standard set of rules that allows for certification in various capacities, such that an entity can be assigned to a set of attributes with an arbitrarily high degree of certainty . The set of attributes may include identities, authorizations, access rights, names, qualities, or any tasks that the entity may be allowed to, with designated time, duration, quantity or other limits.

1.3: What is a Meta-Certificate, in simple terms?

A Meta-Certificate (or MC) is a unit of data and code, cryptographically signed, that allows entities, attributes, authorizations, public-keys, methods, etc. to be distributed, redistributed and certified. All MCs are subsets of characteristics (data, data types, methods, policies, etc.) from a given standard.

Alternatively, a Meta-Certificate (MC) is a class-object with subclass inheritance from a standard called MCAC (Meta-Certificate Abstract Class), that allows for objects to be securely distributed, redistributed and certified.

1.4: What is the purpose of the Meta-Certificate Proposal?

To introduce Meta-Certificates as the lingua franca of Internet certification, based on a suitable Meta-Certificate Standard which incorporates the following main features:

1.5: Who is responsible for the Meta-Certificate Proposal, for the MCG, and where is the MCG located?

E. Gerck is the author of the Meta-Certificate Proposal and coordinator of the MCG. He can be reached at ed@gerck.com

The MCG is housed by Novaware, with address:

Meta-Certificate Group
Av. Albert Einstein, 1031
13081-970 Campinas - SP
Brazil
At.: Prof. Dr. E. Gerck

Phone/Fax numbers are: +55-19-239-5838 or +55-19-239-5850

The Meta-Certificate Group is also located in the Internet. The main server is located in Brazil, where there are no export restrictions on cryptography. Mirror servers can be located anywhere, provided there are no import restrictions. Inquiries are welcome.

1.6: What is the present state of the Meta-Certificate Proposal?

The MCG Home-Page lists the current activities, published e-mails, papers and other contributions from participants in the MCG.

1.7: How about APIs and code for Meta-Certificates? How will they be available?

There are prototypes being tested and APIs being developed by Novaware. The APIs will be freely available for personal use but will require a license for commercial use or integration. The APIs allow for an extensible design, with third-party plug-ins.

Even though a Meta-Certificate standard is not yet defined, inquiries on early-start commercial applications or plug-ins are welcome.

1.8: Are MCs limited to the Internet or to some protocols?

No. MCs allow for several types of certification tasks to be carried out, including distribution, redistribution and certification. These tasks are usually done over the Internet, but MCs are neither limited to the Internet as a vehicle nor to the Internet as a field of work. For example, MCs can be supplied by a CD-ROM, a fax-back service, a pager, a business card, a smart-card, a floppy, etc. MCs can also be used to provide secure login in a single machine, an automated cashier, a smart-card handshake, etc. MCs can also interoperate with biometric devices, GPS (Global Positioning System) devices, kerberos-type tickets, zero-knowledge-proof methods, hierarchical-signature CAs, PGP's web-of-trust, etc.


SECTION 2:
What is a Meta-Certificate and how is it used?

2.1: What is a Meta-Certificate or MC?

Meta-Certificates are persistent, remote and mobile class-object structures. MC-objects are sent to client machines -- and can be further redistributed -- as instances of a class stored in a server machine, which is known as Meta-Certificate Class (MCC). The MCC also has class methods and data. The MCs are used to authenticate the server and to allow assigned tasks to be carried over even in other machines. The MCC can be different in each server machine but all MCCs inherit common features from a uniquely defined Meta-Certificate Abstract Class (MCAC).

2.2: Who issues a MC? Who distributes?

The entity that wishes to be certified. For example, you.

You do not need anyone to issue and distribute a MC for you, as you would need a CA if you would use a X.509 certificate. You also do not depend on a CA's signature, neither do you depend on a CA's signature being trusted by your client. Further, you do not fear the possibility of a CA's signature being forged, which would compromise the security of your certificate. You are also independent from TTPs, because you issue and distribute your own MCs.

In the examples in this FAQ, Alice is always the MC issuer and has the server role. The client (or user) role is assigned to Skywalker.

2.3: What makes up a MC?

A MC is normally composed of three parts, all issuable only by Alice (the MC issuer):

2.4: Are all parts necessary?

No. In some applications, it is possible to have only two parts or even one part, but always with one MCC. The different combinations afford different certification procedures and capabilities, which can be summarized as: (one+ means one or more)

All these cases are discussed in Section 12 and exemplified in Section 13.

2.5: What is the purpose of each part of a MC?

The MCC is a server-side MC Class, which is the common origin of the private-MCs and public-MCs. The MCC contains Alice's trust policies, methods and other data. Under Alice's choice, a set of Alice's data and methods can be transfered to the public-MCs or the private-MCs.

The public-MCs are objects, signed by Alice, that define certified multiple authentication channels which will be used by the private-MCs to certify Alice. The public-MCs are metaphors for independent "witnesses", which will present evidence that Alice's objects are what she claims them to be in the private-MC. The public-MCs can contain self-contained tests from data supplied by the private-MC (such as a signature), can compare data from the private-MC with data stored in other objects (such as a biometric data file in a secure server) or dynamically acquired from external devices (such as a GPS, a retina scan, etc.), or perform any general operation that compares objects from the private-MC with objects that the public-MCs have or can access.

The private-MCs are client-side objects, also signed by Alice, which provide two types of information: (i) objects that will be matched to information present in the public-MCs and thus allow the private-MC to be certified and, (ii) objects that contain private information from Alice to Skywalker (such as Alice's cryptographic public-key) and which are not present in the public-MCs. Because private-MCs are signed by Alice, certification of objects in (i) implies that the objects in (ii) are also from Alice.

2.6: What is the relationship between each part of a MC?

Each part of a MC is linked by strict inheritance from the MCAC (the Meta-Certificate Abstract Class), which means that:

i. all MCCs are subsets of the MCAC. In mathematical notation, this is represented by MCAC >= MCC.
ii. all private-MCs are subsets of the MCC, or MCC >= private-MCs
iii. all public-MCs are subsets of the MCC, or MCC >= public-MCs

In summary, MCAC >= MCC >= private-MCs or public-MCs

In a simple case, all public-MCs, private-MCs and the MCC can be equal to one another.

2.7: What is an archetypical trust model?

"Archetypical" comes from the word "archetype" which means "the original pattern or model of which all things of the same type are representations or copies" and also "an inherited idea or mode of thought in the psychology of C. G. Jung that is derived from the experience of the race and is present in the unconscious of the individual". Thus the words "archetypical trust model" convey that idea of an inherited background model that permeates all derived objects, as is the case with MCs.

This "background" archetypical trust model, can be combined with any number of other trust models such as provided by X.509, PGP, etc. The archetypical trust model is characterized by the following properties:

2.8: How is a MC issued?

It is important to realize that a MC is not issued, it is built. This means that MCs are assembled, both in its data fields and values as well as its internal code, according to the issuer's needs.

The process begins with the MCAC (the MC Abstract Class), which is subclassed by the MC issuer -- Alice -- to obtain her MCC (a MC Class), according to Alice's choice of data and methods.

Each MCC can be instantiated to obtain two flavors of MCs, public and private:

In the above processes, the rules, data structures, codes and behaviors are inherited down, as an archetypical mold, from the MCAC to the MCC to the public-MCs and to the private-MCs. This guarantees a coherent behavior for all MCCs and MCs, while allowing a large diversity of tasks, capabilities and security features.

In summary, when a MC is built (or issued), one MCC is built at the site. This MCC has all the definitions and policies the server needs in order to issue public-MCs (self-issued) and private MCs (client-requested).

2.9: What does a MC certify?

A MC certifies objects, i.e., data, methods and the respective bindings. Thus, a MC is neither an identity certificate nor an attribute certificate, nor an authorization certificate. It unifies all such possible certification objectives and offers more alternatives such as a provided by a combination of objectives.

2.10: What is the client's role in MC certification procedures?

From the beginning, the client is recognized as bearing the first risk. A MC allows the client to choose a level of risk compatible with cost, possible threats, time and other considerations. This means that a MC allows Skywalker (the client) to certify Alice's (the server's) declarations, within his level of accepted risk.

2.11: How does a MC certify?

Depends on the certification procedure used (see item 2.4)

In the "asymmetric certification" and the "symmetric certification" procedures, by matching Alice's (the server's) declarations on the public-MCs to her declarations on the private-MCs, according to Skywalker's accepted risk level.

In the "peer certification" procedures, by matching Alice's (the server's) declarations on the private-MC to the declarations on her MCC, which may involve shared secrets such as a password or pass phrase, according to Skywalker's accepted risk level.

In the "direct certification" procedures, by matching Alice's (the server's) declarations on her MCC with shared secrets such as a password or pass phrase, according to Skywalker's accepted risk level.

2.12: How is MC certification leveraged?

One of the objectives of MCs is to reduce certification costs by leveraging. This is provided by two mechanisms.

The first mechanism is obtained by securely leveraging the certified objects (which have a non-zero certification cost factor) with objects which are per se uncertified (i.e., have a zero certification cost factor) but which share a common hash or signature. One way to accomplish leveraging is, for example, by dividing the set of objects present in the private-MC in three categories:

Thus, because the private-MC is cryptographically signed by Alice -- which binds the three types of objects -- a certification procedure on the first two types of objects will also certify the third.

The second leverage mechanism reduces certification cost by certifying only the object hash, as indicated above for the second type of objects as compared to the first type.


SECTION 3:
MC Communication and Meta-Objects

3.1: Can different parts of a MC communicate?

Yes. The public-MCs and private-MCs can communicate with the parent MCC and with each other. The main communication channel is, however, between the public-MCs and private-MCs.

3.2: How is information exchanged?

Information is exchanged between the MC parts by means of "Meta-Objects" or MOs.

3.3: What is a "Meta-Object", or MO?

A Meta-Object (MO) is an object, with data, methods and binding, which contains other objects that can be safely exchanged to and from remote machines or tasks, but always between objects with the same immediate parent or with the immediate parent itself. MOs thus communicate along a specific inheritance chain: MCC <--> public-MCs <--> private-MCs.

3.4: How is a MO represented and what does it contain?

A MO is represented internally in the MC-API by a Unicode structure, but can be: (i) projected into readable-text or other formats such as binary, uuencoded, 7-bit, 6-bit, etc., by a set of translation rules, (ii) serialized and streamed, (iii) encrypted, (iv) signed, (v) left-linked, right-linked or symmetric-linked to form sequences with other MOs, (vi) nested, (vii) layered, (viii) provided with a validity time range, (ix) provided with an usage limit, (x) restricted or anchored to a location or to a set of locations, etc.

A MO thus contains data, methods and binding (like a standard object), plus linking, origin, destiny and usage informations -- which are cryptographically secure and self-enforceable.

3.5: Can MCs that come from different MCCs also communicate? Using MOs?

Not directly and not using MOs. This is a requirement in the archetypical model (no direct "inter-species" communication). Different MCs (i.e., MCs that come from different parents -- or MCCs) can communicate only by using their respective Projection methods, with suitable security restrictions.


SECTION 4:
What is a MCC?

4.1: What is a MCC?

The MCC is a MC Class located in the issuer's side, which affords three different tasks:

To execute its server function, a MCC exchanges information only with the public-MCs and private-MCs which originated from itself. This is also part of the archetypical trust model, besides inheritance.

4.2: How can a MCC be used?

The MCC can be used in a common server (e.g., a daemon in Unix terminology), in a cgi-bin process called by a http server, in a process called by a .forward file triggered by e-mail, in an applet downloaded in a HTML page, in a JavaScript program downloaded in a HTML page, in an executable file downloaded from a site, in a text HTML page, in an e-mail attachment, in an e-mail header, etc.

4.3: Is a server needed in order to use a MCC?

No, a server is not needed, because the "server function" can be supplied by different mechanisms as explained in (4.2) above.


SECTION 5:
What is a Public-MC?

5.1: What is a public-MC?

A public-MC is an information channel that bears "witness" on the declarations that Alice (the server side) has made in the private-MCs. This is accomplished by proper calculations using data from both sources and also referenced data (such as provided by a referenced third source), some of which may use cryptographic methods.

5.2: What is contained in a public-MC?

Public-MCs contain information and methods chosen by Alice and instantiated by Alice's commands. Public-MCs are also signed by Alice and provided with a validity date. They can be encrypted or hashed.

5.3: How is a public-MC distributed?

They are distributed according to Alice's choices. There is no key-hierarchy such as exists in a CA environment. If Alice distributes her public-MCs to CAs, the CAs do not sign them and do not vouch for their contents -- the CAs are just "Common Archivers".

5.4: How about redistribution of public-MCs?

Public-MCs can be anchored to a specific address or can be redistributed randomly, because they do not need to be certified by specific CAs, which would require knowledge and acceptance of the CAs' public-keys. Thus, public-MCs can be routed to servers close to clients, as in a cache, according to actual traffic needs -- which cannot be entirely forecasted -- without any hierarchy problems.

5.5: Are public-MCs a PKI?

No. Public-MCs do not define a Public-Key Infrastructure because public-MCs neither need to store keys nor need third-party keys for signing them.

5.6: What are the states of a public-MC?

Public-MCs can have two states: "certified" or "invalid". All public-MCs are issued in the certified state.


SECTION 6:
What is a Private-MC?

6.1: What is a private-MC?

A private-MC is an information source that carries Alice's (i.e., the server's) declarations on herself and Skywalker's (i.e., the client's) access rights, by means of proper objects in each case. It can also include referenced data (such as provided by a referenced third source).

6.2: What is contained in a private-MC?

A private-MC is requested by Skywalker (the client) but contains only information and methods chosen by Alice (the server), from which Skywalker or Alice can choose a particular subset when the private-MC is instantiated. Thus, private-MCs may be personalized according to Skywalker's (client's) choices or Alice's (server's) choices for Skywalker (the client). Private-MCs are also signed by Alice and provided with a validity date. They can be encrypted with Skywalker's public-key.

6.3: How is a private-MC distributed?

Directly from Alice (the server) to Skywalker (the client). There is no key-hierarchy such as exists in a CA environment.

6.4: How about redistribution of private-MCs?

Private-MCs are controlled by Skywalker (the client). They can be anchored to a specific address or can be redistributed randomly by Skywalker (the client), according to Alice's (the server's) or Skywalker's (the client's) choices. Private-MCs can be randomly redistributed because they do not need to be certified by specific CAs, which would require knowledge and acceptance of the CAs' public-keys. Thus, private-MCs can be used in any machine if so allowed, can be routed to different servers, can be stored in a common cache, all without any hierarchy problems.

6.5: Are private-MCs a PKI?

No. Private-MCs do not define a Public-Key Infrastructure because even though private-MCs store cryptographic keys, the keys are not distributed by Alice (the server) or handled to a third-party for distribution -- they are directly requested by Skywalker (the client). Private-MCs also do not use third-party keys for signing them.

6.6: What are the states of a private-MC?

Private-MCs can have three states: "green", "certified" or "invalid". All private-MCs are issued in the "green" state.


SECTION 7:
Green and Certified Private-MCs

7.1: What are "green" and "certified" private-MCs?

Private-MCs are called "green" when issued, because even though they are signed by Alice (the server), they have not been certified.

7.2: Who certifies a green private-MC?

Skywalker (the client), using the data provided by and through the public-MCs issued by Alice (the server). Skywalker specifies his desired risk acceptance level and has total control over the certification process.

7.3: How is a green private-MC certified?

A private-MC is certified by its interactions with the public-MCs, which must provide the expected answers as coherently designed into the public-MCs and the private-MC itself. These interactions represent information exchanged using MOs (Meta-Objects). A private-MC has all the objects it needs in order to establish contact with the public-MCs and achieve a level of risk acceptance that the client desires. In special circumstances, a private-MC can also conduct this process with the MCC, either alone or with help from public-MCs. If and when the "green" private-MC satisfies Skywalker's requirements, it mutates into a "certified private-MC".


SECTION 8:
Basic Definitions

8.1: Why do we need basic definitions?

Definitions are necessary to clarify and quantify the discussion, the secondary definitions, logical proofs and inductions. Many of the key terms used in this proposal have been subject to much use and abuse, often conflicting. Further, technical terms may have radically different definitions than standard usage.

For example, in law the word "robbery" is used in a very precise context, whereas the common person uses robbery for theft. "In particular, the information of information theory has little to do with knowledge or meaning, concepts which defy precise definition, to say nothing of quantitative measurement. In the context of communication, information is simply that which is produced by the source for transfer to the user." This is the example we follow. Technical, precise, quantitative meaning -- whenever possible.

Besides, different dictionaries in the same language often have conflicting entries. In different languages, the differences between similar concepts are even larger. The situation is actually worse if you take language dictionaries (after all, the Internet is international) and try to follow a word through a series of dictionaries, such as english --> german --> spanish --> swedish --> chinese --> portuguese --> english. Some entries won't even translate. The reason why one of our efforts should be to define the terms is because we will be using boolean expressions and logical inference on those terms. Then, the key to your bank account might depend on the correct interpretation -- as precise as a good programming language -- of the term anonymous. You may have an anonymous account and yet be precisely identified as yourself, without any biometrics. You may have the equivalent of cash in your hands and anonymously buy software -- to which you are entitled a named warranty (using your identification) that is enforceable in some instances.

8.2: What should be the goals for the basic definitions?

The basic definitions is a set which should be, as much as possible:

8.3: Domain-Space and Image-Space: What are they? 8.4: What are the basic definitions? 8.5: Can we go back to Domain-Space?

No. Image-Space does not carry over to Domain-Space For example, a hash-function that takes Identity into Identification would map a person to an e-mail and a Distinguished Name (DN). However, to reverse the hash-function would require a “leap-of-faith” because information was lost in the process. Thus, certifying Entities in the I-S (e.g., e-mail and DN) does not carry over to the D-S (e.g., the person).

8.6: What is a MC-DN?

A Distinguished Name, which can be more than one for each Entity. It can be defined as a special cryptographic hash with the public-key and other chosen data, which may be used to publicly certify the owner. The MC-DN may be provided by a public-MC from a CA, smart-card, e-mail, pager, printed material, CD-ROM, etc. The owner may have any number of different MC-DNs.

A MC-DN can remain constant even when the public-key is changed.


SECTION 9:
Authentication Channels

A private-MC uses multiple authentication channels to obtain certification data, automatically, from corresponding public-MCs, which co-validate with the server-MC (MCC).

The multiple channels can be virtual channels in one real channel and combine several trust models (CAs, PGP, etc.).

Difficult attacks such as spoofing and man-in-the-middle are thus made practically impossible, even for two anonymous end-points -- which is novel in cryptographic certification.

Multiple authentication channels make MCs totally independent from CAs’ signatures -- the MCs can thus be freely redistributed to any CA, even if the CA is not in a PKI hierarchy or is unknown to the user: the CAs can act as routers, only.

CAs can also be used as “Common Archivers”, without any influence or responsibility on public-MCs content.

The user can choose his level of risk, based on threat models, and enforce 100% risk acceptance.


SECTION 10:
Projection

A server-MC (MCC) can “project” a MC as a standard X.509, PGP, e-mail, etc. certificate, providing backward compatibility.

Projection allows MCs to interoperate with current standards, and even with specialized, or secret, protocols.

Projection can:

Projection thus actually improves upon the original protocols, which do not have these features.


SECTION 11:
Life-Line

A Life-Line allows a MC to be cancelled or updated, according to a Life-Policy.


SECTION 12:
Certification Procedures

See also items 2.4, 2.5 and 2.11. Examples under construction

12.1: Asymmetric Target Certification (ATC)

ATC involves one MCC, one+ public-MC and one private-MC per client.

12.2: Asymmetric Certification (AC)

AC involves one MCC, one+ public-MC and one private-MC for all clients.

12.3: Symmetric Certification (SC)

SC invloves one MCC, one+ public-MC with cryptographic key and a private-MC equal to the public-MC

12.4: Peer Target Certification (PTC)

PTC involves one MCC and one private-MC per client.

12.5: Peer Certification (PC)

PC involves one MCC and one private-MC for all clients.

12.6: Direct Certification (DC)

DC involves one MCC.


SECTION 13:
Examples

13.1: Simple Asymmetric Target Certification (ATC)
 

13.2: Simple Asymmetric Certification (AC)

Alice has public-MCs available from CAs (not necessarily TTPs), a PGP-style web-of-trust, a CD-ROM, etc., with her MC-DN = hash{Alice + Alice's public-key} and other public data. When Skywalker wants to certify Alice, Alice sends Skywalker her private-MC, with her public-key and the object that calculates her MC-DN as hash{Alice + Alice's public-key}, together with the authentication channels (CAs, PGP, CD-ROM, etc.) that are available through her public-MCs. Skywalker uses any desired number of public-MCs and checks the MC-DN as calculated and as supplied. If satisfied, Alice is certified.

13.3: Simple Symmetric Certification (SC)

13.4: Simple Peer Target Certification (PTC)

13.5: Simple Peer Certification (PC)

13.6: Simple Direct Certification (DC)


SECTION 14:
General Questions

SECTION 15:
References


COPYRIGHT NOTICE: "The Meta-Certificate FAQ -- MC FAQ" is Copyright © 1997, by E. Gerck.
All rights reserved, free copying and citation allowed with source and author reference.