Subject: Re: IDP indirectCRL flag

From: "Kazin, Joel" <[email-masked]>
Date: Wed, 27 Jul 2005 11:43:38 -0500

At 10:30 AM 7/27/2005 -0500, DE Gustafson wrote:

Hi All,

Like many (or few?) I've been devoting some of my copious free-time to
listening in on this debate.  My sense is that Denis may be on to something
but his ability to make progress on (at a minimum) completely defining a
"problem at hand" has not moved ahead smartly.  None will fault him for lack
of effort :-)

FWIW, real networks are beginning to see the operational problems that
indirect-CRLs could help solve.  For example, an Enterprise runs a CA system
that pushes out CRLs at high frequency (every couple of hours).  People have
been convinced that "more frequent CRL updates" is vitally important to
stronger/higher assurance security.  However, unexpected failures can
clearly gum up the works for some applications (e.g., smart card logon)
because, sooner or later, the CA is not able to push out a CRL on it's
appointed schedule, impacting secure applications.  In this case, sometime
after the CA goes offline all certificate-based computer and network logons
will fail (creating a variation of the dreaded one-fail/all fail scenario).
This condition will persist until a new CRL is issued and fetched by all
clients.  Newly appearing client logic that continues to use expired (but
not "too expired") CRLs sounds like a dubious approach/workaround but it's
existence may be giving a signal that this isn't the last time someone will
suggest a little standards-rework is needed in this area.  Clearly, the CA
(actually the configured CRL serving systems) will have to work their way
through a peak workload starting shortly after the CA goes back online.

Yes, has happen at least once.  Some CA's, Microsoft 2003, allow an
emergency CRL or delta CRL to be signed which simply extends the expiration
of the last available CRL or delta.  Of course this presumes that you still
have the ability to use the CA's private signing key to sign the emergency
CRL. There is a recent fix by Microsoft that allows one to issue a Group
Policy Object which will allow Windows Logon even though the latest
available CRL and delta have expired. It just ignores the fact that the CRL
and delta hve expired and performs all the other checks.

If your using OCSP or SCVP you might say the certificate is good even though
you really know only that it wasn't on the last or any prior CRL or deltas
and your last CRL has expired. That probably violates the respective RFC's.
No, I don't want to restart the past threads on good, bad, not known. 

In good theory, it would be nice to deploy a separate server (with separate
CRL-signing key) that could issue CRLs on behalf of the CA.  Better yet,
multiple servers (for redundancy), each with it's own signing key and each
able to issue a CRL that lists all certificates revoked by the CA.  This
would allow new CRLs to be published even though the CA might be down long
enough to miss a periodic CRL update event.  Likely there's at least one
application for all the different permutations, combinations, corner-cases,
etc. that might be supported by the current draft.

Has anyone fully considered how these capabilities will be used in practice
and identified any glitches (real or imagined) in a typical vendor's ability
to create truly more robust solutions?  Has that work been assigned,
implementor feedback fetched and processed, etc.?

More to the point, can someone articulate the apparent philosophical
disagreement over the basic requirements for any solution that this group
might embrace.  That is, Denis seems to be saying that CRL-Issuer Names, per
se, will never be crypto-pure enough with respect to their ability to point
to (identify) a particular CRL-issuer/signing key?  If that's what he's
saying, is that a real (undodgeable) technical issue (i.e., it never goes
away and is increasing problematic over time)?

Regards,

--dg

Aisenberg, Michael wrote:

Whatever RFC-based legacy arguments can be concocted here, the gravamen of
the utility of certs in a real world applied environment depends in no small
measure on the reliability (immediacy) of the CRL.  If we ever want to
achieve truly interoperable federated authentication regiemes usable, say in
Defense and NatSec environments talking to commercial environments, then we
had better figure out how to persuade RPs of the integrity of the CRL
process.

 -----Original Message-----
From:   Stephen Farrell [mailto:[email-masked]
<mailto:[email-masked]> ]
Sent:   Wed Jul 27 07:14:51 2005
To:     Denis Pinkas
Cc:     pkix
Subject:        Re: IDP indirectCRL flag

Denis,

> This procedural rule should be mentioned in the main body of the document.

That seems to go against the mitigate/supress approach you're advocating
in other messages to the list.

> However we are back with the vocabulary issue about "indirect CRLs" and
> "delegated CRLs".

IMO a sufficient set of technical concerns have been raised that
this isn't desirable for 3280bis.

And, given that it seems that no-one else wants this distinction, (at
least for now, at least as currently presented), is it really
worthwhile prolonging the discussion when the outcome is almost
inevitable?

Stephen.

Joel S. Kazin CPA, CISA, CISSP, CISM
Senior Consultant
Atos Origin
40 Old Sleepy Hollow Road
Pleasantville, New York 10570-3802
USA
Phone  +1 914-769-8780
Mobile  +1 914-564-1484
email    [email-masked]
www.atosorigin.com <http://www.atosorigin.com/>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 27 Jul 2005 13:51:41 -0400

This e-mail thread is mixing many themes and is causing confusion.  We are
discussing the following largely independent topics.
 
1.  Name collisions for direct and indirect CRL issuance
 
2.  Denis's proposal for extending/enhancing/changing the standard for
another class of indirect CRL.  This should be done via another extension.
 
3.  Gustafson's concern about SCL.  This can be accommodated by existing
mechanisms.  Denis's mechanism is not required.  Having said that it can be
accommodated, practically it will not work since MSFT clients require that
the certificate and CRL be signed using the same key -- so the question of
indirect CRL does not even arise.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kazin, Joel
Sent: Wednesday, July 27, 2005 12:44 PM
To: DE Gustafson; Aisenberg, Michael
Cc: Stephen Farrell; Denis Pinkas; pkix
Subject: Re: IDP indirectCRL flag

Hi All,

Regards,

--dg

 -----Original Message-----
From:   Stephen Farrell [mailto:[email-masked]]
Sent:   Wed Jul 27 07:14:51 2005
To:     Denis Pinkas
Cc:     pkix
Subject:        Re: IDP indirectCRL flag

Denis,

Stephen.