Subject: RE: [TLS] Record layer corner cases

From: Peter Williams <[email-masked]>
Date: Thu, 23 Nov 2006 21:50:14 -0800

in https, the implementor is responsible for choosing how to form certificate paths. There is nothing standardized, or alluded to as good or best practice, by specific intention. Earlier attempts by IETF to standardize certification structures and standardize certification path formation had failed, miserably. There had been three attempts, and the crypto-politics just would not converge: Vint Cerf's personal authority and political skills, notwithstanding. Letting go, infact...was the key to engendering adoption!
 
Netscape's browser team did have access to, but never applied, the results of a DARPA project that locally constructed trust paths according to various metrics concerning the "bestness" of paths through a semi-organized certification mesh, built from certs obtained from any source, and qualified for storage in a local MIB (close to MSFT trust stores, today). The https industry enforcement practice followed what Netscape did, minimally, with whatever time was left in the schedule for parsing and handling certs, after doing SSL: let the local trust store dominate the trust information signaled by the authentication peer. To be fair, this was viewed as good practice, at the time; the only reason for a peer to signal certification paths was to help distribute the cache of certs, per Lampson's theory on distributed authentication for WANs.
 
Netscape set the tone for the web management of certs, never really having "got PKI". The part they did get about it, quickly scared them (a giant control technology). once export rules concerning their higher-strength SSL crypto ciphersuites for international banks were forcing them to test certain cert fields and particular signing keys, they rapidly started to be wary of certificate-based controls. for wire-=protocol, or authorizing client or server software to even do crypto. This lassez-faire mood spread, across the web industry (and probably saved the internet from mandatory key escrow.) it also engendered grassroots adoption!
 
So, this is what drives the apparent quandary, you saw. Its actually the intent, though it is counter-intuitive, to say the least!

> From: [email-masked]> Subject: Re: [TLS] Record layer corner cases> To: [email-masked]> Date: Fri, 24 Nov 2006 02:01:09 +0100> CC: [email-masked]> > Mike wrote:> > > > I clearly misunderstood what you meant, and actually agree that it> > would be good to have one handshake message per record. Practically,> > though, you will need to support earlier versions for some time.> > Just try to connect to the industry-leading certificate authority> > with TLS 1.0: https://www.verisign.com/ for example.> > Talking of VeriSign...> > A few years ago, www.verisign.com had been sending out an expired> rootCA certificate in the certification path of the Server, and> curiously, none of the Web Browsers complained when it had a> replacement cert (same Subject&Issuer, same key, longer validity)> in the list of trust anchors. If the newer local key was> deleted in the browsers list of trust anchors, then the expired> rootCA cert sent by www.verisign.com became visible.> > Maybe there should be some guidance, common sense doesn't seem> to be sufficient (it took VeriSign several months to fix it when> I complained to them about their server misconfiguration/misbehaviour).> > -Martin> > _______________________________________________> TLS mailing list> [email-masked]> https://www1.ietf.org/mailman/listinfo/tls
_________________________________________________________________
Express yourself with gadgets on Windows Live Spaces
http://discoverspaces.live.com?source=hmtag1&loc=us

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 24 Nov 2006 19:20:29 +1300

Peter Williams <[email-masked]> writes:

>Netscape's browser team did have access to, but never applied, the results of
>a DARPA project that locally constructed trust paths according to various
>metrics concerning the "bestness" of paths through a semi-organized
>certification mesh, built from certs obtained from any source, and qualified
>for storage in a local MIB (close to MSFT trust stores, today). 

That's because using the strict hierarchical X.509 with a spaghetti PKI
requires solving NP-complete graph theory problems, which (AFAIK) only the USG
is currently attempting to do (I went to a scary talk some years ago where
someone was talking about their spaghetti PKI experience and mentioned that
their path construction algorithm ran for three days without terminating,
whereupon they had to kill the process.  Instead of taking this as some sort
of hint, they simply continued with another approach.  It was almost surreal,
like watching a bunch of people talking about their different approaches to
building perpetual-motion machines).

>The https industry enforcement practice followed what Netscape did,
>minimally, with whatever time was left in the schedule for parsing and
>handling certs, after doing SSL: let the local trust store dominate the trust
>information signaled by the authentication peer. 

Given that the (obvious with 20/20 hindsight) failures in the browser security
model that we're now seeing have very little to do with certs, this approach
wasn't so bad in the long run.

(This may now be officially off-topic for ietf-tls :-).  security-usability is
probably a better list for this).

Peter.