Subject: Re: Huge CRLs

From: [email-masked]
Date: Fri, 10 Sep 1999 14:08:30 EDT

Thanks Steve,

I will reply with specifics (technical) tonight.  Thanks for not ignoring me 
because  of the *.aol.com thing (I am stuck using my family AOL account 
because 3 of my servers (and domains) are often down (my ISP is killing me 
and I will return the favor when I return to home base) and AOLmailservers 
are never down.

I work closely with some of the earliest commercial x509 players and some of 
the folks who have done early implementations (govt and commercial pkis) and 
most of them freely acknowledge that the practical requirements and 
approaches necessary to practice policy compliant PKI in a realworld setting 
is nothing like their early imaginings [zero criticism applicable].   The 
true test of brilliant ideas is not whether they are implemented and built 
into practical life as a whole and as originally imagined, but that they 
become relied upon parts of production systems in practical applications.  
Everyone involved in the early days has contributed a lot of time, money, 
great ideas, and technology.  To a person they should feel good about their 
work.  Foresight cannot be 20 20 and no one can be blamed for vision issues 
that could not be anticipated.

However, having architected and directed implementation of infrastructure and 
enterprise PKIs and after stress testing most of the technology solutions, I 
am comfortable saying that it is often quite difficult and in some cases 
practically infeasible to make the technology solutions support business and 
policy requirements.  This must change and I am confident that it will if 
people and companies are open to customer input and innovation.  

Revocation is one of the most critical problems that must be addressed and 
tons of smart people are working on it.  Some of my team/partners/members are 
spending nearly all of their time trying to make revocation work the way we 
need it to work.   The financial services sector is providing significant 
input on requirements, technology, and resources to try to make PKI work for 
us.

No offense intended, but the nature of our businesses and the limitations of 
the technology do not lend themselves to the use of CRLs.  The how and why 
will have to wait for a later message (tonight).

...kawika daguio...

---

From: Stephen Kent <[email-masked]>
Date: Sat, 11 Sep 1999 11:52:36 -0400

>will have to wait for a later message (tonight).

Not all the world is the financial services sector.  Criticisms of CRL use
models based primarily on difficulties encountered in employing them in
that environment, or based on poor implementations, or based on poor
management parameter choices, etc.  do not necessarily mean that CRLs are
unworkable.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Sun, 12 Sep 1999 23:15:59 -0700

> management parameter choices, etc.  do not necessarily mean that CRLs are

CRLs, which were first thought to be a positive aspect of relying on CAs
as compared to PGP for instance, presents several unsolvable problems.

For example, there may be a considerable delay (no warranties can be
found on on CAs contracts about upper limits for such delays) between the
actual need to revoke a certificate and the reflection of this need in a
certificate chain with different CAs.

Also, requiring the user to check with a CA before sending a message
makes the use of multiple CAs much more difficult, unless they can be
convinced to work together, an interesting problem for competing
businesses.  Constant checking with a single CA also makes traffic
analysis much easier. Even if the attacker cannot intercept the
message which is sent, if the attacker can monitor the central CA
(with a single administrative order and a GAKware system to circumvent
any encryption), everyone's communication patterns can be seen.
Also, an attacker can fool a CA into revoking a key -- a denial of service
attack.

Further, the major X.509 security application today, SSL, does not
check revocation lists -- so they are near to useless. Also, the user is
not able to check server certificates (and certificates in the CA chains)
against revocation lists.

An examplary case regarding  CRLs, is that they are a will to revoke but
not an actual revocation. Few recognize that CRLS are a solution to a
non-existent problem ... while the real problem is left utterly unsolved. The
non-existent problem solved by CRLs is how to communicate that a
certificate is no longer valid ... because if a certificate were really no
longer valid (as it should be) then no one would need to find a CRL
to know about it.

Cheers,

Ed Gerck
______________________________________________________________________
Dr.rer.nat. E. Gerck                                    [email-masked]

---

From: Ben Laurie <[email-masked]>
Date: Mon, 13 Sep 1999 10:34:16 +0100

> against revocation lists.

That depends on the implementation. It is entirely possible for an SSL
implementation to check CRLs, and some do.

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to try to be in the
first group; there was less competition there."
     - Indira Gandhi

---

From: Ed Gerck <[email-masked]>
Date: Mon, 13 Sep 1999 04:33:25 -0700

> implementation to check CRLs, and some do.

In SSL, the client knows which CAs are acceptable *to the server* for signature
validation and CRL verification because the server *sends* a list of distinguished
names in the "certificate request" message. However, there is no corresponding
list sent in the other direction in SSL (from the client to the server).  Thus,  the
server is essentially groping in the dark when trying to supply a certificate that
the client can check for its CRL, because the server is not informed by the client
what CAs to best aim for in a ranking list  (CAs that are directly trusted by the
client for signature and CRLs, untrusted CAs directly trusted by a CA that
the client trusts, etc.).

So,  SSL indeed does not offer a mechanism to allow clients to effectively check
CRLs for server certs.  Thus, as I commented, "the user is not able to check
*server certificates* (and certificates in the CA chains) against revocation lists"
-- BTW, as we can see in current browsers.

But, your remark does apply to client certs that are sent to the server and I am
thankful for your clarification.  The major use of SSL is however in securing
servers and in this case CRLs are oftentimes useless for clients.

BTW, my text was a segment from the paper "Overview of Certification Systems"
at http://www.mcg.org.br/certover.pdf -- and even though there the context of
users checking *server certificates* seems clear throughout, I will further clarify
it with your comment in mind.

Thanks,

Ed Gerck

---

From: Ben Laurie <[email-masked]>
Date: Mon, 13 Sep 1999 13:37:25 +0100

> it with your comment in mind.

But since most SSL servers have but a single certificate, surely all the
client has to do is check the CRL once it has received the server
certificate?

Cheers,

Ben.

---

From: "Phillip M Hallam-Baker" <[email-masked]>
Date: Mon, 13 Sep 1999 13:16:45 -0400

> management parameter choices, etc.  do not necessarily mean that CRLs are

Steve,

	I agree with your sentiments but I would prefer to see you saying
something of the form 'this argument is irrelevant' or 'this argument
is unproductive'.

	We have already argued the case for supporting both online
and blacklist style revocation. There are applications in which both
approaches have specific advantages which may well prove critical.

	I don't see how the current argument is going to lead to any
substantive change to the WG drafts or RFCs. We have already advanced
both sets of drafts to proposed standard status. 

	Tempting though it may be to answer the numerous minor and minor
fallacies in the argument presented I suggest that we just refer the
combatants to the discussions we had on this topic over a year ago. 

		Phill

---

From: Ed Gerck <[email-masked]>
Date: Mon, 13 Sep 1999 10:34:09 -0700

> client has to do is check the CRL once it has received the server

The first interesting question raised here is that of trust -- I cannot assume
or favor the notion that there is only one CA that the client MUST trust,
which  CA is by the way the ONE that the *other party* (the server) has
chosen ;-)

