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:

Extrinsic,
Intrinsic or,
Combined.

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:

Notes:
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.

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 response, etc.)
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.

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:

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 verification
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

Further, the v1.0 Proposal MAY cover or include the following topics:

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

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:

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.

* Windows is a trademark of Microsoft Corp.