A mighty fortress is our PKI

[Anne & Lynn Wheeler]

On 07/28/2010 12:10 AM, Paul Tiemann wrote:
> I like the idea of SSL pinning, but could it be improved if statistics were kept long-term (how many times I've visited this site and how many times it's had certificate X, but today it has certificate Y from a different issuer and certificate X wasn't even near its expiration date...)
>
> Another thought: Maybe this has been thought of before, but what about emulating the Sender Policy Framework (SPF) for domains and PKI?  Allow each domain to set a DNS TXT record that lists the allowed CA issuers for SSL certificates used on that domain.  (Crypto Policy Framework=CPF?)
>
> cpf.digicert.com IN TXT ""v=cpf1 /^DigiCert/ -all"
>
> Get the top 5 browsers to support it, and a lot of that "any CA can issue to any domain" risk goes way down.
>
> Thought: Could you even list your own root cert there as an http URL, and get Mozilla to give a nicer treatment to your own root certificate in limited scope (inserted into some kind of limited-trust cert store, valid for your domains only)
>
> Is there a reason that opportunistic crypto (no cert required) hasn't been done for https?  Would it give too much confidence to people whose DNS is being spoofed?

Part of SSL was countermeasure to perceived weakness in domain name infrastructure ... is the server that I think I'm talking to really the server I'm talking to (things like ip-address hijacking). Now Certification Authorities typically aren't the authoritative agency for the information they are certifying ... they ask for a whole bunch of information from an SSL certificate applicant and then perform and expensive, time-consuming, and error-prone identification process, x-checking the supplied information with the information on-file at the domain name infrastructure as to the true owner of a domain (the same domain name infrastructure that has the weaknesses that SSL is designed as countermeasure).

So ... something that could be backed by the Certification Authority industry as part of DNSSEC is to ask that all domain name applicants also register a public key as part of obtaining a domain name. domain name infrastructure then can required that all subsequent communication be digitally signed ... and can be verified with the onfile public key (as countermeasure to various kinds of domain name hijacking exploits, hijack domain and then apply for valid SSL certificate using dummy front company which matches the corrupted onfile information). The Certification Authority industry then could take advantage of the same infrastructure and require that all SSL domain name certificate applications, also be digitally signed (and can be verified with the onfile public key at the domain name infrastructure); replacing a time-consuming, expensive, error-prone identification process with an efficient, inexpensive, reliable authentication process.

The catch-22 for the industry is if the Certification Authority industry could start doing real-time, online retrieval of public keys for authentication ... then maybe the rest of the world might also ... changing SSL to a certificateless, real-time, online publickey infrastructure.

One of the possible reasons that it hasn't happened is there no startup, venture capital, IPO ... etc, gorp associated with such an incremental enhancement to the existing domain name infrastructure (it is a pure security/integrity play with no big financial motivation for anybody). W/o startup, venture capital, IPO play ... there is no big marketing budget to blitz the public on how much more comforting things would be (i.e. part of the reason that I coined the term "merchant comfort" certificates back in the early days). In the late 90s, we got visited by somebody that wanted to explain about the downside our comments could have on some pending Certification Authority IPO (much of internet hype from the period was actually part of IPO-mill money generating machine).

I've posted frequently in the past about the catch-22 scenario for the certification authority industry.

disclaimer: the inventor of domain name infrastructure did a stint at the science center a decade earlier ... working on various and sundry projects.

-- 
virtualization experience starting Jan1968, online at home since Mar1970

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com