This is a copy from the slide
This proposal represents work-in-progress,
in collaboration with the MCG.
Contents Copyright © E. Gerck,
1997. All rights reserved.
Allowed copying and public distribution
of the complete work only, with author and source citation.
Meta-Certificate Development steps (1996
- First work and prototypes, zeroth draft, Net discussions
- Formal creation of the MCG - Meta-Certificate Group
- Meta-Certificate Proposal, first draft, work-in-progress
The MCG (1997):
- Web-Page: http://mcwg/mcg.htm
- International: 16 countries, 56 participants:
Australia, Belgium, Brazil, Canada, Chile, China, Germany, Ireland, Italy,
Korea, Malaysia, Poland, Sweden, Switzerland, United Kingdom, United States
- Non-profit, open participation
- Anonymized list-server mcg-talk, with published selected e-mails
- Review group for the Meta-Certificate proposal
- Publishes peer-reviewed papers on certification issues:
“Overview of Certification Systems: X.509, CA, PGP and SKIP”
“Authentication, Reliability and Risks”
- MCs certify objects: data (identity, attributes, etc.), methods and
- primary trust model: decentralized, archetypical, with strict inheritance
- interoperates with any number of secondary trust models: CA, PGP, etc.
- all certification procedures and data are defined in a server-MC called
- the MCC self-distributes public-MCs, which are self-signed objects
- the public-MCs do not have to contain public-keys (no need for PKI,
- the public-MCs may be redistributed as requested: no control is needed
- the MCC sends private-MCs when requested by clients, with public-key,
- the private-MCs are certified by the public-MCs objects, using multiple
- makes possible self-distribution and self-revocation of certified key
- identifies primary recipients of certified key
- eliminates so-called revocation lists (CRLs)
- allows for self-controlled secure key-recovery
- allows public anonymous identification and certification
- allows biding of legal rights, duties and capacities, not just names,
to certified keys
- allows server-defined security constraints and client-defined security
- offers 100% certified procedures that allow for 100% client (user)
MC Exclusive Concepts
- MC-DN : A Distinguished Name. It is 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.
- Constant MC-DN: A MC-DN can remain constant even
when the public-key is changed.
- allows on/off-line safe storage -- allows self-controlled
key recovery, securely distributes and checks MC-DN, etc.
- Projection and Projection Policy -- affords compatibility,
dynamic certification, attribute certification, multiple issuers, etc.
- Authentication Channels and Trust Policy -- allows
quantitative mixing of Authentication Channels: PGP, CAs, smart-cards,
- Life-Line and Life Policy -- no revocation lists.
Offers one-time vouchers, server-push, client-pull, final on-line checking,
MC X (TTP, PKI, key-escrow)
- Public-MCs are not subject to TTP, PKI and key-escrow because public-MCs
do not store cryptographic keys.
- Public-MCs can yet authenticate, because public-MCs store MC-DNs.
- Private-MCs store public-keys but are not subject to TTP, PKI and key-escrow.
- 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.
- 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:
- take into account CRLs, multiple certificates and other potentially
conflicting data, in a quantified way.
- choose accepted trusted CAs or untrusted CAs that lead to trusted CAs,
in relationship to the client.
- choose client accepted validity date ranges.
- choose client accepted attributes (e-mail, etc.)
- Projection allows different trust models to interact, for example providing
a PGP “web-of-trust” with X.509 certificates from local CAs acting as trusted-introducers.
- Projection thus actually improves upon the projected protocols, which
do not have these features.
Today's Certification Procedures
Domain-Space and Image-Space:
What are they?
- Domain-Space: the world as directly seen and experienced by us (i.e.,
persons, corporations, countries, machines, etc.)
- Image-Space: any space derived from Domain-Space (i.e., names, DNs,
MC-DNs, e-mails, photos, IP#s, IDs, etc.).
Can we go back to Domain-Space?
- a basic question that must be answered
- Entity: a member either of Domain-Space or of
- Identity: collective qualities and characteristics
of an Entity over time
- Identification: a frozen value of a hash-function
What is being certified?
- Domain-Space Certification X Image-Space Certification
- Domain-Space allows the assignment of legal rights, duties
- Image-Space relates to public-keys, e-mails, URLs, PINs,
Names, DNs, etc.
- Image-Space needs a "leap-of-faith" to go to
- Image-Space Certificates do not translate to Domain-Space
- Both are necessary
- Today's Certificates:
- X.509v3, SPKI, SDSI, SKIP: Do not certify in Domain-Space
- PGP: Certifies in Domain-Space (web-of-trust) but lacks
liability mechanisms, attribute certification, safe revocation procedures,
- Certifies in Domain- and/or Image-Space
- Allows any desired number of liability mechanisms
- Affords certification of identifications, and/or attributes,
- towards clear engineering concepts
(this list still represents work-in-progress at the MCG)
- Secure: free from tampering of any sort
- Entity: a member either of Domain-Space or of Image-Space
- Identity: collective qualities and characteristics of an Entity over
- Result: an Entity that can be computationally processed by a machine
- Hash-function: a function that produces a Result
- Identification: a Result from a Hash-function of Identity
- Name: an Identification using signs and symbols
- Distinguished Name: a unique and singular Name
- Persona: a member of Domain-Space that is linkable to legal rights,
duties and capacities
- Anonymous: an Entity that is unlinkable to the Domain-Space
- Client: an Entity that receives or queries for information
- Server: an Entity that is a source of information, passive or active
- User: a Persona in the role of a Client or a Server
- Certification: the Secure designation of a set of Identifications to
Meta-Certificate: Definition 1
A Meta-Certificate (or MC) is a unit of data and code,
cryptographically signed, that allows objects with entities, attributes
and methods to be distributed, redistributed and certified.
A MC is an object, in Object-Oriented (O-O) terminology.
Meta-Certificate: Definition 2
Meta-Certificates are persistent and remote 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).
- based on MC-server, using existing infrastructure -
- MCs are class-objects, with archetypical functionality
- Allows for constant MC-DNs even when keys are changed
- Free from TTPs, CAs, key-escrow: Does not distribute
- Interoperates with X.509, CAs, PGP, etc.
- No so-called revocation lists. Uses self-revocation and
- Allows 100% user risk acceptance based on 100% certified
- Uses key-hash (MC-DN) to certify
keys with multiple channels
- Enforces handshake with primary key recipients
- Also binds keys to persons -- not only to machines, e-mails,
- Eliminates "leap of faith" when going from
Image- to Domain-Space
- First draft being discussed by the MCG
- First companies are joining the MCG in order to develop
- Meta-Certificate Servers, Programmer's API, Merchant
Architecture, and other basic software frameworks
- Applications for e-mail, Net commerce, communications,