Windows Live vs Kerberos

[Anne & Lynn Wheeler]

Frank Siebenlist <franks at mcs.anl.gov> 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).