Re: nextUpdate

[Sam Roberts <sroberts@certicom.com>]

Wrote "Friedrichs, Paul (Contractor)" <FriedriP@ncr.disa.mil>, on Mon, Mar 01, 2004 at 05:07:45PM -0500:
> 
> 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?

A PKI validation algorithm that doesn't allow CAs to revoke certificates
is not very useful/secure.

In your case, you want to use a certificate, but you don't want to check
whether they have been revoked. There is no "nuance", there is just your
application using a certificate who's revocation status is unknown. As
an application design matter (application design **IS NOT** specified by
RFC3280), you probably should give your users the ability to say thats
OK. If its an automated system, you might want to have a configuration
variable ("ignore CRL status unknown errors"). That's up to you. But,
the NIST testsuite will at least guarantee that your app has the ability
to determine that the cert is not valid by the RFC3280 algorithm.  After
that, its up to the user.

What would you suggest, that RFC3280 document a validation algorithm
where one step is:

  - determine that you have no way of telling that the cert has been
	  revoked, but use it anyway

And you are mostly talking about CRL checking, but what about all the
other checks that can fail? What about a CA that doesn't have
BasicConstraints, is that OK with you? What about using a cert for
email, where it doesn't have have an alternative name bound to its email
address, is that OK with you?

Its hard to know what you think RFC3280 should do differently.

Do you think it should give a confidence rating, kind of like
SpamAssasin gives a Spam rating? That the user would configure their app
to only use certs above a certain rating, where positive check (found
current CRL, and cert wasn't revoked) would give it more points, and
negative checks (their was an intermediate CA, but it didn't have the
Basic Constraints extension) would give it negative points? That might
allow interesting "nuances" of trust, but it a very different kind of
PKI than X.509/PKIX!

RFC3280 doesn't say you can't use a cert if it's not valid.  But, they
do document an algorithm which can give you confidence the cert is
valid. There are other algorithms, for examle, you could phone the
person who's cert it is, have them read the SHA-1 digest of the cert, and if
it checks out, then you know you can trust the cert. That's not
an RFC3280 algorithm, though, and its not going to get standardized as
part of PKIX.

> 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

So you think a PKI standard should just document the format of a cert,
and whether or not an individual wants to trust that cert should be up
to them? In that case, ignore section 6, and NIST. How could anybody
standardize validation if that was the case, you can't standardize a
rule that says "use this cert if you determine its trustworthy"!

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

Certificates are a mechanism for using a trusted 3rd party to confirm
that some "identity" has the right to use a key pair.

In your example above, if you get access to a private key on a smart
card using your retina and a second person, that's great, the smartcard
trusts you to use the key, and will sign something for you. But, when
you send me email signed with that private key, and I can't check the
revocation status of your cert, I've no way of knowing that actually,
you and your buddy were fired last week, and don't work for the DoD
anymore, and I shouldn't trust anything you guys write me.

If its OK that its 5 seconds past the nextUpdate, what about 10 seconds?
What about 2 hours? What about 2 days? Where does it stop? Using PKIX,
that's up to the CA to determine.

This has some problems, I've worked on application where, because the CA determined
nextUpdate times are so far apart, the users want to not trust CRLs that
are older than a few days, even if they are within the official nextUpdate time.
This is an extra restriction beyond RFC3280.

Anyhow, I agree that CRLs are the weakest and most difficult to use part
of X.509 PKIs, but a PKI without revocation isn't really secure, so I
don't see your point in criticizing PKIX for requiring CRL checking. If
you don't have CRL checking, then you need another mechanism to revoke
certs, and I don't think you'd be enormously happy with a requirement to
check the cert using an on-line real-time certificate status protocol,
either!

Anyhow, thats my personal thoughts, I don't speak for my company, etc.,
etc.

Cheers,
Sam

-- 
Sam Roberts <sroberts@certicom.com>