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 [email protected]
