Subject: RE: The new High Assurance SSL Certificates

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 16 Jan 2006 16:54:41 -0800

> [mailto:[email-masked]] On Behalf Of Jeffrey I. Schiller

> Thus my example about differentiating AOL.COM 
> from AO1.COM.
> 
> Bottom line: If this doesn't improve consumer confidence, 
> then it is a worthless exercise.

Lets add 'justifiably' in there.

I think that we need to forget the AOL.com AO1.com issue which is really
a geek-centric subset of the cases that affect consumers, it is merely
one example of the ways in which the reasonable expectations of the
consumer is betrayed. 

Jeff is giving one example of a more general problem: it is very easy to
make an authentication process that is 'failure proof' if we allow a
useless definition of failure. The only measures that really matter here
are consumer frauds and consumer confidence.

It is also a problem if someone goes to a site that has AOL graphics
plastered all over it and there is no way to quickly and reliably
determine whether or not it is the authorized AOL.

> My take on it is that 
> private key protection is not the problem we have. Phishing 
> is what it is about and phishing doesn't require stealing the 
> private key of the legitimate site.

The problem here is that private key hardware is something that is
objectively and empirically measurable. Quality of authentication
process is not.

What we need to do here is to look at the security of the system as a
whole. It is not just the authentication process that matters, it is the
control and feedback processes.

For example there is no way that any CA can test for honesty of the
certificate holder. The point of the original class 3 certification
process was not to assure the consumer that they were really dealling
with company X, it was to assure the consumer that if X defaulted for
any reason that there was a high degree of probability that the
perpetrators could be identified and face the relevant consequences.

Trusted Third Party services provide accountability based security, it
is a mistake to analyze them as if they were a permission based scheme. 

Permission based security, access control lists, kerberos etc, works
well in closed, tightly controlled environments where the set of rules
is known in advanceand all the security system is required to do is to
enforce the rules. It is not a feasible strategy in a system with a
billion users.

To take the Ao1.com example, the verisign class3 process ensures that
there is an authenticated contact address on file. If ao1.com attempts
to pass itself off as aol they can expect an immediate lawsuit. All
corporations that have strong trusted consumer brands are aware of the
need to protect them. The point about accountability is that it is not
just limited to anticipated abuses, it works also for fredonline.com if
they attempt to pass themselves off as aol by stealling their trade
dress.

Life has inherrent risk. There can never be absolute guarantees. There
is always a finite chance of being hit by a meteor. There is always a
risk that an assurance process will fail - especially if the underlying
government or commercial authentication processes that are relied on are
also fallible. 

There are three separate concerns here, 1) what is the probability of an
authentication failure, 2) what measures are in place to detect and
prevent repeat 3) to what extent can the consequences be mitigated?

Ultimately criminals respond to economics. There is no point in
obtaining a $x certificate fraudulently unless they can expect to
realize a gain of $x+$y where $y is large enough to justify the effort
involved and the risk of being caught.

Realtime revocation mechanisms such as OCSP are likely to pay much
better dividends in a high assurance certification system than some of
the processes being proposed. No authentication process however good
would have denied a certificate to Enron.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Mon, 16 Jan 2006 17:49:53 -0800

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Monday, January 16, 2006 2:58 PM
> To: Aisenberg, Michael; [email-masked]
> Subject: Re: The new High Assurance SSL Certificates
> 
> 
> At 11:01 AM -0500 1/16/06, Aisenberg, Michael wrote:
> >Another "process" ("labour") is the intra industry saga of reaching 
> >consensus on How and Where to do this (standards body, industry
> >assn.) and then doing it...Promptly.
> 
> I will repeat my earlier question, maybe a bit more pointed 
> at the VeriSign folks on the list:
> 
> What is the difference between VeriSign high assurance and 
> VeriSign low assurance certificates? If a developer can't 
> answer the question, then the app doesn't need to differentiate.

There are no VeriSign 'low assurance' certificates.

The basic principle is that all the information in the cert is assured,
the question is what information is there. In some Thawte branded
certificates there is only a domain name and only the domain name has
been authenticated. All the VeriSign branded SSL certificates (including
those off the old RSA root) are class 3 which requires authentication of
the subject identifier as well as the domain name.

The full details of the VeriSign assurance levels are given in the CPS.

If you want to connect up to an ISP to read you email or post to the
acne sufferers blog then all you need to be assured is the domain name.

If on the other hand what you want to do is to establish a commercial
relationship with a previously unknown entity then you need to be
assured that the party you are dealling with can be held legally and if
necessary criminally liable if the need arises.

> That is, if the developer cannot describe to the user what 
> the difference between two types of certificates is, the 
> application should not differentiate them to the user. Making 
> one "green" and one "not green" is a particularly bad method 
> without an explanation.

