confidence in CA

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View
Hi All:

I have a question that I'd thought I'd get some feedback from on
people knowledgable about CAs.

The other day in a Network Security class, our professor asked us,
"When you receive a public key signed by a CA (certificate authority",
how can you be assured of its authenticity?  Think of some better
protocol which is different than the X509 protocol depending on a CA

He said the key was to decentralize everything.  I'm not sure that I
see the weakness in the current X509 protocol.

Anyone have any comments?  Just curious on this!


Re: confidence in CA

Drew wrote:

Quoted text here. Click to load it

So far there's about no CA that can be trusted whatsoever, they're all
bitches. Big player Verisign is giving certs out to strangers,
GeoTrust+Equifax will not verify data sufficiently, not want to talk
about Thawte...
And the few you can actually trust are almost never in use.
So whenever you need to verify a cert, you cannot rely on the CA
signature whatsoever. You need to make a phone call and verify the cert

Quoted text here. Click to load it

man Web of Trust
man PGP

Re: confidence in CA

Quoted text here. Click to load it

note that the original pk-init draft for kerberos

(used in m'soft infrastructure as well as many other authentication
operations) called for registering public key in lieu of
password ... aka w/o digital certificates

then there was a strong lobby to add certificate-based option to the
pk-init specification. i've periodically gotten email apologizing from
the person claiming primary responsibility for certificate-based
option being added to pk-init.

what they realized was that they now have a certification authority
based infrastructure for registering entities ... which has primarily
to do with who they are.

except for the trivial, no-security operations ...  they then continue
to require the kerberos based registration infrastructure which
involves both information about who the entity is, but also what
permissions need to be associated with the entity. the counter
argument is that every entity in the possesion of any valid digital
certificate should be allowed unrestricted access to every system in
the world (regardless of who they are and/or what systems are
involved). the trivial example is that everybody in the world has
unlimited access to perform financial transactions against any and all
accounts that may exist anywhere in the world.

in effect, they now tend to have duplicated registration business
processes ... with the certification authority registration
infrastructure tending to be a subset (and duplicate) of the kerberos
permission oriented registration operation. as a result, the digital
certificates issued by the certification authority based operation
have tended to become superfluous and redundant.

there has been a lot written about various serious integrity
issues related to SSL domain name digital certificates

part of proposals to improve the integrity of the SSL domain name
certification authority operation ... is to have domain name owners
register public keys (with the domain name infrastructure) when domain
names are obtained. then when entities apply for SSL domain name
infrastructures, they are required to be digitally signed. The
certification authority then can do a real-time retrieval of the
on-file public key from the domain name infrastructure to validate the
digital signature on the SSL domain name digital certificate
application (improving the integrity of the SSL domain name
certification process).

the catch-22 for the SSL domain name certification authority industry
is if the certification authority industry can rely on real-time
retrieval of onfile public keys (from the domain name infrastructure)
as the root of their certification and trust ... then why wouldn't it
be possible for everybody in the world to also start performing
real-time retrievals of the onfile public keys (making any use of SSL
domain name digital certificates redundant and superfluous).

one could even imagine a highly optimized SSL variation where any
public key and crypto-opts are piggy-backed on the same domain name
infrastructure response that provided the domain name to ip-address
mapping (totally eliminating the majority of existing SSL setup
protocol chatter)

Anne & Lynn Wheeler | /

Re: confidence in CA

Anne & Lynn Wheeler wrote:

Quoted text here. Click to load it

The more flexible variant of this is called OSCP.

Re: confidence in CA

Quoted text here. Click to load it

there was a point in time when I was being told that the appending of
digital certificates to financial transactions would bring financial
transaction processing into the modern age. I pointed out that
appending digital certificates to financial transaction represented
more of a paradigm regression of 20-30 years (to pre-real time
authentication and authoriziation). Shortly after that, OCSP was born.

the issue regarding OCSP was that it preserved the stale, static
(redundant and superfluous) digital certificate model ... by doing
possibly real-time response regarding whether the stale, static
information in the digital certificate was still valid. It didn't do
anything about providing real-time operational information about
things that may involve non-stale, and non-static information ...
like real-time response authorization a transaction as to whether it
was within the account limits.

credentials, certificates, licenses, diplomas, letters of introduction,
and letters of credit, etc have served for centuries, providing
statle, static information for relying parties that had no other
method for obtaining information about the party they were dealing

digital certificates have been electronic analogs to the physical
world counterparts for relying parties that lack any of their own
information about the party they are dealing AND lack any online
mechanism for obtaining such information.

as online environments have become more ubiquituous and prevalent,
digital certificates have somewhat moved into the no-value market
segment (as the possible offline operations that would benefit from
stale, static digital certificate information have disappeared being
replace with relying parties being able to directly access real-time
information about the entities they were dealing with). the no-value
market segment are business operations where the relying parties can't
justify the cost or expense of having access to real-time information.

the scenario for OCSP for financial transactions ... was that the
relying party could do a OCSP to see whether the digital certificate
was still current.

