[OpenID] Yahoo issue

[Peter Williams]

Not really. A fair amount of existing technology shelf items were take down and dusted off, by several parties acting as customers or partners.
 
One day, Jim talked to Jim, and said, hey you know, we dont have any cash to purchase the RSA BSAFE/TIPEM license. Can we give you (worthless) Netscape equity instead for rights to RSA crypto in the universal browser (only)? Meantime, Tajer El Gamal (VP of RSA Engineering) went to Netscape, disillusioned with IETF's/RSA's s/wan results (IPSEC as the wave of the near term future), and worked with Hickman within the Netscape TCP stack (and the winsock stack on windows3.1, before Netscape became anti-MSFT). Jim remembers the other Jim phoning up one day and saying: what do we do about trust points when handling enterprise-installed servers (vs the MCI/AT&T merchant portals) - SSLv1.x's fixed root keying doesnt scale in the key management area. (1 level) Certs were added, and VeriSign''s business was born. The licensing fee per site for the bundled RSA crypto rights ($400) in the server took thereafter the form of the $400 cert, instead. You originally needed a cert to turn on the latent SSL. Before we (VeriSign) would license you (the competitor to Netscape server) the root keys, you had to complete a third-party code review (since folks made the same old crypto errors, over and over and over again, diminishing the collective brand). Everyone makin server's wanted to ensure they would interoperate with the Netscape browser, addressing all its various quirks and proprietary extensions in the X.509 certs. Much folklore was borne.
 
SSLv2 architecture then took a major turn to form SSLv3 with input from NSA/CSS, who ensured SSLv3 adopted chained-certs and became truely algorithm independent - as condition of DoD standardizing on the Netscape browser (for office systems doing sensitive-but-unclassifed (ie non FOIA accessible) work). The key management capabilities were extended to ensure that (complementary) military type II key management regimes could be applied to govt algorithms (key wrapping, TEKs per security label/caveat, UKMs for daily generator parameters, KRLs for compromise recovery,...). The state machine of the SSL protocol engine and the order of messages had to align with the state machine exposed at the HSM cryptoboundary (essentially) required by FIPS 140-1 evaulators.
 

________________________________

From: Hans Granqvist [mailto:hans at granqvist.com]
Sent: Mon 2/4/2008 10:29 AM
To: Peter Williams
Cc: Eddy Nigg (StartCom Ltd.); general at openid.net
Subject: Re: [OpenID] Yahoo issue



> Why was this so, in SSL3? Because there was a dominant interworking partner that essentially defined the basecase (Netscape). Myopenid.com plays that role, here, surely. Assurance that there has been comprehensive interworking with myopenid.com is surely what is called for.
>

Your comparison is interesting but flawed:  Netscape almost
exclusively defined the
SSL spec on their own.

Hans