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 divided as:

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 cryptographic  methods.

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:
Proposal Mode Level.Extension Comments
MC/E-n.x extrinsic n.x enhanced-extrinsic + LSMC
MC/I-n.x intrinsic n.x SMC
MC/C-n.x combined n.x 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 CAs.

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 topics: Further, the v1.0 Proposal MAY cover or include the following topics: From a process viewpoint, all levels should consider the following basic items :

1) Input of data and setting of policy.
2) Construction of metacertificates.
3) Advertising of service (dissemination of public metacertificates).
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 APIs.

The products include:

Copyright © by MCG, 1997
All rights reserved. Copying and partial citation allowed, with source citation.

* Windows is a trademark of Microsoft Corp.