So, since SSL does not offer a client-mechanism to decide who to trust for
what, and since this also translates into an anti-competitive issue built right
into the SSL protocol, I see then that the decision of trust is, from the first
moment, removed from the client. Both for certificates and for CRLs -- which
would not have to be provided the issuing CA.  So, there is a second decision
of trust removed by the SSL protocol -- the server and the client have no
choice for VA and must use the issuing CA.

So, where should the client look for the CRL? At the CA site that the client does
not trust?  Or, cannot reach?  What URL? How about redundancy, alternatives?

The conclusion IMO is that which I commented first, but edited to stress the
client context. That the major X.509 security application today, SSL, does not
allow the client to check revocation lists that the client trusts -- so they are near
to useless. Also, the client is  not able to check server certificates (and certificates
in the CA chains) against client-defined revocation lists (VAs, for example).

The alternative for the client is to proceed manually, outside of SSL. But, we
know, users do not have the training to use a complicated secure procedure
if a simpler and unsafe procedure is just a click away.

For the server, however, SSL affords a better procedure since the client knows
which CAs the server trusts for what, as I commented above

Cheers,

Ed Gerck

---

From: Ben Laurie <[email-masked]>
Date: Mon, 13 Sep 1999 19:20:40 +0100

> which  CA is by the way the ONE that the *other party* (the server) has

That is irrelevant. The client can choose to trust or not trust the CA.
Whether they do is orthogonal to the question of CRL checking.

> in the CA chains) against client-defined revocation lists (VAs, for example).

That is not what you said. You said that there was no way for the client
to check CRLs, not that there was no way to check CRLs that the client
trusts. Furthermore, if the client trusts the CA, then they should trust
the CRL. If they do not, then it hardly matters whether they check it or
not, since they don't trust the certificate anyway.

> which CAs the server trusts for what, as I commented above

Again, this is a sidetrack: the client can also choose which CAs it
trusts. The fact that it does not communicate them to the server is a
different matter.

Cheers,

Ben.

---

From: Daniel Alex Finkelstein <[email-masked]>
Date: Mon, 13 Sep 1999 15:27:16 -0400

> management parameter choices, etc.  do not necessarily mean that CRLs are

Thank God for that! What a boring world it would be if everyone was a banker.

But the importance of privacy and cryptography to financial services cannot be
overlooked or ignored. It is no coincidence that the largest drivers of
cryptography deployment have been banks and investment firms (and markets). Just
recently, only banks were allowed to distribute greater-than-export strength
crypto for their clientele.

If CRLs are unsuitable for that environment, they should be tweaked until they
are suitable (or until another means of similar functionality is developed).
Ignoring this very large share of the market would be foolish; if you do, you'll
lose a lot of customers. After all, PKI has been around for a while now and still
hasn't "taken off." Many of us believe that PKI as we know it isn't "it," and
something else will inevitably turn up that succeeds where PKI failed. Vendors
clearly haven't produced anything usable for this sector, leaving the firms
themselves to develop next-generation security. And why shouldn't we be
successful? We've done it before.

--
Daniel Alex Finkelstein
Shared IT Services
phone   212-383-2951
pager   917-427-1630
fax     212-383-3289
Securities Industry Automation Corporation

---

From: "Ambarish Malpani" <[email-masked]>
Date: Mon, 13 Sep 1999 17:04:04 -0700

Hi Daniel,
    I would think OCSP (and for that matter, CRTs) is such an
alternative (tweaking of) to CRLs. Were you thinking about that
in your mail?

Regards,
Ambarish

P.S.
For those who might not have been following PKIX actively over the
last few months - there is a protocol - OCSP (RFC 2560) that
enables rapid checking of the revocation status of certs, without
the overhead of needing to download full CRLs. It is currently
being used in quite a few pilots (including some at banks) and even
in a production environment in a few places.

CRTs are a proprietary method to implement OCSP in a more scalable
and secure way.

---------------------------------------------------------------------
Ambarish Malpani
Architect                                    650.567.5457
ValiCert, Inc.                            [email-masked]
1215 Terra Bella Ave.                       http://www.valicert.com
Mountain View, CA 94043-1833

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, September 13, 1999 12:27 PM
Cc: [email-masked]
Subject: Re: Huge CRLs

