Subject: RE: President Clinton digital signing

From: Ambarish Malpani <[email-masked]>
Date: Tue, 22 Aug 2000 18:26:26 -0700

Hi Tom,

It really isn't that hard to set up quite a few of the CAs to
create a new CRL whenever a new revocation happens.

Think of this CRL as a snapshot of the CA's revocation database
and the publishing of a new CRL as a trigger to tell the OCSP
server that the snapshot has changed.

Really, an OCSP server can be set up to be as current as any other
software to provide revocation information, either with or without
CRLs.

    It is completely unclear to me why the CAM solution is any
more real time than OCSP. I believe the real reason for the
CAM solution was just that OCSP didn't exist as a standard till
late in the ACES project as indicated by the mails from both
Judith and Tim. I have a suspicion that it still might be faster
and cheaper for ACES to go with OCSP, rather than try to stick to
a non-standard protocol.

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: Tom Strickland [mailto:[email-masked]]
> Sent: Tuesday, August 22, 2000 9:18 AM
> To: [email-masked]; [email-masked]
> Subject: Re: President Clinton digital signing
> 
> 
> You are correct to ask "why the US govt (GSA, at least) 
> dosent seem to want to
> embrace OCSP as a validation mechanism for ACES (and other 
> programs)??".
> You have to remember that ACES does have built in OCSP. The 
> product that they
> chose includes an OCSP "real time" responder, not antiquated CRLs.
> 
> Please review the following URLs to see how and why Xcert was chosen:
> 
> ACES announcement:
> http://www.xcert.com/corp/Press_Releases/2000-04-04-aces.html
> 
> Reference to digital signature law:
> http://www.xcert.com/resources/esign/index.html
> 
> Sentry CA functionality:
> http://www.xcert.com/software/sentryca.html
> 
> Scalability to manage over 8 million certs on one CA and box:
> http://www.xcert.com/corp/Press_Releases/2000-05-15-8million.html
> 
> 
> 
> [email-masked] wrote:
> 
> > this is very interexting, can somebody please comment on 
> why the US govt
> > (GSA, at least) doesnt seem to want to embrace OCSP as a validation
> > mechanism for ACES (and other programs)??   the 'CAM' as 
> they call it sems
> > to be an alternative mechanism....a duplication of much of 
> the work OCSP has
> > already worked through...
> >
> > -j
> >
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]]
> > Sent: Tuesday, August 22, 2000 8:52 AM
> > To: [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: RE: President Clinton digital signing
> >
> > Terri suggests that the real significance of the 
> certificate and smart card
> > used by President Clinton is that they were obtained 
> through the Access
> > Certificates for Electronic Services (ACES) contract at 
> GSA.  Through the
> > use of a Certificate Arbitrator Module (CAM), which is 
> effectively a parser
> > and validation tool (offered to public domain by GSA), 
> multiple CA's are
> > made available to the government applications.
> >
> > More info at
> >
> > http://www.gsa.gov/aces/
> >
> > To me, though, the most significant thing is that the 
> E-Sign bill was
> > signed, regardless of the technology utilized.
> >
> > Cheers,
>

---

From: Tom Strickland <[email-masked]>
Date: Wed, 23 Aug 2000 00:11:41 -0400

Hello Ambarish,

Thanks for your reply. I agree that OCSP services are by far better than
CRLs. In general, as everyone knows, a CRL is a batch job that updates a
database over certain intervals. From an audit standpoint, one of the many
issues with CRLs is that they can be beat. For example, it is very easy to
perform any series of denial of service attacks against the server. This
could cause longer than expected delays in the execution of the batch job
or worse, prevent the batch job from running causing latent (or corrupted)
CRL publishing. Also, if someone is savvy enough, they could also issue
hundreds of back to back CRL job requests resulting in multiple jobs
waiting on shared services again causing problematic CRLs. I know this may
sound farfetched but they are risks to be considered.

As you may guess I am not a proponent of CRLs for obvious reasons. I have
heard claims by some that their products are OCSP compliant. In reality it
is just a batch job publishing to a database but still they have inherent
CRL batch job latency.

As for the CAM, I am not familiar enough with that to argue for or against
its use. I do know however that the Xcert product has a non proprietary
real time OCSP LDAP out of the box resulting in a more robust product. Note
that the Sentry CA product can publish CRLs to non OCSP products to offer
backwards compatibility when needed. Also, the Sentry product can import
other vendors CRLs and place them in the real time OCSP LDAP.

Also one of the several reasons that Sentry CA was chosen was due to its
ability to cross certify against other CAs (cross certification). It is
very easy to setup trust to another company's CA allowing multiple CAs or
PKI vendors within a central Sentry OCSP environment.

Best regards,

Tom

---

From: "Liaquat Khan" <[email-masked]>
Date: Wed, 23 Aug 2000 09:44:46 +0100

You have to assume that access to the server which issues CRLs is protected
from denial of service attacks.  For example, generally only trusted
operators can authorise the generation of CRLs, after having their
identities authenticated by the server.  Also access to the CRL issuer has
to be protected through firewalls, etc.

If an attacker can perform a DoS attack on a CRL issuer, what is there to
stop him/her launching a similar attack on an OCSP server (e.g. by issuing
an extremely large amount of OCSP requests)?

Regards,
Liaquat Khan
Technical Manager
Global Trust Authority (GTA)

---

From: Tom Strickland <[email-masked]>
Date: Wed, 23 Aug 2000 08:31:12 -0400

Liaquat,

You bring up a very good point, DoS attacks are a risk in each environment.
However if your environment has critical need for current data (such as a bank
or government), then a CRL has a higher risk.

Example: If a company does not have a requirement for current information, a CRL
is sufficient. If a company requires real time data (i.e. a bank or government)
due to high value transactions or security, then I would highly recommend OCSP.
The risk is if you use CRLs for the latter, the company may get a false sense of
security believing their "high value" transactions are guarded by real time
data. If the batch CRL is latent, you may continue processing utilizing old
data. The risk is a cert believed to be revoked may still be considered good in
the system exposing the company to potential fraud or negligence.

In an OCSP environment, if you must trust real time data and someone executes a
DoS attack, the responder may slow down or worst case, stop working. This is an
added value because I would rather slow down or stop processing than to rely on
old data. The risk here is slower response time but guaranteed accurate
information.

This is a question that each company must answer by performing a risk assessment
to determine their acceptable level of "pain", risk and exposure.

I am not trying to be confrontational in my recent "typings". I am just trying
to bring added value to everyone here. As an auditor that has performed audits
on several PKI environments, I am just trying to help elevate certain risks that
sometimes get overlooked.

Best regards,

Tom

---

From: Sam Schaen <[email-masked]>
Date: Wed, 23 Aug 2000 08:42:08 -0400

If the DoS prevents the OCSP responder from receiving a CRL from which it determines
validity status, the result is the same.

---

From: Tom Strickland <[email-masked]>
Date: Wed, 23 Aug 2000 09:20:34 -0400

If you are using a mixture or hybrid OCSP environment to perform checking with an import
of CRL data, yes the result could be the same.

However, if you are using a true OCSP LDAP environment (i.e. no CRLs), part of your
system may slow down due to the DoS but the validity would always be accurate.

In the Sentry product, each Registration Authority (RA) has a built in real time OCSP
LDAP. This allows a complete OCSP enterprise without the need for any CRLs (unless you
want to cross certify a CRL from other non OCSP PKI vendors). This means that your risk
of DoS attacks may only slow down one leg (RA) or department of your PKI environment,
not the whole enterprise ensuring accurate real time information.

---

From: "Liaquat Khan" <[email-masked]>
Date: Wed, 23 Aug 2000 15:00:09 +0100

Tom,

I generally agree with you, but I think the issue of launching a DoS attack
on CRLs has been mixed in with the periodic nature of CRLs.  There are two
separate risks:

1) a CRL has expired and a new one has not been generated in time (e.g. due
to a DoS attack).  In this case the relying party should not really depend
on the CRL as it should be obvious from reading the available CRL that it is
out of date.  Therefore, certificates may have been revoked in the meantime
but there is no fresh CRL to check, so you abort the transaction.  This is
DoS.

