From owner-mcg-talk@localhost Sun May 11 19:18:47 1997 Return-Path: owner-mcg-talk@mcwg Received: (from majordom@localhost) by localhost (8.8.5/v3.2) id TAA13268 for mcg-talk-outgoing; Sun, 11 May 1997 19:18:47 -0300 Message-Id: <199705112218.TAA13268@localhost> Date: Sun, 11 May 1997 19:18:45 -0300 (EST) From: "416720" To: 173447 Subject: e-mail MC certification Sender: owner-mcg-talk@mcwg Status: RO X-Status: On Sun, 11 May 1997, 173447 wrote: -> I would like to send the list a (theoretical) memo which any subscriber -> to the MC system, and the list, can authenticate as having been -> originated by myself -an entity who names itself "alice" for the sake of -> this enquiry. Alice's public key hash is 0x123456789abcdef -> For the benefit of the readers, especially those that are new to the list, since we don't have our Threads and FAQ archives yet, I'll make this msg as self-contained as possible. Again, I apologize for the length but I think that this answer will help also clarify other answers (sketchy) and unite the subjects. Let us suppose that Alice wants, out of a private need, to use the provided hash = 0x123456789abcdef as Alice's MC-DN. Maybe she does not want to have to deal with Life-Lines and just wants to keep the same MC-DN forever as she periodically changes keys. No problem, with MCs she can do just that and have a brand new pair of public/private keys that would match that exact known MC-DN. Please note that this neither compromises the security of the new key-pair nor introduces any constraint in their usual calculation. I know that the above statement is possibly scandalous to some, but that is in the published MC documents. I call it "asymmetric certification". The particular hash = 0x123456789abcdef does not look very collision-free and also does not satify the proposed MC-DN standard of at least 20 bytes, but let us use it as an example. If Alice wants she could also have MC-DN = 0x123456789abcdefa11ce, or whatever. Using an MC program, Alice would create a MCC according to Alice's Policies, which wil hold Alice's key pair, also creating the following signed objects: 1. Life Policy 2. Projection Policy 3. Trust Policy This MCC enables *Alice* to immediately issue Public-MCs signed objects, which are user-independent, do not have to be all equal, do not have to address all authentication channels defined in (3) and have other properties as inherited from the MCC and as defined by (1), (2) and (3). Note that the authentication channels do not have to correspond to actual communication channels. Also note that more than one channel can be present in an authentication channel -- using the concept of virtual channels already advanced in this list. The concept of channels can be checked looking for the query ("spread spectrum" NEAR theory AND communications AND channels AND jamming) in AltaVista. The Public-MCs are signed, remote, persistent and serializable objects. They can be streamed, compressed, sent by e-mail, encrypted, sent over the Net, retrieved by http, ftp, sent in floppies, sent by fax, sent by pager, encoded in smart-cards, etc. Alice then proceeds to register the Public-MCs objects in CAs, smart-cards, etc. ATTENTION: The CAs, etc., do not: a. issue the Public-MCs, b. sign them, c. vouch for them, d. guarantee them in any way but a "fair amount of care", i.e, procedures. The CAs, etc., only actually **archive** the Public-MCs and provide a comon **environment** so that they can be re-called (i.e., Net, card-reader protocol, etc.) No CA root-key is used, no key hierarchy, etc. Actually the CA does not "certify" [or tries to ;-)], the CA is a "Common Archiver". So, the Public-MCs are **issued** by Alice, not by a "Common Archiver" or CA (as we may call them now). This is in marked contrast with today's procedures and abolishes the notion of a Trusted Third-Party or PKI which would try (we all know it cannot *and* will not guarantee results) to aggregate trust to a certificate by following a certification procedure on Alice (also easily spoofed, as well commented by Bohm in his "Identity" e-mail published by the MCG and cited below). The CA (Common Archiver) is used to guarantee procedures, not results. Also, in another marked contrast to today's situation, it is *important* to note that the Public-MCs do not have to carry Alice's cryptographic keys. If Alice wants, her public-key can be in the MC -- or not. Thus, if the Public-MCs do not contain Alice's public-key, then the proposed TTP, PKI and key-escrow legislations do not require any registration of Alice's Public-MC. This statement is to be construed in the technical sense. So, the public distribution of Alice's identification is complete and Alice is ready to be certified by a user. This completes the public distribution phase. In terms of the MCG published e-mail of 173447, "Exposition", in which a separation of phases is suggested to improve the clarity of the MC exposition, we see immediately the contrast with standard structures: 173447 delineates key-distribution as: "However, more generally, a certification chain can exist whose purpose is to 'distribute the (asymmetric) key". Key Distribution, unlike key certification, requires notions of revocation, compromise recovery, and management of risk to compensate for inadequate or costly procedures of key distribution." We see that there is no certification chain, no distributed key, no revocation, no compromised recovery and no risk management except that associated with cost recovery (not loss recovery). Because certification is not an absolute procedure (see MCG definition of certification), we need a "metric-space" or reference. In this case, we are establishing this reference with the Public-MCs as the coordinates and the Trust Policy as the gauge. When we want to certificate, we want to use the gauge and measure "distance" between the coordinates of the Public-MCs and the Private-MC. This is independent of the reference frame, which would be the hierarchical (in root-key and address spaces, the alluded certification chain) arrangement of the TTPs. The CAs (Common Archivers) can have any hierarchy (local or global, like today's root-TTPs and TTPs that link to central TTPs such as in PKI) because this hierarchy is totally transparent. PKI and TTP are also not need in that aspect. Again, this is a technical statement. -> I have an arrangement with a CA who has agreed to issue a public-MC. -> This is not the case, as above, the CAs (or TTPs) do *not* issue, they just archive and provide access to the Public-MCs. The CAs (Common Archivers) are required to guarantee *procedures*, not *results*, in this case. So, this is in perfect harmony with the UCC and the CAs (Common Archivers) can be sued if they do not provide fair and honest procedures. There is no relying party here, because the information in the Public-MC is provided by Alice -- as a closed signed object -- and the CAs (Common Archivers) procedures can be audited and be available for public scrutiny. As Bohm noted in his "identity" e-mail: "Verisign Inc class 3 certificates require personal attendance before a notary and presentation of three forms of identification such as passport, driver's licence, credit card, etc. This does not seem a very high standard, but it is at least clear and practical. It does not prevent impersonation by well-organised criminals, or by any government. " So, one would need a "leap-of-faith" to believe such certificate. This is not the case with MCs. -> Could someone whounderstand the system design now elaborate the steps -> and objects needed to (a) obtain the opportunity to create the signed -> email, (b) sign and validate the email (c) enable the recipient to have -> a guarantee that the signed mail was originated by the entity named -> alice, using key 0x123456789abcdef. -> Let's name the recipient as Skywalker. Step (a) is the creation of the MCC, as above. Step (b) is the use of the MCC by Alice. Step (c) is composed of two scenarios: A.c Skywalker already certified Alice before and has a valid certified private-MC: A.c.1 Skywalker uses his certified private-MC and certifies Alice directly in an exchange between his MC and her MCC, because Alice's MC-DN = 0x123456789abcdef will match **exactly** the cryptographic hash of Alice's public-key, as registered in the certified Private-MC, allowing the e-mail to be read and verified with Alice's appropriate public-key. No public-MCs are used. B.c. Alice is unknown to Skywalker: B.c.1. Skywalker asks Alice for a private-MC. B.c.2. Skywalker may be presented with a series of options for trust levels, lifeline levels and projection (interactive procedure) or may receive all options (take all procedure) or already have them already pre-defined (automatic procedure). After this stage, Skywalker has a private-MC, in a "green" state. Skywalker also has a chance to define or already has pre-defined as a function of some parameters (such as e-mail origin, e-mail subject, etc) ***his*** accepted risk level -- which will be used to ***his*** satisfaction in a quantified procedure. B.c.3. Skywalker's private-MC comes alive in Skywalker's machine and certifies the MCC, using Alice's provided public-key, MC-DN = 0x123456789abcdef and other informations, by consultation with a suitable number of channels, which may need one or more Public-MCs to be queried. This may need a further connection to Alice, or not. B.c.4. Skywalker's private-MC mutates in a cryptographically irreversible way, to a certified private-MC. The validity is determined by the accepted lifeline policy. B.c.5 same as A.c.1 -> Finally, when the CA emits a public-MC, which is used by the recipient, -> please explain how that CA fails to automatically enter into a position -> of creating a relying party at the moment the recipient uses that -> public-MC for the purposes of, or in suppot of processes of, -> authentication of personas. -> It is explained above. It is important to note that being a "relying party" is an unwanted situation for both sides involved, say "buyer" and "seller". For the seller, because he has an "open-ended" set of responsibilities. For the buyer, because he does not know by himself and has no way of knowing (the r-p hypothesis) under reasonable efforts if the transaction is what he wants. Thus, the buyer must "rely upon" the seller. This is a serious "leap-of-faith". I could add that the r-p condition is a "leap-of-faith" not only for the buyer but also for the seller. Because, how can the seller be *sure* that the buyer knows *all* and *implicitly* accepts all? Implicit situations are like hash functions ;-), you never know exactly what is inside (otherwise, it would not be implicit!). Thus, elimination of the r-p condition was one of the design parameters of the Meta-Certificate and we think we managed to do it -- for both sides. At the same time, as a side effect, we also eliminated the need for PKI, TTPs and key-escrow. Again, technically. Yours, Ed Gerck ______________________________________________________________________ Dr.rer.nat. E. Gerck ed@gerck.com http://mcwg P.O.Box 1201, CEP13001-970, Campinas-SP, Brazil - Fax: +55-19-2429533