Stephen Kent wrote:
Not all the world is the financial services sector.  Criticisms of CRL use
models based primarily on difficulties encountered in employing them in
that environment, or based on poor implementations, or based on poor
management parameter choices, etc.  do not necessarily mean that CRLs are
unworkable.
Thank God for that! What a boring world it would be if everyone was a
banker.
But the importance of privacy and cryptography to financial services cannot
be overlooked or ignored. It is no coincidence that the largest drivers of
cryptography deployment have been banks and investment firms (and markets).
Just recently, only banks were allowed to distribute greater-than-export
strength crypto for their clientele.
If CRLs are unsuitable for that environment, they should be tweaked until
they are suitable (or until another means of similar functionality is
developed). Ignoring this very large share of the market would be foolish;
if you do, you'll lose a lot of customers. After all, PKI has been around
for a while now and still hasn't "taken off." Many of us believe that PKI as
we know it isn't "it," and something else will inevitably turn up that
succeeds where PKI failed. Vendors clearly haven't produced anything usable
for this sector, leaving the firms themselves to develop next-generation
security. And why shouldn't we be successful? We've done it before.

---

From: "Daniel Lanz" <[email-masked]>
Date: Tue, 14 Sep 1999 10:57:23 -0400

>CRTs are a proprietary method to implement OCSP in a more scalable

Ambarish,

How do CRTs make OCSP more secure?

Regards,

Dan Lanz

---

From: Ed Gerck <[email-masked]>
Date: Tue, 14 Sep 1999 13:45:59 -0700

> Whether they do is orthogonal to the question of CRL checking.

In some reliance models, a CA can be trusted as much but no more than the
CRL checking service they provide.

> trusts

I guess you understood well what I said in the first time.  Now, you just
need to understand what is the worth of checking distrusted CRLs.

As I wrote some two years ago (URL certover.pdf) and still valid even
if the CRLDistributionPoint is specified in the server certificate and is used at
the client -- in SSL, the server is neither informed by the client what CAs to best
aim for in a ranking list  (CAs that are directly trusted by the client for
signature and CRLs, untrusted CAs directly trusted by a CA that
the client trusts, etc.), nor offers the client a list of CAs for the client to
choose which CA is trusted for what.

So, if we agree that checking distrusted CRLs is as worthless as
checking distrusted certificates, then I guess we achieved closure.
And, clearly, a confirmed conversation with a thief is not secure just
because it is confirmed by the thief himself.

> Furthermore, if the client trusts the CA, then they should trust
> the CRL.

No, these two issues are like apples and speedboats.  Are you familiar
with VAs?

> If they do not, then it hardly matters whether they check it or

The trust in a certificate signed by a CA is a decreasing function of time
as I have exemplified elsewhere, for a variety of reasons, more than two
years ago. Thus, a certificate may be trusted with some reliance bar
for a certain time limit after issuance even without any regard to CRLs,
but not afterwards (on an average basis).  So, it DOES matter whether
the CA is trusted for certificates *and* CRLs or only trusted for
certificates -- as a function of how "stale" the certificate is.

> trusts. The fact that it does not communicate them to the server is a

Again, this discussion indeed seems like others we had.  But, "to be able to
choose" must mean to *have* a choice.  And, in current SSLv3, the client
has no choice for server CA and cannot communciate to the server which
CAs the client is willing to trust for what order of validation chains -- instead,
the client must accept the only option that the server provides, and must do
so also for the CRLs of  that certificate even when the CRLDistributionPoint
is specified by that server certificate and used at the client.  ;-) Sorry, but the
client's choice here is to have no choice, twice.

Cheers,

Ed Gerck

---

From: Ben Laurie <[email-masked]>
Date: Tue, 14 Sep 1999 22:18:19 +0100

I agree that the issue of trust is not necessarily well addressed by
X.509. However, in the case where the client does trust the CA, then
there is a point in the client checking the CRL. In the case where the
client does not trust the CA, then it matters not whether the CRL is
checked or not. If the client wants choice about which CA to trust, then
the server can choose to provide that choice, by, for example, using
different domain names for difference CAs. This may not be ideal, but it
addresses real-world cases that people want addressed, and it is
available now.

That there are other needs that are not addressed is interesting, but
does not mean we should reject the use of CRLs, X.509 or SSL.

Actually, my main interest in CRLs is for servers to check clients,
anyway.

Cheers,

Ben.

---

From: "Ambarish Malpani" <[email-masked]>
Date: Tue, 14 Sep 1999 14:36:46 -0700

Hi Daniel,
    Basically, with OCSP, the responder needs to have its key
available online to sign responses (you can mitigate this risk to
some extent by having a proxy between your responder and the rest
of the world, but it is still an issue). So you need to make your
responder available for people to talk to, but if anybody ever
manages to break into your responder and get access to your private
key, your whole OCSP response system is open to compromise.

With CRTs, you can acctually have the Tree Issuer be separate from
the CRT responders. The Tree Issuer has access to your CRT private
key and can create new CRTs, which it then distributes to one or
more CRT responders (which don't have the highly trusted private
key), which actually provide the CRT responses.

Hope this clarifies the issue,
Regards,
Ambarish

> From: Daniel Lanz [mailto:[email-masked]]
> Sent: Tuesday, September 14, 1999 7:57 AM
> To: 'Ambarish Malpani'
> Cc: [email-masked]
> Subject: RE: Huge CRLs
> 
> 
> 
>

---

From: Ed Gerck <[email-masked]>
Date: Tue, 14 Sep 1999 14:53:16 -0700

Ben Laurie wrote:

> there is a point in the client checking the CRL.

Yes, but perhaps not from that CA. Issuance and revocation are quite
disjoint and there is information-value as well as trust-value in using
different channels for revocation (yes, even more than one for
revocation in different reliance modes).

> In the case where the

Yes, this is also my opinion.  That is why we need to identify the
problems, not just because it is interesting but also so that we can either
solve them or provide work-arounds.

> Actually, my main interest in CRLs is for servers to check clients,

