Let's do the information analysis again.
The public keys that happened to be resident in browsers ... and other distributed applications .... happen to be public keys in account records .... that the physically encoded in certificate format happens to be a physical encoding artifact not a business issues. In fact, almost all standard discriptions say that these public keys are handled in an "out-of-band" process that isn't part of the normal (offline) TTP/CA certificate business process (i.e. as part of a three part transaction/message, aka the actual message, the signature on the actual message, and the signer's certificate obtained from a TTP/CA). The business process of the public keys contained in these account records .... typically included as part of some out-of-band business process .... just happens to be in certificate encoded format. If I were to register public keys and as part of that registration encode them in certificate format as stored in the account records (in the AADS model) ... they could all be considered to be certificates also. However, just because they are in certificate encoded format ... doesn't make them part of a offline TTP/CA infastructure. My actual statements ... in further detail is that in the online AADS model ... the traditional offline TTP/CA business process involving the three-part message/document/transaction has the certificate part as redundant and superfulous .... aka part I is the actual message/document/transactio9n, part II is the digital signature, and part III is the (offline) TTP/CA certificate issued to the entity signing part I. The discussion about offline TTP/CA having a vanishing market niche ... for selling offline certificates ... is in no way invalidated by the existance of account-oriented public keys that happened to be encoded in certificate format in your model. For the most part these "static" certificates have been acquired by some out-of-band business process (not included in the traditional offline TTP/CA business operation) and also tend to be self-signed. Again, just because data has been encoded in certificate format doesn't automagically create any logical conclusion that offline TTP/CA business operation has a large market opportunity in an online world (aka severely confusion the encoding method with the actual business process). When my wife were doing this stuff that came to be called electronic commerce with this thing called SSL .... we realized that we were inserting public keys in both browsers (the traditional SSL based stuff that most people are aware off). However, there was also this thing called a payment gateway ... and we were doing mutual authentication (this was before SSL had a definition for mutual authentication). This part could be considered one of the first B2B infrastructures (although must people aren't really familiar with it since it was much more of a fixed backroom process). The encoding of the public keys used certificate format ... but there was no use of any offline TTP/CA business processes. The business software supporting the payment gateway had the payment gateways public key inserted into the software by an out-of-band process .... and other than the COTS software required certificate format for the public key encoding .... there was no aspect of the process that resembled any offline TTP/CA business process. Correspondingly each merchant site that was allowed to use the gateway was predefined and had account record created. Again the use of certificate encoding for the public key was purely a side-effect of the COTS software library being used and the actual business process bore no resumblance to any offline TTP/CA business operation. The offline TTP/CA business processes have other similarities with AADS models (other than possibly using certificate encoding for public key storage). Basically the offline TTP/CA business process inclused something called a registration authority. This basically does some up front validation of public key stuff before storing the public key in a TTP/CA internal business process database (aka account record). Effectively both offline TTP/CA business processes and AADS implementations can use very similar business process for the validating and recording of public keys in account records (weither or not they are certificate-format encoded when they reside in the account record). Such account records can be in traditional database management infrastructures or just simple tables that are typical of the form used for public key storage by internal browser processes or say by some of the PGP applications. Whether or not they use certificate-format encoding for the stored public keys and whether or or not the account record is a real database entry or just a much more simpler linear table doesn't affect the logical business process (and still doesn't automagically turn it into a offline TTP/CA business process). The place where AADS starts to differ significantly from the offline TTP/CA model is with the elimination of the appended certificate as the 3rd part of a signed message/document/transaction. Now, a traditional account record .... doesn't usually stop with the identification of the TTP ... but some may ... and some could actually use certificate-format encoding of the stored information ... but they typically have to have much more context than just simple a TTP identification. There is a lot more business context involved ... that has to be wrapped around this. At a minimum, it isn't sufficient that you know the identification of the entity .... there has to be some business process that established this is a TTP entity ... and not just some random entity. If all I had was the name of the entity .... and nothing about it be an acceptable TTP entity .... the infrastructure could be susceptable to fraudulent impersonation (aka just because i have a certificate that has my identification and my public key doesn't make me an acceptable TTP). So there has to be some additional context ... either the whole table of publickey/identification entries has to be known to only be acceptable TTPs ... or each entry has to have additional information distinquishing between entries for acceptable TTPs and entries for other entities. misc. refs about this stuff we did with this small client/server startup that was doing this stuff called SSL, HTTPS, and electronic commerce .... the year that we worked with them they moved from menlo park to mountain view and changed their name from mosaic to netscape. http://www.garlic.com/~lynn/aadsm5.htm#asrn3 http://www.garlic.com/~lynn/aadsm5.htm#asrn2 http://www.garlic.com/~lynn/aadsm5.htm#asrn1 http://www.garlic.com/~lynn/aadsm5.htm#asrn4 to re-iterate .... the method of encoding the data doesn't establish the business process of the use of that data. just because some data happens to reside in an account record in certificate-format encoded format doesn't automagically turn things into offline TTP/CA business operation. [EMAIL PROTECTED] on 12/10/2002 1:33 pm wrote: Lynn, In ad-hoc peer-to-peer B2B-networks relying on a set of TTPs, a static certificate have at least one important function: - identifying the TTP So you can delete the certificate, keep the public key but you must add something else to let the RP find the on-line TTP. An URL maybe? Anders To remove yourself from this list send a message Unsubscribe to [EMAIL PROTECTED]
