RE: nextUpdate

["Friedrichs, Paul (Contractor)" <FriedriP@ncr.disa.mil>]

Sharon,

I am very grateful for you help and time. Thank you.

All,

A general rant: Since when is "processing" part of a document standard
profile? Since when is (protocol, or in this case document) implementation
software design part of the IETF's area of responsibility? Why couldn't a
world-class developer be allowed to come up with a different approach to the
implementation? Is the IETF next going to take over FIPS 140?

(You can see how long I've been away from the details of PKI.) 

Obviously a great amount of excellent work went into RFC 3280. But I think
we are worse off having section 6 in it rather than as (excellent!)
*guidance* for relying parties (promulgated by some other mechanism). Since
none of this process is "seen" by anyone but the relying party (which is the
reason that I think it should not be in an RFC - it doesn't affect
interoperability, secure or otherwise), it wouldn't matter that it's in an
RFC unless someone starts mandating compliance testing. 

:-(

But since we've imposed upon ourselves the burden of testing for compliance,
we have control over how much harm we will inflict on ourselves. If (just
supposing) there were a truly obvious problem with the reference standard,
would we require compliance, thereby breaking every product? This isn't a
rhetorical question - If it's possible that we would not impose obviously
faulty criteria, why wouldn't we carefully consider fine tuning the
criteria?

RFC 3280 section 6 fails to satisfy what I see to be legitimate, general
business and DoD needs for PKI. It assumes there is no nuance in the
UNDETERMINED status case. It does appear to me that the authors explicitly
assumed authentication is more important than availability. UNDETERMINED
results in failure (of PKI). (Please don't get me wrong. I think RFC 3280
section 6 is astonishingly good. Any attempt at up-front design would fall
short of perfection. And I'm not claiming I could have done a better job. I
assure you, I could not have come close.) A nextUpdate 5 seconds in the past
for a certificate associated with a two-person, biometrically controlled
level four cryptographic module-protected private key that will be used for
a five cent transaction yields the same information as [fill in the other,
admittedly silly extreme]? It would be wrong to say the PKI already took
that into account. As I explained in my original message, nextUpdate is a
sudden crisis, unrelated to the lifetime of the CRL. And it's the relying
party, not the PKI, who is being shot at or going out of business. 

I'm not saying we should change RFC 3280. (It's too late.) I'm saying I
think we can and should be smarter about the test criteria we create and
use. Unless the PKITS testing criteria change, it looks as though GOTS
software will be required to be smarter than RFC 3280 section 6 because
PKITS will likely break existing COTS alternatives. Can we change these
testing criteria, or does DoD have to spend more money on GOTS to have
reliable PKI capability? 

Anyone?

Thanks,
V/R Paul