The Meta-Certificate Proposal: Presentation Plan
Not for distribution or attribution: for
review purposes only.
Comments welcome. First issued: Jul-24-97
This is an internal document of the MCG.
Copyright (c), 1997.
Public documents will be issued as a result
of the work defined in this document.
1. Prior Considerations
The Meta-Certificate Proposal involves several issues,
some of which well-defined and easily referenced by previous work such
as RFCs and papers. Other issues are still being defined, documented and
discussed. Further, subjects like extrinsic and enhanced-extrinsic certification,
Object-Oriented technology, remote and mobile code, and so on, can leverage
upon existing work on X.509, PGP, Java, RMI, etc. However, themes like
intrinsic and combined certification, metric- and gauge-functions, Image-
and Domain-Space, etc. have little support on the issues normally discussed
in relationship to Internet certification.
This means that it is interesting to divide the
MC Proposal in different documents, one for each aspect that can be covered
-- while maintaining an overall unity. Thus, reviewers that may be more
familiar with one subject may find it easier to understand, criticize and
contribute to that particular subject. This procedure can also considerably
increase the speed of acceptance of MCs in the Internet because those features
that are closest to today's experience and expertise can be implemented
and used first -- reducing the occurrence of bugs and building confidence
on the design.
To divide the MC Standard in parts, the first
natural qualifier is the certification mode:
The second natural qualifier is the certification
level (as will be further defined in the MCS), regarding what
has been verified and to what extent. This is similar to the facilities
provided in the X.509 system by the different certification classes defined
in the CPS for each CA, but in a unified way and including also level 0
as a useful tool. The levels include information which MUST be verified
to a degree of extension (which is a third qualifier), where
verified means "providing information security". Whenever information is
declared as verified it must also include its degree of extension as properly
normatized for each case and indicated by capital letters: A, B, etc. The
certification itself provides for cryptographic security and is defined
by a proper syntax, while the certification levels and degrees of extension
provide for information security and are defined by proper semantics.
Thus, the certification levels, syntatically certified by the issuer, are
1. The degrees of extension are omitted, for
clarity. They will be designated as .x extensions.
2. The levels and extensions can be added
in layers with a left to right notation separated by hyphens, so that a
photograph with levels 2-1 would indicate that it was verified by
The MC Standard can thus be divided in separate MC
Proposals, as a function of content, where the usual indication for version
(e.g., v1.0) would be added after the proposal name:
0 means that nothing was verified,
1 means that cryptographic data (eg, public-key,
data and its cryptographic signature, hash, etc.) was verified by cryptographic
methods specified in the extensions,
2 means that Image-Space data (eg, entity's name,
e-mail address, web-page, photograph, hash signatures, etc.) was verified
as specified in the extensions (eg, legal document comparison, challenge
3 means that Domain-Space data (eg, person,
company, etc.) was verified as specified in the extensions (eg, notary
declaration, physical contact, acquaintance, references, etc.)
4 means that Image-Space data that is physically
defined (eg, caller-ID number, chip serial number, digital signature in
smart-card, street name and house number, etc.) was verified as specified
in the extensions,
5 means that tamper-proof hardware Image-Space data
(eg, tamper-proof hardware in general, secure GPS signals, tamper-proof
chips, tamper-proof smart-cards, etc.) was verified as specified
in the extensions,
6 means that tamper-proof Domain-Space data (eg,
biometrics in general, DNA, retina scan, fingerprint, etc.)
was verified as specified in the extensions,
7 unspecified Image-Space data, to be fully declared
and specified in the extensions for each case,
8 unspecified Domain-Space data, to be fully declared
and specified in the extensions for each case,
9 and further, reserved for future uise.
||enhanced-extrinsic + LSMC
||enhanced-extrinsic + SMC
In this table, the enhanced-extrinsic mode presented
in the Certification paper, Section 4.1., can also
allow several features of MCs to be implemented even for the enhanced-extrinsic
level, including a limited version of Secure Multiple Channels (LSMC),
as allowed by executable content.
The first objective is to address several problems
of current certification procedures which have no solution today, capitalizing
on user-assignable risk acceptance, executable content, strong default
cryptographyt, strong cryptography on top of weak-key bootstrap certificates,
single keys for X.509 and PGP if desired, CA-certificates and root-CA acceptance
based on Secure Multiple Channels, mobile code, congestion- and fault-tolerant
architecture, address indirection, gauge-functions for interoperation between
different trust models and the elimination of CRLs. Another initial objective
is also to afford transparency to currently proposed TTP legislation, if
the user so needs.
2. Main Requirements
The MC architecture must allow for indirection and
a three-tier model has been followed with much success in the prototype
code being tested. This model closely resembles the RMI (Remote Method
Invocation) standard of Sun's Java language and uses Java as the
language of choice. It is felt that a simpler two-tier architecture will
not allow for the breadth and depth of possible applications, besides the
traffic and fault-tolerance limitations.
When MCs are implemented in three-tiers, the router
role is naturally played by the subject, which is the MCC holder, defining
the router-tier. The CA and the public-MCs are akin to public resources
and are thus the server- or target-tier. The verifiers are the clients
and naturally take on the role of the client-tier.
The three-tier structure leads to three different
APIs, which define a set of small-language commands, that must be all native
and may be mobile. The commands must be expressed in ASCII characters to
allow for scripting, but are internally represented as UNICODE characters
to avoid collisions between control-characters and language-characters
-- for any language in the world.
The certificates issued or projected MUST also
support strong encryption. This means that weak 512-bit assymetric key
pairs can be eliminated, also by bootstrapping a MC-cert with a stronger
keylength on top of a weaker key "beginning cert" from export-controlled
Further, MCs MUST allow the same key pair to be
used and projected to PGP and X.509 certificates -- which is currently
not possible. This affords interoperation between standards.
Even though Secure Multiple Channels (SMC) may
not always be possible -- because of the introduction of extrinsic references
-- a limited version MUST be available in all cases, allowing for example
a PGP certificate to help validate a X.509 certificate.
3. The v1.0 Proposal
The v1.0 Proposal MUST cover or include the following
Further, the v1.0 Proposal MAY cover or include the
own certificate format, including executable code
support strong encryption by default
allow for Limited Secure Multiple Channels(LSMC)
in the enhanced mode of extrinsic certification
allow the use of the same key pair for different
standards, such as PGP and X.509
provide enhanced-extrinsic certification, taking
as an example Section 4.1 of the cie.htm paper
allow transparency to currently proposed TTP legislation
Trust Policy, allowing for user-defined risk acceptance
rules as defined by gauge functions which allow also for interoperation
(i.e., acceptance) of X.509v3 and PGPv5.0 certificates and using LSMC
Projection Policy, allowing X.509v3 and PGPv5.0 certificates
to be issued
Life-Line Policy, allowing CRLs to be eliminated
for projected certificates
certification functions (i.e., executable remote
code) for secure storage, online checking, nonce-based certification of
asymmetric key pairs, access authorization, content-sensitive alarm, etc.
UNICODE coding to allow for internationalization
plain text projection of certificates, for human-based
6-bit transport for e-mail
three-tier architecture, allowing for indirection
based on the subject (MCC holder) as the router, the verifier (private-MC
holder) as the client and the CAs and public-MCs as the network resources
to be accessed by the verifier.
secure "sand-box" for the MC code to be remotely
executed in any tier, from any tier
APIs for the three-tiers, in Java
From a process viewpoint, all levels should consider
the following basic items :
Compilation of the .class APIs as .dll or .exe files
-- which will be platform specific but will also be faster and offer other
advantages to users that do not want or have a Java Virtual Machine.
Legal considerations for the roles played by each
party (subject, verifier and issuer), also taking into account Projection,
Life-Lines and Trust Policies
others, as seen fit
1) Input of data and setting of policy.
2) Construction of metacertificates.
3) Advertising of service (dissemination of public
4) Actual process of certification, involving
the two steps of cognition and recognition.
4. Reference Implementation
The MCG has full source control and copyright of
the reference implementation, including the documents and code provided
by E. Gerck and Novaware. The protoytpe of the first working APIs for each
of the three-tiers was available end of September/97 and the MCS is being
written and based on practical applications that exercise the APIs. The
APIs will be unrestrictedly licensed, worldwide, with no royalties, which
should allow any software company to easily build secure applications on
top of the MCS platform. Because the MCS include a secure small-language,
which is the executable code, it should be possible to delegate several
tasks to the MC APIs -- which usually would need additional coding.
5. First Products
Besides the development of the APIs, three companies
are developing first products for the v1.0, especially on security levels
0 and 1. New inquiries are welcome, with an "early start" program that
includes online and personal support. It is expected that at least one
of the products will be ready concurrently with the public release of the
The products include:
a thin-client WWW browser and e-mail agent that runs
in machines with small resources, without Windows*, with a Windows*-like
graphical interface, from 386SX up.
a certificate center, which will allow X.509 and
PGP certificates to be securely collected, managed and projected. This
can be used either standalone or as a "helper" application to SSL, PGP,
S/MIME, etc. using standard programs and browsers.
a fax-email-pager-www interoperation product and
service, allowing secure transport and low-overhead billing.
a MC certificate server, with LDAP queries, targeting
intranets and corporations.
Copyright © by
All rights reserved. Copying and partial citation
allowed, with source citation.
* Windows is a trademark of Microsoft Corp.