Broken SSL domain name trust model

Anne & Lynn Wheeler lynn at garlic.com
Fri Dec 2 01:01:31 EST 2005


leichter_jerrold at emc.com wrote:
> One can look at this in more general terms.  For validation to mean
> anything,
>
> what's validated has to be the semantically meaningful data - not some
> incidental aspect of the transaction.  The SSL model was based on the
> assumption that the URL was semantically meaningful, and further that any
> other semantically meaningful data was irreversibly bound to it, so that if
> the URL were valid, anything you read using that URL could also be assumed
> to be equally valid.

note that the other possible semantic confusion is referring to them as
certificate authorities ... rather than certification authorities.

they happen to distribute certificates which are a representation of the
certication. however, there are some number of the certification
authorities that

1) aren't the actual authoritative agency for the information being
certified i.e. the certification authority is just checking with the
real authoritative agency as to the validity of the information

2) many appear to actually prefer to just do "certificate manufactoring"
... a term we coined when we were doing audits of these new
organizations called certification authorities ... back when we were
consulting with the new client/server startup on something that has come
to be called electronic commerce.

of course the issue has always been that if you can do real-time, online
certification it has no lower value than a stale, static,
offline-oriented certificate. the business model tends to be further
aggrevated by the fact that most of the certification authorities aren't
actually the authoritative agency for the information being certified.
it is highly likely that as online connectivity becomes more and more
pervasive ... that people will start to realize the much higher value of
having real-time, online certification. Since the majority of the
certification authorities aren't actually the authoritative agency for
the actual information, then any transition to high-value, real-time,
online certification will tend to be done directly with the
authoritative agency responsible for the actual informmation. at that
point, most of the certification authorities become obsolete.

an obfuscation is to concentrate on the certificates as having magical
properties, distinct from their representation of an information
certifying business process. referring to them as certificate
authorities helps create semantic confusing as to where the business
process value actual exists. similarly there have articles in the
popular press referring to attached digital crrtificates as what
provides the value to any digitally signed message/document ... further
obfuscating the the value of authentication can be done with digital
signatures with online registered public keys (where any digital
certificates become totally redundant and superfluous).

the other problem/issue with requiring x.509 identity certificates on
every digitally signed message/document .... is that it turns what
should be straight-forward, simple authentication operation into a heavy
duty identification operation.

this has also tended to cause semantic confusion as well as something of
a schizo personality in some societies; especially those professing
extremely stringent privacy principles and at the same time trying to
mandate x.509 identity certificates attached to every electronic
communication (making every electronic message an identification operation).

misc. past posts referring to semantic confusion:
http://www.garlic.com/~lynn/aadsm3.htm#kiss5 Common misconceptions, was
Re: KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION
:draft-ietf-pkix-scvp- 00.txt))
http://www.garlic.com/~lynn/aepay11.htm#53 Authentication white paper
http://www.garlic.com/~lynn/aadsm12.htm#30 Employee Certificates -
Security Issues
http://www.garlic.com/~lynn/aadsm13.htm#16 A challenge
http://www.garlic.com/~lynn/aadsm15.htm#36 VS: On-line signature standards
http://www.garlic.com/~lynn/aadsm19.htm#7 JIE - Contracts in Cyberspace
http://www.garlic.com/~lynn/aadsm19.htm#24 Citibank discloses private
information to improve security
http://www.garlic.com/~lynn/aadsm19.htm#25 Digital signatures have a big
problem with meaning
http://www.garlic.com/~lynn/aadsm20.htm#8 UK EU presidency aims for
Europe-wide biometric ID card
http://www.garlic.com/~lynn/aadsm20.htm#44 Another entry in the internet
security hall of shame
http://www.garlic.com/~lynn/aadsm21.htm#13 Contactless payments and the
security challenges
http://www.garlic.com/~lynn/2003k.html#6 Security models
http://www.garlic.com/~lynn/2004i.html#27 New Method for Authenticated
Public Key Exchange without Digital Certificates
http://www.garlic.com/~lynn/2005f.html#20 Some questions on smart cards
(Software licensing using smart cards)
http://www.garlic.com/~lynn/2005m.html#11 Question about authentication
protocols
http://www.garlic.com/~lynn/2005n.html#51 IPSEC and user vs machine
authentication
http://www.garlic.com/~lynn/2005o.html#42 Catch22. If you cannot legally
be forced to sign a document etc - Tax Declaration etc etc etc
http://www.garlic.com/~lynn/2005q.html#4 winscape?
http://www.garlic.com/~lynn/2005r.html#54 NEW USA FFIES Guidance





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



More information about the cryptography mailing list