RE: nextUpdate

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

Hello Sam,

> -----Original Message-----
> From: Sam Roberts [mailto:sroberts@certicom.com]
> Sent: Tuesday, March 02, 2004 9:50 AM
> To: Multiple recipients of list
> Subject: Re: nextUpdate
> 
> 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.

I don't understand. A validation algorithm can have no control over whether
a CA revokes certificates.

Aren't functional availability and reliability also security requirements?
Aren't they valuable? Is authentication the only security requirement, the
only value?

> In your case, you want to use a certificate, but you don't 
> want to check
> whether they have been revoked. 

Who said that? Are you replying to someone else's email? One wants to check
whether certs have been revoked. One "needs" to. But there's no relationship
between what is "necessary" and what is possible. There may be circumstances
when a user (whose needs we overlook at our peril), despite his best effort,
cannot obtain the latest CRL. 

> There is no "nuance",

Apparently there isn't a "nuanced" understanding of user requirements at
Certicom.

>  there 
> is just your
> application using a certificate who's revocation status is unknown.

Completely unknown? Have you ever actually had to *rely* on PKI for a
business process? (I don't mean to be impolite. I have found few users and
fewer vendors who are users that have real experience suffering with PKI.)
The danger of mission failure seems to force people to question the received
wisdom that there is perfect knowledge and then zero knowledge in the blink
of an eye. It's not true. There is a discontinuity, but it's not
infinity-to-zero.

>  As
> an application design matter (application design **IS NOT** 
> specified by
> RFC3280),

Specifying where error codes are required is design.

> you probably should give your users the ability to say thats
> OK.

I'm asking for something that sounds like this, but I'm not sure what you're
saying is OK after discarding ideas, earlier.

> If its an automated system, you might want to have a configuration
> variable ("ignore CRL status unknown errors").

I would not want to do this. That's less than I would want. I want from the
validation process security- and business-relevant information such as how
bad off am I (in the revocation status information department) and what
credential is being used (so I can measure the extent of the risk I am
taking if the same cert is being repeatedly used during this period of
status information down time).

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

Who cares? That's not a business requirement. It doesn't satisfy business
requirements. It *prevents* the satisfaction of business requirements. Are
these standards just self-licking ice cream cones? Or do they just lick each
other? (Sorry, I just heard this metaphor again recently.)

> After
> that, its up to the user.

It doesn't help. It withholds information the user may need to use.

> What would you suggest, that RFC3280 document a validation algorithm

The RFC claims to be a profile of a document standard. There should be no
algorithm in it at all.

> where one step is:
> 
>   - determine that you have no way of telling that the cert has been
> 	  revoked, but use it anyway

No. Just as it's irresponsible for anyone else to tell a replying party not
to use such a cert it would be irresponsible for anyone to tell a replying
party to use such a cert. It's a business decision, not a technical
decision.

In an CRL checking algorithm, instead of passing only "UNDETERMINED," I
would want it to say stuff like "UNDETERMINED," "nextUpdate 3 hours and 18
minutes in the past." And then in the bigger component, if all else is OK,
I'd want it to pass something like "UNDETERMINED," "nextUpdate 3 hours and
18 minutes in the past." (I suppose the module calling the validation module
would still have the certificate and would be the place to track reuse of
the certificate.) I don't much care whether we say the process "fails," but
I don't want the component to wash its hands of its responsibility to the
relying party as RFC 3280 does.

> And you are mostly talking about CRL checking,

This is a recurring, legitimate challenge. It is all I am talking about.

> but what about all the
> other checks that can fail? 

If something is incorrect _within_the_PKI_, then I think the relying party
should not accept the certificate. Network availability is not within the
PKI.

> What about a CA that doesn't have
> BasicConstraints, is that OK with you? 

Is there any possible reason that it might be in the relying party's
interest to do so?

In contrast, I know of many in DoD who require greater robustness when faced
with CRL checking challenges. 

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

You mean S/MIME v3? Sure. (Barring key compromise, etc.) the verifiable
originator of the message is the signer and the only possible reader of an
encrypted message is the entity named in the encryption certificate. Are you
suggesting the from and to in the email program are not less secure than
S/MIME and PKI? Are you saying, e.g., that someone might maliciously sign
someone else's message with their own key?

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

I explained it again above. I explained it before in the thread to which you
are responding.

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

I am only talking about revocation status age. There's no need to obfuscate.
:-) This is a practical, specific request based on a widespread need. It's
not a theological attack on all you hold dear.

It would, similarly, be irresponsible for the validation process designers
to impose "ratings" on facts that are useful in what would fundamentally be
a business risk decision. We can't make such calls. That's the whole point.
Your (funny :-) example shows that you don't get what I'm saying. We
technologists have to be more considerate of the business needs of our
users. We can't make business decisions for them. RFC3280 is. It, not my
recommendation, is comparable to your "ratings."

> RFC3280 doesn't say you can't use a cert if it's not valid. 

Does PKITS? The section I cited requires "rejection" of the certificate.
After the helpful exchange with Sharon, as I said, I think it is PKITS and
not RFC3280 where I hope we can keep from harming ourselves.

> But, they
> do document an algorithm which can give you confidence the cert is
> valid. 

Or stop the business. Is the whole world PKI? Is there no reality but PKI?

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

Who cares if we test an algorithm if the algorithm doesn't do what we need
to be done? 
 
> > 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,

One that claims to be the profile of that document standard? Yes. 

> and whether or not an individual wants to trust that cert should be up
> to them? 

Yes! Of course! Who else would the stakeholder be? Us? 

Again, I completely agree that guidance and products with known
characteristics are invaluable, but I think we're going too far if we tell
people they have to do their business a certain way. 

> In that case, ignore section 6, and NIST. 