2) a certificate is revoked but the next CRL is not due to be issued until
later.  Therefore, this scenario is not related to a DoS attack.  To
overcome this you need to ensure that CRLs are issued with a frequency which
is acceptable.  By using OCSP, it doesn't necessarily mean this issue goes
away...you will still need to work out how long it will take from the time a
decision is made to revoke a certificate to the time that the OCSP server
becomes aware of this (e.g. note that the OCSP server may be fed using
periodic CRLs).

Regards,
Liaquat Khan
Technical Manager

A relying
----- Original Message -----
From: Tom Strickland <[email-masked]>
To: Liaquat Khan <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, August 23, 2000 1:31 PM
Subject: Re: President Clinton digital signing

> > > > Architect
650.567.5457

---

From: "Jeff Spinney" <[email-masked]>
Date: Wed, 23 Aug 2000 10:00:09 -0400

I am uncertain that I would refer to an OCSP responder which imports CRL
data in order to give out real time cert status a 'hybrid'....CRLs wont be
going away completely anytime soon (nor do i think they were they intended
to), rather the 'audience' for them has changed ...from each individual user
to the OCSP responder.

	The OCSP responder is intended to be the public interface, speaking for the
status of certificates that have been issued on behalf of the CA.  It should
be closely related to the CA, that is there should be a secure channel for
publication of CRLs...however, it shouldn't necessarily be the CA itself.
Having an interface that only the CA can talk to minimizes a potential DoS
attack on that interface. In addition, it is beneficial to have some sort of
'secure' LDAP storage for issued certificates and crls, whether it is an
integral part of the OCSP responder (such as CertCo's CertValidator) or a
separate directory. Having some sort of central storage that can be accessed
by end users in the PKI (or their applications) is critical in having
encrypted email....

	Picture the environment where you wish to be able to take the CA offline
for either security or policy reasons.  The OCSP responder should be able to
speak for certificate status until the next update from the CA comes along,
it has the ability to keep the PKI operational while the CA is offline. In a
high value PKI, where it potentially takes some amount of time to bring
together those individuals who possess the distributed private information
needed to operate the CA, the OCSP responder should have the ability to
place the operational status of a certificate within its PKI on 'hold' as
defined in the rfc2560. This hold status is nearly instantaneous, for all
OCSP queries afterwards the status will be 'revoked' with a reason code of
'on hold'. Once the proper resources are brought together and the CA is
brought online, the certificate may be officially revoked by the entity
which originally issued it. When the CRL is issued, the status of this
certificate is moved to a permanently revoked state.

-j

-----Original Message-----
From: Tom Strickland [mailto:[email-masked]]
Sent: Wednesday, August 23, 2000 9:21 AM
To: Sam Schaen
Cc: Liaquat Khan; [email-masked]
Subject: Re: President Clinton digital signing

If you are using a mixture or hybrid OCSP environment to perform checking
with an import
of CRL data, yes the result could be the same.

However, if you are using a true OCSP LDAP environment (i.e. no CRLs), part
of your
system may slow down due to the DoS but the validity would always be
accurate.

In the Sentry product, each Registration Authority (RA) has a built in real
time OCSP
LDAP. This allows a complete OCSP enterprise without the need for any CRLs
(unless you
want to cross certify a CRL from other non OCSP PKI vendors). This means
that your risk
of DoS attacks may only slow down one leg (RA) or department of your PKI
environment,
not the whole enterprise ensuring accurate real time information.

Sam Schaen wrote:

> > > > real time OCSP LDAP out of the box resulting in a more robust
product.
> > > Note
650.567.5457

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Aug 2000 10:03:07 -0400

Tom,

>Thanks for your reply. I agree that OCSP services are by far better than

I think this is an over generalization, i.e., OCSP is bettr in some 
cases, but not in all cases.

>In general, as everyone knows, a CRL is a batch job that updates a
>perform any series of denial of service attacks against the server.

Which server? A directory?  A CRL has the advantage that it can be 
replicated at any numnber of servers, without imbuing these serves 
with trust (re integrity and authenticity).  While it is certainly 
true that one can engage in  a DoS attack against directories, the 
same is also true for OCSP servers. I don't think we have enough 
experience with both types of servers to determine if one is more 
susceptible than the other, as a class, or if it's just an issue of 
implementation and local management quality.

>This
>CRL publishing.

Batch job?  Now it sounds like your talking about a CA preparing a 
CRL.  A CA component generating a CRL need not be online and thus 
need not be very susceptible to DoS attacks, so I'm puzzled by this 
line of reasoning.

>Also, if someone is savvy enough, they could also issue

CRL job requests?  I've been involved with the design of several CAs 
over time and none offered an external interface which could be 
manipulated inthe fashion you suggest.

>is just a batch job publishing to a database but still they have inherent

The latency issue re CRLs is a red herring, in almost all cases. The 
time required to generate a CRL is fairly small for almost any PKI of 
a reasonable size.  The external, non-technical factors associated 
with deciding that a compromise has occurred or that an attribute has 
changed and thus a cert should be revoked almost always swamp the CRL 
production activity.

>other vendors CRLs and place them in the real time OCSP LDAP.

Oh, OCSp and LDAP?  That combination suggests an DoS opportunity that 
might be the sum of the two server interfaces :-).