I imagine ;-) And SSL does offer the needed feature in this case, as
commented some emails ago.

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Sep 1999 15:09:26 -0400

Ed,

>certificate chain with different CAs.

There also may be considerable delay between a compromise and discovery of
a compromise, which intrduces delay into ANY revocation method, not just
CRLs.  Many factors influence how quickly revocation activities will
proceed, many are adminsitrative and not influenced by the choice of
method, e.g., CRLs or OCSP.  In some systems with which we have experience,
these administrative delays take longer, in aggregate, than the mean time
between CRL issuance, suggesting that the use of CRLs is far from the
limiting factor in determining timeliness of revocation notification.  As
for a warranty re timeliness, I think it more relevant to note that several
major CA service providers offer daily CRL issuance, and some issues new
CRLs as often as every 6-12 hours.

>Also, an attacker can fool a CA into revoking a key -- a denial of service

First, one does not "check with a CA" under the traditional CRL model.  One
accesses a directory to acquire CRLs and if directories cache data, one
might access a single directory to acquire CRLs for more than one CA.
Monitoring of CRL: fetches provides some info about communication patterns,
but with local caching, the granularity of this info is not very fine,
e.g., someone at organization X requested the CRL for organization Y.  Many
users at X might then access the cached copy of the CRL prior to sending
messages to a variety of users ar Y.  Finally, one of the reasons that
revocation is often NOT instantaneous is that CAs usually require some form
of authentication by a party requesting revocation, precisely to counter
the denial of service attacks.

>against revocation lists.

I think you are confusing SSL, the protocol, vs. implementations of SSL
(and https, in browsers.  Browsers have a number of defects in their
handling of certs, but it is not accurate to attribute this to SSL.

>longer valid (as it should be) then no one would need to find a CRL

I just love these philosophical musings ...

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 15 Sep 1999 15:33:31 -0400

Ed,

>which  CA is by the way the ONE that the *other party* (the server) has

In general, two parties are free to choose different CAs as issuers of
their respective certificates.  Thus each party always has to work to find
a path for validating the other party's certificate.  Why is this news to
you, Ed? (By the way, you continue to equate SSL with the cert processing
implemented in the two major browsers, which is inaccurate.)

A client can elect to accept the "root CAs" preconfigured into his browser,
or can remove them and add new ones after performing whatever form of
review that the user deems fit.  Thus a client has the ability to specify
the set of CAs that he will accept as a basis for validating server certs.
In practice, though, only three root CAs issue certs to servers in the
public environment, and just one of these (Verisign) issues the vast
majority of these certs.  So, if one were to choose to not accept server
certs issued by Verisign, one would not be able to communicate security
with many servers that make use of SSL.

>choice for VA and must use the issuing CA.

Your first assertion here is correct, i.e., a shortcoming of the browser
(not SSL) cert processing is that it does not allow one to specify which
CAs are trusted to vouch for which certs, something that can be better
managed with the use of the NameConstraints extension. However, given the
TTP model on which secure access to public web sites is based, this
extension would not help much.

>which CAs the server trusts for what, as I commented above

PKIX specifies a means, the AIA extension, that allows a cert to point to
where to look for the CRL on which it would appear.  Unfortunately, this
facility has not been used in this environment, perhaps because of the lag
between standards development and software development, but maybe it will
be utilized in the future.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Wed, 15 Sep 1999 14:13:28 -0700

> handling of certs, but it is not accurate to attribute this to SSL.

No, Steve, I am not confusing either or even both ;-) Pls check the list archives
for my exchanges with Ben on this thread, especially those with subjects "Re:
Trust and client choices, was Re: Huge CRLs".  At least, Ben and I agreed --
which I must say does not happen so often ;-)

Cheers,

Ed Gerck
______________________________________________________________________
http://www.mcg.org.br/authors/eg.htm                    [email-masked]

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 15 Sep 1999 14:45:52 -0700

> From: Ed Gerck [mailto:[email-masked]]
> Sent: Wednesday, September 15, 1999 2:13 PM
> To: Stephen Kent
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: Re: Huge CRLs
> 
> 
> 
> 
> Stephen Kent wrote:
> 

SSL does not involve certificates, if you read the design carefully. Its
processing is independent of the key distribution mechanism; any valid
means of distributing asymmetric keys is acceptable. Cipher suites
do not bind to any particular method of key distribution, in general.
(some of the poorer specification bind cipher suites to kerberos, 
breaking the architecture though; on well, purity has no value of 
itself.)

https is indeed a distinct protocol from SSL. its specification
is "fluid", and is well now well into its 5th version. Its defined largely
as that which Netscape and Microsoft web client/servers are 
interoperable on, with options and value add on each side. Use of 
SSL for secure data conferencing,  white boarding authorization, etc
and  other uses are not standardized. The securing
of the FrontPage protocol is similarly not standardized. These
all have security protocols built over and above SSL layer protocols,
like https.

It may be time to standardize https which is a hypermedia security
service, is really quite complex, and addresses framed security
contexts, multiple sessions, connection teardown, host-id
selection of keying material on the server, and various other
matters peculiar to stateless web behavior in the context
of hypermedia documents. It goes way beyond  just securing the 
TCP channel over which  http messages are exchanged with an few
integrity/confidentiality keys.

The integration of certificate validation with https (forming 
https "5"  if you  like) is an ongoing task, some of which was 
deployed with IE5. It may be better to use w3c to standardize
https, given its hypermedia orientation, however. IETF is
not too good at web stuff. One can perhaps expect https 
"6" to address XML signatures on the media items
that https governs and interacts with, now that these 
are gaining wide acceptance.

---

From: Ed Gerck <[email-masked]>
Date: Wed, 15 Sep 1999 16:36:05 -0700

Peter Williams wrote:

> SSL does not involve certificates, if you read the design carefully.