I'm afraid DoD may have to put that in writing. That's what I'm trying to
avoid. It's not the PKI's call. 

> How could anybody
> standardize validation 

Why do we think no one can be smarter than we? This is implementation, not
interoperation. 

Why is standardized validation desired? I agree people should understand
their challenge. And I agree that people should understand the software upon
which they are relying. And I agree testing is a good way to understand
software (of this simplicity). And I agree that testing of multiple products
is more efficient if there is a standard test criteria. Once we're sure all
the kinks are out, I can see value in standardized products. But
standardizing on a sub-optimal design is not good. I say sub-optimal because
it is only looking at authentication. 

> if that was the case, you can't standardize a
> rule that says "use this cert if you determine its trustworthy"!

Why would that be in a standard? To support interoperability among a
security protocol's implementations, we would want to say what action is to
be expected at the other end, but that's different.
 
> > 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.

I wouldn't say it that way. The CA has no control over the entity's use of
the private key. (The CA has very little control.) There are no rights
involved. The certificate is a claim that no other entity can "possibly" use
the corresponding private key. 

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

(Having learned the hard way, I would say this is a poor design. I wouldn't
put privilege or affiliation claims in identity authentication certs. In
this case, the PKI should assert nothing other than that which it can
technically control, the smart card and its invocation mechanism. If the
person were discovered to be the Anthrax terrorist, and sent to prison for
life, the certificate still wouldn't need to be revoked.)

But given that scenario, that's your prerogative as the relying party, not
NIST's. 

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

That's the relying party's assessment, not NIST's. Any retail business owner
would understand this. Somehow it seems only PKI experts don't.

> Using PKIX,
> that's up to the CA to determine.

Wrong. First of all, the answer you are suggesting is "zero seconds after
nextUpdate," and that's "required" by RFC3280, not the CA. Are you saying
the CA can tell you one hour after nextUpdate is OK? But that would violate
RFC3280. Secondly, it's never the PKI who would make this call. (It's bad
enough that RFC3280 is.) The PKI is not the center of the world. The
primary, immediate value of PKI is at the relying party. I think we should
understand the relying party to be the center of this world. PKI has to make
complete sense to the relying party. A relying party can decide to accept
two hours past nextUpdate rather than frustrate customers. How can that be
NIST's call?

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

As I said earlier in the thread to which you are responding, the problem I'm
trying to address is entirely unrelated to how much time the CA chooses to
have between thisUpdate and nextUpdate. In real use, the relying party may
suddenly need a CRL it doesn't have and can't obtain. That's the specific
real-world problem I'm trying to address. 

> Anyhow, I agree that CRLs are the weakest and most difficult 
> to use part
> of X.509 PKIs, but a PKI without revocation 

The revocation happens. That's the second time you've confused revocation
with the relying party's knowledge of revocation. Relying parties might not
know that revocation has occurred, but can evaluate business risks
associated with the specific circumstance.

> isn't really secure,

You mean 100% secure versus 0% secure? Is that all there is? Binary? And
don't you really only mean X% authentication security versus Y%
authentication security? What about risk of denial of service? Many in DoD
are not using PKI because it is not providing adequate availability
security. Relying party software is unnecessarily vulnerable to DoS attack.

What if something were 80% secure but 10% reliable but another were 60%
secure and 70% reliable? What's the right choice? Who should decide? It is
the relying party's decision, not ours. I think it's meaningless to say that
something is or is not secure. The world isn't that simple. 

> so I
> don't see 

I'm not getting a comfy feeling about Certicom's products.

> your point in criticizing PKIX for requiring CRL 
> checking.

Where did I say CRLs should not be checked? 

> If
> you don't have CRL checking,

I'm not saying there would not be CRL checking. I'm saying it might return
"UNDETERMINED" with some information.

> then you need another mechanism to revoke
> certs,

I don't understand why you are repeatedly confusing revocation with the
relying party's ability to determine whether revocation has occurred.
Perhaps this is why I'm not being understood. The relying party must
understand that the CA may know ten seconds after creating a new CRL that in
the next CRL another certificate will be revoked. The CA has information
that the relying party can't. But "revocation" of that certificate occurs
when the CA issues that next CRL. After that, it's still possible that the
relying party can't obtain the CRL. In your scenario, the two people could
have been fired ten seconds after a CRL is issued. You shouldn't trust them
but you have no way of knowing. About the only thing that changes after
nextUpdate is the potential shift of liability. 

I know some options traders who would roll their eyes and chuckle at the way
we're treating nextUpdate.

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

You're right. That would be the same sort of thing - telling a relying party
what he has to do. Obviously, it is in the relying party's best interest to
try as hard and as long as it thinks it should, but at some point, it has to
make a decision. For the DoD, does it stop fighting a war? Does it stop
defending itself? Given the importance of action, but its understanding of
the risk, can it mitigate its risk? Yes, it can at least verify that a
certificate is authentic by chaining the cert without any revocation status.
That's better than nothing. It might decide it is enough. 

We're running into this same challenge architecting an enterprise services
environment for DoD. People are terrified of availability and reliability!
(And performance, and....) We've learned a great deal from (our mistakes
with :') the DoD PKI, which can be thought of as perhaps the DoD's first
enterprise service. This isn't mom & pop's email or SSL clients. This is
infrastructure. The "grid" supporting the next war could collapse if we
don't get this right. We don't have it right yet. 

If all U.S. military officers were wired like we security technologists are,
our military would be quivering in a fetal position in a dark corner. Risk
is something to understood and used, not avoided. 

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

Thanks. Given my specific recommendation for essentially nothing other than
passing time information with "UNDETERMINED" and passing both all the way up
to the validation process output, do we really disagree all that much? Would
you not agree with that recommendation?

Many Thanks,
V/R
Paul