>PKI vendors within a central Sentry OCSP environment.

No more product endorsements, OK?

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 23 Aug 2000 10:13:05 -0400

Tom,

>of CRL data, yes the result could be the same.

OCSP does not say how an OCSp server acquires the revocation 
information it relies on. Unless the server is tightly tied to a CA, 
CRLs would probably be the basis for the data.  Also, CRLs are the 
only standard means of acquiring such data from multiple CAs.

>not the whole enterprise ensuring accurate real time information.

In the model you describe, there would also seem to be a robustness 
issue, i.e., unless each RA replicates the OCSP server function, a 
portion of the cert space cannot be checked if the cognizant RA is 
offline. This also seems a bit odd, as the usual model for a PKI 
assigns the task of revocation to the CA, not the RA.

Steve

---

From: "Liaquat Khan" <[email-masked]>
Date: Wed, 23 Aug 2000 16:01:51 +0100

Tom,

Isn't it a good idea to generate CRLs anyway, even if you are using OCSP?
The main reason I have in mind is so that the CRL acts as a historical
record of when the certificate was revoked.
On the other hand, an OCSP response would only be sent subsequent to
receiving an appropriate OCSP request message.

Regards,
Liaquat Khan
Technical Manager

----- Original Message -----
From: Tom Strickland <[email-masked]>
To: Sam Schaen <[email-masked]>
Cc: Liaquat Khan <[email-masked]>; <[email-masked]>
Sent: Wednesday, August 23, 2000 2:20 PM
Subject: Re: President Clinton digital signing