Sorry to disagree in part, Peter, but the client knows which CAs are acceptable to the
server exactly because SSL does not ignore certificates (would that qualify as involve?).

First, the server can indeed send a message with a list of distinguished names  in the
SSL "certificate request" message to the client.  If SSL would ignore certs or not involve
them then this list of *certificate request* would have no reason to exist, no?  Second,
if we see what happens protocol-wise in SSL when the client replies  to this SSL message,
we will see that SSL reacts differently as a function of the *certificates* sent by the
client.

However, there is no corresponding list sent in the other direction (from the client to
the server) as allowed by the SSL protocol.  The effect of this **SSL asymmetry** is
that which I summarized above: SSL does not [allow the client] to check revocation lists
[that are meaningful to the client].

The interpolations above, within [ ], are all in the text I cited for context, at
http://www.mcg.org./br/cert.htm -- already some two years ago and still
valid.  I had no intention of being sloppy or msileading in my remark, just to save
space by providing the context by reference... a common technique used in
CAs' CPS ;-)))

> of hypermedia documents.

Agreed and let's not forget TSL as another element of this letter soup. But
SSL (TSL) is a tool used in https, which means that one should *first* deal
with some SSL (TSL) quirks like the client-server certificate choice
asymmetry I mentioned.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Wed, 15 Sep 1999 17:00:31 -0700

> CRLs as often as every 6-12 hours.

Still, all that you say offers no justification (besides denying liability for it) why
couldn't CAs provide upper limits for *their* delays.  Forget about "discovery delay"
and other things that you mention and which I consider philosophical since they can
never be even estimated, and forget also about how often will the CA issue the
same stale CRL (maybe, even every second if you wish).  The point I mentioned
above is the delay between a need to revoke a cert (which need is materialized at
the CA as request to revoke, of course), and the reflection of this need in a
certificate chain with different CAs.  This is the real-world issue here -- and one
which is not addressed.

> First, one does not "check with a CA" under the traditional CRL model.

Neither did I say so -- but, requiring it won't be so useful because it makes
the use of multiple CAs more difficult and so on.  So, back to point one.

[The other topic you mention, on SSL vs. browsers, was already discussed
in my previous specific reply.]

Cheers,

Ed Gerck

---

From: "Peter Williams" <[email-masked]>
Date: Wed, 15 Sep 1999 18:00:34 -0700

> Sent: Wednesday, September 15, 1999 4:36 PM
> To: Peter Williams
> Cc: [email-masked]
> Subject: Re: Huge CRLs
> 
> 
> 
> 
> Peter Williams wrote:
> 
> > > > Ed Gerck wrote:
> > > >

SSL was designed before certificates were added. Also, if you 
want to make an SSL (2) implementation without support
for the certs messages you can. Client auth is/was not
a required feature. Certs were not intrisic to SSL design.

Thats all Im trying to say. Lets not parse my English
for its philosophical roots.

---

From: Michael Sierchio <[email-masked]>
Date: Wed, 15 Sep 1999 17:59:42 -0700

> server exactly because SSL does not ignore certificates (would that qualify as involve?).

Peter's definition of a careful reading means that he believes that
no reasonable person can be at variance with his understanding.
Lord knows what he means by design.  SSL exists precisely because it 
was implemented before some IETF task force got its paws on it.  

-- 

Michael Sierchio <[email-masked]>

QUI ME AMET, CANEM MEUM ETIAM AMET.

---

From: Ed Gerck <[email-masked]>
Date: Wed, 15 Sep 1999 18:42:46 -0700

Peter Williams wrote:

> > Peter Williams wrote (in part):
> >
> > Sorry to disagree in part, Peter, but the client knows which CAs
> > are acceptable to the server exactly because SSL does not ignore
> > certificates (would that qualify as involve?).
>
> SSL was designed before certificates were added.

It shows that.

Cheers,

Ed Gerck

---

From: Ed Gerck <[email-masked]>
Date: Wed, 15 Sep 1999 19:05:40 -0700

Stephen Kent wrote:

> you, Ed?

The news is that I have assumed that SSL was better known.  What you say is
theoretical and NOT allowed by SLL protocol because there may be no path
known to the client -- even though a path might have existed to the client if
SSL would allow the client to propose a hit list to the server, which however the
server is allowed to do towards the client under the same SSL. Capice?

So, the server can send a message with a list of distinguished names  in the
SSL "certificate request" message to the client.  However, there is no corresponding
list that can be sent in the other direction (from the client to the server) in the
SSL protocol.  The effect of this **SSL asymmetry** is that  SSL does not allow
the client to check revocation lists that are meaningful to the client.

> (By the way, you continue to equate SSL with the cert processing

No, you are perhaps just reading my text segment too narrowly.  The basic
asymmetric fact here is that, using SSL, the client knows which CAs are acceptable
*to the server* for signature validation and CRL verification because the server
*sends* a list of distinguished names in the **SSL** "certificate request"
message. However, there is no corresponding list sent in the other direction in
SSL (from the client to the server).  Thus,  the server is essentially groping in the
dark when trying to supply a certificate that the client can check for its CRL,
because the server is not informed by the client what CAs to best aim for in a
ranking list  (CAs that are directly trusted by the client for signature and CRLs,
untrusted CAs directly trusted by a CA that the client trusts, etc.).

So, SSL denies to browsers what it allows to servers -- to choose who to
trust for what.  Which has the other consequences I wrote below:

> >what, and since this also translates into an anti-competitive issue built
> >right into the SSL protocol, I see then that the decision of trust is, from the
> >firstmoment, removed from the client. Both for certificates and for CRLs -- which
> (not SSL) cert processing

The browser is rendered powerless by the absence of an SSL "certificate
request" message for the client -- though SLL has it for the server, as I
excplained.  So, I disagree with your assertion. This dog won't hunt because
it is tied up.

>
> >So, where should the client look for the CRL? At the CA site that the
> >client does not trust?  Or, cannot reach?  What URL? How about
> > redundancy, alternatives?
> >
> >allow the client to check revocation lists that the client trusts -- so
> >they are near to useless. Also, the client is  not able to check server certificates
> >(and certificates in the CA chains) against client-defined revocation lists
> > (VAs, for example).
> >
>

What you say shows that you know where to find the CRL for a cert. Now, before
you wade through that (huge) CRL, it may be useful to ponder what is the worth of
checking distrusted CRLs?

As I wrote some two years ago (URI certover.pdf) and still valid even

So, if we agree that checking distrusted CRLs is as worthless as
checking distrusted certificates, then I guess we agree that knowing
where to look for a CRL you distrust is worth nothing.

And, clearly, a confirmed conversation with a thief is not secure just
because it is confirmed by the thief himself. Nor, by his associate ;-)

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Sep 1999 07:06:53 -0400

