Subject: RE: Client-side revocation checking capability

From: Ambarish Malpani <[email-masked]>
Date: Thu, 10 Aug 2000 16:31:16 -0700

Hi Juan,
    I agree with Jeff that most client applications don't do
revocation checking. To the best of my belief, some of the 3.0
versions of Netscape Navigator etc. could do CRL checking if the
cert had some magic extensions in them.

Communicator 4.7, with the PSM module does a pretty reasonable
job of revocation checking with OCSP. We (ValiCert) do have
a plugin for both IE 5.0 and Outlook that can also enable those
applications to do revocation checking with OCSP.

We also have plugins for Netscape Enterprise Server and IIS, but
you don't seem to be interested in servers from your mail.

Regards,
Ambarish

---------------------------------------------------------------------
Ambarish Malpani
Architect                                                650.567.5457
ValiCert, Inc.                                  [email-masked]
339 N. Bernardo Ave.                          http://www.valicert.com
Mountain View, CA 94043

> -----Original Message-----
> From: Jeff Spinney [mailto:[email-masked]]
> Sent: Thursday, August 10, 2000 3:05 PM
> To: [email-masked]; ''Ietf-Pkix'
> Subject: RE: Client-side revocation checking capability
> 
> 
> 	OCSP server vendors such as CertCo (www.certco.com) or Valicert
> (www.valicert.com) have toolkits with which you can OCSP 'enable' an
> application. This is great for application vendors who wish 
> to make their
> apps more robust and certificate enabled. Most applications 
> at this point in
> the game are not OCSP enabled even if they can deal with 
> certificates, they
> do the basic crypto checking *if* they have the issuer cert 
> on hand, but do
> not do real time status checking to see whether or not the 
> cert has been
> revoked since it was issued.
> 
> 	in that regard, it seems as though the application 
> market needs to be
> persuaded to make their software support real time certificate status
> checking.
> 
> 
> 	As for Netscape, they do have an OCSP client for their 
> browser. I am unsure
> if it is publically available at this time. It loads into the 
> security area,
> under 'advanced' and gives you the option to specify an OCSP 
> responder. In
> my experiance, and it was in the early stages of this modules 
> lifetime, it
> was very finicky.  If i remember correctly, it wanted the 
> OCSP response to
> be sgned by the same cert that signed the cert being checked. 
>  This may not
> always be the case.
> 
> 
> -j
> 
> 
> 
> -----Original Message-----
> From: Juan Carlos Pérez Aguayo [mailto:[email-masked]]
> Sent: Thursday, August 10, 2000 12:36 PM
> To: 'Ietf-Pkix
> Subject: Client-side revocation checking capability
> 
> 
> I am in trouble about this: What is  the real support that have the
> client-side software for certificate revocation checking now? 
> i.e. (Internet
> Explorer, Netscape, etc.)
> 
> I heard that, in fact, client-applications don`t do any 
> revocation checking
> at all? It's that truly?
> 
> What is the real capability of those client applications this time?
> 
> By example, I know that Netscape define some certificate 
> extensions for
> managing revocation, but I am not sure if realy work
> 
> Can anyone give me some help?
> 
> Thanks you
> 
> 
> 
> Juan Carlos Pérez Aguayo
> Software Engineer
> Acepta.com
> [email-masked]
> 
>

---

From: Juan Carlos Pérez Aguayo <[email-masked]>
Date: Fri, 11 Aug 2000 18:09:59 -0400

Ambarish:

I have been the "magic extensions" in Netscape and I belive that's ok, but
only Netscape Server does those checking...

If clients applications don't have native on-line checking support, then the
options like the check-box in the Advanced\Options\Security in IE5.x, when
say "Chek for publisher's certificate revocation" and "Chek for server
certificate revocation" does not do anything at all , Ok ?

I think that only check if a server certificate, on a SSL connection, belong
to the "trusted certificate store" defined for IE.

Those type of messages seem communicate erroneus propose...

Regards

Juan Carlos

>De: "Ambarish Malpani" <[email-masked]>
>Para: <[email-masked]>; <[email-masked]>;
"''Ietf-Pkix'" <[email-masked]>
>Asunto: RE: Client-side revocation checking capability
>Fecha: Jueves, 10 de Agosto de 2000 19:46

---

From: "Anders Rundgren" <[email-masked]>
Date: Sat, 12 Aug 2000 08:02:08 +0200

Juan Carlos,

That on-line checking of server-certificates is not standard in browsers is probably
beacuse a revocation is not that likely to happen.  In case of a key compromize at the VeriSign
CA the whole world will be notified and in the case of key compromize in a web-server no
one will know or be notified.  You can steal a web-cert+key from a lousy installation (most are)
in case you have sys-admin rights.   Nothing to do about except tighten up internal security.
And if the host-name is no longer valid (the company filed for bancruptsy) the
server will be taken down some day.

IMO status-checking is only needed (or implementable at least) for person-oriented certificates, where
you may revoke yourself due to loss (of card) or by the company because you got fired.

This is a slightly different answer than you get by asking a typical crypto expert but to my
knowledge they usually know zilch, nada etc. about practical things that may be 100 times more
important than the cryptologic solurtion.  I.e. as long as there are serious practical problems
associated with server-certificates, CRLs etc. would basically add nothing (but delays).

Regards
Anders

---

From: Tony Bartoletti <[email-masked]>
Date: Mon, 14 Aug 2000 13:48:16 -0700

At 01:09 PM 8/14/00 -0700, Morrill, Dan wrote:
>Dennis,
>
>My question then is, has anyone ever had a CA compromised? (not that it
>could not happen, but usually CA's are on the "Must Secure at all costs"
>level) Wouldn't that compromise be part of a policy statement? With
>appropriate protocols to address a security issue.
>
>I know that with the CA's that I have worked on, all of them are geared high
>(Paranoid) on a sensor like Real Secure, with NetRanger and some Enterprise
>management backup, so that if it goes red (looks like it is under attack),
>the system is cut off the net whenever there is a possible breach, then the
>folks are paged to come take a look. Normal response times, metrics and
>other ways of reporting data then take over. If warranted, backups, disaster
>recovery protocols then go into effect. Then there is network issues that
>can go a long way to secure a CA from compromise.
>
>I think that security of a CA is more policy than is a technical
>specification. Feel free to disagree.

I'm my view, the "likely" scenario of a CA root key compromise would follow
from a "trusted" hardware technician working on the inside, swapping chips
or boards under the guise of "routine service".  It won't be from some net-
hacker swooping in from afar.

As Dennis Glatting points out, the far more reasonable scenario involves
the massive covert replacement of browser "root-certs" accomplished by
some viral email code, followed shortly thereafter by concerted DNS
redirection to "fake" commercial sites.  The fraudulent root certificates
verify the fraudulent site certificates, take your credit card numbers
and run.

If and when that happens, I suppose browser manufacturers will see fit to make
it an "option" for consumers to "self-sign" or encrypt the installed 
root-certs,
and suffer being prompted for a "key" to verify each transaction.

It seems that most "PKIs" are best suited to everyone BUT the public.

___tony___

>From: Dennis Glatting [mailto:[email-masked]]
>Sent: Monday, August 14, 2000 01:02 PM
>To: Anders Rundgren
>Cc: Bob Jueneman; [email-masked]; [email-masked]
>Subject: Re: Client-side revocation checking capability
>
>
>Anders Rundgren wrote:
>
>
> > To get a new server-certificate is BTW not that trivial so it makes sense
>to improve
> > local security in various ways.
> >
>
>One of the (many) problems with the PKI as it is today (okay, SSL/TLS)
>is all you need is to compromise one CA and you can issue bogus server
>certificates and set up bogus web sites to your hearts content, at
>least for a while. The popular browsers have many root certificates,
>58 in Netscape I believe. If you compromise one of those roots then a
>browser is going to accept a certificate from a compromised CA with
>Amazon.COM and DNS spoofed without distinction from the real
>Amazon.COM. Another trick is to send a viral laden e-mail message to
>the masses and implant a root certificate.
>
>In both cases I am skeptical of the value of CR. I am also skeptical
>that all consumers would repair their systems even with a flood of
>strongly worded advertising. So, :), I believe a compromised or
>spoofed (bogus embeded root certificate) root is the kind of gift that
>keeps on giving.

Tony Bartoletti 925-422-3881 <[email-masked]>
Information Operations, Warfare and Assurance Center
Lawrence Livermore National Laboratory
Livermore, CA 94551-9900

---

From: "Morrill, Dan" <[email-masked]>
Date: Mon, 14 Aug 2000 13:59:40 -0700

Tony & co. Sorry, this really peaks my interest, cause this is something I
am dealing with. Here goes....

Tony>> I'm my view, the "likely" scenario of a CA root key compromise would
follow
Tony>> from a "trusted" hardware technician working on the inside, swapping
chips
Tony>> or boards under the guise of "routine service".  It won't be from
some net-
Tony>> hacker swooping in from afar.

Ok, since a server cert is 1 to 1 bound to IP and lots of other data for 1/2
the key, the CA cuts the other half the key, you would already have to have
your 1/2 keys cut on your bogus servers, and have access to the systems to
do this (RA), plus if it is entrust, you would need their web package, so
much like a DDOS crack, this would have to be highly thought out and highly
coordinated, with plenty of servers and bandwidth. All that for credit card
numbers? It would be easier, and unfortunately far more realistic and
frequent to grab the database that stores all this through the web server. I
don't see a high return on this scenario for the work involved.

Tony>> As Dennis Glatting points out, the far more reasonable scenario
involves
Tony>> the massive covert replacement of browser "root-certs" accomplished
by
Tony>> some viral email code, followed shortly thereafter by concerted DNS
Tony>> redirection to "fake" commercial sites.  The fraudulent root
certificates
Tony>> verify the fraudulent site certificates, take your credit card
numbers
Tony>> and run.

Same issue, you would have had to prepped a whole catalog of systems, then
run your code, easier to simulate the RA responses and mimic a trusted agent
via a virus or hostile code? Again, lots of work, lots of really clever
thinking if they have incorporated IPSec into the Network, plus overhead as
above. Again, not a good value for the return, especially when it is easier
to get credit card numbers from an improperly secured dBase or flat file
driving the e-commerce site.

Tony>> If and when that happens, I suppose browser manufacturers will see
fit to make
Tony>> it an "option" for consumers to "self-sign" or encrypt the installed 
Tony>> root-certs, and suffer being prompted for a "key" to verify each
transaction.

Browsers will already warn you about what is an unrecognized cert (one not
in DB7 or the registry) or one that has expired, or one that is not meeting
all the qualifications. If you poison a DNS system, and point
xxx.xxx.xxx.xxx to a different server, all that cert information is really
doing at the server level is initiating SSL/TLS. It is usually signed by
Verisign, RSA, DST or any of the other 20+ 'root' certs already in your
browser. There should be enough hokey things happening that the user will
pay attention, and if they don't like with anything else, you suffer for
your actions. 

I think again, the argument rests with, more trouble and work than it is
worth because there are ton's easier ways to get credit card numbers. Now,
if it was war time, and we had real enemies, this would be great for DoD's
level of effort to exploit this on the web for intelligence information &
etc. Maybe then this would be a "fun" issue to explore. Anyone ask what the
Banking industry is doing now about this, or have they thought about it yet?

Tony>> It seems that most "PKIs" are best suited to everyone BUT the public.

On this point we agree.
;-)
r/
Dan

-----Original Message-----
From: Tony Bartoletti [mailto:[email-masked]]
Sent: Monday, August 14, 2000 01:48 PM
To: Morrill, Dan; 'Dennis Glatting'; Anders Rundgren
Cc: Bob Jueneman; [email-masked]; [email-masked]
Subject: RE: Client-side revocation checking capability

If and when that happens, I suppose browser manufacturers will see fit to
make
it an "option" for consumers to "self-sign" or encrypt the installed 
root-certs,
and suffer being prompted for a "key" to verify each transaction.

___tony___

---

From: "Bob Jueneman" <[email-masked]>
Date: Mon, 14 Aug 2000 22:09:09 -0600

Al, I don't disagree with you, but then I don't distribute the popular browsers or control what their defaults are, either.

All that I was trying to say was that there are, substantive reasons to believe that the CRL "cure" may be worse than the disease, at least with respect to the current use of PKI consumer e-commerce sites. that's not to say that other applications may not have different trade-offs and criteria.

Without making too big a deal of the whole issue, I think it is important to realize that the goal of PKI is to reduce risk to an affordable level, NOT necessarily to try to reduce that risk to absolute zero, regardless of cost.

Bob

>>> Al Arsenault <[email-masked]> 08/14/00 07:22PM >>>
Bob, et alia:

The scenario against which CRL-checking-for-server-certs-in-SSL-sessions
protects is:

- the key for Popular_fictional_site.com is compromised, and whoever has
it sets up a duplicate site, with appropriate DNS spoofs to direct
traffic to the duplicate site

- the legitimate owners of Popular_fictional_site.com realize that the
compromise has occurred, report it, and get a new cert.

- now, along comes Jean User, connecting to Popular_fictional_site.com. 
Quick:  is this the real site, or the spoof?  Both have certs and
matching private keys that trace back to the same trusted root.  If the
client checks the CRL, (s)he will detect that they cert/key offered by
the spoof site is revoked, while the cert/key offered by the legitimate
site will be okay.

Okay, now, how realistic is that threat?  Is that the one against which
you're defending?  Who knows?  But it is one of the threats against
which the revocation mechanism was designed to work.

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

Bob Jueneman wrote:
> 
> Anders,
> 
> There is a lot of practical truth in what you say.
> 
> CRL checking certainly seems like a nice thing to do cryptographically, until you consider what the threat is that you are trying to address.
> 
> Let's suppose amazon.com's key were compromised somehow. What would happen?  Well, the first thing is that they would call up their CA and get a new certificate, and then download that certificate to any SSL user. So the old certificate and key would be completely out of the picture, and hence no CRL would be needed, much less OCSP.  since they don't use that certificate to sign anything other than SSL sessions, which in which the certificates are sent in line, they don't even need to revoke their old certs -- just stop using them.
> 
> The only case where a CRL might be useful in that scenario would be in the case of some fly-by-night mafia.com type of store-front, where the CA might conceivably revoke the certificate for fraud or other cause. However, that would represent a substantial legal liability for the CA, and so that doesn't seem terribly likely in practice.
> 
> Since the retail merchant accounts for the overwhelming use of PKI to date (e-mail is just barely beginning to make a dent, and everything else are just pilots, it isn't surprising that the browsers don't enable CRL checking by default. It would merely add lots of delay and processing time.
> 
> Bob
> 
> >>> "Anders Rundgren" <[email-masked]> 08/12/00 12:02AM >>>
> Juan Carlos,
>

---

From: Peter Williams <[email-masked]>
Date: Tue, 15 Aug 2000 17:34:43 -0700

Bob,

How does the GroupWise client handle revocation and trust points?

Is the root of trust the Novell directory?

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]]
Sent: Monday, August 14, 2000 9:09 PM
To: [email-masked]
Cc: [email-masked]; [email-masked];
[email-masked]
Subject: Re: Client-side revocation checking capability

Al, I don't disagree with you, but then I don't distribute the popular
browsers or control what their defaults are, either.

All that I was trying to say was that there are, substantive reasons to
believe that the CRL "cure" may be worse than the disease, at least with
respect to the current use of PKI consumer e-commerce sites. that's not to
say that other applications may not have different trade-offs and criteria.

Without making too big a deal of the whole issue, I think it is important to
realize that the goal of PKI is to reduce risk to an affordable level, NOT
necessarily to try to reduce that risk to absolute zero, regardless of cost.

Bob

Bob, et alia:

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

Bob Jueneman wrote:
> CRL checking certainly seems like a nice thing to do cryptographically,
until you consider what the threat is that you are trying to address.
> 
> Let's suppose amazon.com's key were compromised somehow. What would
happen?  Well, the first thing is that they would call up their CA and get a
new certificate, and then download that certificate to any SSL user. So the
old certificate and key would be completely out of the picture, and hence no
CRL would be needed, much less OCSP.  since they don't use that certificate
to sign anything other than SSL sessions, which in which the certificates
are sent in line, they don't even need to revoke their old certs -- just
stop using them.
> 
> The only case where a CRL might be useful in that scenario would be in the
case of some fly-by-night mafia.com type of store-front, where the CA might
conceivably revoke the certificate for fraud or other cause. However, that
would represent a substantial legal liability for the CA, and so that
doesn't seem terribly likely in practice.
> 
> Since the retail merchant accounts for the overwhelming use of PKI to date
(e-mail is just barely beginning to make a dent, and everything else are
just pilots, it isn't surprising that the browsers don't enable CRL checking
by default. It would merely add lots of delay and processing time.

---

From: [email-masked]
Date: Wed, 16 Aug 2000 10:13:33 -0700

actually I believe in CERTS containing some amount of "account" data that can be
used in offline environments when access to the account record is not available.
In that sense, for business applications that are account record oriented, CERTS
can provide a stale (possibly subset) of what might appear in the business
account record.

however, in an online model where a transaction or message has to "hit" the
account record in any case, it is possible to obtain the public key from the
"master" in the account record ... w/o having to bother with an account record
substitute represented by a CERT (i.e. a certification authority has a master
account record someplace with most/all information that went into a CERT ...
along with audit trails and other business requirements that are ordinary part
of business account transaction).

In the DNS case, lack of trusted DNS is even a problem for certification
authorities issueing SSL certificates ... since the domain name "authority" that
the certificationa authority has to reference to validate the information to put
in a CERT ... is the same untrusted DNS infrastructure (as some of the comments
about domain name hijacking represents).

Part of the solution for created a trusting domain name "authority" operation is
to add public keys and digital signature authentication to DNS operation. That
would even closes integrity  "holes" that SSL certificates have because the
authority for the domain information that goes into the SSL certificates can now
be trusted.

My observation is just that with the addition of public keys to domain name
infrastructure ... then the DNS operation not only "hits" an online account
record ... but also one that may include the trusted public key (part of making
the entry trusted and harder to hijack). DNS already supports returning all
sorts of information in addition to host names to ip address mapping ... so the
ability of returning such public keys as part of a trusted DNS operation is
straight forward.

At this point, all DNS operations now could provide both trusted address mapping
and public key binding as part of each online operation. Such a facility would
then make the majority of existing server-side SSL certificates superfulous and
redundant.

The side observation is there is a requirement for such a trusted DNS
infrastructure ... just to improve the integrity of existing server-side SSL
certificates (i.e. problem with hijacking host name and then obtaining a SSL
certificate since the certification authority has to resort to using the DNS
infrastructure as the authoritative entity for validating DNS information). But
addressing that requirement then also makes the need for such servier-side SSL
certificates superfulous and redundant.

Stephen Kent <[email-masked]> on 08/15/2000 01:30:47 PM

To:   Lynn [email-masked]
cc:   [email-masked]
Subject:  Re: Client-side revocation checking capability

Lynn,

I agree that a PKI based on the DNS would be a great benefit to the
Internet. Now that VeriSIgn has bought NSI, the likelihood of
creating such a PKI seems remote, as it would create a decentralized
PKI that would challenge the VeriSign TTP model.

DNSSEC makes use of non-certificate constructs (for understandable
reasons having to do with DNS security details), that are not really
a good substitute for real certs.  Of course, you're a strong
believer in no certs at all, so I'm not surprised that you would find
DNSSEC a suitable alternative all by itself :-).

Steve

---

From: "Bob Jueneman" <[email-masked]>
Date: Wed, 16 Aug 2000 12:09:24 -0600

Peter,

The current GroupWise S/MIME functionality is built upon the capabilities
provided by IE5 and MS-CAPI, unlike other Novell applications 
which use our NICI crypto and are more tightly integrated with NDS.  
The currently shipping version of GroupWise does not support CRLs, 
although I believe that functionality will be included in the forthcoming 
release, later this year.  Because of the more or less common infrastructure, 
plug-ins for other revocation/validation models, e.g., ValiCert's, should be 
straight-forward, assuming there is sufficient user demand.

Since GroupWise shares the same underpinnings as IE5, we have both 
some of the same benefits and same problems as the existing browsers.

In particular, looking forward a couple of years, I can foresee a chaotic
situation where every organization on the planet want to have their own
"root" CA, and the browsers and e-mail clients simply collapse under the 
weight of the trust administration.  The single PEM-type of hierarchical structure
obviously isn't going to work, but an unconstrained explosion of trusted roots 
isn't going to work either.  Some commercial CA's will fail to gain sufficient
acceptance, and others will just be ignored.  If the existing TTPs are not
willing to enable the use of subordinate CAs (some are and some aren't,
for obvious business reasons), then an opportunity will arise for others to
take on this responsibility. one way or the other, though, some coalescing 
of CAs is going have to take place before very long.

From my point of view, the existing PKI and validation structure has been
perhaps excessively focused on the role of the subscriber and the CA
and the identity function, and not enough attention has been payed to the 
management of the basic, underlying TRUST relationship by the relying party.

For that reason, we are looking carefully at the use of the directory to provide 
local mediation and enterprise control over the trust relationships at the relying 
party end.

Case in point, lets say that a hospital decides to revoke a Doctor's staff privileges,
perhaps because a few too many of his patients have been dying. Not only
do they not want him in the operating room, they don't want him reviewing patient 
records, issuing prescriptions or medical orders, etc.  Most of those issues only 
involve access control, not nonrepudiation.

Now, does the hospital care what say VeriSign thinks of that Doctor's credentials,
or even the State of Utah? Clearly not.  So CRL checking isn't the answer for 
managing _trust_, because the issue isn't identity, and it isn't key compromise either.

An attribute certificate issued by the hospital, as opposed to an identity broker,
might be the solution, but frankly just getting identity certs deployed and working
has been a sufficient challenge.  And it is really hard to imagine every hospital, 
pharmacy, HMO, etc., issuing their own individual attribute cert to every doctor,
complete with their own revocation structure.

This might be necessary if nonrepudiation were really an issue, but in most of
these cases it probably isn't.  In that case, a local directory can be used as the 
relying party's Delphic oracle with respect to privilege, and it may also be used to
cache certificates and CRLs to minimize the computational load and bandwidth
requirements.

Where CRL checking does have a role to play in this environment, I believe, is
in the case of extranet access control., In this case Enterprise A may issue identity 
certificates to one of their employees, perhaps using the Novell Security Attributes to 
confirm that Dr. Doakes is a doctor.  Enterprise B, assuming they have a relationship 
with Enterprise A, may accept Dr. Doakes certificate as sufficient evidence of his
credentials and allow him access to certain files, based only on his certificate and 
Enterprise A's say so (while of course auditing his actions based on the name in his 
certificate).  In that type of scenario, Enterprise B would be relying on Enterprise A
to revoke Dr. Doakes certificate if he is no longer working for them.

But that revocation could take the form of a CRL, or alternately a directory status 
update. Each enterprise probably doesn't want to take on the management
burden of managing the entries in the directory for all of the employees in the
other enterprise, but they might be willing to accept the burden on an exception
basis.

Bob

>>> Peter Williams <[email-masked]> 08/15/00 06:34PM >>>
Bob,

-----Original Message-----
From: Bob Jueneman [mailto:[email-masked]] 
Sent: Monday, August 14, 2000 9:09 PM
To: [email-masked] 
Cc: [email-masked]; [email-masked];

Bob

Bob, et alia:

			Al Arsenault
			Chief Security Architect
			Diversinet Corp.

---

From: Warwick Ford <[email-masked]>
Date: Wed, 16 Aug 2000 18:26:20 -0700

Dennis:

You are referring to T&C related to a particular type of certificate issued
by VeriSign in a particular TTP capacity.  Our other PKI service and
technology offerings have their own contractual T&C.  This is not a
particularly unusual situation for vendors that offer many different types
of products.....

Warwick

> Sent: Wednesday, August 16, 2000 4:10 PM
> To: Stephen Kent
> Cc: Warwick Ford; [email-masked]; [email-masked]

[snip]

> And, if you follow www.verisign.com/repository/RPA/, which is 
> embedded in my Verisign personal certificate as a pointer to 
> their CPS, you will find:
> 
> * You are responsible for deciding whether the 
>   information in the certificate is relevant.
> 
> * If you are not a Verisign customer (e.g., 
>   some dummy connecting to a Verisign certified 
>   e-commerce site such as Amazon.COM), and you 
>   want to check for revocation, then you must 
>   agree to their CSP if you want to use their 
>   online services.
> 
> So much for Section 1, Section 2, which covers CRLs, is equally 
> interesting. However, Section 5 says, as a non-subscriber, that 
> Verisign doesn't warrant certificate merchantability, fitness, 
> or the accuracy of information. Then, of course, you won't hold 
> Verisign liable in any way.
> 
> So I see little value in Verisign certificates, infrastructure, and
> technologies; and any effort by Verisign to "secure DNS" of dubious
> value and a bit frightening. 
> 
> Marketing, yo!
>

---

From: "David P. Kemp" <[email-masked]>
Date: Mon, 28 Aug 2000 19:41:45 -0400 (EDT)

Reminds me of the blurb for a new fall TV series:

Student:  "You mean we should go online [to check the facts on a murder]?"
Reporter: "No, I mean you should put on your socks and shoes and walk
            down to the police station."

A CA doesn't have to resort to using DNS to validate the legitimacy of
requests for certificates containing DNS names.  In fact, there is no
point in doing so - DNS maps names to IP addresses, certificates map names
to public keys.  Finding a DNS record, hijacked or not, doesn't give a
CA any assurance that a public key belongs to the owner of the name.

Certs-by-email are cute toys for users to play with, but any merchant
using such a cert shouldn't get an "XYZ seal of approval" from any
legitimate XYZ auditing organization.  The value added by a CA who
checks with D&B and WIPO before issuing a server cert is nearly
orthogonal to the value added by secure DNS (at least until DNS
administrators publish their CPSs).  And even if the CA and the DNS
used identical identity proofing procedures, independently-issued
name-to-key and name-to-IP certificates provide additional assurance.
Maybe overkill for some applications, but certainly not superfluous and
redundant.

Dave

> From: [email-masked]
> Date: Wed, 16 Aug 2000 10:13:33 -0700
>

---

From: [email-masked]
Date: Tue, 29 Aug 2000 20:52:43 -0700

a relying party presumably executes some protocol initiation, signing
validation, certificate validation, etc. after all that is done, the relying
party can compare some "bound" information in the certificates with something
that the relying party may be assuming and/or expects.

If the relying party is expecting a specific business name ... they could check
if the business name in the certificate matches the business name they are
expecting. They might also have some expectation as to the due dilligence that
the certification authority exercised in validating that information (for
business names ... possibly checking with D&B).

Now looking at possibly a trivial occurance of relying party checking ... maybe
only a trivial 99.99999999999999% of all relying party "checking" currently
going on ... it would appear that the most common occurance of a relying party
checking something is a SSL relying party checking a domain name.
99.999999999999% of all such checking might not seem like a valid situation to
consider.

Now if the most common client-side validation of certificate information (only a
trivial 99.9999999999999% of all such checks) involves domain name checking ...
then clients might expect that certification authorities would be checking some
authority that is involved in registering domain names.

Now, it is possible that certification authorities might check with their local
police station with regard to who has registered an internet domain name ... or
they could check with D&B ... or they could check with all the agencies in the
world which are explicitly not part of registering domain names.

Frequently I've heard reference to one of the reasons for certificates in the
SSL protocol is because of weaknesses in the domain name system ... which can be
corrected by SSL domain certificates issued by certification authorities ... who
may have check with the domain name registration authority as to the validity of
the domain name (or on the other hand could have just checked with their local
police station as to who owns a particular domain name). A minor issue if the
domain name system is weak ... then it also is weak as an authority of
certification authorities to check the information that they supposedly need to
be correct (but which the domain name infrastructure can't be trusted to verify
as correct????).

So some of the proposals are to add public key registration to the domain name
process. That makes it harder to hijack domain names and leads to a more trusted
domain name system. Given a trusted domain name system with public keys, then
the domain name system could return the public key (associated with a domain
name) at the same time it returned the IP-address. However, if a trusted domain
name system returned a public key as part of the domain name process, then
having an SSL domain name certificate with a public key would seem to be
superfulous and redundants (at least as far as the trivial SSL case under
consideration).

SSL certificates are somewhat a catch-22 ... some believe they exist because of
untrusted DNS ... however the SSL certificate certification authorities would
appear to be dependant on an untrusted domain name system as the authority for
the domain name information that they place in SSL certificates ... creating a
trusted DNS with the addition of public keys ... allows the real-time DNS domain
name infrastructure to the real time authority of public keys for an SSL
protocol as part of the standard domain name process. In this particular
scenerio, SSL certificates would appear to be superfulous and redundant (aka it
isn't necessary to have a certification authority manufactor a stale certificate
with stale bound information ... when a trusted DNS is providing real-time
information).

That doesn't say that all certificates with public keys are redundant and
superfulous ... just the apparent most common scenerio ... at least in terms of
relying party/clients validating information ... possibly only a trivial
99.99999999999% of the cases (the SSL scenario). If the relying party isn't
doing something on the internet and requires little or no IP services (including
DNS) ... but still needs some authentication process, then certificates could
address the opportunity.

One could do SSL with an ip-address ... rather than a domain name ... and bypass
the (real time) domain name system alltogether and rely on stale information in
manufactored certificates. Hopefully the certification authority would be
checking some internet ip-address authority (rather than the local police
station).

"David P. Kemp" <[email-masked]> on 08/28/2000 04:41:45 PM

Please respond to "David P. Kemp" <[email-masked]>

To:   [email-masked]
cc:    (bcc: Lynn Wheeler/CA/FDMS/FDC)
Subject:  Re: Client-side revocation checking capability

Dave