the counter was the x9.59 financial standard

in both cases there was a digital signature attached to the
transaction to be verified. in the x9.59 scenario, the relying party
could forward the transaction and the attached digital signature to
the customers financial institution and get a real-time response
either standing behind the payment or denying the payment (based not
only on verifying the digital signature and whether the account still
existed, but also current credit limit and possibly recent transaction
patterns that might represent fraud).

attaching a digital certificate was purely redundant and superfluous
in any sort of real-time, online operation ... and provided absolutely
no additional benefit.

my other observation (made at the same time as pointing out that
attaching stale, static digital certificates not only didn't modernize
the operation but set it back 20-30 years) was about the enormous
payload bloat.

the typical payment transaction payload size is on the order of 60-80
bytes. the digital certificate oriented financial efforts going on in
that time-frame were seeing payment transactions being increased by
4k-12k bytes for the digital certificate appending mechanisms
(i.e. payload was being increased by 100 times, two-orders of
magnitude for stale, static information that was redundant and

so the another effort was started in parallel about the same time the
ocsp stuff started ... which was to define "compressed" digital
certificates. this effort hoped to get compress digital certificates
into the 300 byte range ... representing only a factor of five times
payload bloat (for stale, static, redundant and superfluous
information) rather than 100 times payload bloat.

one of their suggested mechanisms was to remove all non-unique
information in the digital certificate ... leaving only the necessary
information that was absolutely unique for a particular digital
certificate. I pointed out if the point of appended the digital
certificate was to have it forwarded to the entity's financial
institution ... for processing by the entity's financial institution
...  then it was also possible to eliminate all information in the
digital certificate tha was already in possession of the entity's
financial institution. I then could trivially prove that the
entity's financial institution would have a superset of all
information in the digital certificate and compress the size
of the digital certificate to zero bytes.

rather than eliminating the appending of stale, static, redundant and
superfluous digital certificates to every financial transaction, in
part to avoid a factor of 100 times payload bloat ... it would be
possible to compress the appended stale, static, redundant and
superfluous digital certificate to zero bytes. You would still have an
appended digital certificate, but since it would only be zero bytes in
size, any associated payload bloat would be significantly reduced.

Anne & Lynn Wheeler | /

Re: confidence in CA

Quoted text here. Click to load it

another target market in that period for digital certificate was the
driver's license analog .... i.e. driver's licenses would be issued
with chips ... and the chip would have a digital certificate
containing all the information normally associated with driver

ocsp was then suggested for that. law enforcement officer would stop
you and ask for a valid driver's license (chip reader to get the
digital certificate copy out) and then they could do an oscp to see
whether it was still valid or not.

however, in that time frame, law enforcement was moving to real-time,
online operations. rather than wanted to know whether the physical
driver's license was still valid (i.e. this is the century's old
paradigm involving credentials, certificates, licenses, diplomas,
letters of credit/introduction, etc) ... the officer needed some
database lookup value (account number analog) ... and the officer
would do real-time access of all the "real" information.

the license was a physical object substitute for relying parties that
lacked the ability to access the real information (including real-time
stuff like oustanding warrents, tickets, etc). in the move to a
real-time, online operation ... any stale, static distributed physical
representation of that information was becoming less and less useful.

having realtime access to the real information eliminated any need for
having a stale, static distributed representation of that information
and/or any OCSP-style real-time operation providing simple yes/no
regarding whether the stale, static distributed copies were still
valid. you get rid of needing stale, static distributed copies (in the
form of physical licenses or digital certificates with the same
information) when you have direct, online, real-time access to the
real information.  

if you have direct, online, real-time access to the real information,
negating the requirement for any stale, static distributed copies,
then any requirement for an OCSP-style protocol is also negated (since
you are dealing with the real information, and don't need to consider
situations involve stale, static, redundant and superfluous copies).

Anne & Lynn Wheeler | /

Re: confidence in CA

Sheesh, you know how to string together  redundant ( or should I say stale,
static and redundant ) verbiage. Do you think that if
yourepeat something often enough people will believe it? I just get tired
and decide that you must have nothing to say since you say it so often.

Quoted text here. Click to load it

Re: confidence in CA

I think was your prof was getting at, is the possibility that the CA
that issues the certificate is only 'trusted' because it is in turn
'trusted' by root CAs. Those are trusted because, well, because you do.
This assumes that the root CA that 'vouched' for this CA that you
accepted the cert from wasn't compromised, and this has of course
happened in the past.

One theoretical architecture to consider would be the possibility of
querying more than one CA for a particular cert (assuming dual
issuance), and if there's a mismatch, querying a third 'tiebreaker' CA
(but only if there's a mismatch). This diversifies your trust
assumptions (as any 'attack' on this cert would have to involved
multiple CAs), but all this would require significant changes in the
very nature of certs, since they are cryptographically tied to a
particular CA. I'm not exactly sure how to go about this even
hypothetically, and I admit I haven't thought it out fully...


Site Timeline