Ed,

>which I must say does not happen so often ;-)

Irrespective of whether you and Ben agree, SSL does not specify cert & CRL
processing.  Even the recently released https I-D does not specify cert
validation behavior, though it probablky should.  So, when you say that
"SSL does not check revocation lists" that is vacuously true, in so far as
SSL specifies no form of cert validation, including CRL processing.  What
you are commenting about appears to be observed behavior of SSL in commonly
available browsers, as I said.  Note that several vendors provide plug in
software for web severs which does check CRLs, and which performs more
extensive cert validation that than offered by the server software. This is
consistent with the fact that SSL, per se, does not address these details,
but rather is a protocol spec that happens to carry certs and relies on
other software to validate them.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Sep 1999 08:24:21 -0400

Peter,

>breaking the architecture though; on well, purity has no value of

I was speaking of SSL v3 and TLS v1, the current specs.  There is a very
definate certificate awareness in these protocols, for transport of server,
CA, and client certs.  Yes the key generation method is independent of the
use of certs, although it is heavily oriented toward public key crypto, and
biased toward the use of RSA (which was the focus of SSL v2, I believe).

>all have security protocols built over and above SSL layer protocols,

You and I differ on principles here.  I don't consider implementations to
be protocol specs.  If I did, then I would have to say that the early
versions of SSL were seriously flawed because Netscape used a terrible
PRNG.  In reality, it was the early IMPLEMENTATIONS that were flawed in
this fashion.

>integrity/confidentiality keys.

SSL already defines a multiple session continuity facility, i.e., the
handshake accommodates both new and resumed sessions.  Are you referring to
some other feature?

>are gaining wide acceptance.

The IETF is pretty good at certificate stuff, and to the extent that we are
talking about how certs and crls are used to support SSL/TLS, I think that
fair game for and IETF WG, should it wish to do so.  Eric's initial SHTTP
draft suggests a step in that direction, but it clearly does not cover much.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Thu, 16 Sep 1999 06:00:32 -0700

Stephen Kent wrote:

> Ed,
>
> Ed Gerck wrote:
> >No, Steve, I am not confusing either or even both ;-) Pls check the list
> >archives for my exchanges with Ben on this thread, especially those with
> >subjects "Re: Trust and client choices, was Re: Huge CRLs".  At least,
> >Ben and I agreed -- which I must say does not happen so often ;-)
>
> processing.

Since this simple discussion is now metagrobolized, let me first note that
it is a common misconception to think that SSL is a socket protocol that
does not care about what is transported, just because it is called
"Secure Socket Layer" ;-) As we know, names used in Internet protocols do
not need to mean what they mean elsewhere, not even in other Internet
Protocols ;-)  SSL is  NOT a socket protocol as the name might indicate and
SSL states fully depend on what was and is being transported in the session
-- SSL is a layered protocol with *stateful* sessions that depend on
transported content.  And, as with any state machine, you may recognize a
Turing machine and yes, guess what... it processes information.

As you can read in http://home.netscape.com/eng/ssl3/3-SPEC.HTM#7-6-4
the client knows which CAs are acceptable to the server exactly because SSL
allows the server to send an SSL message with a list of distinguished names  in the
SSL 'certificate request' message to the client:

   If the server has sent a 'certificate request' message, the client must send either the
   'certificate message' or a 'no certificate alert'.

where the names within single-quotes are *SSL messages* processed and
sent according to * SSL states*.  Further, Section "7.6.4 Certificate request" of
the SSL spec says:

     A non-anonymous server can optionally request a certificate from the client, if
     appropriate for the selected cipher suite.
...
     Note: It is a fatal 'handshake_failure' alert for an anonymous server to request client
     identification.

which means that SSL changes state and aborts the protocol based on an invalid
certificate request performed by the driving application -- so, SSL is aware of what
was transported in the past and reacts to it in the present. It has processed that
information using its states as memory.

Now, if SSL would be just a "socket protocol" that would ignore the content encoded
in whatever is being transported, including certs which would be just bits, then this
fatal alert would not even be able to exist, no?

And this is oftentimes a second misconception here: SSL is not HTTPS but
HTTPS uses SSL, so HTTPS is not stateless as HTTP.

Further, as I noted in this thread, this is what makes SSL *cause* the CRL
verification problem for the client since there is NO corresponding list sent in the
other direction (from the client to the server) allowed by the SSL protocol.  The
effect of this *SSL asymmetry* in dealing with certificates is that which I
summarized in my first message. Which is detrimental to the client's capability
of verifying CRLs.

> Even the recently released https I-D does not specify cert
> SSL specifies no form of cert validation, including CRL processing.

