Subject: Re: IDP indirectCRL flag

From: "Aisenberg, Michael" <[email-masked]>
Date: Wed, 27 Jul 2005 08:00:25 -0400

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]]
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.

---

From: "todd glassey" <[email-masked]>
Date: Wed, 27 Jul 2005 06:14:49 -0700

Re: IDP indirectCRL flagThe key to this is a predefined practice model for its use. That means a fully defined process with a narrative and possibly swim-lane type audit diagrams. This is NOT a joke - if you want the Insurance Industry Auditors to buy off on the use model then you have to create it. The problem with PKIX is that this is really an IRTF effort  - PKIX needs end-use processes and models for the core IP's its created already.

Todd Glassey

   -----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.

---

From: DE Gustafson <[email-masked]>
Date: Wed, 27 Jul 2005 11:30:48 -0400

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.

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.
>