Allowed copying and public distribution
of the complete work only, with author and source citation.
Meta-Certificate Development steps (1996
- 1997):
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://novaware.cps.softex.br/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
of America
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”
Main Features
MCs certify objects: data (identity, attributes, etc.), methods and
binding
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
MCC
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,
TTP, etc.)
the public-MCs may be redistributed as requested: no control is needed
the MCC sends private-MCs when requested by clients, with public-key,
directly
the private-MCs are certified by the public-MCs objects, using multiple
channels
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
levels
offers 100% certified procedures that allow for 100% client (user)
risk acceptance
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,
etc.
Life-Line and Life Policy -- no revocation lists.
Offers one-time vouchers, server-push, client-pull, final on-line checking,
etc.
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.
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.
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:
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.
Life-Line
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
first -
Entity: a member either of Domain-Space or of
Image-Space
Identity: collective qualities and characteristics
of an Entity over time
Identification: a frozen value of a hash-function
of Identity
What is being certified?
Domain-Space Certification X Image-Space Certification
Domain-Space allows the assignment of legal rights, duties
and capacities
Image-Space relates to public-keys, e-mails, URLs, PINs,
Names, DNs, etc.
Image-Space needs a "leap-of-faith" to go to
Domain-Space
Image-Space Certificates do not translate to Domain-Space
Certificates
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,
etc.
Meta-Certificate:
Certifies in Domain- and/or Image-Space
Allows any desired number of liability mechanisms
Affords certification of identifications, and/or attributes,
and/or methods.
Basic definitions
- 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
time
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
an Entity
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
(formal)
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).
Meta-Certificate Implementations
- based on MC-server, using existing infrastructure -
Summary
Meta-Certificate:
MCs are class-objects, with archetypical functionality
and security
Allows for constant MC-DNs even when keys are changed
Free from TTPs, CAs, key-escrow: Does not distribute
keys
Interoperates with X.509, CAs, PGP, etc.
No so-called revocation lists. Uses self-revocation and
online checking
Allows 100% user risk acceptance based on 100% certified
procedures
Key-binding:
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,
names, etc.
Eliminates "leap of faith" when going from
Image- to Domain-Space
Status:
First draft being discussed by the MCG
First companies are joining the MCG in order to develop
applications:
Meta-Certificate Servers, Programmer's API, Merchant
Architecture, and other basic software frameworks
Applications for e-mail, Net commerce, communications,
etc.