Your usage of the words "vacuously true" is disingenuous.  I did provide
a URL with the context for my short comment, since my intention was
to show that my comment in that URL (already visited more than 90,000
times and published in short form in a book by McGrawHill) can be
direclty applied also to CRLs  -- as a second-order choice that the client
is however denied to make under SSL. This is that text, now inlined:

(ii) The client needs to accept the server CAs' key signatures, usually
in a list that may include an unknown (i.e., untrusted) CA if that CA is
trusted by a CA that the client trusts, and so on to a possibly large
depth starting from only one known CA -- otherwise, the client has the
choice of terminating the connection, which is hardly a choice (i.e., no
alternative). However, a good certificate list could decrease, clearly, the
number of untrusted entries (and, risk) in such a chain. Further, the job
of providing a good certificate list is more challenging for the server
than it would have been for the client -- the server is essentially
groping in the dark because it is not informed by the client what CAs
to best aim for in a ranking list (CAs that are directly trusted by the
client or, untrusted CAs directly trusted by a CA that the client
trusts or, etc.). The client, however, would know which CAs are
acceptable to the server because the server sends a list of
distinguished names [2] in the "certificate request" message. Note
that there is no corresponding list sent in the other direction (from
the client to the server).

> What
> extensive cert validation that than offered by the server software.

What is the worth of checking a CRL from a distrusted CA for CRLs? Note also
that the CA may be trusted for signing but not for CRLs, as I commented before.

> This is

You seem to believe that SSL is a socket protocol that "carry things". It ain't,
in spite of the name. It recalls things that it carried before in the session and it
reacts to requests also in terms of that session's past.  It is easy to see that SSL
in fact validates positively or negatively what other software wants to do
after they validate or not a cert.  *Other* software thus also rely on SSL to
validate their actions in terms of those certs, not only the other way around
as you wrote. Who watches over whom is an interesting question here, and
one which is IMO well-solved to a large extent in SSL.

To close, I wish to note that IMO SSL is a very interesting protocol and my
comments to its unfortunate asymmetry in regard to server certs and CRL
bullying to the client are not to be seen as a dismissive treatment of SSL but
rather as a way to  help make it even better -- both by motivating changes
as well as by calling attention to the problems and possible workarounds.

Cheers,

Ed Gerck

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Sep 1999 10:43:33 -0400

Dan,

>But the importance of privacy and cryptography to financial services
>cannot be overlooked or ignored. It is no coincidence that the largest
>drivers of cryptography deployment have been banks and investment firms
>(and markets). Just recently, only banks were allowed to distribute
>greater-than-export strength crypto for their clientele.
>
>for a while now and still hasn't "taken off." Many of us believe that
>PKI as we know it isn't "it," and something else will inevitably turn up
>that succeeds where PKI failed. Vendors clearly haven't produced anything
>usable for this sector, leaving the firms themselves to develop
>next-generation security. And why shouldn't we be successful? We've done
>it before.  

In part, the problem is that the financial services environment is quite
diverse and thus no single characterization of requirements is appropriate.
One can argue that the current use of SSL and certs (even without CRLs!) to
secure access for home banking, online tradeing, and online porfolio
management are all "financial service" applications and this use works well
enough to have spurred very significant activity in these areas.  By that
measure, the problem is solved :-).

SET makes very limited use of CRLs, because its design does not require
much in the way if propogating revocation data, vs. local checking.  It
would seem that that financial app doesn't pose requirements that exceed
the capabilities of the existing CRL mechanisms.  On the other hand, one
can certainly define PKI-based apps that pose such great demands on timely
knbowledge of cert status, and which involve such a large community, that
it may be very difficult, perhaps impractical, to meet these requirements
with CRLs in any form. In the final analysis, PKIs are not the solution for
all problems, though one generally derives great benefit from leveraging
standards and widely available products that meet those standards.

Steve

---

From: "Peter Williams" <[email-masked]>
Date: Thu, 16 Sep 1999 12:06:57 -0700

SET makes very limited use of CRLs, because its design does not require much
in the way if propogating revocation data, vs. local checking.

This was one of the design "flaws" found in the analysis of an early
(private) draft
when the thinking on CRLs, revocation and compromise handling was being
formed.

Processors and merchants are now a critical element in the propagation of
A/CRLs to
the client to address root key and CA compromise/rollover, and
address processor compromise.

SET design requires merchants and clients to do CRL checking. Let us be
quite
clear on this. And merchants are a critical point -
as the conduit for the transfer of infrastructure ARLs to the client.  They
control whether clients receive notice of infrastructure or processor
compromise.

SET has interesting msg relaying characteristics which affect security
flowing
from certs. Clients prepare two items of confidential material. One is
prepared
for the merchant, the other for the processor. Yet the client has only a
direct transfer
channel to the merchant, who also controls the flow of ARL/CRL information
to the client, and thereby the security of the preparation of encrypted
material to the processor.

I almost feel there is design principle lurking here. Never allow one of a
set
of recipients to control the flow of infrastructure revocation information
to
the originator.

SET is noticeably different to https design as regards use of certs
and the security properties of apps which become dependent on PKI -
and particularly as revocation and revocation protocol issues affect
security of multiple sessions relating to a single transaction.  https has
multiple (not merely 2) session support; encryption of a
single-transaction's elements can be conducted in parallel,
as with SET, but revocation information
can always be collected out of band from a source
that is controlled only by the originator, and there
can be  are multiple independent connections to transfer
or gather session-encrypted information.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Sep 1999 12:52:14 -0400

Ed,

<snip>

>[that are meaningful to the client].

SSL is an asymmetric protocol; it treats clients and servers differently,
as opposed to IPsec, which treats both ends a peers.  However, despite your
repeated protests to the contrary, it is not the case that SSL does not
allow clients from checking CRLs; it merely does not provide a mechanism
for transporting CRLs as part of the protocol.  Some protocols do provide
such a facility, e.g., IPsec and S/MIME, but even here this is an optional
facility.  Since one may fetch CRLs by various transport mechanisms, it is
not unreasonable to treat CRL transport as a separate facility.

