Frank Siebenlist <[EMAIL PROTECTED]> writes: > Ahhh, pkinit history... actually, pkinit originates from the good old > DCE efforts at OSF from the 90's. > > The DCE-RFC's 68.3/4 show the evolution that Lynn talked about, where > the last 68.4 was used for the current IETF pkinit incarnation after > some heated ietf-workgroup sessions... > http://www.opengroup.org/dce/tech/pki/dce_pki_spec_08.pdf > > The first versions of pkinit were purely key-based, essentially like > ssh, where the public key was matched to a Kerberos principal. > > At that time we thought that X509-PKIX-PKI was going to take over the > world and X509 certs were the future... (I'm sure that Lynn has a few > references about those dreams ;-) ), so we introduced X509-cert-based > authentication for DCE/Kerberos in RFC 68.4, where the identity > management was taken over by the PKI, and Kerberos (ideally) didn't need > any user-database and would issue tickets to whoever would authenticate > with a x509-cert and the principal name would be derived from the > subject's DN. > > As mentioned, there were some heated arguments in the ietf working group > - the idea that it would demote Kerberos to a credential translation > service and would take away the identity management part was probably > one reason... > > In retrospect, I'm not sure if we made any real improvement with the > changes in the pkinit model... maybe we should have listened better to > Carl Ellison and Lynn ;-)
re: http://www.garlic.com/~lynn/2007q.html#2 Windows Live vs Kerberos one of the issues with x.509 identity (public) digital certificates from the early 90s was "what might the necessary and sufficient information be required in the digital certificates" (for possibly accepting relying parties). as a result there was some direction to include more and more personal information ... to cover the possible requirements of any relying parties which might be depending on the (public) digital certificates (PKI somewhat assumed that public digital certificates were being sprayed all over the world). however, by the mid-90s, several organizations were starting to realize that x.509 identity (public) digital certificate, increasing overloaded with personal information represented significant liability and privacy issues. some of these organizations, attempting to salvage something of the digital certificate infrastructure, regressed to something called relying-party-only digital certificates http://www.garlic.com/~lynn/subpubkey.html#rpo where the individual information was restricted to some sort of account number (or record locator) and a public key. The account/record allowed the personal information to be removed from public distribution. The issue then was that it could be trivially shown that the actual digital certificates were redundant and superfluous ... since the account/record would (or tirivially could) typically also include the public key (effectively regressing to the original pkinit scenario). The trade-off (from the digital certificate design point adapted from the letters of credit/introduction from sailing ship days) ... was that it was necessary to include all the required information needed by relying party in the document. Once the pertinent information moved some place else ... then the original purpose for such documents (or digital certificate) became redundant and superfluous. There were some additional issues with various of the relying-party-only certificates ... besides becoming redundant and superfluous. Even with relying-party-only digital certificates eliminated all the individual specific information except record-locator/account-record and public key ... they could still be quite enormous and require significant processing overhead. This was especially apparent in payment transactions ... where the overhead of a relying-party-only digital certificates could represent an 100-fold payload size increase http://www.garlic.com/~lynn/subpubkey.html#bloat that issue was so significant (in payment infrastructure) that the x9 financial standards body started a work item for "compressed" digital certificates ... with objective of attempting to reduce the payload bloat increase to possibly only 5-fold (again for something effectively redundant and superfluous). ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