I think that the idea of comoditising trust levels is somewhat broken.
What the process is really about here is accountability. The purpose of
a ca process is to hold someone accountable. If the certificate holder
cannot be held accountable then lets hold the CA accountable in their
place.

The best way to do that is to show the CA who issued the certificate.
The real failure in the Shmoo group homologue cert was that the CA
should never have issued the certificate, I am somewhat disappointed
that the Shmoo paper never mentioned the CA concerned (not VeriSign).

Show the CA brand in place of the silly padlock icon and the problem of
inadequate assurance processes goes away. There will still be CAs who
attempt to compete to offer the minimum level of trust, most CAs however
will be looking to establish themselves as premium trust providers and
being the most careful and exclusive accreditors.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 17 Jan 2006 07:41:19 -0800

> 2. I may be wrong here, but is there actually anything that 
> prevents a low- assurance certificate issuer to include high 
> assurance policy identifiers?

I think that you identify the real problem here. The system today lacks
mechanisms to hold CAs accountable for untrustworthy certificate
practices.

The problem is made worse by the SSL user interface which gives only 1
bit of information and a pretty irrelevant one. All the padlock icon
actually means is 'this communication is encrypted'. Users are misled to
believe that it means 'this transaction is secure and I can trust that
the other party can be held accountable in case of default'.

The first problem can be solved using a self signed certificate. The
problem with the current situation is that all a CA needs to do to get
in the root store is to describe their issue practices and be audited.
It is entirely possible for a CA to essentially state that they do not
authenticate at all and still meet this criteria.

The high assurance CA project is one proposal to try to address the
problem. The question that has to be asked here is whether it is
sufficient to try to define a new bar. 

One area where it is certain that a higher bar is required is if
logotype certificates (Secure Internet Lettehead) are to be issued.
Logotypes are potentially a way to avoid the problem of domain name
attacks such cousin domain. They provide a means of providing the user
with an unambiguous proof of the subject identity but only if backed by
stringent authentication techniques that effectively prevent fraudulent
registrations.

The real key to solving this problem is to change the nature of the
business so that there is a positive incentive for all CAs to apply
stringent assurance practices. Holding the CA accountable by displaying
the ca logo as well as the subject logo creates a situation which is
effectively self-policing. The ca is required to put their own brand on
the line each time they issue a cert. Any CA that issues a bogus
certificate to the bank of england is going to be on the front page of
the new york times.

---

From: "Kemp David P." <[email-masked]>
Date: Tue, 17 Jan 2006 16:43:58 -0500

Displaying the CA logo is a helpful step, but is not sufficient.  CA
assurance levels need to be commoditized (to at least a binary level -
"UL Listed" or not), if only to solve the revocation problem.

There must be a way for a browser and a user to distinguish between
the large number of CAs in a trust list (for which the only
qualification is "we adhere to whatever claims, if any, we put
in our CPS"), and the smaller number of CAs that adhere to
industry consensus practices for HA organizational authentication.
How would that consensus be bootstrapped into existence? I don't
know, but I think a consortium like IMC or OATH would have a
better chance of gaining mindshare as the "Good Housekeeping"
of HA authentication than would any single CA operating alone.
There would have to be some general principles in the HA charter,
such as no CA could buy their way in by becoming a Platinum
level sponsor, and no CA could be excluded for reasons unrelated
to the assurance of their issuing practices, but beyond that
the listing criteria could be fairly informal ("we know HA
when we see it") and accountability-based ("two strikes and
you're out"), at least initially.

Technically, the HA could issue a list of approved root certificate
fingerprints signed along with the HA logo and the distribution
URL for the next list update.  Browsers could be modified to install
the HA authority signature key, download and validate the HA list,
and display the HA seal along with the SSL server logo whenever
the SSL cert can be validated back to a root on the HA fingerprint
list.  Would users benefit from or be confused by seeing three
logos (HA Seal, CA brand and SSL server)?  Who knows.

Is it better to invent a brand new structure (signed good-guy
list with logo) than to reuse existing structures (augment
the trust list with an HA root, HA issues CA certs and an ARL
for the previous roots)?  Probably, because otherwise there is
nothing to prevent a non-HA-listed CA from issuing a self-signed
cert with a logo identical or suspiciously close to the HA seal,
just as there is nothing to prevent a low assurance root from
claiming a high assurance CP OID.  Presumably users would have
an easier time managing 1 (or 2 or 3) HA approvers separately
from 150 root CAs.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Hallam-Baker, Phillip
Sent: Tuesday, January 17, 2006 10:41 AM
To: Anders Rundgren; [email-masked]
Subject: RE: The new High Assurance SSL Certificates

---

From: [email-masked]
Date: Wed, 18 Jan 2006 11:42:22 +0100

Ooops... the level of assurance depends on the amount of money I am willing
to pay for?

Best regards

Thomas  

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] 
> [mailto:[email-masked]] Im Auftrag von 
> [email-masked]
> Gesendet: Mittwoch, 18. Januar 2006 10:23
> An: [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: The new High Assurance SSL Certificates
> 
> 
> Paul Hoffman <[email-masked]> writes:
> 
> VeriSign low 
> >assurance certificates? If a developer can't answer the 
> question, then 
> >the app doesn't need to differentiate.
> 
> With the HA certs you have a high level of assurance that the 
> cert owner paid more for them, thus indicating that they were 
> more serious about obtaining a cert than a LA cert owner.
> 
> Peter.
> 
>

---

From: "Aisenberg, Michael" <[email-masked]>
Date: Wed, 18 Jan 2006 09:32:31 -0500

No. It depends on the amount of info the subscriber wishes to provide to rhe CA.

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]]
Sent:	Wed Jan 18 07:00:42 2006
To:	[email-masked]; [email-masked]; Aisenberg, Michael; [email-masked]
Subject:	AW: The new High Assurance SSL Certificates