<snip>

>with some SSL (TSL) quirks like the client-server certificate choice

The acronym is TLS, not TSL, unless you are referring to some protocol not
developed under the IETF umbrella.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 16 Sep 1999 13:11:08 -0400

Ed,

>certificate chain with different CAs.  This is the real-world issue here

I presume you mean not addressed in specific CA CPS.  That's a business
matter.  if clients demand this as a part of doing business with a CA, then
CAs will do it.  I'm not even sure how widely this is true, i.e., how many
CA CPSs have you reviewed in coming to this conclusion?

>the use of multiple CAs more difficult and so on.  So, back to point one.

Yes, Ed, you did say so! The triple-indented text above is yours.

Steve

---

From: Ed Gerck <[email-masked]>
Date: Fri, 17 Sep 1999 09:41:57 -0700

Stephen Kent wrote:

> as opposed to IPsec, which treats both ends a peers.

Yes, but let us not get into IPSEC now ;-) since IMO IPSEC also treats the
man-in-the-middle as a peer ;-)

> However, despite your
> for transporting CRLs as part of the protocol.

Yes, I believe we calmly agree that there is something fishy about SSL's
treatment of the client's "rights" compared to the server's.

But, as I see it, being forced to choose from one option is not an option for
*checking* -- and this is because I don't see a  trust-value in "trust me" or
self-declarations.  Trust is that which cannot be self-declared  -- as known in
business, trust is not simply given away, it must be earned.  The same
happens in a formal treatment of this subject when trust is as well-defined
as information in Shannon's theory, and not a bit more emotional -- please
see Peter William's book, page 194 and references.

>  Some protocols do provide

Yes, and IMO this is one the central ideas that need to be emphazised: a CRL
is not just an attribute of a certificate (ie, the cert is valid if not in the CRL).
A CRL is a  *different information token*, requiring a different channel if a
trust-value is to be assignable to it.

> developed under the IETF umbrella.

God forbid! No, it was just a simple mistype.  Thanks for catching it implicitly.

Cheers,

Ed Gerck

---

From: Daniel Alex Finkelstein <[email-masked]>
Date: Fri, 17 Sep 1999 12:59:30 -0400

Stephen Kent wrote:

> In part, the problem is that the financial services environment is quite diverse and thus no single characterization of requirements is appropriate. One can argue that the current use of SSL and certs (even without CRLs!) to secure access for home banking, online tradeing, and online porfolio management are all "financial service" applications and this use works well enough to have spurred very significant activity in these areas. By that measure, the problem is solved :-).
>

Yes, I was completely disregarding the penetration of cryptographic security into public domain (SSL-enabled transactions and, to a much more limited extent, the distribution of certificates from commercial CA's like Verisign et alii). This was not intentional. My sights were very narrowly focussed on inter- and intra-business applications, reflecting my personal interest.

>
> SET makes very limited use of CRLs, because its design does not require much in the way if propogating revocation data, vs. local checking. It would seem that that financial app doesn't pose requirements that exceed the capabilities of the existing CRL mechanisms. On the other hand, one can certainly define PKI-based apps that pose such great demands on timely knbowledge of cert status, and which involve such a large community, that it may be very difficult, perhaps impractical, to meet these requirements with CRLs in any form. In the final analysis, PKIs are not the solution for all problems, though one generally derives great benefit from leveraging standards and widely available products that meet those standards.

That's very important to us, especially as we have found that even slight deviations from standards may cause dramatic failures. And also, exploits into areas not addressed by standards can do the same. But standards have generally been designed along a technical line rather than a business line. This was well and good just to establish the technology, however as we identify business requirements we find that technology has tried to take the lead and isn't terribly applicable to our business models. Form follows function, if you will.

---

From: Ed Gerck <[email-masked]>
Date: Fri, 17 Sep 1999 10:07:06 -0700

Stephen Kent wrote:

> Ed Gerck wrote (in part):
> > The point I mentioned above is the delay between a need to revoke a
> > cert (which need is materialized at the CA as request to revoke, of
> > course), and the reflection of this need in a certificate chain with
> > different CAs.  This is the real-world issue here -- and one which is
> > not addressed.
>

All I could. I see that you have not seen one that does that either, otherwise
I am sure you would quote it.  Whether this is a business issue or not, I suggest
a litmus test:

Suppose you contract with a limo service to take any of *your potential clients*
from downtown to your shop, so that you rely on the limo to take *your clients*
to you and not to the a spoof shop or to the swamp,  but for which service the
provider would say -- "if I know that my limos which I provide to you as a paid
service are not going to your shop with your potential clients, either because
you tell me so or because I find it out, I am under no obligation to issue a
service revocation to my drivers within any specific time limit and may do so
as I happen to do it".  Would you contract it?

> Yes, Ed, you did say so! The triple-indented text above is yours.

But not the ending, Steve -- the "under the traditional CRL model" part is of your
vintage.  So, that is why I wrote that "requiring it won't be so useful", where you may
note the future tense of the phrase employed by myself. In other words, what I am
saying is that after we see all the shortcomings of the present CRL usage model
in actual protocols (as I summarized in that posting and you have by now agreed
that the cited problems do exist -- though you say that some of them are to be dealt
elsewhere), then I commented that it will not be useful to solve them by requiring
so and so.  One of the "so and so" that I disfavored was to check with a CA
before every transaction.

I hope it is clear now. There are problems, but requiring to check with a CA won't be
so useful to solve it.  And, of course, Kansas already went bye-bye -- the traditional
CRL model is in the past.

Cheers,

Ed Gerck