with an import
accurate.
(unless you
that your risk
environment,
product.
650.567.5457

---

From: Tom Strickland <[email-masked]>
Date: Wed, 23 Aug 2000 12:22:36 -0400

Hello Liaquat,

Yes it is a good idea to save CRL data for historical purposes. My two cents,
for high availability cert checking, I would want to rely on an OCSP SSL-LDAP
instead of a CRL.
In a "best case" high availability OCSP environment, it would be even better to
have a mirror image server backing up the SSL-LDAP in real time. While this is
not needed (due to cost) by everyone, once again this depends on a company's
risk assessment.

---

From: Tom Strickland <[email-masked]>
Date: Wed, 23 Aug 2000 12:45:07 -0400

> but there is no fresh CRL to check, so you abort the transaction.  This is

I agree. However in several audit reviews of PKI infrastructures, I have always
seen the most recent CRL utilized as "good" regardless of the age. If all
enterprises mitigated this risk by checking and aborting transactions according
to age restrictions, this would be an adequate practice (until OCSP was the
standard, not the exception.)

> becomes aware of this (e.g. note that the OCSP server may be fed using

Once again you are correct. However "certain PKI products" have the OCSP
SSL-LDAP server integrated within the CA and RA. This ensures that once the cert
is revoked or suspended, the next instance that it is checked for validity (even
within seconds), it gives an accurate reflection of status without latency.

Best regards,

Tom