Best regards

Thomas

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 18 Jan 2006 08:22:37 -0800

> [mailto:[email-masked]] On Behalf Of 
> [email-masked]

> Ooops... the level of assurance depends on the amount of 
> money I am willing to pay for?

The level of authentication is certainly constrained by cost. It is hard
to see what authentication can be done at the bargain basement rates
some charge. Checking the credit card clears perhaps?

Providing effective revocation mechanisms such as OCSP also costs money.

The 'seriousness' effect Peter refers to might be significant in some
contexts, certainly if there is an effective revocation mechanism that
closes down a certificate used fraudulently in days it would be harder
for a criminal to make a profit on an expensive cert than a cheapie.
That is not the mechanism intended here.

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 21 Jan 2006 02:29:31 +1300

"Marc Poulaud" <[email-masked]> writes:

>In the UK, if you try to incorporate a company with a similar name to
>another, your application will be turned down citing the similarity to avoid
>a AO1 type of problem.

You wouldn't need to do that, just get a "trading-as" certificate (a DBA cert
in the US) for (say) aolsecure.co.uk and get a cert for that (I'm using that
particular form because of existing precdent set by the visa-secure.com SSL'd
phishing site, but you can insert your name variant of choice).  Or create a
self-signed cert with all the high-assurance decorations in it.  Either is
fine for phishing purposes.

Peter.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 20 Jan 2006 06:27:43 -0800

> So If I were to incorporate AO1 Computers as my legitimate 
> business name and obtain the domain name AO1.COM (this is 
> hypothetical, I'm sure its not available :-) ), A High 
> Assurance CA would deny me a certificate because it looks too 
> much like an AOL certificate?
> 
> Is that really right?

No, there are some domains that you SHOULD be denied, AOL.com as an
international domain with the 0 from the Martian code set circle of
harmony. &ct.

However it is impossible to enumerate all the possible rules in advance
and EVEN WITHOUT international domain names there is a major business
detecting lookalike and cousin domains just in the ASCII character set.
Phishing gangs register names like security-bizybank.com.

> How do you decide which domains are "famous" enough to 
> deserve this protection? What constitutes a domain name that 
> looks too much like a famous domain?

It's a permissions based security approach - enumerate all the possible
failures in advance and try to stop them. Not a practical or effective
strategy in an open system with a billion users.

> On the other hand. If I obtain a high assurance certificate 
> and then use it to confuse consumers into believing my site 
> is AOL (it looks like AOL's, it abuses their trademarked 
> logos etc.) I am clearly acting in bad faith. If a High 
> Assurance CA had previously issued me a certificate, it would 
> be justified in revoking it. This is why I believe revocation 
> is a critical technology to making progress.

Revocation is critical. But revocation is not just a technical process,
there has to be a process to make the decision to revoke. That will
inevitably have to be human driven and is going to take some time, hours
rather than minutes. All owners of major trademarks like AOL will have a
trademark protection company monitoring its domain, the CA does not need
to be the only party detecting abuse.

Revocation is one aspect of an accountability scheme but where we need
to do more than deny the attempted fraudster their entry fee. We need to
hold someone accountable for the attempt, either the fraudster
themselves or the agent who set up their false corporate identity.

> It is easier to detect bad actors (and deal with them) then 
> assume someone *might* be a bad actor ahead of time and deny 
> them access to commerce by denying them a high assurance 
> certificate up front.

The real issue here is scope. The origins of the high assurance project
was with the people who still think that the function of a CA is to
establish identity, it isn't. The job of the CA in this environment is
to make it safe for the consumer by ensuring that the certificate
subject is accountable.

I would prefer to be discussing High Accountability SSL Certificates.