[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Design Patterns and MCs, was Re: Designer Certs
On Sat, 7 Feb 1998, Phillip M. Hallam-Baker wrote:
-> However once research is complete the most likely means by
-> which the market will adopt the results is by finding some
-> means of making it backwards compatible with the old.
It might be instructive here to consider the software tool known as
"design patterns" and their application in a security design currently in
development at the MCG. Design patterns are frequent software design
problems which can be modelled using the same "pattern" --- like a bridge
in archictecture is a design pattern for any solution that needs to close
a traffic gap. However, designing a security standard as a design pattern
poses also other implications -- such as the need for an API to exemplify
the concepts and allow a library of design patterns.
This is the approach taken at the MCG, a non-profit open international
group currently with participants from 22 countries. The MCG is developing
a security design which not only solves the current certification and PKI
scalability problems but also offers a "lingua franca" which can
interoperate with any certificate standard, worldwide and with no patent
The design is based on the security concepts discussed in the paper at
http://www.mcg.org.br/cie.htm and further exemplified in the MC-FAQ at
http://www.mcg.org.br/mcfaq.htm, with update at
Currently, the MC design is being exercised in pre-release commercial
products so that the first draft of the MC Standard will already have a
practical flavor and a working MC-API.
One substantial market difference is that the MCS will include the
standard MCS-API which will be licensed without restrictions and with
published source code by the MCG -- which will immediately enpower
programmers worldwide with a secure interface to their applications, that
they just have to "bolt-on". The MC-API will be released against a small
fee but without royalties, with strong crypto and without any need for CAs
in order to certify two unknown parties to the same extent that X.509
Basically, the design patterns used predicate that certificates should not
only be atomic (as discussed in this thread) but also "molecular" (in the
sense that links can be pre-assigned, in order to be occupied in real-time
by allowed "atoms" in allowed combinations/numbers).
The combination rules of MCs can allow certs to be securely designed and
customized according to a set of very general rules -- catalogued as
certification design patterns.
Further, Meta-Certificates are executable, mobile secure code. They can
carry not only data (as today's certificates) but also no data -- just
behavior. Or, neither data nor behavior, just binding. A MC can be just a
20-byte number and yet be perfectly contextualized anywhere the MCS is
This is possible for three reasons:
1. MCs are true Objects (as defined in Object Oriented terms) and thus
include data, methods and their binding, with a secure sand-box called the
2. MCs use intrinsic certification procedures based on the Intrinsic
Geometry of Gauss, which are able to allow a security design without any
need for CAs or third-parties, while also using extrinsic certification
compatible with PGP and X.509, plus combined certification.
3. MCs use an archetypical trust model, based on modelling the real-world
properties of trust in an Information Theory background, such that trust
becomes an n-dimensional information object -- which obeys theorems and
derivations that parallel Shannon's IT theory. This trust model alows
trust relationships to be built up, changed and recognized as such,
without introducing the security risks and costs of a third-party.
-> PGP proved that
-> mandatory hierarchy was unnecessary. Once compulsion was
-> eliminated however people adopted structures that have lead
-> to the misleading conclusion that X.509v3 mandates hierarchy.
This discussion may be especially interesting because X.509 is often times
seen as a top-down trust structure, that is just dictorially imposed upon
the verifier, while PGP would follow a grass-roots approach. However, both
PGP and X.509 define their central role to be played by the verifier
regarding cert acceptance, while cert metrics is defined in both cases
without any influence from the verifier. Further, both are key-transport
protocols, and they depend on two types of extrinsic references: keys
(quantitative) and trust (qualitative). Further still, the web-of-trust in
PGP finds its parallel in the X.509 CPS, also where the issuer sets the
rules and defines semantic acceptance conditions before cert signature.
The main difference is possibly syntatic, in the sense that PGP allows
certs to be stacked up so to say as signatures upon signatures, whereas in
X.509 the certs are linked usually in a chain (though X.509 could also
include PGP syntax).
Of course, this may limit direct conversion between PGP and X.509 in a
general case. Since MCs are being designed to operate also as an
interface, MCs can allow for PGP <--> MC <--> X.509 conversion -- as a
type of "lingua franca" between specific languages. Here, MCs fulfill
another design pattern needed in certification, in which they form a
"convertion table" which can be used as a systemic interface between
widely different security designs, present and future -- which may be
needed for specialized applications such as smart-cards, home appliances,
e-commerce, secret, etc.
Dr.rer.nat. E. Gerck email@example.com
--- Meta-Certificate Group member, http://www.mcg.org.br ---